On 2/20/20 4:43 PM, Steven Fosdick wrote: I have been reading Sharon Tuggle's book "Assembler Language
Programming: Systems/360 and 370" and it makes use of a macro SNAP on
OS (MVS etc) which, from what I can tell, produces some kind of dump
output of the program state.
This does not seem to be defined while assembling on CMS. Is there an
equivalent? Or do I need to do something to include a specific macro
library?
The SNAP macro is in the OSMACRO MACLIB S -- Drew Derbyshire How would the Lone Ranger have handled this?
|
The SNAP macro is simply a wrapper for the PDUMP macro. IIRC the parameters given to the SNAP macro are labels in the program whereas the PDUMP macro expects addresses in storage.
Hello!
That's an excellent question. I don't know. Dave W might,. There are
other books on the subject, two of them were written by Jeff Savit.
He's an old friend of VM, and wrote those two whilst actually managing
the OS for one of the victims of the Great Recession. I can list them,
but I can rather do that in a completely different thread. The other
was written by Phil Smith III and Gabe Goldberg. It's on VM/ESA but
should provide some good ideas.
If you're running DOS under VM then the book written by the Professors
Yarnish concerning Assembly programming on OS and DOS for S/360 and
S/370 will work.
I seem to recall that many good libraries have books stacked up on the subject.
---
Uh oh, the Blob has fully covered a museum in PA. No one can get in,
and no one is getting out. However an adventurous something else has
started trying to remove it by eat it. We'll know more in six weeks.
-----
Gregg C Levine gregg.drwho8@...
"This signature fought the Time Wars, time and again."
On Thu, Feb 20, 2020 at 7:43 PM Steven Fosdick <stevenfosdick@...> wrote:
>
> I have been reading Sharon Tuggle's book "Assembler Language
> Programming: Systems/360 and 370" and it makes use of a macro SNAP on
> OS (MVS etc) which, from what I can tell, produces some kind of dump
> output of the program state.
>
> This does not seem to be defined while assembling on CMS.? Is there an
> equivalent?? Or do I need to do something to include a specific macro
> library?
>
>
>
|
Hello!
That's an excellent question. I don't know. Dave W might,. There are
other books on the subject, two of them were written by Jeff Savit.
He's an old friend of VM, and wrote those two whilst actually managing
the OS for one of the victims of the Great Recession. I can list them,
but I can rather do that in a completely different thread. The other
was written by Phil Smith III and Gabe Goldberg. It's on VM/ESA but
should provide some good ideas.
If you're running DOS under VM then the book written by the Professors
Yarnish concerning Assembly programming on OS and DOS for S/360 and
S/370 will work.
I seem to recall that many good libraries have books stacked up on the subject.
---
Uh oh, the Blob has fully covered a museum in PA. No one can get in,
and no one is getting out. However an adventurous something else has
started trying to remove it by eat it. We'll know more in six weeks.
-----
Gregg C Levine gregg.drwho8@...
"This signature fought the Time Wars, time and again."
toggle quoted message
Show quoted text
On Thu, Feb 20, 2020 at 7:43 PM Steven Fosdick <stevenfosdick@...> wrote:
I have been reading Sharon Tuggle's book "Assembler Language
Programming: Systems/360 and 370" and it makes use of a macro SNAP on
OS (MVS etc) which, from what I can tell, produces some kind of dump
output of the program state.
This does not seem to be defined while assembling on CMS. Is there an
equivalent? Or do I need to do something to include a specific macro
library?
|
I have been reading Sharon Tuggle's book "Assembler Language
Programming: Systems/360 and 370" and it makes use of a macro SNAP on
OS (MVS etc) which, from what I can tell, produces some kind of dump
output of the program state.
This does not seem to be defined while assembling on CMS. Is there an
equivalent? Or do I need to do something to include a specific macro
library?
|
I believe there is some memory/code shared by all CMS users.
I vaguely remember writing something to check for an updated Y-disk,
then re-access it if necessary.
It was supposed to allow me to distribute updates without forcing
users to re-ipl (or them even being aware).
Paul
On 2/18/2020 2:32 PM,
adriansutherland67 wrote:
toggle quoted message
Show quoted text
On Tue, Feb 18, 2020 at 03:44 PM, rvjansen@... wrote:
one IPL is not enough to get it in working state again
That is weird ... could it be something to do with resident
code?(global variables) surviving the IPL? Or worse being shared
between CMS users. Both of these I though / assumed was impossible
so would be interested in thoughts from anyone ...
Anyway, Rene - great progress - I am sure we will crack it!
I hope to have a docker image with the new GCCLIB build tomorrow.
It will be interesting to see if this helps any of the REXX IO
issues. We might need to rebuild BREXX.
Adrian
|
On Tue, Feb 18, 2020 at 03:44 PM, rvjansen@... wrote:
one IPL is not enough to get it in working state again
That is weird ... could it be something to do with resident code?(global variables) surviving the IPL? Or worse being shared between CMS users. Both of these I though / assumed was impossible so would be interested in thoughts from anyone ... Anyway, Rene - great progress - I am sure we will crack it! I hope to have a docker image with the new GCCLIB build tomorrow. It will be interesting to see if this helps any of the REXX IO issues. We might need to rebuild BREXX. Adrian
|
Hi Adrian,
I checked in the current source, will add some of the VM modules also. I started with the .corig sources and checked them in as.c, and then checked in the current .c modules, so we can track them with git diff. As a result, some of the files are empty now (and are not part of the build procedure - hmm).
Btw, I scripted the downloads with s3270 - something else to consider for automation of building and testing. Very probably we will need some extra containers, with the 1.2 sixpack for example, and the Dr. Latz fix, before we can bring it all together.
I hope we will find and fix some of the more infuriating aspects of BREXX on VM/370, which is the absolute flakeyness in loading files and getting their names wrong, especially with 8 character filenames; and the fact that sometimes one IPL is not enough to get it in working state again. I hope that the improvements in the gcc library also will help in getting more stability.
I’ll leave the build process automation and release process to you then, and will focus on debugging first. I just realized that I always used Rexx to start debug sessions and set breakpoints - with MVS, that is, hmm again.
I also started adding issues to work on, mostly for myself and to document potential progress.
best regards,
搁别苍é.
toggle quoted message
Show quoted text
On 13 Feb 2020, at 11:52, adriansutherland67 < adrian@...> wrote:
On Thu, Feb 13, 2020 at 10:37 AM, rvjansen@... wrote:
Or, Adrian, you can just add me as collaborator so I can work directly on the CMS brexx code in there, and use your build system, for speed.
Yeah I will do that. Please work in feature/fnnnn branches off develop. If you handle the source/brexx itself, I will handle the build process automation, and release management - OK? :-) I don't care about licenses, in the sense I don't care about owning any of this but I do care in the sense that I don't want to cause aggravation!? It sounds like it should be GPL-2.0 license because that is what Bill has used and it trickles down. Hopefully that is compatible with the other licence Dave mentioned! LOL
|
I would think so. Use #CP DISPLAY to display the content of the jump table to seem where the routines are loaded? ? Dave ?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]> On Behalf Of adriansutherland67
Sent: 16 February 2020 19:03
To: [email protected]
Subject: Re: [h390-vm] GCCLIB Advice? Yes reslib, it seems to pickup externs from the global lib fine. Question is does this pull it all into highmem? Is there a way to see the size of it? I could do a sanity check ...
|
Yes reslib, it seems to pickup externs from the global lib fine. Question is does this pull it all into highmem? Is there a way to see the size of it? I could do a sanity check ...
|
What are you using to load it? RESLIB? ? Dave ?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]> On Behalf Of adriansutherland67
Sent: 16 February 2020 18:16
To: [email protected]
Subject: Re: [h390-vm] GCCLIB Advice? The TEXT file is all the TEXT files appended together with COPYFILE. I am amazed this works but anyway!
After experimenting I think we just need the jump table in the TEXT file, and by having the “global txtlib gcclib” in sysprofile CMS automatically pulls in from the library.
It works - the question is, is there anything bad with this - i.e. does everything go into high memory if I do it this way round?
Adrian?
|
The TEXT file is all the TEXT files appended together with COPYFILE. I am amazed this works but anyway!
After experimenting I think we just need the jump table in the TEXT file, and by having the “global txtlib gcclib” in sysprofile CMS automatically pulls in from the library.
It works - the question is, is there anything bad with this - i.e. does everything go into high memory if I do it this way round?
Adrian?
|
Re: GCCRES (GCCLIB Res Stub) is rather large
The fixed GCCLIB with the fixed pointer is a huge improvement…
Dave
?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]> On Behalf Of adriansutherland67
Sent: 16 February 2020 18:12
To: [email protected]
Subject: Re: [h390-vm] GCCRES (GCCLIB Res Stub) is rather large? OK - Got my head round it ... and it is working. I think that we should still treat it as beta but it is a massive product, and this version will be a big improvement on the one on the six pack, I think.
I have found some test scripts for the STDC library ...?
|
Re: GCCRES (GCCLIB Res Stub) is rather large
OK - Got my head round it ... and it is working. I think that we should still treat it as beta but it is a massive product, and this version will be a big improvement on the one on the six pack, I think.
I have found some test scripts for the STDC library ...?
|
Re: GCCRES (GCCLIB Res Stub) is rather large
I am envisaging a kind of stack for rexx context, etc.
|
Re: GCCRES (GCCLIB Res Stub) is rather large
Especially in the case of a REXX program that calls another REXX program, the two programs should not end up accessing each others variables. Regards, Peter Coghlan. Date: Sun, 16 Feb 2020 10:07:28 +0000 From: Dave Wade <dave.g4ugm@...> Subject: Re: [h390-vm] GCCRES (GCCLIB Res Stub) is rather large To: [email protected]Yes it makes sense. If REXX calls another program using the shared library then won’t it need this? Dave From: [email protected] < [email protected]> On Behalf Of adriansutherland67 Sent: 16 February 2020 09:59 To: [email protected]Subject: Re: [h390-vm] GCCRES (GCCLIB Res Stub) is rather large Rereading the code I am a bit clearer. Still think gcccrab is overkill (or perhaps underkill and it should become a facility that things like brexx could use). It allows user process specific variables when using a shared libres library. Otherwise all programs using the library would share the same global variable. If that makes any sense. (Presumably brexx having shared variables would be a good thing to allow a program like execio to update rexx variables ... but anyway!) The debugging issue is without printf working I can't be sure if the call to a resident function is not working, or just the gcccrab bit meaning stdout is busted. Oh well ... Work continues
|
Re: GCCRES (GCCLIB Res Stub) is rather large
Yes it makes sense. If REXX calls another program using the shared library then won’t it need this? ? Dave ?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]> On Behalf Of adriansutherland67
Sent: 16 February 2020 09:59
To: [email protected]
Subject: Re: [h390-vm] GCCRES (GCCLIB Res Stub) is rather large? Rereading the code I am a bit clearer.
Still think gcccrab is overkill (or perhaps underkill and it should become a facility that things like brexx could use). It allows user process specific variables when using a? shared libres library. Otherwise all programs using the library would share the same global variable. If that makes any sense.
(Presumably brexx having shared variables would be a good thing to allow a program like execio to update rexx variables ... but anyway!)
The debugging issue is without printf working I can't be sure if the call to a resident function is not working, or just the gcccrab bit meaning stdout is busted.
Oh well ... Work continues
|
Re: GCCRES (GCCLIB Res Stub) is rather large
Rereading the code I am a bit clearer.
Still think gcccrab is overkill (or perhaps underkill and it should become a facility that things like brexx could use). It allows user process specific variables when using a? shared libres library. Otherwise all programs using the library would share the same global variable. If that makes any sense.
(Presumably brexx having shared variables would be a good thing to allow a program like execio to update rexx variables ... but anyway!)
The debugging issue is without printf working I can't be sure if the call to a resident function is not working, or just the gcccrab bit meaning stdout is busted.
Oh well ... Work continues
|
I think that the:- ? “global txtlib gcclib” ? Means that when you load something “normally” you get the “normal” “C” library. ? ? Dave ? ?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]> On Behalf Of adriansutherland67
Sent: 15 February 2020 17:04
To: [email protected]
Subject: [h390-vm] GCCLIB Advice? I am trying to make sure I understand what is going on?
The MKGCCLIB EXEC makes 3 files - GCCLIB TXTLIB - This is "normal" library that is linked to a users program
- GCCRES TXTLIB - This is the "stub" version that will call the resident programme (using magic, but enough of that 'till later!). Users should link against this to use the resident library.
- GCCLIB TEXT - This is the "program" that is loaded into resident memory (btw it is loaded as GCCLIB, isn't there a CMS naming convention to stop it being called by accident?)
Is that right?
However, in the SYSPROG EXEC I have RESLIB LOAD GCCLIB (NAME GCCLIB
Now why are we doing the GLOBAL TXTLIB? There is no member called GCCLIB of course. So is it just a harmless error, or am I missing something in my mental image of what is going on?
Thanks!!?
|
Re: GCCRES (GCCLIB Res Stub) is rather large
Adrian, I think something is wrong with the profiles being used. When I loaded the modified version from Hans (I think its Hans) things worked, but something isn’t and I am travelling so don’t have time to look now. Dave ?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]> On Behalf Of adriansutherland67
Sent: 15 February 2020 19:35
To: [email protected]
Subject: Re: [h390-vm] GCCRES (GCCLIB Res Stub) is rather large? Thanks Dave - I have tested it (with hello world only). The traditional library works (GCCLIB), the resident one doesn't.
Dave - you mentioned that you had it working on your latest version - have you the source that you built, or did you just take it off the binary tape?
I will run the test from the binaries on the tape tomorrow.
Cheers
Adrian
|
Re: GCCRES (GCCLIB Res Stub) is rather large
Thanks Dave - I have tested it (with hello world only). The traditional library works (GCCLIB), the resident one doesn't.
Dave - you mentioned that you had it working on your latest version - have you the source that you built, or did you just take it off the binary tape?
I will run the test from the binaries on the tape tomorrow.
Cheers
Adrian
|
PaulJayD
