开云体育

  1. H390-Vm
  2. Messages
Expanded Topics Messages Polls
Date
Re: Hyperion 4.2.1 looping but Hercules 3.13 ok

 

开云体育

Fish,
Thanks for such a detailed response.?

Where did your six pack come from? Perhaps I could download it and try it.? Also, I could use your config file.

After reading the Hyperion installation instructions again, I'm somewhat confused.? Since there isn't a .msi file for Hyperion 4.2.1 or installation executable,?I simply unzipped???into a C:\Hyperion folder and updated the system PATH replacing \Program Files\...R3.13 with \Hyperion. Could that be my problem?

Jim
Re: Hyperion 4.2.1 looping but Hercules 3.13 ok

 

I've never heard of that. What is it? Where do I get those files?

? ?It provides a KICKS environment for developing?CL CICS programs.

I downloaded , unzipped the file, and copied the /disk files into my test area.? Same results:
image.png

I changed LPARNUM?01 to LPARNUM?BASIC, added the CPUIDFMT?BASIC, and removed both parameters.? All had the same result which was no change.

I'm going to uninstall Hyperion and re-install it.


On Sep 12, 2020, at 11:15 AM, Fish Fish <david.b.trout@...> wrote:

?Fish wrote:
JimDooey wrote:

I’ve been running VM/370 Sixpack

Where did you download it from? I would like to try
the same thing for myself.

Never mind. I located my own original copy of the SixPack on my system that I tried a long time ago, and it appears to work just fine with the SDL Hyperion 4.2.1 version of Hercules. No looping, and VM/370 appears to be responsive. I can enter commands to VM/370 just fine and it responds just fine.

The version of the SixPack that I'm using *IS* different from the version that you appear to be using however:


The version of the SixPack that I AM using:

??/VM/370 Release 06 Hercules "SixPack" version 1.2: 07/19/15 16:01:24
??/Now 06:28:39 GMT SATURDAY 09/12/92


The version of the SixPack that YOU are using:

??/VM/370 Release 06 Hercules "SixPack" version 1.2: 08/13/10 00:06:27
??/Now 01:00:50 GMT TUESDAY 12/26/05



So it appears you are using a much older version of the VM/370 SixPack than I am. Have you tried using to most current version of the VM/370 SixPack instead? I forget where I got mine from. I think maybe it was Dave Wade's web site?

?



and the VM370Ext files

I've never heard of that. What is it? Where do I get those files?

I would still like to know what these files are! I've never heard of them before.


[...]
Subsequent attempts are done using a ckpt startup.? I may
have config file problem but I can’t find it.

One thing I noticed that doesn't seem right to me is you have
a LPARNUM 01 statement. As far as I know neither the 4381 nor
VM/370 supported LPARs. Have you tried either removing that
statement or changing it to LPARNUM BASIC instead?

This very likely is your problem!

I just performed the same exact test (IPL) again, but using LPARNUM 01 instead of LPARNUM BASIC, and guess what? I didn't work! I did not get a looping system like you (the instrcount was not rapidly increasing like yours was), but VM/370 itself was completely unresponsive. It appeared to have gotten "stuck" during startup/initialization.


In my previous normal IPL (using LPARNUM BASIC, which worked), I saw VM/370 issue the following messages:


07:28:39.271 /
07:28:39.273 /
07:28:39.273 /
07:28:39.274 /VM/370 Release 06 Hercules "SixPack" version 1.2: 07/19/15 16:01:24
07:28:39.274 /
07:28:39.274 /Now 06:28:39 GMT SATURDAY 09/12/92
07:28:39.274 /
07:28:39.274 /DMKCPI971I System is Uniprocessor generated
07:28:39.275 /DMKCPI977I Free Trap Installed
07:28:39.275 /
07:28:39.282 /DMKUDR476I System Directory loaded from volume VM50-1
07:28:39.282 /
07:28:39.377 /06:28:39 AUTO LOGON ??*** ??OPERATOR USERS = 001 ?BY ?SYSTEM
07:28:39.378 /
07:28:39.378 /DMKCPI957I Storage size = 16384 K, ??Nucleus = 316 K,
07:28:39.378 / ??????????Dynamic Paging = 14808 K, Trace Table = 240 K,
07:28:39.378 / ??????????Free Storage = 1020 K, ???Virtual=Real = 00000 K
07:28:39.379 /
07:28:39.484 /06:28:39 AUTO LOGON ??*** ??AUTOLOG1 USERS = 002 ?BY ?OPERATOR
07:28:39.484 /
07:28:39.490 /
07:28:40.746 /06:28:40 AUTO LOGON ??*** ??CPWATCH ?USERS = 003 ?BY ?AUTOLOG1
07:28:41.275 /06:28:41 RDR ?00C DRAINED ??SYSTEM
07:28:41.276 /06:28:41 PUN ?00D DRAINED ??SYSTEM ??CLASS = P ?????SEP
07:28:41.277 /06:28:41 PRT ?00E DRAINED ??SYSTEM ??CLASS = A ?????SEP
07:28:41.278 /06:28:41 PRT ?00F DRAINED ??SYSTEM ??CLASS = D ?????SEP
07:28:41.283 /06:28:41 AUTO LOGON ??*** ??CMSBATCH USERS = 004 ?BY ?AUTOLOG1
07:28:41.344 /06:28:41
07:28:41.344 / WNG FROM AUTOLOG1: ?AUTOLOG1 DONE - LOGGING OFF
07:28:41.345 /06:28:41 USER DSC LOGOFF AS AUTOLOG1 USERS = 003



When I tried the same thing using LPARNUM 01 however, I only saw the following VM/370 startup messages:


07:31:45.267 /
07:31:45.268 /
07:31:45.268 /
07:31:45.269 /VM/370 Release 06 Hercules "SixPack" version 1.2: 07/19/15 16:01:24
07:31:45.269 /
07:31:45.270 /Now 06:31:45 GMT SATURDAY 09/12/92
07:31:45.270 /
07:31:45.270 /DMKCPI971I System is Uniprocessor generated
07:31:45.270 /DMKCPI977I Free Trap Installed
07:31:45.270 /
07:31:45.271 /DMKUDR476I System Directory loaded from volume VM50-1
07:31:45.271 /
07:31:45.351 /06:31:45 AUTO LOGON ??*** ??OPERATOR USERS = 001 ?BY ?SYSTEM
07:31:45.351 /
07:31:45.352 /DMKCPI957I Storage size = 16384 K, ??Nucleus = 316 K,
07:31:45.352 / ??????????Dynamic Paging = 14808 K, Trace Table = 240 K,
07:31:45.352 / ??????????Free Storage = 1020 K, ???Virtual=Real = 00000 K
07:31:45.353 /



So it looks like VM/370 got "stuck" somewhere during initialization, and the ONLY difference between the two runs was the LPARNUM statement.

This makes sense too. The chosen LPARNUM value determines your CPUIDFMT value (which is the format that the STIDP (STORE CPU ID) instruction uses) which I'm guessing that VM/370 is very sensitive to. In fact, in my HercGUI product's Help file it clearly states in the section describing the LPAR Number:


??"LPAR Number is a critical configuration setting that
???can greatly influence how a guest operating system
???behaves since its value also controls the CPU ID format.
???Using the wrong value can easily cause your guest to
???not even IPL."

??"For older operating systems such as DOS/VS, MVS 3.8 and
???VM/370 the value "BASIC" should be used."



So either CHANGE your LPARNUM statement to "BASIC" instead, -or- remove it altogether, -or- insert a CPUIDFMT BASIC statement immediately after it.

Doing any one of those things SHOULD, I suspect, fix your problem.

I personally recommend changing it to LPARNUM BASIC.

Hope that helps!

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...
Re: Hyperion 4.2.1 looping but Hercules 3.13 ok

 

Fish wrote:
JimDooey wrote:

I’ve been running VM/370 Sixpack
Where did you download it from? I would like to try
the same thing for myself.
Never mind. I located my own original copy of the SixPack on my system that I tried a long time ago, and it appears to work just fine with the SDL Hyperion 4.2.1 version of Hercules. No looping, and VM/370 appears to be responsive. I can enter commands to VM/370 just fine and it responds just fine.

The version of the SixPack that I'm using *IS* different from the version that you appear to be using however:


The version of the SixPack that I AM using:

/VM/370 Release 06 Hercules "SixPack" version 1.2: 07/19/15 16:01:24
/Now 06:28:39 GMT SATURDAY 09/12/92


The version of the SixPack that YOU are using:

/VM/370 Release 06 Hercules "SixPack" version 1.2: 08/13/10 00:06:27
/Now 01:00:50 GMT TUESDAY 12/26/05



So it appears you are using a much older version of the VM/370 SixPack than I am. Have you tried using to most current version of the VM/370 SixPack instead? I forget where I got mine from. I think maybe it was Dave Wade's web site?





and the VM370Ext files
I've never heard of that. What is it? Where do I get those files?
I would still like to know what these files are! I've never heard of them before.


[...]
Subsequent attempts are done using a ckpt startup. I may
have config file problem but I can’t find it.
One thing I noticed that doesn't seem right to me is you have
a LPARNUM 01 statement. As far as I know neither the 4381 nor
VM/370 supported LPARs. Have you tried either removing that
statement or changing it to LPARNUM BASIC instead?
This very likely is your problem!

I just performed the same exact test (IPL) again, but using LPARNUM 01 instead of LPARNUM BASIC, and guess what? I didn't work! I did not get a looping system like you (the instrcount was not rapidly increasing like yours was), but VM/370 itself was completely unresponsive. It appeared to have gotten "stuck" during startup/initialization.


In my previous normal IPL (using LPARNUM BASIC, which worked), I saw VM/370 issue the following messages:


07:28:39.271 /
07:28:39.273 /
07:28:39.273 /
07:28:39.274 /VM/370 Release 06 Hercules "SixPack" version 1.2: 07/19/15 16:01:24
07:28:39.274 /
07:28:39.274 /Now 06:28:39 GMT SATURDAY 09/12/92
07:28:39.274 /
07:28:39.274 /DMKCPI971I System is Uniprocessor generated
07:28:39.275 /DMKCPI977I Free Trap Installed
07:28:39.275 /
07:28:39.282 /DMKUDR476I System Directory loaded from volume VM50-1
07:28:39.282 /
07:28:39.377 /06:28:39 AUTO LOGON *** OPERATOR USERS = 001 BY SYSTEM
07:28:39.378 /
07:28:39.378 /DMKCPI957I Storage size = 16384 K, Nucleus = 316 K,
07:28:39.378 / Dynamic Paging = 14808 K, Trace Table = 240 K,
07:28:39.378 / Free Storage = 1020 K, Virtual=Real = 00000 K
07:28:39.379 /
07:28:39.484 /06:28:39 AUTO LOGON *** AUTOLOG1 USERS = 002 BY OPERATOR
07:28:39.484 /
07:28:39.490 /
07:28:40.746 /06:28:40 AUTO LOGON *** CPWATCH USERS = 003 BY AUTOLOG1
07:28:41.275 /06:28:41 RDR 00C DRAINED SYSTEM
07:28:41.276 /06:28:41 PUN 00D DRAINED SYSTEM CLASS = P SEP
07:28:41.277 /06:28:41 PRT 00E DRAINED SYSTEM CLASS = A SEP
07:28:41.278 /06:28:41 PRT 00F DRAINED SYSTEM CLASS = D SEP
07:28:41.283 /06:28:41 AUTO LOGON *** CMSBATCH USERS = 004 BY AUTOLOG1
07:28:41.344 /06:28:41
07:28:41.344 / WNG FROM AUTOLOG1: AUTOLOG1 DONE - LOGGING OFF
07:28:41.345 /06:28:41 USER DSC LOGOFF AS AUTOLOG1 USERS = 003



When I tried the same thing using LPARNUM 01 however, I only saw the following VM/370 startup messages:


07:31:45.267 /
07:31:45.268 /
07:31:45.268 /
07:31:45.269 /VM/370 Release 06 Hercules "SixPack" version 1.2: 07/19/15 16:01:24
07:31:45.269 /
07:31:45.270 /Now 06:31:45 GMT SATURDAY 09/12/92
07:31:45.270 /
07:31:45.270 /DMKCPI971I System is Uniprocessor generated
07:31:45.270 /DMKCPI977I Free Trap Installed
07:31:45.270 /
07:31:45.271 /DMKUDR476I System Directory loaded from volume VM50-1
07:31:45.271 /
07:31:45.351 /06:31:45 AUTO LOGON *** OPERATOR USERS = 001 BY SYSTEM
07:31:45.351 /
07:31:45.352 /DMKCPI957I Storage size = 16384 K, Nucleus = 316 K,
07:31:45.352 / Dynamic Paging = 14808 K, Trace Table = 240 K,
07:31:45.352 / Free Storage = 1020 K, Virtual=Real = 00000 K
07:31:45.353 /



So it looks like VM/370 got "stuck" somewhere during initialization, and the ONLY difference between the two runs was the LPARNUM statement.

This makes sense too. The chosen LPARNUM value determines your CPUIDFMT value (which is the format that the STIDP (STORE CPU ID) instruction uses) which I'm guessing that VM/370 is very sensitive to. In fact, in my HercGUI product's Help file it clearly states in the section describing the LPAR Number:


"LPAR Number is a critical configuration setting that
can greatly influence how a guest operating system
behaves since its value also controls the CPU ID format.
Using the wrong value can easily cause your guest to
not even IPL."

"For older operating systems such as DOS/VS, MVS 3.8 and
VM/370 the value "BASIC" should be used."



So either CHANGE your LPARNUM statement to "BASIC" instead, -or- remove it altogether, -or- insert a CPUIDFMT BASIC statement immediately after it.

Doing any one of those things SHOULD, I suspect, fix your problem.

I personally recommend changing it to LPARNUM BASIC.

Hope that helps!

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...
Re: Hyperion 4.2.1 looping but Hercules 3.13 ok

 

JimDooey wrote:

I’ve been running VM/370 Sixpack
Where did you download it from? I would like to try the same thing for myself.


and the VM370Ext files
I've never heard of that. What is it? Where do I get those files?


using the Hercules 3.13 emulator on a Windows 10 host
for several months now. Recently, I learned a newer,
more up to date version of Hercules is available called
Hyperion 4.2.1 which was downloaded from SDL’s website.

After installing Hyperion, I copied the disks and such,
created a new configuration file and successfully IPL’d.
Okay...


Immediately, the emulator system appears to be in a loop.
The emulator processor is 100% and the Instctr increments
rapidly.
Technically, that by itself is not indicative of any problem.


It does not respond to /shutdown
THAT however seems to be indicative of a problem!


so I issue the stop command and then exit.
So Hercules is working. Just VM/370 for some reason isn't.


Subsequent attempts are done using a ckpt startup. I may
have config file problem but I can’t find it.
One thing I noticed that doesn't seem right to me is you have a LPARNUM 01 statement. As far as I know neither the 4381 nor VM/370 supported LPARs. Have you tried either removing that statement or changing it to LPARNUM BASIC instead?


The R3.13 system works just fine but I cannot get
Hyperion to run right.
I have not tried the VM/370 Sixpack in a very long time now, but I *have* tried it in the past and it seemed to work just fine for me. But that was a long time ago. Maybe something has changed since then?

I would like to try this for myself. Where can I download the same SixPack that you're using from? And where can I get those VM370Ext files from that I have never heard of before?

Thanks!

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...
Re: Hyperion 4.2.1 looping but Hercules 3.13 ok

 

开云体育

Jim,

Just a thought. You did copy the shadow files as well as the DASD files?

Dave

?

From: [email protected] <[email protected]> On Behalf Of JimDooey
Sent: 12 September 2020 00:36
To: [email protected]
Subject: Re: [h390-vm] Hyperion 4.2.1 looping but Hercules 3.13 ok

?

Thanks Dave,
I’m not using a .rc file, I am manually ipl’ing. Please see the screenshots in Photos and the log and configuration files in the Files section. For this test, I renamed Hercules.rc to Hercules.rcsave.?

I probably didn’t attach the files properly, I’m trying to figure out how this groups.io thing works!

Jim Snellen
Re: Hyperion 4.2.1 looping but Hercules 3.13 ok

 

开云体育

I tried using the existing configuration file but found that Hyperion didn’t like it. ?It called out too many errors because the configuration file and many parameters are different. ?
I created another using the sample file in the manual but replaced the device parameters with the settings from the working file.?
Instead of copying the executables, I copied the disk files into a separate folder as I didn’t want to risk corruption of my VM disks. Thanks for your comments.

Jim

On Sep 11, 2020, at 10:15 PM, carlos feldman <carlfelster@...> wrote:

?I just was doing something similar} but had no problems. What I was doing was just copy the binary files in the root directory where the disks reside, so I was able to run several versions of hercules, using the standard config files that comes with the disk packs. I was having a problem in mounting tapes with old versions of hercules and I started testing new versions, with no Inconvenience at all.?

Best regards?
--
Carlos

Argentina
Re: Hyperion 4.2.1 looping but Hercules 3.13 ok

 

I just was doing something similar} but had no problems. What I was doing was just copy the binary files in the root directory where the disks reside, so I was able to run several versions of hercules, using the standard config files that comes with the disk packs. I was having a problem in mounting tapes with old versions of hercules and I started testing new versions, with no Inconvenience at all.?

Best regards?
--
Carlos

Argentina
Re: Hyperion 4.2.1 looping but Hercules 3.13 ok

 

Thanks Dave,
I’m not using a .rc file, I am manually ipl’ing. Please see the screenshots in Photos and the log and configuration files in the Files section. For this test, I renamed Hercules.rc to Hercules.rcsave.?

I probably didn’t attach the files properly, I’m trying to figure out how this groups.io thing works!

Jim Snellen
Re: Hyperion 4.2.1 looping but Hercules 3.13 ok

 

开云体育

Jim,

The first time you run a new program on Windows/10 things go slowly because it does some checks, and possibly the firewall kicks in. This means you don’t get a good start. Try renaming the hercules.rc file and manually IPL the system.

Dave

?

From: [email protected] <[email protected]> On Behalf Of JimDooey
Sent: 11 September 2020 23:52
To: [email protected]
Subject: [h390-vm] Hyperion 4.2.1 looping but Hercules 3.13 ok

?

Hey everyone, this is my first post so I hope I do things right.?

I’ve been running VM/370 Sixpack and the VM370Ext files using the Hercules 3.13 emulator on a Windows 10 host for several months now. ?Recently, I learned a newer, more up to date version of Hercules is available called Hyperion 4.2.1 which was downloaded from SDL’s website. After installing Hyperion, I copied the disks and such, created a new configuration file and successfully IPL’d. ?Immediately, the emulator system appears to be in a loop. ?The emulator processor is 100% and the Instctr increments rapidly. ?It does not respond to /shutdown so I issue the stop command and then exit. Subsequent attempts are done using a ckpt startup. ?I may have config file problem but I can’t find it. The R3.13 system works just fine but I cannot get Hyperion to run right. Files are attached.?

Any suggestions?

?
Hyperion 4.2.1 looping but Hercules 3.13 ok

 

Hey everyone, this is my first post so I hope I do things right.?

I’ve been running VM/370 Sixpack and the VM370Ext files using the Hercules 3.13 emulator on a Windows 10 host for several months now. ?Recently, I learned a newer, more up to date version of Hercules is available called Hyperion 4.2.1 which was downloaded from SDL’s website. After installing Hyperion, I copied the disks and such, created a new configuration file and successfully IPL’d. ?Immediately, the emulator system appears to be in a loop. ?The emulator processor is 100% and the Instctr increments rapidly. ?It does not respond to /shutdown so I issue the stop command and then exit. Subsequent attempts are done using a ckpt startup. ?I may have config file problem but I can’t find it. The R3.13 system works just fine but I cannot get Hyperion to run right. Files are attached.?

Any suggestions?

?
Re: VM OpenExtensions was RE: [h390-vm] Sending command output to the stack in VM/370

 

Ugly indeed - actually getting GCCLIB IO to be Cish on top of the CMS Macros was kind of similar (although MUCH less scope/work!)

I wish (perhaps they did?) IBM just made a super-lite UNIX VM to sit in CP. Perhaps folks will say, they did it was called Linux! But I mean lighter than that, kind of CMS done POSIX from the ground up but simply.

A
Re: Sending command output to the stack in VM/370

 

I love it!!!!


On Mon, Sep 7, 2020 at 11:02 AM adriansutherland67 <adrian@...> wrote:
Hey - that almost looks lite real rexx running :-)

Re: Sending command output to the stack in VM/370

 

Hey - that almost looks lite real rexx running :-)
Re: Sending command output to the stack in VM/370

 

What does work today is capturing the output of any? CP command with Diagnose X'08'.
We use it in our EXECIO implementation for VM/370. That code is in final testing now, for release very soon. For example:

set exectrac on ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
Ready; T=0.01/0.01 09:46:03 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
test ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
? ? ? ?+++ Interactive trace. ?"Trace Off" to end debug.? ENTER to continue. +++ ? ?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
? ? ?2 *-* 'EXECIO * CP ( STEM RESPONSE. STRING Q N' ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
? ? ?3 *-* Do i = 1 to response.0 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
say response.0 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
2 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
? ? ?3 *-* Do i = 1 to response.0 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
? ? ?4 *-* ?say response.iEnd ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
OPERATOR - 009, CMSBATCH - DSC, CPWATCH ?- DSC, MAINTC ? - 0C1 ? ? ? ? ? ? ? ? ? ? ?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
? ? ?3 *-* Do i = 1 to response.0 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
? ? ?4 *-* ?say response.iEnd ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
MAINT ? ?- 0C0, CMSUSER ?- 0C2 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
? ? ?6 *-* Exit 0 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
Ready; T=0.02/0.03 09:46:25 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??

Bob Bolch
Re: Sending command output to the stack in VM/370

 

Dave Wade wrote:

but that is CMS output only. Trapping CP output in R6 might be harder. I
see there is a general tool around, CMSEX that is supposed to do this but
it uses the IUCV services that don’t exist in old VM
I've done some work on IUCV for VM/370. Right now, there is only barely
enough done to catch incoming MSGs and WNGs using the *MSG system service
in specific circumstances (ie to make IUCVTRAP MODULE work). I hope to get
around to adding more capability but unfortunately, I am not known for my
speed of implementation :-(

Which IUCV capabilities does CMSEX need?

Regards,
Peter Coghlan.
VM OpenExtensions was RE: [h390-vm] Sending command output to the stack in VM/370

 

开云体育

Adrian,

?

That was even later, ESA or Z and like much POSIX code, is there I feel there to allow boxes to be ticked that allow a system to be eligible for use on certain government contracts.

So mixing POSIX and conventional code may not play well together.

You may wish to read this description of the Byte File System and how it is accessed from conventional programs to see what a mess it is…

?

?

although it does make porting certain GNU applications simpler…

?

Dave

?

From: [email protected] <[email protected]> On Behalf Of adriansutherland67
Sent: 07 September 2020 09:38
To: [email protected]
Subject: Re: [h390-vm] Sending command output to the stack in VM/370

?

On Mon, Sep 7, 2020 at 08:19 AM, Dave Wade wrote:

I will point out that the much hated fullscreen cms must also do it…

… that came with SP 5…..

Very true

Presumably IBM also must have done a lot for POSIX compatibility as well

Re: Sending command output to the stack in VM/370

 

开云体育

Joe,

?

In my experience asking John usually results in stuff that doesn’t work on VM/370. You can usually trap CMS output. I think these will work on VM/370 with NUCXLOAD mods…

?

?

but that is CMS output only. Trapping CP output in R6 might be harder. I see there is a general tool around, CMSEX that is supposed to do this but it uses the IUCV services that don’t exist in old VM

?

?

which from this fairly recent post to the PIPELINES list looks like it was added for FULLSCREEN CMS so SP5 or later

?

?

which also explains some of the issues……

?

Dave

G4UGM

?

From: [email protected] <[email protected]> On Behalf Of Joe Monk
Sent: 06 September 2020 23:27
To: [email protected]
Subject: Re: [h390-vm] Sending command output to the stack in VM/370

?

"The question is how did IBM do it for CMS PIPES"

?

Ask John Hartmann. He is the author of CMS PIPES and a hercules developer.

?

You're also in luck.... ?

?

Joe

?

On Sun, Sep 6, 2020 at 2:42 PM adriansutherland67 <adrian@...> wrote:

It is obvious that IBM (or indeed anyone who cared to) could implement the ANSI REXX stuff on CMS using the CMS PIPES infrastructure.

However my understanding is that IBM is no longer investing in REXX (or indeed CMS?) so presumably IBM will indeed never implement it on later versions of CMS,

But to be practical, to implement it on VM/370 someone would need to develop a MOD so that console output could be redirected. It is not obvious to me how this could be done in a way that would be compatible with anything IBM did (not that I care about that). The question is how did IBM do it for CMS PIPES, and can that be duplicated? The answer is probably - "wont fix" :-)

Re: Sending command output to the stack in VM/370

 

On Mon, Sep 7, 2020 at 08:19 AM, Dave Wade wrote:

I will point out that the much hated fullscreen cms must also do it…

… that came with SP 5…..

Very true

Presumably IBM also must have done a lot for POSIX compatibility as well
Re: Sending command output to the stack in VM/370

 

开云体育

I will point out that the much hated fullscreen cms must also do it…

… that came with SP 5…..

?

Dave

?

From: [email protected] <[email protected]> On Behalf Of Bob Bolch
Sent: 06 September 2020 23:55
To: [email protected]
Subject: Re: [h390-vm] Sending command output to the stack in VM/370

?

The PIPEs Runtime Library was implemented on later VM releases and will not run on VM/370.

CMS PIPELINEs does happen to be one of the greatest application development tools in existence.?

?

Bob Bolch

?

On Sun, Sep 6, 2020 at 6:26 PM Joe Monk <joemonk64@...> wrote:

"The question is how did IBM do it for CMS PIPES"

?

Ask John Hartmann. He is the author of CMS PIPES and a hercules developer.

?

You're also in luck.... ?

?

Joe

?

On Sun, Sep 6, 2020 at 2:42 PM adriansutherland67 <adrian@...> wrote:

It is obvious that IBM (or indeed anyone who cared to) could implement the ANSI REXX stuff on CMS using the CMS PIPES infrastructure.

However my understanding is that IBM is no longer investing in REXX (or indeed CMS?) so presumably IBM will indeed never implement it on later versions of CMS,

But to be practical, to implement it on VM/370 someone would need to develop a MOD so that console output could be redirected. It is not obvious to me how this could be done in a way that would be compatible with anything IBM did (not that I care about that). The question is how did IBM do it for CMS PIPES, and can that be duplicated? The answer is probably - "wont fix" :-)

Re: Sending command output to the stack in VM/370

 

Joe Monk wrote:
Adrian Sutherland wrote:

The question is how did IBM do it for CMS PIPES, ...
Ask John Hartmann. He is the author of CMS PIPES
and a hercules developer.
FYI/CLARIFICATION:

He WAS (past tense) a Hercules developer of the original (now defunct) Hercules-390 Hyperion, but he is definitely *NOT* a member of the SDL-Hercules-390 organization and hasn't made any significant contribution to the Hercules project for MANY years now.

--
"Fish" (David B. Trout)
Software Development Laboratories

mail: fish@...
4521 - 4540 of 6550