Re: File hrc403ds.memo deleted
I had accidentlly put HRC403DS MEMO in the wrong directory.
It is? in the HRC403DS directory now, as it should be.
Bob
|
File hrc403ds.memo deleted
Hello!
Bob? What was on the file that you were convinced it needed to be
deleted from the site?
And of course one person reading that will need extraterrestrial help
to understand it.
-----
Gregg C Levine gregg.drwho8@...
"This signature fought the Time Wars, time and again."
|
Re: CMS updates for Nucleus Extenstions and CMS Subcommands
Adrian and I are currently testing an EXECCOMM subcommand interface into BREXX, built for CMS with HRC404DS in place. I am testing a full function EXECIO?command?built to match the early VM documentation of the command. It is going to take a lot of testing because of all the options and combination of options you can use.?
Bob Bolch
On Sat, Aug 29, 2020 at 8:24 AM Peter Coghlan < groups@...> wrote: >
> Thank you Peter.
>
Thank you for taking on this CMS stuff.? I just seem to sink into quicksand
every time I go near CMS.? I get confused about how many times I have been
through the SVC 202 interface :-(
>
> My updates do assume that the Sixpack updates are already supplied.
>
A valid assumption.
>
> You are right that the NUCXDROP ABEND is too harsh. I'll provide an update
> to issue a message and error return code.
>
Great - thanks!
>
> Being able to use BLOCKTAP is so great!! Those old tapes have some
> support neat
> stuff. I even found an old set of code for the 7171 on there, that I wrote
> long ago.
> So many tools from the old days are there, that I have not had time to look
> at them all yet.
>
Years ago, I was looking for a CP modification to get a 7171 to drop the line
on logoff or disconnect when I ran into the BLOCKTAP roadblock.? I never got
around to finding a way past it until now.
I wrote an EXECCOMM interface for the EXEC processor (because some package I
was trying to build needed it).? I added the EXECCOMM command into the CMS
command table in DMSFNC as a quick hack to make this work.? Now I can change
it to register EXECCOMM properly using SUBCOM.? I just need to figure out
where to make the SUBCOM call from.
Regards,
Peter Coghlan.
|
Re: CMS updates for Nucleus Extenstions and CMS Subcommands
Thank you Peter.
Thank you for taking on this CMS stuff. I just seem to sink into quicksand every time I go near CMS. I get confused about how many times I have been through the SVC 202 interface :-(
My updates do assume that the Sixpack updates are already supplied.
A valid assumption.
You are right that the NUCXDROP ABEND is too harsh. I'll provide an update
to issue a message and error return code.
Great - thanks!
Being able to use BLOCKTAP is so great!! Those old tapes have some
support neat
stuff. I even found an old set of code for the 7171 on there, that I wrote
long ago.
So many tools from the old days are there, that I have not had time to look
at them all yet.
Years ago, I was looking for a CP modification to get a 7171 to drop the line on logoff or disconnect when I ran into the BLOCKTAP roadblock. I never got around to finding a way past it until now. I wrote an EXECCOMM interface for the EXEC processor (because some package I was trying to build needed it). I added the EXECCOMM command into the CMS command table in DMSFNC as a quick hack to make this work. Now I can change it to register EXECCOMM properly using SUBCOM. I just need to figure out where to make the SUBCOM call from. Regards, Peter Coghlan.
|
Re: CMS updates for Nucleus Extenstions and CMS Subcommands
Thank you Peter.
My updates do assume that the Sixpack updates are already supplied.
You are right that the NUCXDROP?ABEND is too harsh. I'll provide an update to issue a message and error return code.
Being able to use BLOCKTAP is so great!! Those old tapes have some support?neat? stuff. I even found?an old set of code for the 7171 on there, that I wrote long ago. So many tools from the old days are there, that I have not had time to look at them all yet.
Bob
Bob
On Fri, Aug 28, 2020 at 10:20 AM Peter Coghlan < groups@...> wrote: 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.
>
> 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
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:
|
carlos feldman
Jim Snellen