Using DASD on emulated CU 3990-3 or -6 generates HCPERP513I error under z/VM

[fbi-ranger]

z/OS V2.x requires that its DASD is defined on CU type 3990 model 3 or higher. Defining a z/VM guest on full-pack minidisk leads to several HCPERP513I errors of the form:

10:10:21 HCPERP513I DASD 1A9F AN OPERATION WAS TERMINATED BECAUSE A FILE
10:10:21 HCPERP513I PROTECT ERROR OCCURRED
10:10:21 HCPERP6300I SENSE DATA FORMAT = 00 MSG CODE = 00
10:10:21 HCPERP6301I CHANNEL COMMAND WORD COMMAND CODE = 92
10:10:21 HCPERP6302I SEEK ADDRESS = 0000044F0002
10:10:21 HCPERP6303I SENSE = 00040000 004F4200 00000000 00000000 00000000
10:10:21 HCPERP6303I 00000000 00000080 00044F02
10:10:21 HCPERP6304I IRB = 00C24017 7FF91620 0E400008 00800000
10:10:21 HCPERP6305I USERID = ZOSSA
10:10:21 HCPERP2216I CHANNEL PATH ID = 1A

In the CP directory the full-pack minidisk is defined as follows MDISK A9F 3390 DEVNO 1A9F MRV ZOSACC

A dedicated address however does not generate this error.

A more complete CCW trace is available at "https://gist.github.com/fbi-ranger/54eda01a191cfba63aa1a5620000d452" Note: that this trace is cut because full trace file would be more than 216MB. I can provide the trace if required.

[jphartmann]

First of all, do Q A9F so see whether the drive is indeed R/W. If not Q LINKS A9F will show you who is holding it.

If there is no luck with that, I'd suggest defining a full-pack minidisk in the oldfashioned way (volume label rather than DEVNO) to see whether that fails.

Looking at the sense bytes, they do not make sense (sorry) in relation to my 3990/9390 reference; perhaps you can find a more recent specification.

You can also do Hercules I/O trace and look for CCWs that have operation code 00. This is an indication that CP CCW translate has found an error in the virtual channel program (CP does this to be sure that CCW is indeed issued in this particular case).

Then let's see what we have and scratch our collective heads.

[fbi-ranger]

q 1a9f DASD 1A9F ATTACHED TO ZOSSA 0A9F R/W SARES1

Note: In the IODF 1A9F is not defined and I wanted not to influence the system that only one UA has a different CU type than all the others defined in the range. The Hercules I/O trace (t+1A9F) is at the GIST.

I will check to see if the old way will change anything.

[ivan-w]

John,

You probably mean Q V A9F (if the virtual machine is class B, Q A9F will query real device A9F). Furthermore, if the minidisk was R/O, it would only affect the virtual device, not the real device (although CP probably does inserts a Set File Mask CCW somewhere in the chain to ensure there are no accidental writes). It's indeed odd to have a 'FILE PROTECT' problem on a read type CCW (X'92')

[fbi-ranger]

I change the directory. It looks now:

MDISK A9F 3390 0 END SARES1 MW READ WRITE MULTI

q 1a9f DASD 1A9F CP SYSTEM SARES1 1 q v a9f DASD 0A9F 3390 SARES1 R/W 3339 CYL ON DASD 1A9F SUBCHANNEL = 000A

Same effect:

11:40:03 HCPERP513I DASD 1A9F AN OPERATION WAS TERMINATED BECAUSE A FILE
11:40:03 HCPERP513I PROTECT ERROR OCCURRED
11:40:03 HCPERP6300I SENSE DATA FORMAT = 00 MSG CODE = 00
11:40:03 HCPERP6301I CHANNEL COMMAND WORD COMMAND CODE = 92
11:40:03 HCPERP6302I SEEK ADDRESS = 00000CD10009
11:40:03 HCPERP6303I SENSE = 00040000 00D1C900 00000000 00000000 00000000
11:40:03 HCPERP6303I 00000000 00000080 000CD109
11:40:03 HCPERP6304I IRB = 00C24017 4EA23620 0E400008 00800000
11:40:03 HCPERP6305I USERID = ZOSSA
11:40:03 HCPERP2216I CHANNEL PATH ID = 1A

So it is excluded that the DASD is R/O. It works when it is dedicated. It does not work when it is a mdisk.

[fbi-ranger]

BTW: The guest privileges BCG. It does the same when it is only G. I think it is something z/VM "expects" from a 3990-3/6 which is not provided by the emulation. A simple cu=3990 produces no error but in that case z/OS does not find its paging data sets.

[jphartmann]

Anyone running MVS in class other than G deserves what he gets.

[dasdman]

Looking at the sense bytes, they do not make sense (sorry) in relation to my 3990/9390 reference.

Correct, and non-trivial to repair even close to properly. I have a very large fix-set for this, and several hundred other DASD issues, but then certain key operating systems won't complete their IPLs at all in it's current state (in other words, the current failures experienced by the Hercules community are less damaging than the current state of the fix code). Hopefully I'll be able to begin to address this again starting in some form later this year. Currently working on a higher priority project. When the time comes, I will definitely employ assistance from others in the group to facilitate completion and validation before the code is "officially" rolled in for everyone to use.

Sidebar #1: With the DASD update, the sense bytes provided will be correct. That, however, does not say that all that could be presented, will be presented.

Sidebar #2: There will also be a few smaller side projects as well that will need to be completed during this time period as well; working on the smaller projects for anyone at present would not be productive as the results will not be usable within Hercules until the DASD work is near completion.

[fbi-ranger]

BTW: The guest privileges BCG. It does the same when it is only G. I think it is something z/VM "expects" from a 3990-3/6 which is not provided by the emulation. A simple cu=3990 produces no error but in that case z/OS does not find its paging data sets.

[fbi-ranger]

Isn't it possible to introduce the work of DASDMAN as a fake new CU type suche as 3990-X or 3990-8 or something like this? With this we would not affect the exiting functionality and we would have way to test the fixes. Simple way to activate is to code cu=3990-X instead of 3390-3. What do you think?

[rwoodpd]

The file protect error is caused by incorrect handling of a read count CCW that is suffixed to a CCW chain. In that case, if the current position is end of track, the data returned should be the count field for the first record read, instead of attempting to advance to the next track. In this case. the read goes to the end of the extent defined by the defined extent CCW, and then the suffixed read count CCW is processed. Because it is at end of track, it should return the first count field, but instead attempts to advance and gets the file protect error.

[dasdman]

For clarity for all involved, it would be helpful to use reference citations from the manual(s), as well as to assemble sample programs for testing. Also, there may be secondary mitigating factors that have to be taken into account once fully researched.

[jphartmann]

If this is still what is being debated:

11:40:03 HCPERP6301I CHANNEL COMMAND WORD COMMAND CODE = 92

The command is a multitrack read count and thus the position should advance to record 1 on the next track. At the end of the cylinder or the extent, unit check and the appropriate sense bytes should be returned.

[rwoodpd]

That is true unless it is a suffixed multitrack read count at the end of a read any domain that is part of a locate record extended. Please refer to pages 47-48 in SC26-7298-01, “System 390 Command Reference 2105 Models E10, E20, F10 and F20.”.