|
On Mon, Feb 10, 2020 at 11:14 AM, adriansutherland67 wrote:
docker run --rm -d -p 3270:3270 -p 8038:8038 -p 3505:3505 --name vm370 adriansutherland/vm370:1.3.5
Fast start - Use from the normal windows console: * start the container docker run -d -p 3270:3270 -p 8038:8038 -p 3505:3505 --name vm370 adriansutherland/vm370:1.3.5 * attach to the linux console docker exec -it vm370 /bin/bash This will give you a linux command line, then: herccontrol "ipl 141" c3270 localhost:3270 (on my windows computer the mouse even works - which surprised me) (and ctrl-c clears the 3270 screen) Use the menu to exit c3270 then "exit" to close the shell. And - yes you can do multiple shells via docker attach * To stop (pause) the container docker stop vm370 * To kill it (pull the plug) docker kill vm370 * to unpause/start it docker start vm370 * And to remove and delete the container docker rm vm370 Boom! In this config use the hercules webconsole (or herccontrol); hercules is running detached. If your data/time becomes completely unsynced you need to restart docker desktop (and therefore stop/start your container); defect with Docker and Hybernate. You know - its a bit like CP ...
|
Hello!
Actually well stated. But it was aimed at Dave M, who monitors this group.
And Adrian I just tried out your Docker image, and it worked just dandy here.
--
Gregg C Levine hansolofalcon@...
"Didn't we just leave this party?" Han Solo
toggle quoted message
Show quoted text
-----Original Message----- From: [email protected] < [email protected]> On Behalf Of rvjansen@... Sent: Monday, February 10, 2020 3:21 AM To: [email protected]Subject: Re: [h390-vm] building BREXX Hi Gregg, You can probably just run it and it will download it from Docker Hub the first time, when the disk seek for it fails. Yeah, tried to get my cats interested but they said they only accept paying assignments, and will not work on OS’es without mice. So unless one foots the Purina, it’s bleak. 搁别苍é. On 10 Feb 2020, at 02:43, Gregg Levine <gregg.drwho8@...> wrote:
?Hello!
Adrian how did you construct this Docker Container? And is it
available for us to work with?
Dave, a question, since this concerns the sixpack. How does one launch
it? (Together with how to log into it?)
And this will be obvious only to the Yeti working with two people and
many cats all over a museum in PA. But not to the people, only the
cats and the yeti.
-----
Gregg C Levine gregg.drwho8@...
"This signature fought the Time Wars, time and again."
On Sun, Feb 9, 2020 at 3:16 AM adriansutherland67
<adrian@...> wrote:
So I would support this and started with CMSLIB. I have a repository with buildable code.
I want to set up a GitHub action so that code can be built automatically on a push, and a release (on a tape) produced on a tag.
I am nearly there:.
- I have a VM/370 docker container for the runner
- I have made herccontrol that allows me to automate the build
through a script
- I have yata (yet another text archive), a light weight tool to allow me to send source code via the punch reader to cms. This autobuilds (as above) but it needs a change to handle lines over 80 characters. The point is it is a simple c program that builds on CMS, Linux, or Windows.
So I just need to do yata and set up the script for CMSLIB and then I can tackle some bugs in it. And then move to do the same to other facilities, etc.
All on GitHub under adesutherland
My lesson learnt is that GitHub actions are painful to debug!
It would be amazing to work with folks to have a repository for CP
and for CMS, and so on. Each building automatically and running some
tests. And a master repository that builds distributions from fresh
with different configurations (min size, everything, everything with source, Fortran, c, COBOL, etc.) _._,_._,_ ________________________________ Groups.io Links: "And this space is being left blank.:
|
Hi Dave,
“what your mother never told you” - I read it a really loooooong time ago and it reminded me how we used IEBUPDTE on MVS to update cards. I might be old but I love to use Git for things like source code maintenance. So I will join Adrian in working on that. Thank you and Peter for those pointers to what to do with VMF. I now also understand how the mechanism works that makes sure an exec is vetted on its first line and sent to the right interpreter, and I also can now build a BREXX MODULE, I still seem to have trouble with BREXX TEXT which is needed for RESLIB.
I would very much like to have test cases but I am still not there. As always, there must be several problems obscuring each other. One is a tendency to not find the exec, specially if the name is 8 characters. The other seem general flakeyness. But I have my eye on several problem cases in interpretation; only not well reproducible now due to all the random things that seem to happen. It sometimes reminds me of what you get when an LPA module in MVS is not linked reentrant; CMS being single user does not have that problem but checking for REUS should be done in the assembly after the C compiler produces its code - reentrant would be best because that implies reusable. I have to check. It might even be Hercules. I sometimes noticed that after a FILE I left things alone for some moments, chances of success are better. I must poke around more before I have usable testcases. I can execute BREXX <script name> without the resident part so I can isolate causes better.
I still see things like:
reslib delete gcclib ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Ready; T=0.01/0.01 14:19:36 ? ? ? ? ? ? ? ? ? ? ?? reslib delete dmsrex ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Ready; T=0.01/0.01 14:19:46 ? ? ? ? ? ? ? ? ? ? ?? brexx id ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? AB2217 AT SIXPACK ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? Ready; T=0.01/0.02 14:19:52 ? ? ? ? ? ? ? ? ? ? ?? brexx rexxtest ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? INVALID CHARACTER '%' IN FILEID 'REXXTEST %XEC'. ? fopen error: file 'STATE REXXTEST *' not found. ?? Error 58 running "REXXTEST%": File not found ? ? ? Ready; T=0.01/0.02 14:19:58 ? ? ? ? ? ? ? ? ? ? ?? brexx rexxtest aap noot mies ? ? ? ? ? ? ? ? ? ? ? INVALID CHARACTER '%' IN FILEID 'REXXTEST %XEC'. ? fopen error: file 'STATE REXXTEST *' not found. ?? Error 58 running "REXXTEST%": File not found ? ? ? Ready; T=0.01/0.02 14:20:24 ? ? ? ? ? ? ? ? ? ? ?? brexx rxv ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??
That last one is odd, it it a script that just does a parse version X; say X. If I logoff and logon it just works most of the time:
rxv ? ? ? ? ? ? ? ? ? ? ? ?? bREXX 2.1.8 Aug ?6 2010 ? ?? Ready; T=0.02/0.03 14:23:46?
and
brexx rxv ? ? ? ? ? ? ? ? ? bREXX 2.1.8 Feb 10 2020 ? ? Ready; T=0.01/0.02 14:24:46
that latter being my newly compiled BREXX MODULE on A and the former being the BREXX TEXT on S.
I experimented with?RESLIB LOAD BREXX (NAME DMSREX SYSTEM and I now sometimes get errors like ’SHARED PAGE UPDATED”. I think I read somewhere this check only happens with key 15 code. It would indicate a not serially reusable module. I must investigate how the linkage editor sets those bits; I assume it is something like in OS but again I don’t know.
I am fairly sure we will find the reasons for this. For hypotheses like ‘misuse of the DOS support’ I am still dependent on ideas from more knowledgeable people. I am looking for the explanation that Dr. Latz gave years ago but could not find it. If you have newer versions of the libraries available, I will happily switch to those. I am going to use Adrian’s Docker build system and will store changes to BREXX and related DMS modules in Adrian’s git repo. It would not hurt to upgrade to BREXX 2.1.9; I’ll keep an eye on what the MVS BREXX people did.
Apart from this, I will have to try the DMSREX module from MUSIC/SP and see how that works. Maybe Mark Hessling can have a look in how to reduce the memory footprint of Regina; he also started out on VM. I think it is good to have options.
best regards,
toggle quoted message
Show quoted text
Rene,Have you read "what mother never told you"?/g/h390-vm/files/What%20Mother%20Never%20Told%20You%20About%20VM%20Service%20%281983%29.pdfand the "SYSPROG MEMO" describes some of the mods. So if you want to assemble a CMS modules doCMSACCVMFASM modulename DMSHRC (DISKWill assemble the module and leave the listing as "$modulename LISTING" on the A disk.?It will also leave a text deck. If you don't want that add "NODECK" to the options.I also believe that many of the BREXX problems are caused by its mis use of the DOS flag. Do you have some tests to show the problems??Dave-----Original Message-----
From:?[email protected]?<[email protected]> On Behalf Of
rvjansen@...
Sent: 09 February 2020 22:51
To:?[email protected]
Subject: Re: [h390-vm] building BREXX
ok. Another beginner’s question: I see the original source of DMSEXC
ASSEMBLE is from 1978, and changes are patched on using a line-by-line
approach. Is there some easy way to assemble the source module with all
the patches merged, so that I can check the offsets without going through
the whole rebuild of the system? Would this be one of those VMFxxx
commands?
搁别苍é.
On 9 Feb 2020, at 23:41, Dave Wade <dave.g4ugm@...> wrote:
Rene,
When you logon to maint the CP mods disk is accessed as "B". There is
another HRCMODS MEMO on that disk for the CP mods.
Dave
-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of
rvjansen@...
Sent: 09 February 2020 22:36
To: [email protected]
Subject: Re: [h390-vm] building BREXX
Ah!
Thanks Dave!
搁别苍é.
On 9 Feb 2020, at 23:25, Dave Wade <dave.g4ugm@...> wrote:
To see what CMS mods there are in the n-Pack logon to maint and type
CMSACC
This accesses the CMS modifications disk as "B" and then do
EE HRCMODS MEMO B
You will see HRC371DS implements this change. So
MEMO ????HRC371DS B1
Will contain details of how this is implemented.
Dave
-----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.
|
Rene, OK I Will have a look at those errors. The problem with switching to GIT is that when a new mod is uncovered, which happens surprisingly often its hard to figure out how to apply it if the sequence numbers are gone. I see it as a lot of work for little gain. Dave ?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]> On Behalf Of rvjansen@...
Sent: 10 February 2020 14:53
To: [email protected]
Subject: Re: [h390-vm] building BREXX? Hi Dave, “what your mother never told you” - I read it a really loooooong time ago and it reminded me how we used IEBUPDTE on MVS to update cards. I might be old but I love to use Git for things like source code maintenance. So I will join Adrian in working on that. Thank you and Peter for those pointers to what to do with VMF. I now also understand how the mechanism works that makes sure an exec is vetted on its first line and sent to the right interpreter, and I also can now build a BREXX MODULE, I still seem to have trouble with BREXX TEXT which is needed for RESLIB. I would very much like to have test cases but I am still not there. As always, there must be several problems obscuring each other. One is a tendency to not find the exec, specially if the name is 8 characters. The other seem general flakeyness. But I have my eye on several problem cases in interpretation; only not well reproducible now due to all the random things that seem to happen. It sometimes reminds me of what you get when an LPA module in MVS is not linked reentrant; CMS being single user does not have that problem but checking for REUS should be done in the assembly after the C compiler produces its code - reentrant would be best because that implies reusable. I have to check. It might even be Hercules. I sometimes noticed that after a FILE I left things alone for some moments, chances of success are better. I must poke around more before I have usable testcases. I can execute BREXX <script name> without the resident part so I can isolate causes better. reslib delete gcclib ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Ready; T=0.01/0.01 14:19:36 ? ? ? ? ? ? ? ? ? ? ?? reslib delete dmsrex ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Ready; T=0.01/0.01 14:19:46 ? ? ? ? ? ? ? ? ? ? ?? brexx id ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? AB2217 AT SIXPACK ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? Ready; T=0.01/0.02 14:19:52 ? ? ? ? ? ? ? ? ? ? ?? brexx rexxtest ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? INVALID CHARACTER '%' IN FILEID 'REXXTEST %XEC'. ? fopen error: file 'STATE REXXTEST *' not found. ?? Error 58 running "REXXTEST%": File not found ? ? ? Ready; T=0.01/0.02 14:19:58 ? ? ? ? ? ? ? ? ? ? ?? brexx rexxtest aap noot mies ? ? ? ? ? ? ? ? ? ? ? INVALID CHARACTER '%' IN FILEID 'REXXTEST %XEC'. ? fopen error: file 'STATE REXXTEST *' not found. ?? Error 58 running "REXXTEST%": File not found ? ? ? Ready; T=0.01/0.02 14:20:24 ? ? ? ? ? ? ? ? ? ? ?? brexx rxv ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? That last one is odd, it it a script that just does a parse version X; say X. If I logoff and logon it just works most of the time: rxv ? ? ? ? ? ? ? ? ? ? ? ?? bREXX 2.1.8 Aug ?6 2010 ? ?? Ready; T=0.02/0.03 14:23:46? brexx rxv ? ? ? ? ? ? ? ? ? bREXX 2.1.8 Feb 10 2020 ? ? Ready; T=0.01/0.02 14:24:46 that latter being my newly compiled BREXX MODULE on A and the former being the BREXX TEXT on S. I experimented with?RESLIB LOAD BREXX (NAME DMSREX SYSTEM and I now sometimes get errors like ’SHARED PAGE UPDATED”. I think I read somewhere this check only happens with key 15 code. It would indicate a not serially reusable module. I must investigate how the linkage editor sets those bits; I assume it is something like in OS but again I don’t know. I am fairly sure we will find the reasons for this. For hypotheses like ‘misuse of the DOS support’ I am still dependent on ideas from more knowledgeable people. I am looking for the explanation that Dr. Latz gave years ago but could not find it. If you have newer versions of the libraries available, I will happily switch to those. I am going to use Adrian’s Docker build system and will store changes to BREXX and related DMS modules in Adrian’s git repo. It would not hurt to upgrade to BREXX 2.1.9; I’ll keep an eye on what the MVS BREXX people did. Apart from this, I will have to try the DMSREX module from MUSIC/SP and see how that works. Maybe Mark Hessling can have a look in how to reduce the memory footprint of Regina; he also started out on VM. I think it is good to have options. 搁别苍é.
? Rene,
Have you read "what mother never told you"?
/g/h390-vm/files/What%20Mother%20Never%20Told%20You%20About%20VM%20Service%20%281983%29.pdf
and the "SYSPROG MEMO" describes some of the mods. So if you want to assemble a CMS modules do
CMSACC
VMFASM modulename DMSHRC (DISK
Will assemble the module and leave the listing as "$modulename LISTING" on the A disk.?
It will also leave a text deck. If you don't want that add "NODECK" to the options.
I also believe that many of the BREXX problems are caused by its mis use of the DOS flag. Do you have some tests to show the problems??
Dave
-----Original Message-----
From:?[email protected]?<[email protected]> On Behalf Of
rvjansen@...
Sent: 09 February 2020 22:51
To:?[email protected]
Subject: Re: [h390-vm] building BREXX
ok. Another beginner’s question: I see the original source of DMSEXC
ASSEMBLE is from 1978, and changes are patched on using a line-by-line
approach. Is there some easy way to assemble the source module with all
the patches merged, so that I can check the offsets without going through
the whole rebuild of the system? Would this be one of those VMFxxx
commands?
搁别苍é.
On 9 Feb 2020, at 23:41, Dave Wade <dave.g4ugm@...> wrote:
Rene,
When you logon to maint the CP mods disk is accessed as "B". There is
another HRCMODS MEMO on that disk for the CP mods.
Dave
-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of
rvjansen@...
Sent: 09 February 2020 22:36
To: [email protected]
Subject: Re: [h390-vm] building BREXX
Ah!
Thanks Dave!
搁别苍é.
On 9 Feb 2020, at 23:25, Dave Wade <dave.g4ugm@...> wrote:
To see what CMS mods there are in the n-Pack logon to maint and type
CMSACC
This accesses the CMS modifications disk as "B" and then do
EE HRCMODS MEMO B
You will see HRC371DS implements this change. So
MEMO ????HRC371DS B1
Will contain details of how this is implemented.
Dave
-----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.
?
|
On Mon, Feb 10, 2020 at 05:05 PM, Dave Wade wrote:
if the sequence numbers are gone
In Assembler files right? No need to strip them out if we put it in GIT. However, I suppose we might need a very simple tool to add new ones if lines are entered outside of VM/370? I assume the algorithm to make sequence numbers is triveral? A
|
Maybe I am missing something.
Is there something wrong with the IBM
supplied utilities to install/maintain the system code?
I for one would prefer to use the old
tried and true methods.
Possibly I am thinking of another
version of VM (or possibly it was something we wrote in-house) but
we used something called UPDATE which had the ability to start
with the normal distributed (base) software and apply the entire
library of fixes and updates to that code and build all of the
necessary steps and modules to the running system. Of course we
had to schedule an IPL from time to time to get some of the fixes
installed.
I will dig through some old stuff and
see if I can find some of the old notes and procedures we had.
George
On 2/10/2020 12:33 PM,
adriansutherland67 wrote:
toggle quoted message
Show quoted text
On Mon, Feb 10, 2020 at 05:05 PM, Dave Wade wrote:
if the sequence numbers are gone
In Assembler files right? No need to strip them out if we put it
in GIT.
However, I suppose we might need a very simple tool to add new
ones if lines are entered outside of VM/370? I assume the
algorithm to make sequence numbers is triveral?
A
|
There isn’t an algorithm. You choose! ? Dave ?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]> On Behalf Of adriansutherland67
Sent: 10 February 2020 17:34
To: [email protected]
Subject: Re: [h390-vm] building BREXX? On Mon, Feb 10, 2020 at 05:05 PM, Dave Wade wrote: if the sequence numbers are gone
In Assembler files right? No need to strip them out if we put it in GIT.
However, I suppose we might need a very simple tool to add new ones if lines are entered outside of VM/370? I assume the algorithm to make sequence numbers is triveral?
A
|
George, ? Thats my preference too. ? Dave ?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]> On Behalf Of George Shedlock
Sent: 10 February 2020 17:57
To: [email protected]
Subject: Re: [h390-vm] building BREXX? Maybe I am missing something. Is there something wrong with the IBM supplied utilities to install/maintain the system code? I for one would prefer to use the old tried and true methods. Possibly I am thinking of another version of VM (or possibly it was something we wrote in-house) but we used something called UPDATE which had the ability to start with the normal distributed (base) software and apply the entire library of fixes and updates to that code and build all of the necessary steps and modules to the running system. Of course we had to schedule an IPL from time to time to get some of the fixes installed. I will dig through some old stuff and see if I can find some of the old notes and procedures we had. On 2/10/2020 12:33 PM, adriansutherland67 wrote: On Mon, Feb 10, 2020 at 05:05 PM, Dave Wade wrote: if the sequence numbers are gone
In Assembler files right? No need to strip them out if we put it in GIT.
However, I suppose we might need a very simple tool to add new ones if lines are entered outside of VM/370? I assume the algorithm to make sequence numbers is triveral?
A
?
|
No, nothing wrong of course. It’s just that we are not used to it (imagine doing a change in VM, but now as a ++USERMOD in SMP/E - could do that in my sleep, but I’d rather never do it again now). And it is also that Git as distributed version management system, and Docker as container technology, make it much easier to collaborate on this kind of work. In a non-locking version management system work of several people can be merged, branches can be taken, and an automated testing environment can be set up, and this starting from a known situation, for example a clean Sixpack 1.4 distribution. This is why we (well Adrian and I at least) like this approach, and rather not go back to working without version management, or with locking version management systems like PVCS or Endevor.
Of course everyone should work the way they like, and of course we are extremely grateful for the work people put into this and certainly Dave for keeping this alive and kicking. We just want to assist the best way we can, with the tools we think will allow us to contribute in a meaningful way.
best regards,
René Jansen (President, Rexx Language Association)
toggle quoted message
Show quoted text
Maybe I am missing something.
Is there something wrong with the IBM
supplied utilities to install/maintain the system code?
I for one would prefer to use the old
tried and true methods.
Possibly I am thinking of another
version of VM (or possibly it was something we wrote in-house) but
we used something called UPDATE which had the ability to start
with the normal distributed (base) software and apply the entire
library of fixes and updates to that code and build all of the
necessary steps and modules to the running system. Of course we
had to schedule an IPL from time to time to get some of the fixes
installed.
I will dig through some old stuff and
see if I can find some of the old notes and procedures we had.
George
On 2/10/2020 12:33 PM,
adriansutherland67 wrote:
On Mon, Feb 10, 2020 at 05:05 PM, Dave Wade wrote:
if the sequence numbers are gone
In Assembler files right? No need to strip them out if we put it
in GIT.
However, I suppose we might need a very simple tool to add new
ones if lines are entered outside of VM/370? I assume the
algorithm to make sequence numbers is triveral?
A
|
With respect to GCCLIB problems here is Dr Hans Latz explanation of the problem:
GCCLIB without DOSTRANS?????????????????????????????
Dr. Hans-Walter Latz, 2014-01-08
1????????
Drawbacks of the resident GCCLIB in VM/370 SixPack 1.2
The native C library GCCLIB, which is part of VM/370 SixPack 1.2, can be loaded as resident library, allowing for small MODULEs. For this, the SYSPROF profile loads the GCCLIB into the resident memory with
RESLIB and uses the DOSTRANS field in the NUCON area to store the base pointer to the dispatch table of the resident library. The pointer is fetched by the GCCLIB-stubs (CL*-modules) linked into the programs to reference the corresponding real function implementation
in the resident GCCLIB.
This leads to problems (i.e. addressing errors and very likely to ABENDs) if the DOSTRANS field is needed for its original purpose, i.e. when running DOS/VSAM accessing programs like KICKS, as the DOSTRANS
field then no longer points to the dispatch table of the resident library when a GCCLIB based program is started afterwards.
Furthermore, the memory cleanup portion of the ABEND handler in CMS (DMSABN, invoked after a program ABEND or after issuing a HX immediate command) will assume that additional memory was allocated by an aborted
DOS/VSAM program if DOSTRANS is not zero. This will lead to a wrong computation of the memory size to be free-ed, which generally results in a warning or in halting CMS execution, requiring to re-IPL CMS. Issuing the HX command with the original resident GCCLIB
will usually result in the following message when entering the next command to CMS:
DMSABN149T 175 (HEX 0000AF) DOUBLEWORDS OF SYSTEM STORAGE HAVE BEEN DESTROYED. RE-IPL CMS.
CP ENTERED; DISABLED WAIT PSW '00020000 6001F0CE'
2????????
Modified functionality in GCCLIB
To resolve these problems, the addressing mechanism for the dispatch table of the resident library has been modified as follows:
- The resident library's base address is fetched early in the startup phase of the C program (GCCLIB-module CMSENTRY) and stored in a new ENTRY variable.
- The CL*-stubs now use this variable to load the base address to the dispatch table of the resident library.
So the DOSTRANS field is no longer needed for the resident GCCLIB and can serve again its original purpose.
After the modified resident GCCLIB is installed, all MODULEs using GCCLIB created under SixPack 1.2 must be re-linked against this new version, as the DOSTRANS field no longer holds the address of the dispatch
table and programs with the old stubs will therefore crash.
Programs loaded from TEXT or TXTLIB files need not to be modified, as loading them with the new GCCLIB TXTLIB will automatically use the new stubs to access the resident GCCLIB. This is also valid for the
bREXX interpreter, which can be used unmodified and is loaded by the system profile into resident memory using the modified GCCLIB.
Eddy Balem
|
On Mon, Feb 10, 2020 at 08:46 PM, <eddy_balem@...> wrote:
With respect to GCCLIB problems here is Dr Hans Latz explanation of the problem:
Yep - and the version on sixpack beta 3 has not got this fix - and moreover I believe has some other fixes that are probably the root cause of some brexx defects. This is why I am working to get this??built into? Adrian
|
|
|
|
|
On Mon, Feb 10, 2020 at 09:59 PM, Dave Wade wrote:
What is holding me up is reporting proper versions
Cheat! Just add VERSION EXEC to the S drive (or wherever!) ?
|
On Mon, Feb 10, 2020 at 08:10 PM, rvjansen@... wrote:
we are extremely grateful for the work people put into this and certainly Dave for keeping this alive and kicking
Hear hear!
|
Its a tad harder, because it done through the query command and I didn’t want to front that with an exec. Too many options? ? Dave ?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]> On Behalf Of adriansutherland67
Sent: 10 February 2020 22:31
To: [email protected]
Subject: Re: [h390-vm] building BREXX? On Mon, Feb 10, 2020 at 09:59 PM, Dave Wade wrote: What is holding me up is reporting proper versions
Cheat! Just add VERSION EXEC to the S drive (or wherever!) ?
|
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.
toggle quoted message
Show quoted text
-----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.
|
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,
搁别苍é.
toggle quoted message
Show quoted text
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.
|
I can't check today. What should happen is RESLIB should patch the command table..?
Dave
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.
>>
>
>
>
>
>
|
No problem. I fixed it by putting an &DISK = A in between, marking the first time I edited something in classic exec. Logging on after that loads the new BREXX TEXT, which means I can now debug, change things to see what happens. I’ll keep the list posted.
best regards,
搁别苍é.
toggle quoted message
Show quoted text
I can't check today. What should happen is RESLIB should patch the command table..?
Dave 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,
|
