Jean-Yves Collot has examined my posted changes and has discovered a bug in the VMS_TRICKS.C
Where the old code was: int d[2] = { 512, (int) imgname}; I replaced it with: int d[2]; ... d[0] = 0; d[1] = (int) imgname; Where the interim fix would be for d[0] = 512;. This could will disable SMBD caching and possibly introduce a memory leak. I will not have time to address this before late tuesday evening at the earliest, so if you are using my posted code for testing, it will need this edit. The proper fix would be to change "d" to be of struct dsc$descriptor_s and completely fill in the descriptor values. When VFS modules are implemented, there should not be any need for this trick as the caching code would be contained in the VFS module, and only the SMBD loads the VFS modules. And I want to clarify that I am limited in what I can test, and what VMS versions that I can build for. I am concentrating on getting the current SAMBA releases for the 2.2.x, 3.x, and 4.x to build on the current OpenVMS version for ALPHA and IA64, and using only the minimum number of supplimental or replacement routines needed for this. The UNIX 2.2.x release is now up to 2.2.12 because of a security related patch that was just release. That is my next target. Since current versions of VMS support LDAP and Kerberos, I will also be phasing in support of this in future builds, along with the HP released version of OpenSSL. As the SSL is only for SAMBA to SAMBA connections, it's use would be a build time option. My preference is to default it as off. For building and linking on older versions of VMS, I want to positively identify exactly what suppliemental or replacement routines are needed for them, and why they are needed. Some of the stuff in earlier SAMBA releases was being carried around just to support versions of VMS that it was not even possible to run that version of SAMBA on. And even now there are comments that indicate an uncertanty of what replacement routines are needed or not. If there is something that needs to be enhanced or fixed in the current C RTL for SAMBA or other UNIX program, I would like to get that formally documented. Compiling on newer versions of VMS and then linking on older versions is risky and not supported by HP. Code must be compiled on the oldest version of VMS that it will be linked against. So if it is known at compile time that a hack/feature is not needed for the version that is being compiled on, then the build should take advantage of this. There are unsupported tricks to get around this, but they involve keeping private copies of selected files from the older VMS versions and setting a bunch of logical names, some of which are not publically documented. And this is not something that is easy to maintain. Especially since ECOs also affect this. Unless otherwise documented in the compiler documentation, redefining a reserved predefined macro can result in undefined operation at compile time. What you can get away with on one version/patch level of the compiler and VMS may not apply to any other combination. Reserved predefined macros typically start with a double underscore. The specific rules are in the ANSI documentation and in the HP C Compiler documentation. So the use of the compiler pre-defined macros is to allow programs built on a specfific version of VMS to take advantage of new features in the CRTL or the operating system, which should make the programs more efficient. Now if there is a strong need for LINKING on an older version of VMS than what the modules were compile on, and no one can volunteer to compile on that older version, then it may be possible to work out extra defines like #ifdef VMS_TARGET_V552 to flag the hacks needed to convince the compiler to generate the correct code. > > http://encompasserve.org/~malmberg/samba/ > > SAMBA_2_2_8-V82-SRC-20041003_BCK.ZIP, 5504 Kb, Sun Oct 3 20:14:54 2004 > Good Luck, -John [EMAIL PROTECTED] Personal Opinion Only PLEASE READ THIS IMPORTANT ETIQUETTE MESSAGE BEFORE POSTING: http://www.catb.org/~esr/faqs/smart-questions.html