I will need to read the old CMS books, but for MVS you¡¯ll need the list-versions of the macro¡¯s (MF=L) and map a getmained chunk of memory. Mike¡¯s original Rex interpreter code was reentrant assembler and had to deal with paging drums etc.
I am glad you found where the problem is, because its non-predictabilty nearly drove me crazy.
I wonder if, short of a compiler that generates reentrant code, the brexx interpreter cannot just be reloaded after external calls. PC DOS batch had a stub that reloaded the command processor if it was overwritten, for example; that only needs to be done when non-statically linked code overlays Brexx, like external commands. The part that implements ADDRESS maybe can do that.
best regards,
¸é±ð²Ô¨¦.
toggle quoted message
Show quoted text
My guess would be local as I don't see anything in the code to
indicate that would be re-entrant or designed to be loaded
resident, but I will defer to the current maintainers.? A shared
stack is usually created via a "GETMAIN" type call with uses
memory outside of program storage with its address stored in a
Control Block type construct.
Gary
On 2/25/20 10:53 AM, adriansutherland67
wrote:
On Tue, Feb 25, 2020 at 12:09 PM, gdblodgett wrote:
The DS in the MAINSTK statement means Define Storage.?
The 32000F states that variable 32000 "F"s in size.? With "F"
meaning a full word (4 bytes) aligned on a full word boundary.?
So it's 32000 x 4 = 128000 bytes long, aligned on a full word
boundary.?
So does this mean that the stack is local to each instance of the
program? I.e. if 2 programs link with GCCLIB will they have the
same stack, or not??
Presumably if the stack was defined as part of the GCCLIB loaded
resident then they would indeed share the same stack -
disastrously!
Thanks for any hints!
