开云体育

Hi Dave,

that is good to know. Question then is, why does the MKBREXX EXEC build a BREXX MODULE. I still cannot build the BREXX TEXT.
Just to verify: when I mount brexx 191 as J, and run MKBREXX, the .TEXT modules go to my A disk. Is that correct? Or do they need to go to J? This is what MKBREXX assumes.
Do I need to link brexx 191 in a different way? What happens when you run it?

best regards,

搁别苍é.


> On 11 Feb 2020, at 10:22, Dave Wade <dave.g4ugm@...> wrote:
>
> Folks (especially Rene)
>
> There is no REXX MODULE because having a REXX module in CMS is pretty useless.
> In VM/370 CMS? MODULES are usually loaded at the same location in main store, in the start of the user area.
> So if you build REXX as a module whenever it calls a program that runs in the user area it overwrites REXX.
> RESLIB loads REXX at the top of storage and reserves the storage with a system flag.
> You can't easily build a module to do that as they load absolute (in R6 at least) and you don't know how big some ones VM is when you build the module.
>
> Dave
>
> p.s. yes I know some modules run in the transient space, but it doesn't help. It just makes things worse.
>
>> -----Original Message-----
>> From: [email protected] <[email protected]> On Behalf Of
>> rvjansen@...
>> Sent: 09 February 2020 20:15
>> To: [email protected]
>> Subject: Re: [h390-vm] building BREXX
>>
>> One piece of the puzzle is this:
>>
>> 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.
>>
>> best regards,
>>
>> René Jansen.
>>
>
>
>
>
>