Re: Stupid Question - how to add a file to MAINT MNT19E
Thank you all ... You are gentlemen and scholars!
I will try tomorrow.
Btw ... What does?the 2 in the filemode signify?
|
Re: Stupid Question - how to add a file to MAINT MNT19E
Make sure its mode Y2 as well ? Dave ?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]> On Behalf Of George Shedlock
Sent: 11 February 2020 21:25
To: [email protected]
Subject: Re: [h390-vm] Stupid Question - how to add a file to MAINT MNT19E? On 2/11/2020 3:45 PM, adriansutherland67 wrote: So I logged on to MAINT
Acc 19e C
Copied the file
But although the new file is on the "c" drive (even after an IPL) it is not visible on Y/S (for MAINT or anyone)
And then in the back of my mind something about he Y/S means something - delta??????
Anyway I am obviously missing part of the?incantation - can anyone help?
Thanks
Adrian
?
|
Re: Stupid Question - how to add a file to MAINT MNT19E
Filemode as target must be C2 based on your description. ? Mark ? ?
toggle quoted message
Show quoted text
From: [email protected] <[email protected]> On Behalf Of adriansutherland67
Sent: Tuesday, February 11, 2020 12:45 PM
To: [email protected]
Subject: [h390-vm] Stupid Question - how to add a file to MAINT MNT19E ? So I logged on to MAINT
Acc 19e C
Copied the file
But although the new file is on the "c" drive (even after an IPL) it is not visible on Y/S (for MAINT or anyone)
And then in the back of my mind something about he Y/S means something - delta??????
Anyway I am obviously missing part of the?incantation - can anyone help?
Thanks
Adrian
|
Re: Stupid Question - how to add a file to MAINT MNT19E
So I logged on to MAINT
Acc 19e C
Copied the file
But although the new file is on the "c" drive (even after an IPL) it is
not visible on Y/S (for MAINT or anyone)
And then in the back of my mind something about he Y/S means something -
delta?????
Anyway I am obviously missing part of the?incantation - can anyone help?
Not a stupid question at all. It is tricky to make changes to files on the Y or S disks. As far as I recall, the directories for the Y and S disks are saved as part of the saved CMS system and these saved directories are only updated when the CMS system is saved again. Does it not say this somewhere in SYSPROG MEMO or somewhere like that? I'd suggest something like this (which might not be correct): DEFINE STORAGE 16M IPL 190 SAVESYS CMS Regards, Peter Coghlan.
|
Re: Stupid Question - how to add a file to MAINT MNT19E
rel c
ipl 190 (clear
savesys cms
George
On 2/11/2020 3:45 PM,
adriansutherland67 wrote:
toggle quoted message
Show quoted text
So I logged on to MAINT
Acc 19e C
Copied the file
But although the new file is on the "c" drive (even after an IPL)
it is not visible on Y/S (for MAINT or anyone)
And then in the back of my mind something about he Y/S means
something - delta??????
Anyway I am obviously missing part of the?incantation - can anyone
help?
Thanks
Adrian
|
Stupid Question - how to add a file to MAINT MNT19E
So I logged on to MAINT
Acc 19e C
Copied the file
But although the new file is on the "c" drive (even after an IPL) it is not visible on Y/S (for MAINT or anyone)
And then in the back of my mind something about he Y/S means something - delta??????
Anyway I am obviously missing part of the?incantation - can anyone help?
Thanks
Adrian
|
On Tue, Feb 11, 2020 at 04:41 PM, rvjansen@... wrote:
break things this quickly and catastrophically and be able to start from scratch
For me the most useful "cultural" description is this. Computers and VMs are like pets, they have names and you keep them fed and healthy; containers are like cattle, they have no name and you shoot them if they get ill.
|
On Tue, Feb 11, 2020 at 04:41 PM, rvjansen@... wrote:
build mechanism
This is my most complex example - the script that builds my yata thingy -? Basically it IPLs, sends in 3 files via the card reader, does the build, runs a test, puts the binary on a tape, and shuts down
|
Hi Adrian,
works like a charm. Except high CPU usage of com.docker.hyperkit, but if I google around, that seems a macos docker app problem. Extremely useful for the type of thing I am planning to do, because I never have been able to break things this quickly and catastrophically and be able to start from scratch without touching my ‘precious’ images (i.e. those that have more work invested in them). Thank you for putting this together. I’ll study your build mechanism and will bother you with questions.
best regards,
搁别苍é.
toggle quoted message
Show quoted text
On 10 Feb 2020, at 13:49, adriansutherland67 < adrian@...> wrote:
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 ...
|
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,
|
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.
>>
>
>
>
>
>
|
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.
|
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.
|
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!) ?
|
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!
|
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: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
|
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
|
