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...