Re: CMS updates for Nucleus Extenstions and CMS Subcommands
This is great work Bob - well done and many thanks.
I've managed to successfully install HRC403DS and HRC404DS on my pre-sixpack
system without any difficulty as long as I have already installed HRC309DS.
This is much nicer than the temporary NUCEXT/EXECCOMM hacks I have been
using up to now.
I can now build IUCVTRAP and have it load itself as a nucleus extension
without having to make any hacks to it like I did previously and I can
also use BLOCKTAP now which I never got around to getting working with my
previous setup.
I only found one tiny snag. If I try to NUCXDROP something that has not
actually been loaded, I get this:
nucxdrop foobar
DMSABN155T USER ABEND 0001 CALLED FROM 00E18E.
CMS
which I guess is a valid response to my user error but it does seem a
little bit harsh, particularly if I did it within a CMS subset.
Regards,
Peter Coghlan.
toggle quoted message
Show quoted text
The BREXX development team uploaded two sets of updates to the FILES area
today in the "CMS Extensions for BREXX" folder. The first expands the NUCON
area to allow future updates, and the second provides support for Nucleus
Extensions and Subcommands in VM/370. These updates will allow a future
BREXX release (soon to be available) to use existing REXX Function Packages.
Also, BREXX will soon be able to establish an EXECCOMM subcommand
environment to work with an upcoming EXECIO command. NUCXMAP and
NUCXDROP commands are included but there is no NUCXLOAD command. This level
of CMS does not have relocatable MODULEs. We are thinking about a new
command to load TEXT files as Nucleus Extensions. The support will run any
self-loading REXX Function Packages. The IBM RXUSERFN sample program,
documented in manuals from VM/SP or later runs under this support.
We plan to release an updated BREXX very soon that exploits these
facilities.
Please respond with any questions or comments.
I also added a VMARC file in the same directory for the old
BLOCKTAP facility written by Steve Howes, then at BYU. Some of the
currently downloadable VMSHARE tapes were encoded using BLOCKTAP and are
unreadable on VM/370. BLOCKTAP runs as a Nucleus Extension. Using it will
allow you to read some of the 1980s era VMSHARE tapes. See
Bob Bolch
|
Re: CMS updates for Nucleus Extenstions and CMS Subcommands
I forgot to say where the updates are located.
The NUCON update is in folder HRC403DS in the CMS Extensions for BREXX folder.
The Nucleus Extensions and Subbcommand support updates are the
folder HRC404DS in the folder CMS Extensions for BREXX.
Bob Bolch
|
Re: CMS updates for Nucleus Extenstions and CMS Subcommands
toggle quoted message
Show quoted text
On 27 Aug 2020, at 11:19, Bob Bolch < Bob@...> wrote:
The?BREXX development team uploaded two sets of updates to the FILES area today in the "CMS Extensions for BREXX" folder. The first expands the NUCON area to allow future updates, and the second provides support for Nucleus Extensions and Subcommands in VM/370. These updates will allow a future BREXX release (soon to be available) to use existing?REXX Function Packages. Also, BREXX will soon be able to establish an EXECCOMM subcommand environment to work with an upcoming EXECIO command. NUCXMAP?and NUCXDROP?commands are included but there is no NUCXLOAD command. This level of CMS does not have relocatable?MODULEs. We are thinking about a new command to load TEXT files as Nucleus Extensions. The support will run any self-loading REXX Function?Packages. The IBM RXUSERFN sample program, documented in manuals from VM/SP or later runs under this support.?
We plan?to release an updated BREXX very soon that exploits these facilities.
Please respond with any questions or comments.
I also added a VMARC? file in the same directory for the old BLOCKTAP?facility written by Steve Howes, then at BYU. Some of the currently downloadable VMSHARE tapes were encoded using BLOCKTAP and are unreadable on VM/370. BLOCKTAP runs as a Nucleus Extension. Using it will allow you to read some of the 1980s era VMSHARE tapes. See
Bob Bolch
|
CMS updates for Nucleus Extenstions and CMS Subcommands
The?BREXX development team uploaded two sets of updates to the FILES area today in the "CMS Extensions for BREXX" folder. The first expands the NUCON area to allow future updates, and the second provides support for Nucleus Extensions and Subcommands in VM/370. These updates will allow a future BREXX release (soon to be available) to use existing?REXX Function Packages. Also, BREXX will soon be able to establish an EXECCOMM subcommand environment to work with an upcoming EXECIO command. NUCXMAP?and NUCXDROP?commands are included but there is no NUCXLOAD command. This level of CMS does not have relocatable?MODULEs. We are thinking about a new command to load TEXT files as Nucleus Extensions. The support will run any self-loading REXX Function?Packages. The IBM RXUSERFN sample program, documented in manuals from VM/SP or later runs under this support.?
We plan?to release an updated BREXX very soon that exploits these facilities.
Please respond with any questions or comments.
I also added a VMARC? file in the same directory for the old BLOCKTAP?facility written by Steve Howes, then at BYU. Some of the currently downloadable VMSHARE tapes were encoded using BLOCKTAP and are unreadable on VM/370. BLOCKTAP runs as a Nucleus Extension. Using it will allow you to read some of the 1980s era VMSHARE tapes. See
Bob Bolch
|
The word I got when I attempted to report this, along with several other issues, well over 40 years ago was ¡°won¡¯t fix¡±.? The reason given was that there is other IBM code that relies on the current behavior and the coordinated fix required is ¡°impossible¡±. ? A major case in point is that STAE is permanently broken (first noted in 1974). Fixing STAE (the correct thing to do) breaks the runtime for COBOL, FORTRAN, and PL/I. In working with a major debugger in the 1980s at an ISV when this became a major issue, I ended up intercepting the old PSWs and running filters as to what to let pass through and what to intercept, then reformatting into STAE and ESTAE exit routines when and where appropriate. ? Mark L. Gaubatz ? ?
toggle quoted message
Show quoted text
From: [email protected] < [email protected]> On Behalf Of Bob Bolch Sent: Wednesday, August 19, 2020 7:40 AM To: [email protected]Subject: [h390-vm] Funny CMS problem ? I started working on an obscure bug in an?update I am working on to?add MAKEBUF,?DROPBUF, and SENTRIES to CMS on VM/370. CMS always provided some simple support for various macros used in TSO programs, so this type of program could be ported over to CMS without changes (in some cases). This particular TSO macro (TCLEARQ) is supposed?to clear out any pending input?console data that the program has not processed yet. Anyway, my test case showed that my update did NOT clear the console input queue when TCLEARQ?was issued.?? I finally tracked it down to the fact that the macro set up the input parameters in a specific way, but that the CMS handler code expected?the parameters to be set up in a different way. The fact is that the CMS processing for this macro never worked. I took my test case over to a z/VM system, and IT FAILS?THE SAME WAY!? That means that no one has ever used this interface in any VM release. I asked?one of my friends at my old job to look at the z/VM source and the bug is still there after almost half a century.? I decided to leave out the TCLEARQ?part of my update :-)? If someone ever fixes the CMS bug and uses the macro, I will fix my update then!!
|
±á¾±?¸é±ð²Ô¨¦, Just waiting suits me!!
I will check on it once a decade to see if they fix it :-) Bob
Hi Bob,
Great story! I am on the last days of a z/VM contract so I could open a PMR if you want. ¸é±ð²Ô¨¦. On 19 Aug 2020, at 16:40, Bob Bolch <Bob@...> wrote:
? I started working on an obscure bug in an?update I am working on to?add MAKEBUF,?DROPBUF, and SENTRIES to CMS on VM/370. CMS always provided some simple support for various macros used in TSO programs, so this type of program could be ported over to CMS without changes (in some cases). This particular TSO macro (TCLEARQ) is supposed?to clear out any pending input?console data that the program has not processed yet. Anyway, my test case showed that my update did NOT clear the console input queue when TCLEARQ?was issued.??
I finally tracked it down to the fact that the macro set up the input parameters in a specific way, but that the CMS handler code expected?the parameters to be set up in a different way. The fact is that the CMS processing for this macro never worked. I took my test case over to a z/VM system, and IT FAILS?THE SAME WAY!? That means that no one has ever used this interface in any VM release. I asked?one of my friends at my old job to look at the z/VM source and the bug is still there after almost half a century.?
I decided to leave out the TCLEARQ?part of my update :-)? If someone ever fixes the CMS bug and uses the macro, I will fix my update then!!
Bob Bolch
|
Hi Bob,
Great story! I am on the last days of a z/VM contract so I could open a PMR if you want. ¸é±ð²Ô¨¦.
toggle quoted message
Show quoted text
On 19 Aug 2020, at 16:40, Bob Bolch <Bob@...> wrote:
? I started working on an obscure bug in an?update I am working on to?add MAKEBUF,?DROPBUF, and SENTRIES to CMS on VM/370. CMS always provided some simple support for various macros used in TSO programs, so this type of program could be ported over to CMS without changes (in some cases). This particular TSO macro (TCLEARQ) is supposed?to clear out any pending input?console data that the program has not processed yet. Anyway, my test case showed that my update did NOT clear the console input queue when TCLEARQ?was issued.??
I finally tracked it down to the fact that the macro set up the input parameters in a specific way, but that the CMS handler code expected?the parameters to be set up in a different way. The fact is that the CMS processing for this macro never worked. I took my test case over to a z/VM system, and IT FAILS?THE SAME WAY!? That means that no one has ever used this interface in any VM release. I asked?one of my friends at my old job to look at the z/VM source and the bug is still there after almost half a century.?
I decided to leave out the TCLEARQ?part of my update :-)? If someone ever fixes the CMS bug and uses the macro, I will fix my update then!!
Bob Bolch
|
I started working on an obscure bug in an?update I am working on to?add MAKEBUF,?DROPBUF, and SENTRIES to CMS on VM/370. CMS always provided some simple support for various macros used in TSO programs, so this type of program could be ported over to CMS without changes (in some cases). This particular TSO macro (TCLEARQ) is supposed?to clear out any pending input?console data that the program has not processed yet. Anyway, my test case showed that my update did NOT clear the console input queue when TCLEARQ?was issued.??
I finally tracked it down to the fact that the macro set up the input parameters in a specific way, but that the CMS handler code expected?the parameters to be set up in a different way. The fact is that the CMS processing for this macro never worked. I took my test case over to a z/VM system, and IT FAILS?THE SAME WAY!? That means that no one has ever used this interface in any VM release. I asked?one of my friends at my old job to look at the z/VM source and the bug is still there after almost half a century.?
I decided to leave out the TCLEARQ?part of my update :-)? If someone ever fixes the CMS bug and uses the macro, I will fix my update then!!
Bob Bolch
|
I have uploaded a new update to folder "CMS Extensions for BREXX"
in the subfolder for HRC402DS. This update streamlines the way that CMS calls BREXX?
for EXEC files identified as REXX programs. This works with the GCC release 0.7.16
and BREXX release 0.9.6 available now.
See HRC402DS MEMO for installation instructions and HRC403DS.VMARC for updates.
Bob Bolch
|
Docker image (1.4.20/latest)
Finally got through the bulk of the IO changes and so can do a release - will now revert to weekly releases to get some cadence going. This release also includes some CMS Mods (Thanks Bob Bolch).
Updates in the usual places -?
Change History
Release Assets
Docker Image
|
Re: vm/sp 5.5 living computer museum
My usual disclaimer (if you came in late): I do not work for the LCM+L? and I do not speak for them. On 7/26/20 7:50 AM, rvjansen@... wrote: It¡¯s back! So apparently without the flex-es sollicitor From what can be seen at login, it's little a more complicated than that. The details of "what" are left as an exercise for the user. :-) and a brand-new system generated A new system generation of CP can be for simple as fixing a typo on the logon screen or whacking the system name.? It's like Linux -- "regen the system twice and call me in the morning." and IPLed two days ago! Every time I nudge the SSD USB cable on my Raspberry Pi the system crashes (and takes my personal Hercules instances with it), so I'm not sure that matters much.? (The real 4361 has had its moments of flakiness as well.) Thanks for the great work and Thank whomever is still at the LCM+L, not me. thanks for telling us on the list. You're welcome on that one.? (I've got a menu item for connecting to it, so it's easy to check.) -ahd- p.s. "it's little a more complicated than that" originated in 1989 with The Grey-Eyed Elf.? Last Wednesday (22 July) made it 31 years since I met her in person.? :-) -- Drew Derbyshire "Live free or die; death is not the worst of evils." -- Gen. John Stark
|
Re: vm/sp 5.5 living computer museum
It¡¯s back! So apparenrtly without the flex-es sollicitor and a brand-new system generated and IPLed two days ago! Thanks for the great work and thanks for telling us on the list.
best regards,
toggle quoted message
Show quoted text
On 26 Jul 2020, at 07:34, Drew Derbyshire < swhobbit@...> wrote:
On Fri, Jul 3, 2020 at 04:40 AM, rvjansen@... wrote:
Does anybody know? The 4361? Is it gone now?? Try it and see. -ahd-
p.s. My usual disclaimer applies.?
|
Re: vm/sp 5.5 living computer museum
On Fri, Jul 3, 2020 at 04:40 AM, rvjansen@... wrote:
Does anybody know? The 4361? Is it gone now??
Try it and see.
-ahd-
p.s. My usual disclaimer applies.?
|
|
|
Re: Hercules and Window 10
As a retiree and former VM systems programmer, I did the same and am really enjoying the memories!
Jim
Kentucky, USA
toggle quoted message
Show quoted text
On Jul 12, 2020, at 12:11 PM, carlos feldman <carlfelster@...> wrote:
|
Re: Hercules and Window 10
I installed the last? hecules ( 64 bit ), copied the sixpack to my choosen directory, adjusted the scripts to reflect the directory and voila !!! it was playing VM/CMS !!
No troubles at all
--
Carlos
Argentina
|
Re: vm/sp 5.5 living computer museum
On 7/9/20 12:50 AM, gpcramins@... wrote: Just a side note, I see you are a licensed ham radio operator. I am as
well, call sign AE5HL.
We just closed on a house and moved last month, no antennas up yet, but
the check is in the mail, looking to cover 40/20/15/10 meters, similar
to my old setup. (I assume this was directed at me) Sounds great, congrats on your new place and good luck getting your HF antennas up. I've not keyed up a transmitter in forever, zero (or less than zero) free time, but I do miss it. Someday.. -Dave -- Dave McGuire, AK4HZ New Kensington, PA
|
Re: MAKEBUF, DROPBUF, SENTRIES
I am not quite sure what the question is here but SENTRIES is a command that gives the same information as queued() in your example.
You are correct that adding "(STACK" is the VM way of putting the output of the command/module onto the latest program input stack. It provided a easy work around to ensure that EXEC processors and Rexx could access the information. It was never elegant as is demonstrate if your program exits unexpectedly, at which point CMS will take the program stack as input. If the stack contains a list of files, then multiple other programs got fired up. All very quirky.
Ant
|
Re: MAKEBUF, DROPBUF, SENTRIES
I looked up how those commands handled the CMS control blocks, and writing the support turned out to be trivial. I'll post it after more testing.
Anyone porting in old REXX tools from later CMS systems will need these.
Bob
Was waiting for someone more knowledgeable to answer this, but in BREXX you can do something like this:
'coap-client -m get -u "'TF_USERNAME'" -k "'KEY'" -B "1" coaps://'TF_GATEWAYIP':5684/15001/'pilot' (STACK' if queued() <> 1 then exit 99
¡ which controls my IKEA home automation gateway.
That (STACK construct looks a lot like what some commands on VM do, but it seems unique to BREXX (where ANSI REXX says ¡®address with¡¯), and it is generalised to all command environment commands. The same construct works on VM/370 but I do not know whether it uses the VM program stack or not. As MAKEBUF seems to work with EXEC2 I assume it was added around the same time.?
BREXX does have a ¡®makebuf¡¯ function, as mention in Howard Fosdick¡¯s book on page 363. (??) So I guess for MAKEBUF and friends, we would need a way to connect PARSE PULL and the program stack. SENTRIES I never even heard of, so thank you for that.
¸é±ð²Ô¨¦. On 8 Jul 2020, at 13:23, Bob Bolch < Bob@...> wrote:
Has anyone looked at doing these for VM/370? With the newest BREXX developments, these interfaces seem necessary to me. I would love it if someone already has this working! If not, I will proceed in making them.
Bob Bolch
|
Re: MAKEBUF, DROPBUF, SENTRIES
Was waiting for someone more knowledgeable to answer this, but in BREXX you can do something like this:
if queued() <> 1 then exit 99
¡ which controls my IKEA home automation gateway.
That (STACK construct looks a lot like what some commands on VM do, but it seems unique to BREXX (where ANSI REXX says ¡®address with¡¯), and it is generalised to all command environment commands. The same construct works on VM/370 but I do not know whether it uses the VM program stack or not. As MAKEBUF seems to work with EXEC2 I assume it was added around the same time.?
BREXX does have a ¡®makebuf¡¯ function, as mention in Howard Fosdick¡¯s book on page 363. (??) So I guess for MAKEBUF and friends, we would need a way to connect PARSE PULL and the program stack. SENTRIES I never even heard of, so thank you for that.
¸é±ð²Ô¨¦.
toggle quoted message
Show quoted text
On 8 Jul 2020, at 13:23, Bob Bolch < Bob@...> wrote:
Has anyone looked at doing these for VM/370? With the newest BREXX developments, these interfaces seem necessary to me. I would love it if someone already has this working! If not, I will proceed in making them.
Bob Bolch
|
carlos feldman
Jim Snellen
Dave McGuire
Anthony Smith