开云体育

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

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

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

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

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

I would think so. Use #CP DISPLAY to display the content of the jump table to seem where the routines are loaded? Dave Sent: 16 February 2020 19:03 To: [email protected] Subject: Re: [h390-vm] GCCLIB

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 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.

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

The fixed GCCLIB with the fixed pointer is a huge improvement… Dave Sent: 16 February 2020 18:12 To: [email protected] Subject: Re: [h390-vm] GCCRES (GCCLIB Res Stub) is rather large OK - Got my

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

I am envisaging a kind of stack for rexx context, etc.

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

Yes it makes sense. If REXX calls another program using the shared library then won’t it need this? Dave Sent: 16 February 2020 09:59 To: [email protected] Subject: Re: [h390-vm] GCCRES (GCCLIB Res

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

I think that the:- “global txtlib gcclib” Means that when you load something “normally” you get the “normal” “C” library. Dave Sent: 15 February 2020 17:04 To: [email protected]

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

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