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
|
Re: GCCRES (GCCLIB Res Stub) is rather large
Ok. When I say loaded high I mean loaded with RESLIB. In a modern CMS we have relocatable modules and nucxload which loads this as nucleus extensions. RESLIB does much of this but not all....
Dave
On Sat, 15 Feb 2020, 6:32 pm adriansutherland67, < adrian@...> wrote: On Sat, Feb 15, 2020 at 05:57 PM, Dave Wade wrote:
REXX to be dynamically loaded into high memory, so it can call
But does gcclib need to be resident to allow rexx to be resident? And is loaded in high memory the same as resident? I am assuming so ...
The solution I am looking at seems very complex and brittle. Seems only to be needed for stdin and stdout. And I am not sure it works (I fear incompatible versions of assembler sources). I will light it up and see how it goes.?
Personally my reading of all the code is people are only using the traditional library and not the resident one, however by changing the GCC calling prologue it is doing potentially evil.
I am not being critical, we are all volunteers, and I am often wrong. I am just trying to report what I see and be transparent! Please don't anyone take offence :-)
Anyway I think I will test it. If it works, my bad, I will try harder.
If it does not work I will unwind all the weird stuff and make it a baseline traditional library. I hope this will still work for rexx (perhaps it will be too big to go into high mem?)
Then I will implement a resident library. Using a c static variable for stdin etc.
|
Re: GCCRES (GCCLIB Res Stub) is rather large
On Sat, Feb 15, 2020 at 05:57 PM, Dave Wade wrote:
REXX to be dynamically loaded into high memory, so it can call
But does gcclib need to be resident to allow rexx to be resident? And is loaded in high memory the same as resident? I am assuming so ... The solution I am looking at seems very complex and brittle. Seems only to be needed for stdin and stdout. And I am not sure it works (I fear incompatible versions of assembler sources). I will light it up and see how it goes.? Personally my reading of all the code is people are only using the traditional library and not the resident one, however by changing the GCC calling prologue it is doing potentially evil. I am not being critical, we are all volunteers, and I am often wrong. I am just trying to report what I see and be transparent! Please don't anyone take offence :-) Anyway I think I will test it. If it works, my bad, I will try harder. If it does not work I will unwind all the weird stuff and make it a baseline traditional library. I hope this will still work for rexx (perhaps it will be too big to go into high mem?) Then I will implement a resident library. Using a c static variable for stdin etc.
|
Re: GCCRES (GCCLIB Res Stub) is rather large
Adrian, As I said to Rene a while ago, the while point of all of this is to allow REXX to be dynamically loaded into high memory, so it can call other programs that run in the user space without getting over written. Usually CMS loads things at 20000 (hex) so if you generate REXX as a normal module then when you call another program you wipe yourself out. I believe that if your program uses OS storage macros, when an OS program terminates CMS re-initializes the storage so its important that REXX does not use any OS macros either. Dave (btw some small CMS programs load at E000, the transient program area, but REXX won’t fit there, an any way if it then called a program that runs there it would still over write its self) ?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]> On Behalf Of adriansutherland67
Sent: 15 February 2020 17:19
To: [email protected]
Subject: [h390-vm] GCCRES (GCCLIB Res Stub) is rather large? It is disappointingly large relative to the real library - need to improve this (otherwise why bother!)
It is full of stub functions like this one ? ? ? ? ?L? ? ?R15,=V(GCCANCHR) get anchor ptr ? ? ? ? ?L? ? ?R15,0(R15)? ? ? ?get the anchor ? ? ? ? ?LA? ? R15,VTGETS(R15) ? ? ? ? ?BR? ? R15? ? ? ? ? ? go there ? ? ? ? ?END
I don't fully understand it yet. The point is that each stub is a seperate file/member.
Two questions are:
1.VTABLE is quite large. Is it being duplicated in each member? Hence the large size of the TXTLIB. If I put more than one function / sub in the same ASSEMBLE would it therefore be smaller?
2. When linking does it only pull in the members used? Or does it pull in everything from the library?
Thanks again!
|
GCCRES (GCCLIB Res Stub) is rather large
It is disappointingly large relative to the real library - need to improve this (otherwise why bother!) It is full of stub functions like this one
? ? ? ? ?EXTRN GCCANCHR
GETS? ? ?CSECT
? ? ? ? ?USING GETS,R15
? ? ? ? ?L? ? ?R15,=V(GCCANCHR) get anchor ptr
? ? ? ? ?L? ? ?R15,0(R15)? ? ? ?get the anchor
? ? ? ? ?LA? ? R15,VTGETS(R15)
? ? ? ? ?BR? ? R15? ? ? ? ? ? go there
? ? ? ? ?LTORG
? ? ? ? ?VTABLE
? ? ? ? ?REGEQU
? ? ? ? ?END
I don't fully understand it yet. The point is that each stub is a seperate file/member.
Two questions are:
1.VTABLE is quite large. Is it being duplicated in each member? Hence the large size of the TXTLIB. If I put more than one function / sub in the same ASSEMBLE would it therefore be smaller?
2. When linking does it only pull in the members used? Or does it pull in everything from the library?
Thanks again!
|
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
GLOBAL TXTLIB GCCLIB
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: Blank last line blues
On Thu 13 Feb 2020 at 14:28:24 -0800, adriansutherland67 wrote: Just to make you guys smile ...
In the world of Unix rather dopey old software had issues with last
lines not ending with a LF. I guess that is because once upon a time, on early Unix, a line was defined as zero or more characters ended by a LF. So picky software can rightly say that if there isn't a LF at the end, it isn't a line. I also think that some common patterns for reading lines character by character would indeed effectively overlook such lines. -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG"
|
Just to make you guys smile ...
In the world of Unix rather dopey old software had issues with last lines not ending with a LF. And you still get warnings and lots of modern editors add a blank line at the end of files as a matter of course. Moreover the conversions between LF and CRLF seem to add a line, sometimes.
And in CMS ... In Assembler files blank lines are not ignored, some excuse about punch cards. And of course CMS has fixed sized records etc etc.
So I carefully made sure my yata thingy religiously preserved? any empty lines at the end of files. Big mistake.
They just creep in ... Linux, windows, editors, git, the empty last line ... Well they breed.
Anyway ... I will have to change yata to remove the emply last line when extracting files on CMS. Funny but irritating!
|
On Thu, Feb 13, 2020 at 10:52 AM, rvjansen@... wrote:
Maybe we could have a downstream of that repository in an MVS subdirectory.
Let me know if you want me to do that - A
|
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
|
One More Thing:
other people (Peter Jacob, Mike Grossmann ) are working on BREXX for OS/VS 3.8 (MVS) TK4- which runs quite nice - their repo is at?
They have forked, with permission, only the relevant code for MVS. I imagine some of the problems will be the same. Maybe we could have a downstream of that repository in an MVS subdirectory. I spoke to the TSO team, which owns the z/OS Rexx code, and they have no plans for 64 bit. Likewise, the Rexx compiler, which is in the Icing department, will not be modified, although I spoke to the original Vienna compiler team to ask them if they would do a ’Space Cowboys) effort for taking it to 54 bits. Some were tempted, and the (then) IBM compiler owner was amused, but it is not to be. For me, there is no reason not to attempt 64 bit builds of BREXX, Regina and (eventually) ooRexx. Our Brexx experience could be valuable here.
best regards,
搁别苍é. ?
toggle quoted message
Show quoted text
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.
Yes, I have a fork of Bill Vlachoudis’s repository at rvjansen/brexx, because I use that for pull requests for macos. Maybe it’s best if you also fork from the main brexx repository, than I can fork yours for pull requests and use the issue system. There is a CMS directory; I suggest we put the current code on BREXX 191 in there. If we put the [FILENAME] ORIG files there first, we can track the diffs with git.
btw, that odd bug with division seems to be in INTERPRET:
type test2 exec ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* */ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? SAY 100/81 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Ready; T=0.01/0.01 10:30:54 ? ? ? ? ? ? ? ? ? ? ? test2 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 1.2345679 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Ready; T=0.02/0.03 10:30:58 ? ? ? ? ? ? ? ? ? ? ? say 100/81 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? 1.2345679zABCDEFGHIJKLMNOPQRSTUVWXYZ0123 ? ? ? ?? Ready; T=0.02/0.03 10:31:06 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? So that is one clue.
btw2 I don’t care about licenses, we should respect what people put in their comments.
best regards,
搁别苍é.
On 13 Feb 2020, at 11:27, adriansutherland67 < adrian@...> wrote:
On Wed, Feb 12, 2020 at 01:42 PM, adriansutherland67 wrote: I will create a CMS BREXX project directly and ping the link So I made a repository -??- (and guessed licenses - wrongly) - but then noticed this?the motherload. So we have a couple of choices ... 1. If the port didn't change the code (only added to it), we can have a repository, pull in his code as a submodule and just do the build and install scripts and add any special code to handle CMS. Looking at his repository it has a MVS folder that implies this is feasible. 2. Fork and (being good citizens) provide pull requests for any code fixes we might do Thoughts? I think we should try 1 ... A
|
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.
toggle quoted message
Show quoted text
Yes, I have a fork of Bill Vlachoudis’s repository at rvjansen/brexx, because I use that for pull requests for macos. Maybe it’s best if you also fork from the main brexx repository, than I can fork yours for pull requests and use the issue system. There is a CMS directory; I suggest we put the current code on BREXX 191 in there. If we put the [FILENAME] ORIG files there first, we can track the diffs with git.
btw, that odd bug with division seems to be in INTERPRET:
type test2 exec ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* */ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? SAY 100/81 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Ready; T=0.01/0.01 10:30:54 ? ? ? ? ? ? ? ? ? ? ? test2 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 1.2345679 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Ready; T=0.02/0.03 10:30:58 ? ? ? ? ? ? ? ? ? ? ? say 100/81 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? 1.2345679zABCDEFGHIJKLMNOPQRSTUVWXYZ0123 ? ? ? ?? Ready; T=0.02/0.03 10:31:06 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? So that is one clue.
btw2 I don’t care about licenses, we should respect what people put in their comments.
best regards,
搁别苍é.
On 13 Feb 2020, at 11:27, adriansutherland67 < adrian@...> wrote:
On Wed, Feb 12, 2020 at 01:42 PM, adriansutherland67 wrote: I will create a CMS BREXX project directly and ping the link So I made a repository -??- (and guessed licenses - wrongly) - but then noticed this?the motherload. So we have a couple of choices ... 1. If the port didn't change the code (only added to it), we can have a repository, pull in his code as a submodule and just do the build and install scripts and add any special code to handle CMS. Looking at his repository it has a MVS folder that implies this is feasible. 2. Fork and (being good citizens) provide pull requests for any code fixes we might do Thoughts? I think we should try 1 ... A
|
Yes, I have a fork of Bill Vlachoudis’s repository at rvjansen/brexx, because I use that for pull requests for macos. Maybe it’s best if you also fork from the main brexx repository, than I can fork yours for pull requests and use the issue system. There is a CMS directory; I suggest we put the current code on BREXX 191 in there. If we put the [FILENAME] ORIG files there first, we can track the diffs with git.
btw, that odd bug with division seems to be in INTERPRET:
type test2 exec ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? /* */ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? SAY 100/81 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Ready; T=0.01/0.01 10:30:54 ? ? ? ? ? ? ? ? ? ? ? test2 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 1.2345679 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Ready; T=0.02/0.03 10:30:58 ? ? ? ? ? ? ? ? ? ? ? say 100/81 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? 1.2345679zABCDEFGHIJKLMNOPQRSTUVWXYZ0123 ? ? ? ?? Ready; T=0.02/0.03 10:31:06 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? So that is one clue.
btw2 I don’t care about licenses, we should respect what people put in their comments.
best regards,
搁别苍é.
toggle quoted message
Show quoted text
On 13 Feb 2020, at 11:27, adriansutherland67 < adrian@...> wrote:
On Wed, Feb 12, 2020 at 01:42 PM, adriansutherland67 wrote:
I will create a CMS BREXX project directly and ping the link
So I made a repository -??- (and guessed licenses - wrongly) - but then noticed this?the motherload. So we have a couple of choices ... 1. If the port didn't change the code (only added to it), we can have a repository, pull in his code as a submodule and just do the build and install scripts and add any special code to handle CMS. Looking at his repository it has a MVS folder that implies this is feasible. 2. Fork and (being good citizens) provide pull requests for any code fixes we might do Thoughts? I think we should try 1 ... A
|
There are substantial changes because original assumes ASCII. Some where we have a separate licence.??
Dave
On Thu, 13 Feb 2020, 10:27 am adriansutherland67, < adrian@...> wrote: On Wed, Feb 12, 2020 at 01:42 PM, adriansutherland67 wrote:
I will create a CMS BREXX project directly and ping the link
So I made a repository -??- (and guessed licenses - wrongly) - but then noticed this?the motherload. So we have a couple of choices ...
1. If the port didn't change the code (only added to it), we can have a repository, pull in his code as a submodule and just do the build and install scripts and
add any special code to handle CMS. Looking at his repository it has a MVS folder that implies this is feasible.
2. Fork and (being good citizens) provide pull requests for any code fixes we might do
Thoughts? I think we should try 1 ...
A
|
On Wed, Feb 12, 2020 at 01:42 PM, adriansutherland67 wrote:
I will create a CMS BREXX project directly and ping the link
So I made a repository -??- (and guessed licenses - wrongly) - but then noticed this?the motherload. So we have a couple of choices ... 1. If the port didn't change the code (only added to it), we can have a repository, pull in his code as a submodule and just do the build and install scripts and add any special code to handle CMS. Looking at his repository it has a MVS folder that implies this is feasible. 2. Fork and (being good citizens) provide pull requests for any code fixes we might do Thoughts? I think we should try 1 ... A
|
Re: Stupid Question - how to add a file to MAINT MNT19E
On 2/12/20 3:45 AM, Bob Bolch wrote: The ability to make only certain filemode number files visible, like filemode 2 files on the S and Y disks,
was not a security mechanism. It was a way to save storage by making only necessary files visible.
Maintenance files were not needed during ordinary use. It was convenient to place them on the system
disk.
VM data security was based on the architecture?that made one user's disks completely unavailable to
another user who does not have the disk read or write passwords. And then there was the Romulan Cloaking Device (RLD) which created a second directory on the disk.?? Rather dangerous actually, as hidden files would get clobbered if the directory they were hidden from was used for read/write.
|
Re: Stupid Question - how to add a file to MAINT MNT19E
On 2/11/20 10:33 PM, adriansutherland67
wrote:
On Tue, Feb 11, 2020 at 11:16 PM, Peter Coghlan wrote:
Then I used DDR to copy the original disk which I only
had read access to
onto the temporary disk. Because I had read/write access to the
temporary
disk, the standard ACCESS command let me see all the files on
it.
Those were more innocent times, well in terms of IT security at
least ...
_._,_._,_
Well, yes.? Consider I used DDR to dump the raw tracks of the MVS
master catalog for its password a couple of weeks ago.
And of course, all those clear text passwords in the USER DIRECT
...
-ahd-
|
