There is no DMSREX module in VM/370. Ren¨¦ Ferland confirmed this.
The RESLIB command is used to load BREXX TEXT into resident storage. RESLIB itself is not documented in the official VM/370 documents, I just read the System Programmer¡¯s guide and the CMS Commands and Macros guide. It is documented by HELP RESLIB, and was written by Andrew Hanushevsky, Langmuir Laboratory, Cornell University in 1980.
The HELP RESLIB (MORE command states that every program that is loaded in this way, needs to be serially reusable (which is one step above/below reentrant/reenterable, depending on how you see it). This means BREXX may not have compiler initialized static variables. I wonder if GCC has an option to make sure it does not, and I would be more at ease if it was reentrant.
The loading is done for each VM/user by an exec called SYSPROF EXEC. I found out by doing a RESLIB DELETE GCCLIB, RESLIB DELETE DMSREX for my MAINT user, and trying to make it work again afterwards. It did not, because the botched builds left a wrong SYSPROF EXEC on MAINT¡¯s A disk, or that is what I think.
As soon as I found this, and deleted the one on the A disk, the one on the V disk is executed at logon and the info is correct again. Interestingly, the modules GCCLIB and DMSREXX are loaded at different (virtual) address in different userid¡¯s. Then I remembered that the release notes for Sixpack 1.2 say:
? During initialization, CMS executes "SYSPROF EXEC" before executing "PROFILE EXEC". This allows you to ensure certain commands are always executed for users.
These commands are the RESLIB commands for BREXX; it then chains SYSPROX EXEC for the mecaff programs.
I¡¯ll keep you posted on more progress, for example whe I find out how the exec processor finds it is a REXX exec, which is rather anachronistic for this level of VM.