search

SDL-Hercules-390 / hyperion

The SDL Hercules 4.x Hyperion version of the System/370, ESA/390, and z/Architecture Emulator
Other
240 stars 90 forks source link

Multipath I/O config causes EQC messages from MVS TK4- at NIP time #593

Closed SE20225 closed 7 months ago

SE20225 commented 1 year ago

Hercules version: 4.6.0.10941-SDL-g65c97fd6 Running on: T480S (Windows-6.2.9200 Intel(R) x64) LP=8, Cores=4, CPUs=1

My testing with optional paths has now progressed to 3350 with device 0140, volser WORK00, being the first 3350 in the config. It is actually a completely empty volume, with just a VTOC in the rest of cyl 0.

A lot of reading works OK on any of the paths, but the two available paths definitely work slightly differently.

The MVS involved is a TK4- regenned to include FEATURES=ACR and CRH. (i.e. support for multiprocessing and Channel Recovery Hardware, Connect and Disconnect Channels)

Snippet from Hercules configuration file:

0:0140  3350  dasd/work00.140
1:0140  3350  localhost::0140

When MVS initialization starts, we typically get this on the console:

1040 18.17.34     IEA000I 140,EQC,31,0E00,,,WORK00,*MASTER*,18.17.34
1040 18.17.34     IEA000I 140,,,,100000008000011000000000000000000000000000000000

and the log contains a message indicating that we have run out of the track, which is the very first track in the VTOC.

The log also shows that Search ID EQ keeps hitting something reporting as R0 but with a DL of zero. I guess something increments with 8 until the end of track is hit.

The problem is intermittent. Does not occur on every IPL.

I am enclosing:

  1. The CCKD volume ("work00.140"), which is empty except for the VTOC.

  2. MVS Hardcopy files, with and without the EQC message.

  3. Hercules log files with trace active for both paths to 0140:   "MVS_LOG_EQC.txt" is the log file when the EQC message goes to the console after Search ID saw a lot of records with number 0 and correct track address and KL=DL=0 and finally reaching the end of that track and EQC.   "MVS_LOG_NoEQC.txt" is much shorter.   Note that there is a re-IPL later, and at 21.32.34, the fields operated on do not have the KL and DL that a VTOC track has. So what is going on? It seems MVS does not worry about the NRF when it tries to read part of the VTOC.

  4. The Hercules configuration file: "MVS_CONF.cnf"

I will provide documentation for the (related?) IEHLIST behaviour in a separate GitHub Issue.

Please advise.

Anders Edlund, andersedlund@telia.com

Fish-Git commented 1 year ago

Before going any further, I need you to closely review the above editing I have performed on your original problem report to make sure it is correct.

Your original report was badly formatted, so I had to edit it so that it would display properly. I may have accidentally deleted some important information?

So please review the above problem description and make any needed changes to ensure the information presented is accurate. Thanks.

(You can edit any comment you make to GitHub by simply clicking the ... on the right side of the comment's title, and selecting "Edit" from the list of available actions.)

SE20225 commented 1 year ago

I am perfectly happy with the editing. Looks very nice. I have a few things to pick up here!

Fish-Git commented 1 year ago

I have a few things to pick up here!

Using markdown syntax is not that tough. The extended syntax can be tricky, but the basic stuff is pretty easy:

Fish-Git commented 7 months ago

My apologies, Anders (@SE20225 ), for taking so long to get back to you on this. A lot has been happening in the Hercules world as well as in my personal life too.

Forgive me BUT... Your reported problem appears to be an MVS issue/problem, not a Hercules issue/problem. I am not seeing any evidence anywhere of any type of Hercules problem in any of the information you've provided.

Second, please keep in mind that Hercules developers are not necessarily IBM mainframe operating system developers. That is to say, don't expect that if you are having a problem with a given IBM operating system (e.g. MVS or DOS/VS or VM/370 or z/OS or z/VSE or z/VM, etc) that that means the Hercules developer knows about or is experienced with such operating systems.

Hercules is a hardware emulator. Hercules developers are familiar with IBM's mainframe architecture (so that we can ensure Hercules accurately emulates the [hardware] architecture), but that doesn't mean we are familiar with the plethora of mainframe operating systems designed to run on that architecture.

I myself know virtually nothing about MVS. And we're not here to provide MVS support. We're here to provide Hercules support.

Have you reported this problem to the H390-MVS support group? What did they say? They are experts at MVS, and should be able to help you with whatever problem you are having.

I am going to close this issue as "Unknown" since it is not known (yet!) whether there is an actual Hercules problem anywhere. Please feel free to re-open this issue (or submit a new issue) once you've obtained more convincing evidence that Hercules is actually malfunctioning.

Thanks.

SE20225 commented 7 months ago

This has never reoccurred after I changed the config to: 

0F40    3350  dasd/work00.140
0:0140  3350  localhost::0F40
1:0140  3350  localhost::0F40

where 0F40 is a device which is not used by the MVS system involved.