|
I've been trying find/figure this out. A CMS module is of a certain length/size. How do I find out what that size is? Why? because I want to call another module, and have it load above the first one, rather than on top of the first.
A related question is: Do I need to specify a full word, or double word, or 4K page boundary as the starting address for the second module? I understand the first one loads at X'020000'.
What I have found so far is DMSMOD which GENMOD and LOADMOD come from. It seems there is an 80 byte record at the beginning of the MODULE which contains a number of values, which are stored in NUCON areas, and then written out to the disk file being created.
FSVIEW: DMSMOD ASSEMBLE H1?????????? Lines 112-150/725 F80[1-79]? FSVIEW V1.2.5
*? OPERATION??????????????????????????????????????????????????????????? 00112000
*?????????????????????????????????????????????????????????????????????? 00113000
*???????? GENMOD-?????????????????????????????????????????????????????? 00114000
*?????????????????????????????????????????????????????????????????????? 00115000
*???????? GENMOD ISSUES THE START (NO) COMMAND TO FINISH LOADING OF???? 00116000
*???????? OBJECT PROGRAMS. NEXT ERASE THE OLD MODULE IF IT EXISTS.????? 00117000
*???????? THE START AND ENDING LOCATIONS ARE DETERMINED FROM THE??????? 00118000
*???????? USER OPTIONS 'TO' AND 'FROM' OR BY DEFAULT. THE DEFAULT?????? 00119000
*???????? START IS THE ADDRESS OF THE FIRST LOADER TABLE NAME, THE????? 00120000
*???????? DEFAULT END IS THE CURRENT SETTING OF LOCCNT IN NUCON.??????? 00121000
*???????? AN EIGHTY BYTE RECORD IS WRITTEN AS THE FIRST RECORD OF THE?? 00122000
*???????? THE MODULE. THIS RECORD CONSISTS OF THE NUCON LOADER INFORMA- 00123000
*???????? TION. NEXT THE TEXT INFORMATION IS WRITTEN TO THE MODULE????? 00124000
*???????? FILE IN VARIABLE SIZE RECORDS UP TO 65535 BYTES. IF THE?????? 00125000
*???????? MODULE IS NOT FOR A TRANSIENT ROUTINE AND NOMAP WAS NOT?????? 00126000
*???????? SPECIFIED THE LOADER TABLE IS WRITTEN AS THE LAST MODULE????? 00127000
*???????? FILE RECORD. CLOSE THE NEW MODULE FILE AND RETURN TO THE????? 00128000
*???????? CALLER.?????????????????????????????????????????????????????? 00129000
*?????????????????????????????????????????????????????????????????????? 00130000
*???????? LOADMOD-????????????????????????????????????????????????????? 00131000
*?????????????????????????????????????????????????????????????????????? 00132000
*???????? LOADMOD CHECKS FOR THE EXISTENCE OF THE REQUESTED MODULE????? 00133000
*???????? THEN READS THE TEXT INFORMATION INTO THE LOCATIONS SET??????? 00134000
*???????? UP WHEN THE MODULE WAS CREATED. THE MODULE NAME IS??????????? 00135000
*???????? STORED IN THE APPROPRIATE NUCON LOCATION. IF THERE IS???????? 00136000
*???????? A LOADER TABLE RECORD IN THE MODULE IT IS READ INTO?????????? 00137000
*???????? THE LOADER TABLE LOCATION IN STORAGE. SELECTED LOADER???????? 00138000
*???????? INFORMATION IS STORED IN NUCON. RETURN TO CALLER????????????? 00139000
*.????????????????????????????????????????????????????????????????????? 00140000
...
FSVIEW: DMSMOD ASSEMBLE H1?????????? Lines 289-327/725 F80[1-79]? FSVIEW V1.2.5
STBUFF?? LA??? R0,10????????? GET BUFFER FOR FIRST RECORD?????????????? 00289000
???????? DMSFREE DWORDS=(0),TYPCALL=BALR??????????????????????????????? 00290000
???????? LR??? R9,R1????????? R9 IS BUFFER ADDRESS????????????????????? 00291000
???????? ST??? R9,DSKLIN+28?? PUT IN PLIST????????????????????????????? 00292000
???????? MVC?? 0(80,R9),STRTADDR?? MOVE LOADER INFORMATION TO BUFFER??? 00293000
???????? STH?? R8,TBENT-STRTADDR(R9)??? SAVE LDR TABLE COUNT??????????? 00294000
???????? MVC?? DSKLIN+32(4),=XL4'50' SET TO WRITE 80 BYTES????????????? 00295000
???????? LA??? R1,DSKLIN????? ADDR. OF WRITE PLIST????????????????????? 00296000
???????? L???? R15,AWRBUF???? ADDR. OF WRBUF??????????????????????????? 00297000
???????? BALR? R14,R15??????? WRITE FIRST RECORD OF MODULE????????????? 00298000
...
NUCON
...
FSVIEW: CMSHRC MACLIB F1????????? Lines 1285-1323/3391 F80[1-79]? FSVIEW V1.2.5
STRTADDR DC??? 1F'0'????????? MODULE STARTING ADDRESS?????????????????? 00252100
FRSTLOC? DC??? 1F'0'????????? MODULE BEGINNING ADDRESS????????????????? 00252200
LASTLOC? DC??? 1F'0'????????? MODULE ENDING ADDRESS???????????????????? 00252300
LOCCNT?? DC??? 1F'0'????????? LOADER LOCATION COUNTER?????????????????? 00252400
LDRADDR? DC??? 1F'0'????????? LOADER RETURN ADDRESS???????????????????? 00252500
LDRRTCD? DC??? 1F'0'????????? LOADER RETURN CODE??????????????????????? 00252600
PSW????? DC??? 1D'0'????????? USER'S STARTING PSW?????????????????????? 00252700
LDRFLAGS DC??? 1F'0'????????? LOADER FLAGS????????????????????????????? 00252800
PRHOLD?? DC??? 1F'0'????????? PSEUDO REGISTER COUNTER?????????????????? 00252900
TBENT??? DC??? H'0'?????????? INITIALIZE TABLE ENTRIES TO?????????????? 00262000
*???????????????????????????? ZEROES??????????????????????????????????? 00262100
...
So when I hexdump, sorry HEXPRINT the file, I get the following which I edited, inserting spaces between each fullword.
HEX??? RECORD: 000001? RECORDLENGTH: 000080???????????????????????????????????????????????????? ?
?????? ---- +--- -|-- --+- ---| ---- +--- -|-- --+- ---| ---- +--- -|-- --+- ---| ---- +--- -|-- --+- ---|----+----|
000000 .... .... .... .... ...O .... .... .... .... .... .... .... .... .... .... Z... .... .... .... ....???????? ?
ZONE?? 0000 0000 0000 0000 002D 0000 0000 0001 4800 0000 0000 0000 0000 0000 0000 E000 0000 0000 0000 0006???????? ?
NUMBR? 0200 0200 0258 0258 0156 0000 0000 001F 4003 0000 0300 0000 0000 0000 0000 9000 0000 0000 0000 00E9???????? ?
???? ? |STRTADDR |FRSTLOC? |LASTLOC? |LOCCNT?? |LDRADDR? |LDRRTCD? |PSW??????????????? |LDRFLAGS |PRHOLD?? |
?????? 00020000? 00020508? 000125D6? 00000000? 44800003? 00030000? 00000000 00000000?? 00000000? 00000000 ?
?????? 00020000? 00020508? 00000000? 0000011F? 00000000? 00000000? 00000000 E9000000?? 00000000? 00000E69
...
If I map NUCON variables to those fields, then I end up with LOCCNT having a value of 000000000000011F. Therefor the length of the module is X'011F' or 287 decimal bytes.
Am I close, or just totally lost in the woods, and I should send up a flare?
?... Mark S.
|
Mark, Not sure what you are planning, but if your program has issued any storage requests, the space at the end of the program will have been used to satisfy those requests so not available to load a second program. ? From what I remember there are two ways to load another program and not have it overlay your program. ? One is to use the transient program area. The other is to use an auxiliary directory as used by the assembler. ? In VM/CE we added the RESLIB & NUCXTXT commands which allow TEXT files to be loaded in high memory and called as commands. REXX is installed in this manner. ? Dave ? ? ?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]> On Behalf Of Mark A. Stevens via groups.io
Sent: Sunday, February 4, 2024 9:20 PM
To: [email protected]
Subject: [h390-vm] How Big/Long is a CMS Module? I've been trying find/figure this out. A CMS module is of a certain length/size. How do I find out what that size is? Why? because I want to call another module, and have it load above the first one, rather than on top of the first.
A related question is: Do I need to specify a full word, or double word, or 4K page boundary as the starting address for the second module? I understand the first one loads at X'020000'.
What I have found so far is DMSMOD which GENMOD and LOADMOD come from. It seems there is an 80 byte record at the beginning of the MODULE which contains a number of values, which are stored in NUCON areas, and then written out to the disk file being created.
FSVIEW: DMSMOD ASSEMBLE H1?????????? Lines 112-150/725 F80[1-79]? FSVIEW V1.2.5
*? OPERATION??????????????????????????????????????????????????????????? 00112000
*?????????????????????????????????????????????????????????????????????? 00113000
*???????? GENMOD-?????????????????????????????????????????????????????? 00114000
*?????????????????????????????????????????????????????????????????????? 00115000
*???????? GENMOD ISSUES THE START (NO) COMMAND TO FINISH LOADING OF???? 00116000
*???????? OBJECT PROGRAMS. NEXT ERASE THE OLD MODULE IF IT EXISTS.????? 00117000
*???????? THE START AND ENDING LOCATIONS ARE DETERMINED FROM THE??????? 00118000
*???????? USER OPTIONS 'TO' AND 'FROM' OR BY DEFAULT. THE DEFAULT?????? 00119000
*???????? START IS THE ADDRESS OF THE FIRST LOADER TABLE NAME, THE????? 00120000
*???????? DEFAULT END IS THE CURRENT SETTING OF LOCCNT IN NUCON.??????? 00121000
*???????? AN EIGHTY BYTE RECORD IS WRITTEN AS THE FIRST RECORD OF THE?? 00122000
*???????? THE MODULE. THIS RECORD CONSISTS OF THE NUCON LOADER INFORMA- 00123000
*???????? TION. NEXT THE TEXT INFORMATION IS WRITTEN TO THE MODULE????? 00124000
*???????? FILE IN VARIABLE SIZE RECORDS UP TO 65535 BYTES. IF THE?????? 00125000
*???????? MODULE IS NOT FOR A TRANSIENT ROUTINE AND NOMAP WAS NOT?????? 00126000
*???????? SPECIFIED THE LOADER TABLE IS WRITTEN AS THE LAST MODULE????? 00127000
*???????? FILE RECORD. CLOSE THE NEW MODULE FILE AND RETURN TO THE????? 00128000
*???????? CALLER.?????????????????????????????????????????????????????? 00129000
*?????????????????????????????????????????????????????????????????????? 00130000
*???????? LOADMOD-????????????????????????????????????????????????????? 00131000
*?????????????????????????????????????????????????????????????????????? 00132000
*???????? LOADMOD CHECKS FOR THE EXISTENCE OF THE REQUESTED MODULE????? 00133000
*???????? THEN READS THE TEXT INFORMATION INTO THE LOCATIONS SET??????? 00134000
*???????? UP WHEN THE MODULE WAS CREATED. THE MODULE NAME IS??????????? 00135000
*???????? STORED IN THE APPROPRIATE NUCON LOCATION. IF THERE IS???????? 00136000
*???????? A LOADER TABLE RECORD IN THE MODULE IT IS READ INTO?????????? 00137000
*???????? THE LOADER TABLE LOCATION IN STORAGE. SELECTED LOADER???????? 00138000
*???????? INFORMATION IS STORED IN NUCON. RETURN TO CALLER????????????? 00139000
*.????????????????????????????????????????????????????????????????????? 00140000
...
FSVIEW: DMSMOD ASSEMBLE H1?????????? Lines 289-327/725 F80[1-79]? FSVIEW V1.2.5
STBUFF?? LA??? R0,10????????? GET BUFFER FOR FIRST RECORD?????????????? 00289000
???????? DMSFREE DWORDS=(0),TYPCALL=BALR??????????????????????????????? 00290000
???????? LR??? R9,R1????????? R9 IS BUFFER ADDRESS????????????????????? 00291000
???????? ST??? R9,DSKLIN+28?? PUT IN PLIST????????????????????????????? 00292000
???????? MVC?? 0(80,R9),STRTADDR?? MOVE LOADER INFORMATION TO BUFFER??? 00293000
???????? STH?? R8,TBENT-STRTADDR(R9)??? SAVE LDR TABLE COUNT??????????? 00294000
???????? MVC?? DSKLIN+32(4),=XL4'50' SET TO WRITE 80 BYTES????????????? 00295000
???????? LA??? R1,DSKLIN????? ADDR. OF WRITE PLIST????????????????????? 00296000
???????? L???? R15,AWRBUF???? ADDR. OF WRBUF??????????????????????????? 00297000
???????? BALR? R14,R15??????? WRITE FIRST RECORD OF MODULE????????????? 00298000
...
NUCON
...
FSVIEW: CMSHRC MACLIB F1????????? Lines 1285-1323/3391 F80[1-79]? FSVIEW V1.2.5
STRTADDR DC??? 1F'0'????????? MODULE STARTING ADDRESS?????????????????? 00252100
FRSTLOC? DC??? 1F'0'????????? MODULE BEGINNING ADDRESS????????????????? 00252200
LASTLOC? DC??? 1F'0'????????? MODULE ENDING ADDRESS???????????????????? 00252300
LOCCNT?? DC??? 1F'0'????????? LOADER LOCATION COUNTER?????????????????? 00252400
LDRADDR? DC??? 1F'0'????????? LOADER RETURN ADDRESS???????????????????? 00252500
LDRRTCD? DC??? 1F'0'????????? LOADER RETURN CODE??????????????????????? 00252600
PSW????? DC??? 1D'0'????????? USER'S STARTING PSW?????????????????????? 00252700
LDRFLAGS DC??? 1F'0'????????? LOADER FLAGS????????????????????????????? 00252800
PRHOLD?? DC??? 1F'0'????????? PSEUDO REGISTER COUNTER?????????????????? 00252900
TBENT??? DC??? H'0'?????????? INITIALIZE TABLE ENTRIES TO?????????????? 00262000
*???????????????????????????? ZEROES??????????????????????????????????? 00262100
...
So when I hexdump, sorry HEXPRINT the file, I get the following which I edited, inserting spaces between each fullword.
HEX??? RECORD: 000001? RECORDLENGTH: 000080???????????????????????????????????????????????????? ?
?????? ---- +--- -|-- --+- ---| ---- +--- -|-- --+- ---| ---- +--- -|-- --+- ---| ---- +--- -|-- --+- ---|----+----|
000000 .... .... .... .... ...O .... .... .... .... .... .... .... .... .... .... Z... .... .... .... ....???????? ?
ZONE?? 0000 0000 0000 0000 002D 0000 0000 0001 4800 0000 0000 0000 0000 0000 0000 E000 0000 0000 0000 0006???????? ?
NUMBR? 0200 0200 0258 0258 0156 0000 0000 001F 4003 0000 0300 0000 0000 0000 0000 9000 0000 0000 0000 00E9???????? ?
???? ? |STRTADDR |FRSTLOC? |LASTLOC? |LOCCNT?? |LDRADDR? |LDRRTCD? |PSW??????????????? |LDRFLAGS |PRHOLD?? |
?????? 00020000? 00020508? 000125D6? 00000000? 44800003? 00030000? 00000000 00000000?? 00000000? 00000000 ?
?????? 00020000? 00020508? 00000000? 0000011F? 00000000? 00000000? 00000000 E9000000?? 00000000? 00000E69
...
If I map NUCON variables to those fields, then I end up with LOCCNT having a value of 000000000000011F. Therefor the length of the module is X'011F' or 287 decimal bytes.
Am I close, or just totally lost in the woods, and I should send up a flare?
?... Mark S.
|
On Sun, Feb 4, 2024 at 03:20 PM, Mark A. Stevens wrote: The following is wrong. If I could only count.
HEX??? RECORD: 000001? RECORDLENGTH: 000080???????????????????????????????????????????????????? ?
?????? ---- +--- -|-- --+- ---| ---- +--- -|-- --+- ---| ---- +--- -|-- --+- ---| ---- +--- -|-- --+- ---|----+----|
000000 .... .... .... .... ...O .... .... .... .... .... .... .... .... .... .... Z... .... .... .... ....???????? ?
ZONE?? 0000 0000 0000 0000 002D 0000 0000 0001 4800 0000 0000 0000 0000 0000 0000 E000 0000 0000 0000 0006???????? ?
NUMBR? 0200 0200 0258 0258 0156 0000 0000 001F 4003 0000 0300 0000 0000 0000 0000 9000 0000 0000 0000 00E9???????? ?
???? ? |STRTADDR |FRSTLOC? |LASTLOC? |LOCCNT?? |LDRADDR? |LDRRTCD? |PSW??????????????? |LDRFLAGS |PRHOLD?? |
?????? 00020000? 00020508? 000125D6? 00000000? 44800003? 00030000? 00000000 00000000?? 00000000? 00000000 ?
?????? 00020000? 00020508? 00000000? 0000011F? 00000000? 00000000? 00000000 E9000000?? 00000000? 00000E69
I think this should be: ...HEX??? RECORD: 000001? RECORDLENGTH: 000080???????????????????????????????????????????????????? ??????? ---- +--- -|-- --+- ---| ---- +--- -|-- --+- ---| ---- +--- -|-- --+- ---| ---- +--- -|-- --+- ---|----+----|000000 .... .... .... .... ...O .... .... .... .... .... .... .... .... .... .... Z... .... .... .... ....???????? ?ZONE?? 0000 0000 0000 0000 002D 0000 0000 0001 4800 0000 0000 0000 0000 0000 0000 E000 0000 0000 0000 0006???????? ?NUMBR? 0200 0200 0258 0258 0156 0000 0000 001F 4003 0000 0300 0000 0000 0000 0000 9000 0000 0000 0000 00E9???????? ??????? |STRT|FRST|LAST|LOCC|LDRA|LDRR|PSW????? |LDRF|PRHO|??????? ADDR LOC? LOC? NT?? DDR? TCD??????????? LAGS LD?????? STRTADDR? FRSTLOC?? LASTLOC?? LOCCNT??? LDRADDR?? LDRRTCD?? PSW??????????????? LDRFLAGS? PRHOLD?????? 00020000? 00020000? 00020508? 00020508? 000145D6? 00000000? 00000000 0000011F? 44800300? 00000000 ?...If I map NUCON variables to those fields, then I end up with LOCCNT having a value of 0000000000020508. Therefor the length of the module is X'0508' or 1288? decimal bytes. Am I close, or just totally lost in the woods?
|
On Sun, Feb 4, 2024 at 04:42 PM, Dave Wade wrote:
Not sure what you are planning, but if your program has issued any storage requests, the space at the end of the program will have been used to satisfy those requests so not available to load a second program.
There is a modules called RUNPARM and XRUNPARM, which is on the Y-Disk. There is also WMSASM from the CBT. All three are supposed to be a 'front end' for programs that are by nature MVS code. They take command line parameters and fix up the PLIST to be something the MVS program will be able to understand. My few examples show something like: RUNPARM MYPROG ... Where MYPROG is a MODULE. So I am attempting to set the load address for MYPROG to be beyond the end of RUNPARM. Do I really know what I am doing. Nope. Just trying to figure it all out. ?... Mark S.
|
Hello, When I was in college (Ohio University), I developed a technique to run multiple commands from one program.
Basically, I created a dynamic loader to load the control program.? Once the control program work? was complete, it would call the dynamic loader in unload mode.
The dynamic loader would obtain free storage at the highest available area (enough to run the control program). It would load the control program in this area and the transfer control to it.? ?This is the gist of it.? This method allows for a multi-tasking CMS using interrupts.
While at Cray Research, I used it to allow customers to run the various Cray CMS commands while also running one normal command (e.g. editor, compiler, etc.)
The thing is, customers came back wanting me to allow them to use multiple CMS commands at the?same time. This was beyond the scope of the Cray VM Station.? ?Running our commands at the same time and one normal CMS command was the directive.
Could one create an OS that looks like CMS and allows you to run both foreground and multiple backgrounds tasks.? Yeah!? Figured most of it out years ago, but who would fund it?? I can't.? IBM?? Maybe, if they even thought of it.
I talked to an IBMer about it while working for Cray.? He was speechless. I told him I developed the idea in college. He could use it, as the idea and technique were from my college days.? Obviously, the IBM VM team never pursued multitasking CMS.
Note:? It isn't meant to have a massive overhead for CP. It is meant to give users the ability to do things in parallel, not one command at a time.
The key would be in setting the requirements.?
Thanks.
Mark, Not sure what you are planning, but if your program has issued any storage requests, the space at the end of the program will have been used to satisfy those requests so not available to load a second program. ? From what I remember there are two ways to load another program and not have it overlay your program. ? One is to use the transient program area. The other is to use an auxiliary directory as used by the assembler. ? In VM/CE we added the RESLIB & NUCXTXT commands which allow TEXT files to be loaded in high memory and called as commands. REXX is installed in this manner. ? Dave ? ? ? ? I've been trying find/figure this out. A CMS module is of a certain length/size. How do I find out what that size is? Why? because I want to call another module, and have it load above the first one, rather than on top of the first.
A related question is: Do I need to specify a full word, or double word, or 4K page boundary as the starting address for the second module? I understand the first one loads at X'020000'.
What I have found so far is DMSMOD which GENMOD and LOADMOD come from. It seems there is an 80 byte record at the beginning of the MODULE which contains a number of values, which are stored in NUCON areas, and then written out to the disk file being created.
FSVIEW: DMSMOD ASSEMBLE H1?????????? Lines 112-150/725 F80[1-79]? FSVIEW V1.2.5
*? OPERATION??????????????????????????????????????????????????????????? 00112000
*?????????????????????????????????????????????????????????????????????? 00113000
*???????? GENMOD-?????????????????????????????????????????????????????? 00114000
*?????????????????????????????????????????????????????????????????????? 00115000
*???????? GENMOD ISSUES THE START (NO) COMMAND TO FINISH LOADING OF???? 00116000
*???????? OBJECT PROGRAMS. NEXT ERASE THE OLD MODULE IF IT EXISTS.????? 00117000
*???????? THE START AND ENDING LOCATIONS ARE DETERMINED FROM THE??????? 00118000
*???????? USER OPTIONS 'TO' AND 'FROM' OR BY DEFAULT. THE DEFAULT?????? 00119000
*???????? START IS THE ADDRESS OF THE FIRST LOADER TABLE NAME, THE????? 00120000
*???????? DEFAULT END IS THE CURRENT SETTING OF LOCCNT IN NUCON.??????? 00121000
*???????? AN EIGHTY BYTE RECORD IS WRITTEN AS THE FIRST RECORD OF THE?? 00122000
*???????? THE MODULE. THIS RECORD CONSISTS OF THE NUCON LOADER INFORMA- 00123000
*???????? TION. NEXT THE TEXT INFORMATION IS WRITTEN TO THE MODULE????? 00124000
*???????? FILE IN VARIABLE SIZE RECORDS UP TO 65535 BYTES. IF THE?????? 00125000
*???????? MODULE IS NOT FOR A TRANSIENT ROUTINE AND NOMAP WAS NOT?????? 00126000
*???????? SPECIFIED THE LOADER TABLE IS WRITTEN AS THE LAST MODULE????? 00127000
*???????? FILE RECORD. CLOSE THE NEW MODULE FILE AND RETURN TO THE????? 00128000
*???????? CALLER.?????????????????????????????????????????????????????? 00129000
*?????????????????????????????????????????????????????????????????????? 00130000
*???????? LOADMOD-????????????????????????????????????????????????????? 00131000
*?????????????????????????????????????????????????????????????????????? 00132000
*???????? LOADMOD CHECKS FOR THE EXISTENCE OF THE REQUESTED MODULE????? 00133000
*???????? THEN READS THE TEXT INFORMATION INTO THE LOCATIONS SET??????? 00134000
*???????? UP WHEN THE MODULE WAS CREATED. THE MODULE NAME IS??????????? 00135000
*???????? STORED IN THE APPROPRIATE NUCON LOCATION. IF THERE IS???????? 00136000
*???????? A LOADER TABLE RECORD IN THE MODULE IT IS READ INTO?????????? 00137000
*???????? THE LOADER TABLE LOCATION IN STORAGE. SELECTED LOADER???????? 00138000
*???????? INFORMATION IS STORED IN NUCON. RETURN TO CALLER????????????? 00139000
*.????????????????????????????????????????????????????????????????????? 00140000
...
FSVIEW: DMSMOD ASSEMBLE H1?????????? Lines 289-327/725 F80[1-79]? FSVIEW V1.2.5
STBUFF?? LA??? R0,10????????? GET BUFFER FOR FIRST RECORD?????????????? 00289000
???????? DMSFREE DWORDS=(0),TYPCALL=BALR??????????????????????????????? 00290000
???????? LR??? R9,R1????????? R9 IS BUFFER ADDRESS????????????????????? 00291000
???????? ST??? R9,DSKLIN+28?? PUT IN PLIST????????????????????????????? 00292000
???????? MVC?? 0(80,R9),STRTADDR?? MOVE LOADER INFORMATION TO BUFFER??? 00293000
???????? STH?? R8,TBENT-STRTADDR(R9)??? SAVE LDR TABLE COUNT??????????? 00294000
???????? MVC?? DSKLIN+32(4),=XL4'50' SET TO WRITE 80 BYTES????????????? 00295000
???????? LA??? R1,DSKLIN????? ADDR. OF WRITE PLIST????????????????????? 00296000
???????? L???? R15,AWRBUF???? ADDR. OF WRBUF??????????????????????????? 00297000
???????? BALR? R14,R15??????? WRITE FIRST RECORD OF MODULE????????????? 00298000
...
NUCON
...
FSVIEW: CMSHRC MACLIB F1????????? Lines 1285-1323/3391 F80[1-79]? FSVIEW V1.2.5
STRTADDR DC??? 1F'0'????????? MODULE STARTING ADDRESS?????????????????? 00252100
FRSTLOC? DC??? 1F'0'????????? MODULE BEGINNING ADDRESS????????????????? 00252200
LASTLOC? DC??? 1F'0'????????? MODULE ENDING ADDRESS???????????????????? 00252300
LOCCNT?? DC??? 1F'0'????????? LOADER LOCATION COUNTER?????????????????? 00252400
LDRADDR? DC??? 1F'0'????????? LOADER RETURN ADDRESS???????????????????? 00252500
LDRRTCD? DC??? 1F'0'????????? LOADER RETURN CODE??????????????????????? 00252600
PSW????? DC??? 1D'0'????????? USER'S STARTING PSW?????????????????????? 00252700
LDRFLAGS DC??? 1F'0'????????? LOADER FLAGS????????????????????????????? 00252800
PRHOLD?? DC??? 1F'0'????????? PSEUDO REGISTER COUNTER?????????????????? 00252900
TBENT??? DC??? H'0'?????????? INITIALIZE TABLE ENTRIES TO?????????????? 00262000
*???????????????????????????? ZEROES??????????????????????????????????? 00262100
...
So when I hexdump, sorry HEXPRINT the file, I get the following which I edited, inserting spaces between each fullword.
HEX??? RECORD: 000001? RECORDLENGTH: 000080???????????????????????????????????????????????????? ?
?????? ---- +--- -|-- --+- ---| ---- +--- -|-- --+- ---| ---- +--- -|-- --+- ---| ---- +--- -|-- --+- ---|----+----|
000000 .... .... .... .... ...O .... .... .... .... .... .... .... .... .... .... Z... .... .... .... ....???????? ?
ZONE?? 0000 0000 0000 0000 002D 0000 0000 0001 4800 0000 0000 0000 0000 0000 0000 E000 0000 0000 0000 0006???????? ?
NUMBR? 0200 0200 0258 0258 0156 0000 0000 001F 4003 0000 0300 0000 0000 0000 0000 9000 0000 0000 0000 00E9???????? ?
???? ? |STRTADDR |FRSTLOC? |LASTLOC? |LOCCNT?? |LDRADDR? |LDRRTCD? |PSW??????????????? |LDRFLAGS |PRHOLD?? |
?????? 00020000? 00020508? 000125D6? 00000000? 44800003? 00030000? 00000000 00000000?? 00000000? 00000000 ?
?????? 00020000? 00020508? 00000000? 0000011F? 00000000? 00000000? 00000000 E9000000?? 00000000? 00000E69
...
If I map NUCON variables to those fields, then I end up with LOCCNT having a value of 000000000000011F. Therefor the length of the module is X'011F' or 287 decimal bytes.
Am I close, or just totally lost in the woods, and I should send up a flare?
?... Mark S.
|
On Sun, Feb 4, 2024 at 03:06 PM, Mark A. Stevens wrote:
Where MYPROG is a MODULE. So I am attempting to set the load address for MYPROG to be beyond the end of RUNPARM.
Have you check the assembler code of RUNPARM? I can't say for sure but, looking at it, I feel RUNPARM does make a call to GETMAIN to obtain storage for the module beyond the end of itself. Cheers, Rene FERLAND, Montreal
|
I have written XRUNPARM some years ago (2016), based on a routine
called RUNPARM,
which IMO is or was part of the COBOL runtime or came with the
COBOL compiler
(which, AFAIK, is an MVS compiler, which can be used with VM, too,
and the objects
created by this compiler have to be started using RUNPARM).
IIRC, I created XRUNPARM to start my Pascal programs
look here:
same story as with the Cobol compiler above.
Because XRUNPARM changed its size several times, the origin where
the Pascal programs start is now 20700.
You can look at the PASRUN EXEC (which should be on the S or Y
drive of the VM CE edition);
there you find:
...
&L1 = PASMONN
&L2 = PASLIBX
&L3 = PASUTILS
&L4 = PASSNAPC
&O1 = ORIGIN
&O2 = 20700
&O3 = RESET
&O4 = $PASENT
&O5 = CLEAR
LOAD &L1 &L2 &L3 &L4 &M1 &M2 &M3
&M4 &1 ( &O1 &O2 &O3 &O4 &O5
&IF &RETCODE NE 0 &GOTO -NOLOAD
*-----------------------------------------------------------
GENMOD &1
&IF &RETCODE NE 0 &GOTO -NOMOD
*-----------------------------------------------------------
FILEDEF QRD DISK &1 DBGINFO (RECFM F
XRUNPARM &1 &R1 &R2 &R3 &R4 &R5 &R6
&R7 &R8 &R9 &R10 &R11 &R12 &R13
&R14
...
I also tried to get rid of XRUNPARM completely and link the
startup code in XRUNPARM together with the
generated code coming from the Pascal compiler to build one single
module, but when I did so, my programs failed
by unknown reasons ... so I was stuck with the XRUNPARM solution.
At the moment, the code generated by the Pascal compiler is the
same for MVS and CMS, and this is fine
and I don't want to change this. If I could find a solution where
only the runtime libraries are different,
this would be OK for me. But at the moments the runtimes are the
same, too (only one minor difference,
concerning the allocation of the debug information data: on MVS a
member in a library DBGINFO with the member
name of the Pascal program (say: PROGNAME), and on VM a file
PROGNAME DBGINFO.
If you want to know more about the reasons, why I had to write an
own version of RUNPARM
or how I found out the length of XRUNPARM, contact me offline (I
guess it was by looking at
the LOAD MAP after building the XRUNPARM MODULE - the source code
should be on the S or Y drive, too;
if not, I can send you the actual version, which is from August
2023, BTW.
HTH, kind regards
Bernd
Am 05.02.2024 um 00:06 schrieb Mark A.
Stevens via groups.io:
toggle quoted message
Show quoted text
On Sun, Feb 4, 2024 at 04:42 PM, Dave Wade wrote:
Not sure what you are planning, but if your program
has issued any storage requests, the space at the end of the
program will have been used to satisfy those requests so not
available to load a second program.
There is a modules called RUNPARM and XRUNPARM, which is on the
Y-Disk. There is also WMSASM from the CBT. All three are supposed
to be a 'front end' for programs that are by nature MVS code. They
take command line parameters and fix up the PLIST to be something
the MVS program will be able to understand.
My few examples show something like:
RUNPARM MYPROG ...
Where MYPROG is a MODULE. So I am attempting to set the load
address for MYPROG to be beyond the end of RUNPARM.
Do I really know what I am doing. Nope. Just trying to figure it
all out.
?... Mark S.
|
One more remark, BTW:
when I tested my Pascal compiler - including XRUNPARM - on modern
z/VM,
I found out that XRUNPARM with its current coding doesn't work
there, because the layout
of the module description areas have changed, and the length
information of the modules
(which is read by XRUNPARM to retrieve the needed length for
GETMAIN) isn't at the place any more
where it used to be).
So XRUNPARM on modern VM constantly failed with this error
message:
BADSIZE? DS??? 0H
???????? LA??? R2,1024-1(,R2) CONVERT REQUIRED SIZE TO 'K'
???????? SRL?? R2,10
???????? LINEDIT TEXT='"...................." REQUIRES ....K MORE
STORA*
?????????????? GE',DOT=NO,RENT=NO,SUB=(CHAR8A,MODNAME,DEC,(R2))
???????? LA??? R15,104????????????? SET RETURN CODE
which gives (for example):
MODULE XXXXXXXX REQUIRES 192K MORE STORAGE
no matter how many storage you allocated to your VM/CMS session.
I found a way to overcome this error message, but don't recall
what it was;
because z/VM doesn't belong to my regulary working environments, I
didn't pay much
attention (this was a user's request, and I didn't find an easy
way to make XRUNPARM
run on the old VM/370 R6 system and on z/VM at the same time ...
and I don't have the resources
to support different environments, which I do not use myself).
I'm sorry to say that MVS 3.8 and current z/OS are no problem in
this respect,
although I'd prefer working on VM, when preparing new mainframe
versions of the Pascal compiler.
Sorry, kind regards
Bernd
Am 05.02.2024 um 00:57 schrieb Bernd
Oppolzer via groups.io:
toggle quoted message
Show quoted text
I have written XRUNPARM some years ago (2016), based on a
routine called RUNPARM,
which IMO is or was part of the COBOL runtime or came with the
COBOL compiler
(which, AFAIK, is an MVS compiler, which can be used with VM,
too, and the objects
created by this compiler have to be started using RUNPARM).
IIRC, I created XRUNPARM to start my Pascal programs
look here:
same story as with the Cobol compiler above.
Because XRUNPARM changed its size several times, the origin
where the Pascal programs start is now 20700.
You can look at the PASRUN EXEC (which should be on the S or Y
drive of the VM CE edition);
there you find:
...
&L1 = PASMONN
&L2 = PASLIBX
&L3 = PASUTILS
&L4 = PASSNAPC
&O1 = ORIGIN
&O2 = 20700
&O3 = RESET
&O4 = $PASENT
&O5 = CLEAR
LOAD &L1 &L2 &L3 &L4 &M1 &M2 &M3
&M4 &1 ( &O1 &O2 &O3 &O4 &O5
&IF &RETCODE NE 0 &GOTO -NOLOAD
*-----------------------------------------------------------
GENMOD &1
&IF &RETCODE NE 0 &GOTO -NOMOD
*-----------------------------------------------------------
FILEDEF QRD DISK &1 DBGINFO (RECFM F
XRUNPARM &1 &R1 &R2 &R3 &R4 &R5 &R6
&R7 &R8 &R9 &R10 &R11 &R12 &R13
&R14
...
I also tried to get rid of XRUNPARM completely and link the
startup code in XRUNPARM together with the
generated code coming from the Pascal compiler to build one
single module, but when I did so, my programs failed
by unknown reasons ... so I was stuck with the XRUNPARM
solution.
At the moment, the code generated by the Pascal compiler is the
same for MVS and CMS, and this is fine
and I don't want to change this. If I could find a solution
where only the runtime libraries are different,
this would be OK for me. But at the moments the runtimes are the
same, too (only one minor difference,
concerning the allocation of the debug information data: on MVS
a member in a library DBGINFO with the member
name of the Pascal program (say: PROGNAME), and on VM a file
PROGNAME DBGINFO.
If you want to know more about the reasons, why I had to write
an own version of RUNPARM
or how I found out the length of XRUNPARM, contact me offline (I
guess it was by looking at
the LOAD MAP after building the XRUNPARM MODULE - the source
code should be on the S or Y drive, too;
if not, I can send you the actual version, which is from August
2023, BTW.
HTH, kind regards
Bernd
Am 05.02.2024 um 00:06 schrieb Mark
A. Stevens via groups.io:
On Sun, Feb 4, 2024 at 04:42 PM, Dave Wade wrote:
Not sure what you are planning, but if your program
has issued any storage requests, the space at the end of the
program will have been used to satisfy those requests so not
available to load a second program.
There is a modules called RUNPARM and XRUNPARM, which is on the
Y-Disk. There is also WMSASM from the CBT. All three are
supposed to be a 'front end' for programs that are by nature MVS
code. They take command line parameters and fix up the PLIST to
be something the MVS program will be able to understand.
My few examples show something like:
RUNPARM MYPROG ...
Where MYPROG is a MODULE. So I am attempting to set the load
address for MYPROG to be beyond the end of RUNPARM.
Do I really know what I am doing. Nope. Just trying to figure it
all out.
?... Mark S.
|
On Sun, Feb 4, 2024 at 05:54 PM, Ren¨¦ Ferland wrote:
Have you check the assembler code of RUNPARM? I can't say for sure but, looking at it, I feel RUNPARM does make a call to GETMAIN to obtain storage for the module beyond the end of itself.
Rene, Yes, I have, and it has a call to GETMAIN and FREEMAIN. ?... Mark S.
|
Hi, Mark,
RUNPARMS and XRUNPARM are very small, so no reason they could not be compiled and loaded with "(ORIGIN TRANS" to run in the CMS transient area (only 8K), then that way they can load and run any normal VM/CMS module that has the default origin address of x'20000' ... :-)
All the best,
Mark S. Waterbury
|
Hi, Bernd,
See my reply to Mark Stevens regarding RUNPARMS and XRUNPARM... :-)
Also, for VM/SP and above, you should be able to use the OSRUN command that is built-in to VM/SP and above to invoke your compiler with an OS style parameter list.
All the best,
Mark S. Waterbury
|
On Sun, Feb 4, 2024 at 05:57 PM, Bernd Oppolzer wrote:
I have written XRUNPARM some years ago (2016), based on a routine called RUNPARM,
I wondered where XRUNPARM came from, and now I know! Thank you!! I do know where the source is, and have assembled it. The TEXT and LISTING files are somewhere around here. I had been looking at LOAD MAPs for both XRUNPARM and RUNPARM, and could not determine where the end/length of/size of the MODULEs were. Something I read steered me to look at DMSMOD, where I found the information cited above. I *think* I'm using it correctly. ?... Mark S.
|
On Sun, Feb 4, 2024 at 06:32 PM, Mark Waterbury wrote:
RUNPARMS and XRUNPARM are very small, so no reason they could not be compiled and loaded with "(ORIGIN TRANS" to run in the CMS transient area (only 8K), then that way they can load and run any normal VM/CMS module that has the default origin address of x'20000' ... :-)
Had not considered that, since I don't know off hand how big the transient area is. I'm sure it's in a manual someplace :-D So, I'll add that to my list.? Thanks! However, since RUNPARM issues a GETMAIN, I need to learn what it does when running from the transient area, as compared to the user area. More to learn. ?... Mark S.
|
For future reference.
From GC20-1809-7_VM370_OLTSEP_and_Error_Reporting_Guide_Rel_6_PLC_1_Mar79.pdf
Transient Program Area (X'0E000' to X'10000') Since it is not
essential to keep all nucleus functions resident in storage all the
time, some of them are made "transient." This means that when they
are needed, they are loaded from the disk into the transient program
area.? Such programs may not be longer than two pages, because that
is the size of the transient area.? (A page is 4096 bytes of virtual
storage.) All transient routines must be serially reusable since
they are not read in each time they are needed.
User Program Area (X'20000' to Loader Tables) User programs are
loaded into this area? by the LOAD command.? Storage allocated by
means of the GETMAIN macro instruction is taken from this area,
starting from the high address of the user program.? In addition,
this storage area can be allocated from the top down by DMSFREE, if
there is not enough storage available in the low DMSFREE storage
area. Thus, the usable size of the user program area is reduced by
the amount of free storage that has been allocated from it by
DMSFREE.
Free Storage Management
Free storage can be allocated by issuing the GETMAIN or DMSFREE macros.
Storage allocated by the GETMAIN macro is taken from the user program
area, beginning after the high address of the user program.
... Mark S.
|
Hi, Mark,
For the archives and future folks reading these messages:
The CMS "transient area" is defined and explained in several of the CMS manuals, such as:
?
and
?
or
?
(under the LOAD and GENMOD commands).
Mark S. Waterbury
|
Mark, Are you building a compiler for VM? If so you might want to look at the two assembler routines on the Fortran 191 disk which provide the interface between CMS and the OS Fortran compiler. Dave ?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]> On Behalf Of Mark Waterbury
Sent: Monday, February 5, 2024 12:35 AM
To: [email protected]
Subject: Re: [h390-vm] How Big/Long is a CMS Module? Hi, Bernd,
See my reply to Mark Stevens regarding RUNPARMS and XRUNPARM... :-)
Also, for VM/SP and above, you should be able to use the OSRUN command that is built-in to VM/SP and above to invoke your compiler with an OS style parameter list.
All the best,
Mark S. Waterbury
|
On Mon, Feb 5, 2024 at 02:50 AM, Dave Wade wrote:
Are you building a compiler for VM?
Still struggling with U of Waterloo Assembler G. I need the OS to VM conversion program, RUNPARM/XRUNPARM/WMSASM/... but am struggling with figuring out how/where to load that module, and the ASMG* MODULES, that is, their load/entry address. I also don't get to spend a lot of time thinking about it, as I have a grandson (2 1/2 years old) running around the house 4 days per week. My wife has Parkinson's Disease, so I am picking up more of her duties as time goes along. No tears. It's life. I am learning a H*** of a lot along the way. ?... Mark S.
|
Mark W.,
You are correct to point out the Transient Area as critical to understanding this issue.
Mark S., some thoughts in case they are helpful.
It's important to remember that?modules are imager of memory after the link loader has been run. This means that all address constants (external or internal, ACONS and VCONS, as we used to call them) have been resolved into absolute addresses, preventing relocation of the code. It's possible to have fully relocatable 370 code, but it is more than a bit painful, and?I'd be surprised if the whole assembler is relocatable.
The lack of relocation is why the transient area is handy. The different load areas means that even without relocation, transient modules can call non-transient modules, and nontransient modules can call transient modules. XEDIT and REXX used various forms of voodoo to load essentially all their code except for an initial boot module into high memory (or they lived on a DCSS at an address above the usual user area).?They could run arbitrary modules (as long as there was enough main memory in play). We do have the CMS dynamic loader, but it did not exist at the time that asmg was ported. I believe it's also possible to have a small transient module that can serve as an overlay manager, capable of loading and calling multiple heavyweight non-transient modules that do most of the work. The alternative is to rely on SVC 202, and ensure that the entry point of any module you via SVC will be at the same address as the return address from SVC. While that is theoretically possible, I don't think it's really maintainabl, especially since you have two different memory areas into which you can load modules without conflict.
I have not ported stuff from MVS, and indeed I know relatively little about OS variants, but especially the compilers tended to have complicated overlay structures. These were replicated when proting to CMS by using multiple Modules (one for each overlay), and loading and branching to them directly. That's why PLI on CMS consists of so many different modules. Building this up from scratch could be pretty painful at this remove. If you are trying to get ASMG running (even if you only have the MVS version, as it seems), and given that ASMG started as a patched version of Assembler F, I'd start first by looking at the source and build structure for? Assembler F in CMS, as you might be able to use that build structure (and it's execs) as a starting point for the task. With luck you might even be able to replace the existing F Modules with thjeir equivalent G modules.
At Brown where I was an undergrad, and where I did most of my hacking on VM, they did have ASMG running in VM, but I'm afraid that I never looked at the implementation.
|
Hi, David,
You are correct to point out how often times, people used the CMS loader to combine one or more TEXT object decks (CSECTs) into a single CMS load MODULE that could then be loaded on demand.? But, as you pointed out, you have to assign the different module "origins" (load addresses) yourself.? This can be a pain to figure out.
One nice thing is, with VM/CMS OS Simulation, we can just put all the object decks in a TXTLIB and issue GLOBAL TXTLIB and then, run the command front-end module, and have it issue the OS LINK OR LOAD macro to dynamically load those objects from the TXTLIB "on demand."
With newer versions (VM/SP and above), you also have the LKED command in CMS, that creates a LOADLIB that works similar to a TXTLIB, but with pre-linked load modules. They are still "relocatable" just like load modules on OS/360, or OS/VS1, SVS or MVS.? ?You could also issue a CP LINK to an OS DASD volume (on 2314, 3330, or 3350) and then ACCESS it as a CMS mode letter, and issue a special format FILEDEF to allow you to access an OS PDS library directly from CMS.? In this way, you could also use the LINK, LOAD, ATTACH or XCTL macros from CMS to load and run OS resident load modules under OS simulation.
Also of interest, we do have the LKED command on VM/370 Rel. 6 CMS, as it was there to facilitate creating a load module for use with VTAM NCP, to create the image that CP used to download into the IBM 3705 or equivalent.? ?I am working (part time) to experiment to see if we can create a few small "mods" to the OS simulation in VM/CE CMS to allow a similar use of those CMS resident LOADLIBs.? This would make it easier when porting various compilers, assemblers, etc., to run under CMS.
I note also that with? VM/CMS and virtual memory of up to 16 MB per user, we now have the luxury of just linking everything into one big fat "mega-MODULE" rather than having to deal with programmed "overlays."? ?The only problem with this approach is certain old applications relied on the overlay supervisor to re-load certain overlays into memory each time they were called, and that would re-initialize certain local variables, when the code was not reentrant.? Otherwise, I have had good success in the past in un-doing overlay structures with that approach.
Hope that helps,
Mark S. Waterbury
|
Hi, Mark,
Here is another idea that may help to make your job easier in trying to get ASMG running under VM/CE CMS.
You can create a small OS mini-disk DASD volume, just big enough to have a minimal VTOC and one PDS library.? Size the minidisk just a few cylinders, just large enough to hold everything needed, with a little extra for "maintenance" activities, such as re-linking certain modules to incorporate fixes, etc.
Then, you run the link-edits under the real OS/360, or OS/VS1 or MVS (could even be MVS TK3, TK4- or TK5), to create your load modules from the object decks.
Then, to use it from VM/CE CMS, you issue CP LINK to that minidisk, then ACCESS it as a "mode" letter, (I like "O" for this, since it is an "OS disk"), and then issue a FILEDEF to define it to CMS, and then your main front-end program, equivalent of XRUNPARM or WMSASM, etc. can just issue a LOAD EP=name and then you load the address into R15 and issue a BALR R14,R15 to call the desired module, or even issue LINK EP= to let OS Simulation handle loading and unloading each "phase" in turn.
Then, when done, you can just remove the FILEDEF, release the "O" minidisk, and CP DETACH the OS volume when no longer in use.
Hope this helps,
Mark S. Waterbury
|
Mark A. Stevens
Ren¨¦ Ferland