We have been able to get SMBD to work under the TCPIP Aux Server environment - multiple server processes - automatically - and access from multiple clients simultaneously. So now the next challenge is to reduce the number of shared images so we can then have SMBD and NMBD run with minimal impact on a server - reduce or minimize sysgen parameter changes.

Then the testing and debugging will continue more evenly as we move forward.

Need to find, isolate and fix a bug a day for a while. Not too much issue finding. The isolation is a bit more of a challenge as well as getting a fix in a day.

Also need to start developing the new VMS specific ACL code.

Also utilities need to checked out and tested.

No attempt will be made to get the Python extension working - at least not on first blush.

And I need to start working on a paper about this port for the OpenVMS Boot Camp being held in late September in Nashua, New Hampshire.

See you there!

We can CREATE files! Yes, that's right. Create files! View files! Create new folders! Navigate a share.

Now this has all been in "single" process mode. But it is definite progress!

Currently we are working on getting this version of Samba (4.3.6) to running under the HPE TCPIP Auxilury Server (this is similar to the inetd environment of Linux/Unix). Various issues have to be addressed, the invocation under the AUX server does not use stdin as its base socket, but relies upon the server to create a socket with a special "protocol family" type - TCPIP$C_AUXS. There are also issues with the code as it has come to us in that it does not like doing the DEBUG logging in this mode until after a certain point - which we still have to isolate, document and resolve.

Many things still to be done.

Onward.

Bill.

We have some nice progress...

Have been able to get the code to a point where I can navigate the folders in a share and also open and display a file. Yes, progress.

And then I tried to create a file... Oops! Well, not really surprising that code path has not been excised yet and many issued need to be checked. Looks like an issue with some of the talloc code possibly - that was the comment in the log file. So will dive into that soon.

Nice to see the progress and get the reward of seeing the navigation and the display.

Bill.

Well, the fact that they do not fall over and crash immediately is more like the truth. I have successfully compiled and linked an initial incantation of Samba 4.3.6 on OpenVMS I64 8.4.

Now the fun stuff has started! Looking through the reams of log files - thank you Samba developers for DEBUG - and finding errors. And then fixing those errors and going to the next iteration of the port. Also as I work through this then I also will continue to turn on more and more options along the way.

It is still very early in this port. There are thousands of files; some will never need to be looked at initially, thank goodness, as they will just compile and run. Others have already been taking time and finding bugs in the OpenVMS CRTL - nothing new there. Thankfully there have been some workarounds already available - except for a tweak here and an tweak there.

One major point that needs to be considered - until there is a fix for CRTL bug dealing with AF_UNIX sockets and bind() - is the "collision" of routines in a couple routines that deal with IO on VMS to support unix/linux style IO - the issue of open(), close(), select(), poll(), bind(), socket() and such that need to play with all devices - terminals, sockets (of all types), pipes, etc. I am hoping to avoid this with having isolated calls, but it may need to be unified - and then of course torn apart to some extent when/if the CRTL fix is released. But of course the issue of supporting older versions of VMS plays there as well.

Anyway, off to a side project while Samba builds in the latest fixes I have implemented.

Have started testing and debugging with the code that runs on OpenVMS.

Have been working through issues with logic and concept - not necessarily final concept/configuration but enough to let code run.

Am not further along than I was awhile back before starting the implementation of the VMS specific framework into the Samba environment. I have read the smb.conf file and am starting to execute code past that setting up the Samba environment.

I have fixed some issues in the vms_security module which did not make sense as far as the initial operation of Samba and updated some issues I saw as well before starting the nightly build.

Yes, nightly build. The build currently takes about 8 hours on VMS on a rx2600 running OpenVMS 8.4. While I have not gone and started any analysis to determine WHERE this cost in time is occurring I have my suspicions.

The cost of creating a process in OpenVMS is fairly expensive. More than opening a file by many times. The cost of image activation is expensive as well. And then I am using Python and Perl; they are part of the build environment, and to not use them is more expensive in terms of re-engineering the build process. But to find a way to get more performance out of them would be very useful.

And of course the issues of how GNV works on OpenVMS - that too is a potential issue as far as performance. For example, to get Python or Perl to properly invoke GNV/Bash as an exec'd process requires the invocation of bash reading a script file which then has the necessary commands. So given a build from GNV the following tree is to be expected:

DCL->bash->python->bash->(cc/ld)->DECC

That is sort of the minimal view

DCL->bash->python->Dbash->python->bash->(cc/ld)->DECC

or even:

DCL->bash->python->bash->python->bash->perl->bash->(cc/ld)->DECC

So we can have from 5 to 10 or more processes invoked at any one time as part of the process of executing the build process associated with the WAF build environment implementation on OpenVMS. The issue being the need to create a DCL based process to them invoke a new image of bash and have it then execute a script file. If there were a way to create a process where the "command interpreter" was bash rather than DCL then that could effectively eliminate as many as three process creations in a chain of processes. It could also eliminate the creation of two or three temporary files used to create the required temporary scripts to drive the process.

Another saving could come about if we could create a mechanism of reusing processes in this environment. That is to say that at least we might be able to eliminate one of the process creations by having the initial invocation of bash from Python as being persistent. It is not clear how one might make this happen or even how one might extend this to other levels of the process tree at present.

While these issues and ruminations are interesting the more interesting is that we are moving forward with the port...

Check back occasionally...

Thanks!

Best,
Bill.