Discussion:
[hercules-390] 3390 Synchronous Disk I/O w. Diagnose 'A8' Problem for z/VM SSI cmd FORMSSI
peter_j_jansen@yahoo.com [hercules-390]
2016-04-18 19:46:26 UTC
Permalink
Testing z/VM SSI capability under Hercules has encountered an unexpected showstopper. During z/VM 6.3 SSI installation, this command gets executed :


FORMSSI CREATE 0630 SSICLNAM


Which results in this error :


HCP6605E Error 13 reading/writing Persistent Data Record


The actual I/O is performed synchronously using DIAGNOSE 'A8'.
Tracing what actually happens under Spinhawk 3.12 reveals this :


t+0630
HHCPN136I CCW tracing is now on for device 0:0630
0630:start i/o file[0] bufcur 1 cache[148]
0630:synchronous I/O ccw addr 7ff2a388
HHCCP048I 0630:CCW=63400010 7FF47C78=>C0C08000 00000000 00000000 00000001 {{..............
HHCCP075I 0630:Stat=0C00 Count=0000
HHCCP048I 0630:CCW=47400010 7FF2A4B8=>06000001 00000001 00000001 01FF0000 ................
0630:HHCDA038I seeking to cyl 0 head 1
0630:HHCDA041I read count orientation is index
0630:HHCDA043I cyl 0 head 1 record 0 kl 0 dl 8 of 0
0630:HHCDA041I read count orientation is count
0630:HHCDA043I cyl 0 head 1 record 13 kl 0 dl 4096 of 0
0630:HHCDA041I read count orientation is count
0630:HHCDA043I cyl 0 head 1 record 14 kl 0 dl 4096 of 0
0630:HHCDA041I read count orientation is count
0630:HHCDA043I cyl 0 head 1 record 15 kl 0 dl 4096 of 0
0630:HHCDA041I read count orientation is count
0630:HHCDA043I cyl 0 head 1 record 16 kl 0 dl 4096 of 0
0630:HHCDA041I read count orientation is count
0630:HHCDA043I cyl 0 head 1 record 17 kl 0 dl 4096 of 0
0630:HHCDA041I read count orientation is count
0630:HHCDA043I cyl 0 head 1 record 18 kl 0 dl 4096 of 0
0630:HHCDA041I read count orientation is count
0630:HHCDA043I cyl 0 head 1 record 19 kl 0 dl 4096 of 0
0630:HHCDA041I read count orientation is count
0630:HHCDA043I cyl 0 head 1 record 20 kl 0 dl 4096 of 0
0630:HHCDA041I read count orientation is count
0630:HHCDA043I cyl 0 head 1 record 21 kl 0 dl 4096 of 0
0630:HHCDA041I read count orientation is count
0630:HHCDA043I cyl 0 head 1 record 22 kl 0 dl 4096 of 0
0630:HHCDA041I read count orientation is count
0630:HHCDA043I cyl 0 head 1 record 23 kl 0 dl 4096 of 0
0630:HHCDA041I read count orientation is count
0630:HHCDA043I cyl 0 head 1 record 24 kl 0 dl 4096 of 0
0630:HHCDA041I read count orientation is count
0630:HHCDA043I cyl 0 head 1 record 255 kl 255 dl 65535 of 0
HHCCP075I 0630:Stat=0E00 Count=0000
HHCCP076I 0630:Sense=00080000 00000100 00000000 00000000 00000000 00000000
HHCCP077I 0630:Sense=NRF
0630:end i/o bufcur 1 cache[148] waiters 0
HHCCP050I 0630:SCSW=00C24017 Stat=0E00 Count=0000 CCW=7FF2A398
t-0630
HHCPN136I CCW tracing is now off for device 0:0630


Message HHCDA043I is issued in "ckddasd.c" on line 1682, and the Unit Check / NoRecordFound issued in line 1708 and following. I have tried to find the error by reading GA32-0099-06 but have to admit that this is currently way beyond my abilities and understanding. My suspicion is that this NRF condition in synchronous mode should perhaps just not be reported i.e. not generate a Unit Check at all. But this is a mere suspicion only, and for real Hercules 3390 experts to perhaps have a look at.


I compared Spinhawk 3.12 to Hyperion 4.00 code, but believe there is no significant difference in this CKD disk I/O area between the two.


Help will be greatly appreciated !



Peter J. Jansen
Ivan Warren ivan@vmfacility.fr [hercules-390]
2016-04-18 20:34:42 UTC
Permalink
Post by ***@yahoo.com [hercules-390]
Testing z/VM SSI capability under Hercules has encountered an
unexpected showstopper. During z/VM 6.3 SSI installation, this command
FORMSSI CREATE 0630 SSICLNAM
HCP6605E Error 13 reading/writing Persistent Data Record
The actual I/O is performed synchronously using DIAGNOSE 'A8'.
The I/O is performed by DIAG A8 - by the virtual machine running under
CP - but CP uses traditional I/O when issuing I/Os to hercules
Post by ***@yahoo.com [hercules-390]
Message HHCDA043I is issued in "ckddasd.c" on line 1682, and the Unit
Check / NoRecordFound issued in line 1708 and following. I have tried
to find the error by reading GA32-0099-06 but have to admit that this
is currently way beyond my abilities and understanding. My suspicion
is that this NRF condition in synchronous mode should perhaps just not
be reported i.e. not generate a Unit Check at all. ;But this is a
mere suspicion only, and for real Hercules 3390 experts to perhaps
have a look at.
I compared Spinhawk 3.12 to Hyperion 4.00 code, but believe there is
no significant difference in this CKD disk I/O area between the two.
Help will be greatly appreciated !
Was the valume properly formated (via CPFMTXA) prior to issuing
FORMATSSI ? Also the volume must be a CP owned volume (to be usable for
the underlying SSI).

(Only refering to :
https://www.ibm.com/support/knowledgecenter/SSB27U_6.3.0/com.ibm.zvm.v630.hcpb7/formplx.htm
usage notes 4 & 5).

It just seems to me the volume isn't properly formatted for CP use.

--Ivan


[Non-text portions of this message have been removed]
'Mark L. Gaubatz' mgaubatz@groupgw.com [hercules-390]
2016-04-19 02:10:37 UTC
Permalink
Post by ***@yahoo.com [hercules-390]
HHCCP048I 0630:CCW=47400010 7FF2A4B8=>06000001 00000001 00000001 01FF0000 ................
0630:HHCDA038I seeking to cyl 0 head 1
0630:HHCDA041I read count orientation is index
0630:HHCDA043I cyl 0 head 1 record 0 kl 0 dl 8 of 0
0630:HHCDA041I read count orientation is count
0630:HHCDA043I cyl 0 head 1 record 13 kl 0 dl 4096 of 0
0630:HHCDA041I read count orientation is count
0630:HHCDA043I cyl 0 head 1 record 14 kl 0 dl 4096 of 0
0630:HHCDA041I read count orientation is count
0630:HHCDA043I cyl 0 head 1 record 15 kl 0 dl 4096 of 0
0630:HHCDA041I read count orientation is count
0630:HHCDA043I cyl 0 head 1 record 16 kl 0 dl 4096 of 0
0630:HHCDA041I read count orientation is count
0630:HHCDA043I cyl 0 head 1 record 17 kl 0 dl 4096 of 0
0630:HHCDA041I read count orientation is count
0630:HHCDA043I cyl 0 head 1 record 18 kl 0 dl 4096 of 0
0630:HHCDA041I read count orientation is count
0630:HHCDA043I cyl 0 head 1 record 19 kl 0 dl 4096 of 0
0630:HHCDA041I read count orientation is count
0630:HHCDA043I cyl 0 head 1 record 20 kl 0 dl 4096 of 0
0630:HHCDA041I read count orientation is count
0630:HHCDA043I cyl 0 head 1 record 21 kl 0 dl 4096 of 0
0630:HHCDA041I read count orientation is count
0630:HHCDA043I cyl 0 head 1 record 22 kl 0 dl 4096 of 0
0630:HHCDA041I read count orientation is count
0630:HHCDA043I cyl 0 head 1 record 23 kl 0 dl 4096 of 0
0630:HHCDA041I read count orientation is count
0630:HHCDA043I cyl 0 head 1 record 24 kl 0 dl 4096 of 0
0630:HHCDA041I read count orientation is count
0630:HHCDA043I cyl 0 head 1 record 255 kl 255 dl 65535 of 0
HHCCP075I 0630:Stat=0E00 Count=0000
HHCCP076I 0630:Sense=00080000 00000100 00000000 00000000 00000000 00000000
HHCCP077I 0630:Sense=NRF
0630:end i/o bufcur 1 cache[148] waiters 0
HHCCP050I 0630:SCSW=00C24017 Stat=0E00 Count=0000 CCW=7FF2A398
Ivan is correct. The track is improperly formatted as record 1 does not
exist, and, as such, the Locate Record fails. Looking solely at your
trace, the records on the track are 0, 13, 14, ..., 23, 24 ("255" is
actually the end-of-track marker, x'FFFFFFFF FFFFFFFF').

Mark L. Gaubatz
dasdman
somitcw@yahoo.com [hercules-390]
2016-04-19 03:58:50 UTC
Permalink
In hercules-***@yahoogroups.com, <***@...> wrote:
- - -old note snipped - - -
Post by 'Mark L. Gaubatz' ***@groupgw.com [hercules-390]
Ivan is correct. The track is improperly formatted as record 1 does not
exist, and, as such, the Locate Record fails. Looking solely at your
trace, the records on the track are 0, 13, 14, ..., 23, 24 ("255" is
actually the end-of-track marker, x'FFFFFFFF FFFFFFFF').
Mark L. Gaubatz
dasdman
There is no requirement for IBM to use the record numbers that you expect.
Same for cylinder numbers.

There are 12 records of 4KB each which is what fits on a 3390 track.

I don't know why Hercules appears to try to display a data record of
X'FFFFFFFFFFFFFFFF' but it did give a no-record-found indicator.
Perhap Hercules should not attempt to display the no-record-found record?

I trust that this is only a formatting issue.
'John P. Hartmann' jphartmann@gmail.com [hercules-390]
2016-04-19 07:45:58 UTC
Permalink
Actually, a 3390 track would fit 13 pages, but the 3380 geometry was
retained.

All foxes is the end-of-track marker. It is exposed in read track.
Post by ***@yahoo.com [hercules-390]
There are 12 records of 4KB each which is what fits on a 3390 track.
I don't know why Hercules appears to try to display a data record of
X'FFFFFFFFFFFFFFFF' but it did give a no-record-found indicator.
Perhap Hercules should not attempt to display the no-record-found record?
'Peter J. Jansen' peter_j_jansen@yahoo.com [hercules-390]
2016-04-19 11:27:11 UTC
Permalink
Ivan, Mark, John, Somitcw,



thanks for all the replies I received !



The main consensus in that it is probably a formatting problem may very well be true. However, the CPFMTXA is performed during the z/VM 6.3 INSTALL process, does not report any errors, and takes place right before the FORMSSI. I repeated both the appropriate CPFMTXA and FORMSSI commands manually with the same results: FORMSSI generates HCP6605E / HCPPDF6605E Error 13 etc. 


I also (Hercules-) traced CPFMTXA’s I/O’s (lengthy), but these too can only be helpful for CKD DASD experts.

It appears that in order to support SSI, this “Persistent Data Record” (PDR) is something new that got introduced on (one of) the shared disks between SSI members, as the new OWNER parameter on the CPFMTXA command shows. So perhaps the Hercules I/O CCW’s to create and maintain this PDR has problems both for CPFMTXA and FORMSSI.

I do not know if CPFMTXA also uses DIAGNOSE ‘A8’, or if running VM SSI members use it also to perform PDR I/O. Somehow I suspect the problem only comes from synchronous I/O via DIAGNOSE ‘A8’. And right at the top of “syncgen_io” in “vm.c” there is this comment (Spinhawk 3.12 as well as Hyperion 4.00):



//FIXME: code not right for shared devices



“syncgen_io” appears to be only used in one place by DIAGNOSE ‘A8’, so perhaps I’ve hit a known problem ? Anything I can do to help debugging this problem ?



Peter J.
Ivan Warren ivan@vmfacility.fr [hercules-390]
2016-04-19 12:11:55 UTC
Permalink
Post by 'Peter J. Jansen' ***@yahoo.com [hercules-390]
Ivan, Mark, John, Somitcw,
thanks for all the replies I received !
****
I do not know if CPFMTXA also uses DIAGNOSE ‘A8’, or if running VM SSI
members use it also to perform PDR I/O. Somehow I suspect the problem
only comes from synchronous I/O via DIAGNOSE ‘A8’. And right at the
top of “syncgen_io” in “vm.c” there is this comment (Spinhawk 3.12 as
//FIXME: code not right for shared devices
“syncgen_io” appears to be only used in one place by DIAGNOSE ‘A8’, so
perhaps I’ve hit a known problem ? Anything I can do to help debugging
this problem ?
Peter,

Again, CP does NOT use Diag A8. Diag A8 was only implemented in hercules
for Solaris so that it could run standalone under hercules with z/VM.
CMS, FMTSSI and CPFMTXA may issue a Diag A8 when running in a virtual
machine - which will generate a SIE intercept and CP will then issue the
I/Os using regular SSCH.

--Ivan



[Non-text portions of this message have been removed]
Ivan Warren ivan@vmfacility.fr [hercules-390]
2016-04-19 12:15:57 UTC
Permalink
Post by Ivan Warren ***@vmfacility.fr [hercules-390]
Post by 'Peter J. Jansen' ***@yahoo.com [hercules-390]
Ivan, Mark, John, Somitcw,
thanks for all the replies I received !
****
I do not know if CPFMTXA also uses DIAGNOSE ‘A8’, or if running VM SSI
members use it also to perform PDR I/O. Somehow I suspect the problem
only comes from synchronous I/O via DIAGNOSE ‘A8’. And right at the
top of “syncgen_io” in “vm.c” there is this comment (Spinhawk 3.12 as
//FIXME: code not right for shared devices
“syncgen_io” appears to be only used in one place by DIAGNOSE ‘A8’, so
perhaps I’ve hit a known problem ? Anything I can do to help debugging
this problem ?
Peter,
Again, CP does NOT use Diag A8. Diag A8 was only implemented in hercules
for Solaris so that it could run standalone under hercules with z/VM.
CMS, FMTSSI and CPFMTXA may issue a Diag A8 when running in a virtual
machine - which will generate a SIE intercept and CP will then issue the
I/Os using regular SSCH.
--Ivan
Solaris *WITHOUT* z/VM I meant

--Ivan



[Non-text portions of this message have been removed]
somitcw@yahoo.com [hercules-390]
2016-04-19 15:11:38 UTC
Permalink
Post by 'Peter J. Jansen' ***@yahoo.com [hercules-390]
Ivan, Mark, John, Somitcw,
thanks for all the replies I received !
The main consensus in that it is probably a formatting problem may very
well be true. However, the CPFMTXA is performed during the z/VM 6.3 INSTALL
process, does not report any errors, and takes place right before the FORMSSI.
I repeated both the appropriate CPFMTXA and FORMSSI commands manually
with the same results: FORMSSI generates HCP6605E / HCPPDF6605E Error 13 etc. 

I also (Hercules-) traced CPFMTXA’s I/O’s (lengthy), but these too can only be
helpful for CKD DASD experts.
It appears that in order to support SSI, this “Persistent Data Record” (PDR) is
something new that got introduced on (one of) the shared disks between SSI
members, as the new OWNER parameter on the CPFMTXA command shows.
So perhaps the Hercules I/O CCW’s to create and maintain this PDR has
problems both for CPFMTXA and FORMSSI.
I do not know if CPFMTXA also uses DIAGNOSE ‘A8’, or if running VM SSI
members use it also to perform PDR I/O. Somehow I suspect the problem only
comes from synchronous I/O via DIAGNOSE ‘A8’. And right at the top of
“syncgen_io” in “vm.c” there is this comment (Spinhawk 3.12 as well as
//FIXME: code not right for shared devices
“syncgen_io” appears to be only used in one place by DIAGNOSE ‘A8’, so
perhaps I’ve hit a known problem ? Anything I can do to help debugging
this problem ?
Peter J.
I have never seen a PDR so am only guessing.

Instead of Hercules I/O tracing while CPFMTXA is running,
wouldn't Hercules I/O tracing while FORMSSI CREATE is
running have less output and therefor be easier to read?
Ivan Warren ivan@vmfacility.fr [hercules-390]
2016-04-19 15:29:10 UTC
Permalink
Post by ***@yahoo.com [hercules-390]
I have never seen a PDR so am only guessing.
Instead of Hercules I/O tracing while CPFMTXA is running,
wouldn't Hercules I/O tracing while FORMSSI CREATE is
running have less output and therefor be easier to read?
Peter already provided that ;)

--Ivan



[Non-text portions of this message have been removed]
somitcw@yahoo.com [hercules-390]
2016-04-19 15:42:55 UTC
Permalink
Post by 'John P. Hartmann' ***@gmail.com [hercules-390]
Actually, a 3390 track would fit 13 pages, but the 3380 geometry was
retained.
If you check:
GX26-1678-0_3380_Reference_Summary_Feb83.pdf for 3380 disks
and
GX26-4577-0_3390_Reference_Summary_Jun89.pdf for 3390 disks

They claim:
For 3380, 10 blocks of 4KB fit on a track.
For 3390, 12 blocks of 4KB fit on a track.

Yes, I can squeeze more data especially with Hercules but
prefer to keep disks close to what IBM documents.
Yes, IBM doesn't always follow their own documentation.
Post by 'John P. Hartmann' ***@gmail.com [hercules-390]
All foxes is the end-of-track marker. It is exposed in read track.
I know, but the display didn't hurt because the display was
followed by a no-record-found
Post by 'John P. Hartmann' ***@gmail.com [hercules-390]
Post by ***@yahoo.com [hercules-390]
There are 12 records of 4KB each which is what fits on a 3390 track.
I don't know why Hercules appears to try to display a data record of
X'FFFFFFFFFFFFFFFF' but it did give a no-record-found indicator.
Perhap Hercules should not attempt to display the no-record-found record?
Mike Schwab Mike.A.Schwab@gmail.com [hercules-390]
2016-04-19 16:35:11 UTC
Permalink
Maybe the records 13-24 were written to fill the track and don't
contain any data.
Post by ***@yahoo.com [hercules-390]
Post by 'John P. Hartmann' ***@gmail.com [hercules-390]
Actually, a 3390 track would fit 13 pages, but the 3380 geometry was
retained.
GX26-1678-0_3380_Reference_Summary_Feb83.pdf for 3380 disks
and
GX26-4577-0_3390_Reference_Summary_Jun89.pdf for 3390 disks
For 3380, 10 blocks of 4KB fit on a track.
For 3390, 12 blocks of 4KB fit on a track.
Yes, I can squeeze more data especially with Hercules but
prefer to keep disks close to what IBM documents.
Yes, IBM doesn't always follow their own documentation.
Post by 'John P. Hartmann' ***@gmail.com [hercules-390]
All foxes is the end-of-track marker. It is exposed in read track.
I know, but the display didn't hurt because the display was
followed by a no-record-found
Post by 'John P. Hartmann' ***@gmail.com [hercules-390]
Post by ***@yahoo.com [hercules-390]
There are 12 records of 4KB each which is what fits on a 3390 track.
I don't know why Hercules appears to try to display a data record of
X'FFFFFFFFFFFFFFFF' but it did give a no-record-found indicator.
Perhap Hercules should not attempt to display the no-record-found record?
------------------------------------
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
------------------------------------
Yahoo Groups Links
--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?
Tony Harminc tharminc@gmail.com [hercules-390]
2016-04-19 17:34:05 UTC
Permalink
Post by ***@yahoo.com [hercules-390]
GX26-1678-0_3380_Reference_Summary_Feb83.pdf for 3380 disks
and
GX26-4577-0_3390_Reference_Summary_Jun89.pdf for 3390 disks
For 3380, 10 blocks of 4KB fit on a track.
For 3390, 12 blocks of 4KB fit on a track.
You're presumably looking at the tables. If you do the calculation,
you get 13 exactly for 3390. I'm not sure why the tables are more
pessimistic, but I'd bet on the formula.

Tony H.
Ivan Warren ivan@vmfacility.fr [hercules-390]
2016-04-19 18:37:32 UTC
Permalink
Post by ***@yahoo.com [hercules-390]
0630:synchronous I/O ccw addr 7ff2a388
HHCCP048I 0630:CCW=63400010 7FF47C78=>C0C08000 00000000 00000000
00000001 {{..............
HHCCP075I 0630:Stat=0C00 Count=0000
HHCCP048I 0630:CCW=47400010 7FF2A4B8=>06000001 00000 001 00000001
01FF0000 ................
2 things here....

First the "synchronous I/O ccw..." message doesn't mean the operation
was issued by a DIAG A8. It means that (until further notice) the I/O is
being performed synchronously by the CPU thread (and not a separate I/O
thread). The I/O is then diverged to a device thread if the necessary
data is not in cache or if some condition arises for which holding up
the CPU thread would be counter-productive.

Side Note : if CP was using DIAG A8 for when issuing I/Os - it wouldn't
be able to dispatch other virtual machines while waiting for an
operation to complete - and this would defeat CP as a virtualization
hypervisor. So I'm pretty sure CP does NOT use DIAG A8 to issue I/Os.
Because the message prefix is "HCP" for FORMSSI doesn't mean it is
issued directly by CP - It just indicates FORMSSI is a CP utility (it's
still a CMS module).

Next....

The other thing that I however find disturbing is that second CCW. It's
a locate record with read record of length 1 (1 record) with a seek to
Cyl 0 Head 1 - to read Record Cyl 0 Hd 1 Rec 1 :

(Note - The Record number is the 5 first bytes of the count area).

06 : Read
000001 : 1 Record
00000001 : Cyl 0, Head 1
00000001 01 : Cyl 0, Head 1, Record 1 (The search succeeds if the CCHH
is correct and the Record ID in the count field matches) - Won't happen
for CPFMTXA formated DASDs.
FF0000 : Sector positioning (FF - N/A) and transfer length factor (only
for write ops)

However, CPFMTXA gives record numbers in sequential order for all
tracks on a cylinder (except for record 0). So for a CPFMTXA formated
volume, The only record 1 for cyl 0 is CCHHRR 0 0 1 - there is no CCHHRR
0 1 1 (that's what my z/VM 5.3 CPFMTXA does anyway - but I doubt it has
changed since then).

So obviously this volume WAS CPFMTXA formatted - (CMS Format doesn't do
that - Records are allocated with sequential numbering per track instead
of CPFMTXA record numbering per cylinder). However I am wondering why
FORMSSI is trying to access head 1 instead of head 0 for that cylinder.

Food for thought.

--Ivan



[Non-text portions of this message have been removed]
'John P. Hartmann' jphartmann@gmail.com [hercules-390]
2016-04-19 19:03:35 UTC
Permalink
This thread seems confusing to me.

A virtual machine can do synchronous disk I/O using diagnose A4. It can
issue diag A8 do generalised I/O to any device for which CP does error
recovery.

In either case, CP does SSCH (as it clearly must do).

The multisystem minidisk access that was designed at Uithoorn in the
seventies (if they did not steal it from somewhere else) worked
essentially like this:

A track would be formatted with a record that contains a byte for each
cylinder on the volume. A record with key or data 0; a number of
records containing 1, 2, ... to the max number of systems in the cluster.

To reserve a minidisk, a channel program would read the byte map, do a
search key/data equal for the appropriate slot on the record containing
0. If it matched a suitable number of records are skipped to get to the
one for the system performing the reservation and that record is read
into the byte map at the appropriate place. Finally the updated byte
map would be written back to disk.

All in one channel program and no reserve/release needed. Brilliant.
Post by Ivan Warren ***@vmfacility.fr [hercules-390]
0630:synchronous I/O ccw addr 7ff2a388
HHCCP048I 0630:CCW=63400010 7FF47C78=>C0C08000 00000000 00000000
00000001 {{..............
HHCCP075I 0630:Stat=0C00 Count=0000
HHCCP048I 0630:CCW=47400010 7FF2A4B8=>06000001 00000 001 00000001
01FF0000 ................
2 things here....
First the "synchronous I/O ccw..." message doesn't mean the operation
was issued by a DIAG A8. It means that (until further notice) the I/O is
being performed synchronously by the CPU thread (and not a separate I/O
thread). The I/O is then diverged to a device thread if the necessary
data is not in cache or if some condition arises for which holding up
the CPU thread would be counter-productive.
Side Note : if CP was using DIAG A8 for when issuing I/Os - it wouldn't
be able to dispatch other virtual machines while waiting for an
operation to complete - and this would defeat CP as a virtualization
hypervisor. So I'm pretty sure CP does NOT use DIAG A8 to issue I/Os.
Because the message prefix is "HCP" for FORMSSI doesn't mean it is
issued directly by CP - It just indicates FORMSSI is a CP utility (it's
still a CMS module).
Next....
The other thing that I however find disturbing is that second CCW. It's
a locate record with read record of length 1 (1 record) with a seek to
(Note - The Record number is the 5 first bytes of the count area).
06 : Read
000001 : 1 Record
00000001 : Cyl 0, Head 1
00000001 01 : Cyl 0, Head 1, Record 1 (The search succeeds if the CCHH
is correct and the Record ID in the count field matches) - Won't happen
for CPFMTXA formated DASDs.
FF0000 : Sector positioning (FF - N/A) and transfer length factor (only
for write ops)
However, CPFMTXA gives record numbers in sequential order for all
tracks on a cylinder (except for record 0). So for a CPFMTXA formated
volume, The only record 1 for cyl 0 is CCHHRR 0 0 1 - there is no CCHHRR
0 1 1 (that's what my z/VM 5.3 CPFMTXA does anyway - but I doubt it has
changed since then).
So obviously this volume WAS CPFMTXA formatted - (CMS Format doesn't do
that - Records are allocated with sequential numbering per track instead
of CPFMTXA record numbering per cylinder). However I am wondering why
FORMSSI is trying to access head 1 instead of head 0 for that cylinder.
Food for thought.
--Ivan
[Non-text portions of this message have been removed]
Ivan Warren ivan@vmfacility.fr [hercules-390]
2016-04-19 19:21:08 UTC
Permalink
Post by 'John P. Hartmann' ***@gmail.com [hercules-390]
This thread seems confusing to me.
A virtual machine can do synchronous disk I/O using diagnose A4. It can
issue diag A8 do generalised I/O to any device for which CP does error
recovery.
Agreed !
Post by 'John P. Hartmann' ***@gmail.com [hercules-390]
In either case, CP does SSCH (as it clearly must do).
Of course :) (what I said)
What I am saying is that Peter may have misconstrued the "synchronous"
hercules message - as a virtual machine issued DIAG A8 (which is what he
might have seen as being issued by the virtual machine) - although they
are completely unrelated.

Diag A8 is what you describe

The "Synchronous" message is simply that some I/Os in hercules are
"synchronous" in the sense they are performed by the CPU thread (instead
of a device thread) directly whenever possible (When operations permit
(some immediate operations, or cache is available), the I/O operation is
complete when the SIO(F)/SSCH instructions complete). Remember this
technique dates from 15/20 years ago when cross thread communication (or
spawning thread) was a heavy operation, and multi-thread/multi-core
systems were uncommon.

--Ivan



[Non-text portions of this message have been removed]
'Peter J. Jansen' peter_j_jansen@yahoo.com [hercules-390]
2016-04-20 14:46:52 UTC
Permalink
My assumption that FORMSSI issued a DIAG A8 instruction was purely because the description of error message “HCP6605E Error 13 
” mentioned it, and because I saw return code 13 being issued in the source for that instruction. But, I can now confirm that what you already knew is indeed the case: FORMSSI does NOT issue a DIAG A8 instruction (and neither does CPFMTXA / ICKDSF). My next suspicion is for a bug in FORMSSI, but so far I saw nothing applicable in the 3 APAR’s or so that I found. I will now try to debug this not whilst trying the z/VM SSI install, but in a regular (non-SSI) z/VM, as the CPFMTXA / ICKDSF followed by FORMSSI commands are easy enough. I’ll try to reproduce the problem in a more capable environment.



Ivan, following your very valuable explanation, could it be that a correct functioning FORMSSI should be able to CREATE CCHHRR=0 1 1 following CPFMTXA which did not create that record ? It would have to act on the NRF condition instead of ending in error. I kinda assume that that single CCHHRR=0 1 1 record contains (or begins) the PDR, which FORMSSI can also UDATE. So as improbable as it may seem to me, it would not be impossible that the FORMSSI I used does have a problem creating the PDR from scratch. Installations upgrading from an existing PDR would never experience the problem. But again, hard to imagine such FORMSSI bug would only be discovered now 
 So I’m still searching 




Thanks,



Peter J.



From: hercules-***@yahoogroups.com [mailto:hercules-***@yahoogroups.com]
Sent: Tuesday, 19 April, 2016 20:38
To: hercules-***@yahoogroups.com
Subject: Re: [hercules-390] 3390 Synchronous Disk I/O w. Diagnose 'A8' Problem for z/VM SSI cmd FORMSSI
0630:synchronous I/O ccw addr 7ff2a388
HHCCP048I 0630:CCW=63400010 7FF47C78=>C0C08000 00000000 00000000 00000001 {{..............
HHCCP075I 0630:Stat=0C00 Count=0000
HHCCP048I 0630:CCW=47400010 7FF2A4B8=>06000001 00000 001 00000001
01FF0000 ................
2 things here....

First the "synchronous I/O ccw..." message doesn't mean the operation
was issued by a DIAG A8. It means that (until further notice) the I/O is
being performed synchronously by the CPU thread (and not a separate I/O
thread). The I/O is then diverged to a device thread if the necessary
data is not in cache or if some condition arises for which holding up
the CPU thread would be counter-productive.

Side Note : if CP was using DIAG A8 for when issuing I/Os - it wouldn't
be able to dispatch other virtual machines while waiting for an
operation to complete - and this would defeat CP as a virtualization
hypervisor. So I'm pretty sure CP does NOT use DIAG A8 to issue I/Os.
Because the message prefix is "HCP" for FORMSSI doesn't mean it is
issued directly by CP - It just indicates FORMSSI is a CP utility (it's
still a CMS module).

Next....

The other thing that I however find disturbing is that second CCW. It's
a locate record with read record of length 1 (1 record) with a seek to
Cyl 0 Head 1 - to read Record Cyl 0 Hd 1 Rec 1 :

(Note - The Record number is the 5 first bytes of the count area).

06 : Read
000001 : 1 Record
00000001 : Cyl 0, Head 1
00000001 01 : Cyl 0, Head 1, Record 1 (The search succeeds if the CCHH
is correct and the Record ID in the count field matches) - Won't happen
for CPFMTXA formated DASDs.
FF0000 : Sector positioning (FF - N/A) and transfer length factor (only
for write ops)

However, CPFMTXA gives record numbers in sequential order for all
tracks on a cylinder (except for record 0). So for a CPFMTXA formated
volume, The only record 1 for cyl 0 is CCHHRR 0 0 1 - there is no CCHHRR
0 1 1 (that's what my z/VM 5.3 CPFMTXA does anyway - but I doubt it has
changed since then).

So obviously this volume WAS CPFMTXA formatted - (CMS Format doesn't do
that - Records are allocated with sequential numbering per track instead
of CPFMTXA record numbering per cylinder). However I am wondering why
FORMSSI is trying to access head 1 instead of head 0 for that cylinder.

Food for thought.

--Ivan

[Non-text portions of this message have been removed]

Loading...