Discussion:
IPL from channel program
(too old to reply)
Mike Stramba
2010-04-21 04:24:37 UTC
Permalink
Hi guys,

I thought I would start with something "easy" with a DASD ccw / sio program.

So I setup a CCW with a read-ipl cmd (02), so as not to have to do
the seek, etc other ccw's.

When I run it, however it is not reading the same data that I get when
I use the Hercules ipl command.

This happens both in S/370 and S/390 / z/Arch archmodes.

Is it supposed to? .. or is there a different behavior expected for
a "program-executed" ipl-ccw, vs the "hardware" ipl ?

2) Also, I wrote the ipl text to the dasd using the dasdload program,
and the ipl text is actually more than 24 bytes long.

The Hercules / ipl command *is* reading the entire ipl text.

Is that because the dasd (3330) is ignoring the (implied) CCW length of 24?

In GA26-1592-2 (".. 3830 Storage Control and 3330 Disk storage"),
for the READ IPL command it does show a count field, that is supposed
to be used for number of bytes to be transferred.

Mike
John P. Hartmann
2010-04-21 04:41:02 UTC
Permalink
Assuming you are doing this on CKD, you need to format track 0 with one
24-byte record that contains your PSW, a read for the actual IPL channel
program (which you store in record 1 of the track), and a TIC to the
program.

If you want to emulate the IPL sequence, you need to build the implied read
IPL CCW at location 0 (CC and SILI) and limit it to read 24 bytes; and, at
the end of the channel program, store absolute 184 to 191 and load the PSW
from location 0.

Some may recall that 360/30 needed an EC to be able to ipl the OS/360
release 6 starter system.

j.
Post by Mike Stramba
Hi guys,
I thought I would start with something "easy" with a DASD ccw / sio
program.
So I setup a CCW with a read-ipl cmd (02), so as not to have to do
the seek, etc other ccw's.
When I run it, however it is not reading the same data that I get when
I use the Hercules ipl command.
This happens both in S/370 and S/390 / z/Arch archmodes.
Is it supposed to? .. or is there a different behavior expected for
a "program-executed" ipl-ccw, vs the "hardware" ipl ?
2) Also, I wrote the ipl text to the dasd using the dasdload program,
and the ipl text is actually more than 24 bytes long.
The Hercules / ipl command *is* reading the entire ipl text.
Is that because the dasd (3330) is ignoring the (implied) CCW length of 24?
In GA26-1592-2 (".. 3830 Storage Control and 3330 Disk storage"),
for the READ IPL command it does show a count field, that is supposed
to be used for number of bytes to be transferred.
Mike
[Non-text portions of this message have been removed]



------------------------------------
Mike Stramba
2010-04-21 04:59:36 UTC
Permalink
Hi John,

I'm not trying to emulate the IPL sequence, I'm just trying to read
from the dasd, ... and know what I'm reading ;)

I'll try using the SEEK, SEARCH, and all the various READ permuations next.

I *thought* that using a READ-IPL (2) command in the CCW, should read
the same data as the console / Hercules ipl command, but I'm not
seeing that result.

Mike

The dasdload is writing the ipl text correctly, as I *can* ipl from
the dasd ... though I'm not sure that it should be able to .... given
that the ipl text is > 24 bytes. (And the ipl text does *not* have a
valid CCW starting at the 8th byte (which presumably would be loaded
as a CCW, and chained to by the IPL) ... (I copied the ipl text from
the IBCDASDI program btw)

I'm only using the ipl command as
Post by John P. Hartmann
Assuming you are doing this on CKD, you need to format track 0 with one
24-byte record that contains your PSW, a read for the actual IPL channel
program (which you store in record 1 of the track), and a TIC to the
program.
If you want to emulate the IPL sequence, you need to build the implied read
IPL CCW at location 0 (CC and SILI) and limit it to read 24 bytes; and, at
the end of the channel program, store absolute 184 to 191 and load the PSW
from location 0.
Some may recall that 360/30 needed an EC to be able to ipl the OS/360
release 6 starter system.
j.
Post by Mike Stramba
Hi guys,
I thought I would start with something "easy" with a DASD ccw / sio
program.
So I setup a CCW with a read-ipl cmd (02), so as not to have to do
the seek, etc other ccw's.
When I run it, however it is not reading the same data that I get when
I use the Hercules ipl command.
This happens both in S/370 and S/390 / z/Arch archmodes.
Is it supposed to? .. or is there a different behavior expected for
a "program-executed" ipl-ccw, vs the "hardware" ipl ?
2) Also, I wrote the ipl text to the dasd using the dasdload program,
and the ipl text is actually more than 24 bytes long.
The Hercules / ipl command *is* reading the entire ipl text.
Is that because the dasd (3330) is ignoring the (implied) CCW length of 24?
In GA26-1592-2 (".. 3830 Storage Control and 3330 Disk storage"),
for the READ IPL command it does show a count field, that is supposed
to be used for number of bytes to be transferred.
Mike
[Non-text portions of this message have been removed]
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
Yahoo! Groups Links
John P. Hartmann
2010-04-21 05:09:40 UTC
Permalink
Read IPL seeks to cylinder 0 track 0 and reads record 1. You won't be able
to read any old data that way.

For 3390 disk you have a bit of learning curve with define extent and
locate, but maybe you can get away with just seek, search, tic *-8, read.
If you're not running stand-alone on the machine, the operating system will
insert a set file mask CCW in front of your chain to limit your ability to
seek and/or write. But I guess that as you say SIO, you're already in
supervisor state.

j.
Post by Mike Stramba
Hi John,
I'm not trying to emulate the IPL sequence, I'm just trying to read
from the dasd, ... and know what I'm reading ;)
I'll try using the SEEK, SEARCH, and all the various READ permuations next.
I *thought* that using a READ-IPL (2) command in the CCW, should read
the same data as the console / Hercules ipl command, but I'm not
seeing that result.
Mike
The dasdload is writing the ipl text correctly, as I *can* ipl from
the dasd ... though I'm not sure that it should be able to .... given
that the ipl text is > 24 bytes. (And the ipl text does *not* have a
valid CCW starting at the 8th byte (which presumably would be loaded
as a CCW, and chained to by the IPL) ... (I copied the ipl text from
the IBCDASDI program btw)
I'm only using the ipl command as
Post by John P. Hartmann
Assuming you are doing this on CKD, you need to format track 0 with one
24-byte record that contains your PSW, a read for the actual IPL channel
program (which you store in record 1 of the track), and a TIC to the
program.
If you want to emulate the IPL sequence, you need to build the implied
read
Post by John P. Hartmann
IPL CCW at location 0 (CC and SILI) and limit it to read 24 bytes; and,
at
Post by John P. Hartmann
the end of the channel program, store absolute 184 to 191 and load the
PSW
Post by John P. Hartmann
from location 0.
Some may recall that 360/30 needed an EC to be able to ipl the OS/360
release 6 starter system.
j.
Post by Mike Stramba
Hi guys,
I thought I would start with something "easy" with a DASD ccw / sio
program.
So I setup a CCW with a read-ipl cmd (02), so as not to have to do
the seek, etc other ccw's.
When I run it, however it is not reading the same data that I get when
I use the Hercules ipl command.
This happens both in S/370 and S/390 / z/Arch archmodes.
Is it supposed to? .. or is there a different behavior expected for
a "program-executed" ipl-ccw, vs the "hardware" ipl ?
2) Also, I wrote the ipl text to the dasd using the dasdload program,
and the ipl text is actually more than 24 bytes long.
The Hercules / ipl command *is* reading the entire ipl text.
Is that because the dasd (3330) is ignoring the (implied) CCW length of 24?
In GA26-1592-2 (".. 3830 Storage Control and 3330 Disk storage"),
for the READ IPL command it does show a count field, that is supposed
to be used for number of bytes to be transferred.
Mike
[Non-text portions of this message have been removed]
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
Yahoo! Groups Links
[Non-text portions of this message have been removed]



------------------------------------
PeterH
2010-04-21 05:31:55 UTC
Permalink
Post by John P. Hartmann
For 3390 disk you have a bit of learning curve with define extent and
locate
DEFINE EXTENT followed by

LOCATE RECORD


These perform the same function as the old

STAND ALONE SEEK followed by

SET FILE MASK (to inhibit SEEK CYLINDER)
Gerhard Postpischil
2010-04-22 01:52:23 UTC
Permalink
Post by PeterH
Post by John P. Hartmann
For 3390 disk you have a bit of learning curve with define extent and
locate
DEFINE EXTENT followed by
LOCATE RECORD
These perform the same function as the old
STAND ALONE SEEK followed by
SET FILE MASK (to inhibit SEEK CYLINDER)
I'm confused. I've never run on real 3390s, only the Hercules
and OS/390 simulated disks. I have a forty year old program that
uses EXCP to read and write to DASD, without benefit of SAM or
BPAM, and the only things I ever had to change in the channel
programs was addition of SET SECTOR CCWs. The routine
SEEK/SEARCH/READ KD/WRITE KD and CKD commands appear to work
just fine.

So either someone translates the chains (unlikely in MVS or
OS/390), or the control unit recognized the command type and
behaves accordingly?

Gerhard Postpischil
Bradford, VT
PeterH
2010-04-22 03:01:21 UTC
Permalink
Post by Gerhard Postpischil
Post by PeterH
DEFINE EXTENT followed by
LOCATE RECORD
These perform the same function as the old
STAND ALONE SEEK followed by
SET FILE MASK (to inhibit SEEK CYLINDER)
I'm confused. I've never run on real 3390s, only the Hercules
and OS/390 simulated disks. I have a forty year old program that
uses EXCP to read and write to DASD, without benefit of SAM or
BPAM, and the only things I ever had to change in the channel
programs was addition of SET SECTOR CCWs. The routine
SEEK/SEARCH/READ KD/WRITE KD and CKD commands appear to work
just fine.
EXCP is pretty much EXCP, and the DEFINE EXENT and LOCATE RECORD are
under the covers of the STARTIO function of IOS, and EXCP really
doesn't know that much about it, although it can, of course, receive
feedback from BASIC IOS through the appendage mechanism, which is
really only a simulation, and a translation from BASIC IOS' several
exits (Post Status Normal End, Post Status Abnormal End, etcetera) to
the somewhat equivalent appendages of EXCP (CEND, XEND).

By design, the SIO function can and most often does run on a
different CPU than the PSNE and PSAE exits, as the SIO function is
totally synchronous (with the channel scheduler) whereas the PSNE and
PSAE exits are totally asynchronous (with the channel scheduler) and
are run under an SRB.
Post by Gerhard Postpischil
So either someone translates the chains (unlikely in MVS or
OS/390), or the control unit recognized the command type and
behaves accordingly?
STAND ALONE SEEK plus SET FILE MASK accomplishes data set integrity
on OS/360 and related OSes. The file mask determines the permission
to effect seeks by subsequent CCWs. If the dataset is track
allocated, then the file mask will allow seek tracks, only. STAND
ALONE SEEKS and SET FILE MASKS are inhibited after the TIC which is
after the initial SET FILE MASK, therefore these may not appear in
any user's channel program.

After the SFM, a TIC is done to the channel program pointed to in the
IOB (only virtual addresses are provided, unless it is an EXCPVR).

DEFINE EXTENT plus LOCATE RECORD accomplishes data set integrity on
ESA and related OSes. The DX has the equivalent of the file mask.

After the LR, a TIC is done to the channel program pointed to in the
IOSB (both real and virtual addresses are provided).

Obviously DX and LR are more flexible than SAS and SFM.

In my last position before I retired, we did everything at the
STARTIO level, and all of our CPs began with DX and LR.
Mike Stramba
2010-04-21 06:06:23 UTC
Permalink
Post by John P. Hartmann
Read IPL seeks to cylinder 0 track 0 and reads record 1. You won't be able
to read any old data that way.
I'm not expecting to read "any old data", just the data that's defined
by the manual ;)
Post by John P. Hartmann
For 3390 disk you have a bit of learning curve
Even more of a learning curve, since I can't seem to find any manuals
for the 3390 online. The few links I've found on IBM's site are
broken.

I'm looking for manuals for whatever the newest DASD that Hercules supports
(9345 ?? .. and the FBA devices).

Considering that IBM is in the information business, their web site /
manuals organization is ..... "not good" IMO ;)
laddiehanus
2010-04-21 14:28:48 UTC
Permalink
Post by Mike Stramba
Post by John P. Hartmann
Read IPL seeks to cylinder 0 track 0 and reads record 1. You won't be able
to read any old data that way.
I'm not expecting to read "any old data", just the data that's defined
by the manual ;)
Post by John P. Hartmann
For 3390 disk you have a bit of learning curve
Even more of a learning curve, since I can't seem to find any manuals
for the 3390 online. The few links I've found on IBM's site are
broken.
Look for the 3990 control unit manuals. They are on the IBM website
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/Shelves/EZ2HW125
Look for 3990 Reference

They are old but still work IBM has not updated them in years. Now you have to license them for many $ (7 figures) and the NDA you would have to sign would not allow you to use them as you would want to.
Post by Mike Stramba
I'm looking for manuals for whatever the newest DASD that Hercules supports
(9345 ?? .. and the FBA devices).
Considering that IBM is in the information business, their web site /
manuals organization is ..... "not good" IMO ;)
I agree there is no easy way to get to the z systems library from the main IBM web page.

Laddie Hanus
Mike Schwab
2010-04-22 01:58:50 UTC
Permalink
On Wed, Apr 21, 2010 at 9:28 AM, laddiehanus <laddiehanus-/***@public.gmane.org> wrote:
<deleted>
Post by laddiehanus
I agree there is no easy way to get to the z systems library from the main IBM web page.
Laddie Hanus
Open browser, type in www.ibm.com, result is http://www.ibm.com/us/en/
Mouse over Support & Downloads, Click on Documentation, result
http://www.ibm.com/support/documentation/us/en/?cm_re=masthead-_-supdl-_-documentation
Select System Z, click =>, result
http://www-947.ibm.com/systems/support/supportsite.wss/brandmain?brandind=5000026
Select hardware or operating system (z/OS), Click (GO), result
http://www-947.ibm.com/systems/support/z/zos/index.html
Click z/OS Internet Library, result
http://www-03.ibm.com/systems/z/os/zos/bkserv/
Under z/OS elements and Feature, row PDF, Select 1.11 (APARs and PTFs
may have updated you system to use newer features or messages.
Manuals reflect the initial release). Result
http://www-03.ibm.com/systems/z/os/zos/bkserv/r11pdf/ which is a long
list of manuals.
--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?
Mike Stramba
2010-04-22 02:32:26 UTC
Permalink
Mike,

Thanks for posting the "magic link" : !

http://www-03.ibm.com/systems/z/os/zos/bkserv/r11pdf/

At least one of the links on that page works ;) (they may all work,
but the one I was interested in does (DFMS diagnosis)

.... and you also proved : ;)
Post by laddiehanus
I agree there is no easy way to get to the z systems library from the main IBM web page.
Mike
Post by laddiehanus
<deleted>
Post by laddiehanus
I agree there is no easy way to get to the z systems library from the main IBM web page.
Laddie Hanus
Open browser, type in www.ibm.com, result is http://www.ibm.com/us/en/
Mouse over Support & Downloads, Click on Documentation, result
http://www.ibm.com/support/documentation/us/en/?cm_re=masthead-_-supdl-_-documentation
Select System Z, click =>, result
http://www-947.ibm.com/systems/support/supportsite.wss/brandmain?brandind=5000026
Select hardware or operating system (z/OS), Click (GO), result
http://www-947.ibm.com/systems/support/z/zos/index.html
Click z/OS Internet Library, result
http://www-03.ibm.com/systems/z/os/zos/bkserv/
Under z/OS elements and Feature, row PDF, Select 1.11 (APARs and PTFs
may have updated you system to use newer features or messages.
Manuals reflect the initial release). Result
http://www-03.ibm.com/systems/z/os/zos/bkserv/r11pdf/ which is a long
list of manuals.
--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?
PeterH
2010-04-21 05:20:26 UTC
Permalink
Post by Mike Stramba
I'll try using the SEEK, SEARCH, and all the various READ
permuations next.
CCHHR 00000001 contains the channel program (2 x 8 bytes) and the
restart PSW (1 x 8 bytes) = 24 bytes

CCHHR 00000002 contains the IPL text = 3K or so

CCHHR 00000003 contains the volume label in the more-or-less standard
VOL1 format, but it also contains the CCHHR of the VTOC = 80 bytes

You can access these with traditional commands.

IIRC, the volume label has a 4 byte key, so use READ KEY+DATA for
that one.
laddiehanus
2010-04-21 14:41:39 UTC
Permalink
Post by Mike Stramba
2) Also, I wrote the ipl text to the dasd using the dasdload program,
and the ipl text is actually more than 24 bytes long.
Dasdload will build its own IPL record 1 and 2 and writes the object file you give it as record 4
Post by Mike Stramba
The Hercules / ipl command *is* reading the entire ipl text.
The hardware issues the read ipl which reads the IPL1 record into location 0 and does a TIC (transfer in channel ) to location 8 which reads the IPL2 record in. The IPL2 record (i dont have the code with me right now) reads in record 4 at location 0.
Unless you code that exactly you will not get the same result.
Post by Mike Stramba
Is that because the dasd (3330) is ignoring the (implied) CCW length of 24?
In GA26-1592-2 (".. 3830 Storage Control and 3330 Disk storage"),
for the READ IPL command it does show a count field, that is supposed
to be used for number of bytes to be transferred.
Mike
Laddie Hanus
Mike Stramba
2010-04-21 15:15:46 UTC
Permalink
Laddiie,

Ah ! .. thank you .. it's now starting to make (some) sense.

I fired up zzsa,and it shows the same thing my program was reading, so
that's good ;)

Mike
Post by laddiehanus
Post by Mike Stramba
2) Also, I wrote the ipl text to the dasd using the dasdload program,
and the ipl text is actually more than 24 bytes long.
Dasdload will build its own IPL record 1 and 2 and writes the object file
you give it as record 4
Post by Mike Stramba
The Hercules / ipl command *is* reading the entire ipl text.
The hardware issues the read ipl which reads the IPL1 record into location 0
and does a TIC (transfer in channel ) to location 8 which reads the IPL2
record in. The IPL2 record (i dont have the code with me right now) reads in
record 4 at location 0.
Unless you code that exactly you will not get the same result.
Post by Mike Stramba
Is that because the dasd (3330) is ignoring the (implied) CCW length of 24?
In GA26-1592-2 (".. 3830 Storage Control and 3330 Disk storage"),
for the READ IPL command it does show a count field, that is supposed
to be used for number of bytes to be transferred.
Mike
Laddie Hanus
Ivan Warren
2010-04-21 15:45:25 UTC
Permalink
Post by laddiehanus
The hardware issues the read ipl which reads the IPL1 record into location 0 and does a TIC (transfer in channel ) to location 8 which reads the IPL2 record in. The IPL2 record (i dont have the code with me right now) reads in record 4 at location 0.
Unless you code that exactly you will not get the same result.
Actually, close, but not quite..

The IPL manual control operation issues an I/O to the IPL
device/subchannel by issuing a CCW with the Read IPL Command Code
(X'02'), an absolute address of 0, SILI+CC (Suppress Incorrect Length
Indication + Command Chaining), and a length of 24. NO CCW is prefetched
at that point.

Upon successful completion of the CCW, the next CCW is chained (by the
CC bit) - and that is what was read by the initial CCW (so you have a
fine example of a self modifying I/O !). No TIC is involved here by the
IPL processing in itself - so the CCW at 8 isn't fetched because of a
TIC but because of command chaining which occurs as if the initial IPL
CCW was at address 0. the CCWs contained in the IPL record *may* contain
a TIC - and often do - but that's beyond the actual IPL process.

Let's look at how it would work on a sequential type device (a tape or a
card reader for example)..

Let's say the 1st record (card, tape block) contains the following :

00080000 00001050 02001000 60000050 08001000 00000000

Followed by a 80 byte record containing :

02001050 60000050 020010A0 60000050 .. etc .. (with a final CCW with no
CC in the flags)

And finally 80 byte records containing the executable code..

The initial CCW is executed at 0 (or rather as if it was at 0) :
02000000 60000018.. Data transfer completes, the next CCW is fetched
from address X'8' by the channel because of the command chaining :
02001000 60000050 .. then the TIC .. then the series of reads..

Finally, when the last CCW is encountered (one without Command Chaining
that is), and assuming the final status is CE+DE, then the PSW is loaded
with the contents of address 0 (real address 0, but at this point, the
prefix is 0 so real=absolute) - that's the 1st 8 bytes of the IPL record.

--Ivan
John P. Hartmann
2010-04-22 08:12:27 UTC
Permalink
Post by Ivan Warren
a TIC - and often do - but that's beyond the actual IPL process.
Close, Ivan, but no cigar. The IPL sequence continues and the load light
stays on until channel end on the final CCW.

In the 360 days I made a three card deck that could load TXT records from a
standard OS object deck without doing additional I/O and having to cope with
interrupts. That is, throw away the ESD and insert a card in front of the
end card to set the psw address at location 5-7 from that card.

j.


[Non-text portions of this message have been removed]
Ivan Warren
2010-04-22 10:05:17 UTC
Permalink
Post by John P. Hartmann
Post by Ivan Warren
a TIC - and often do - but that's beyond the actual IPL process.
Close, Ivan, but no cigar. The IPL sequence continues and the load light
stays on until channel end on the final CCW.
In the 360 days I made a three card deck that could load TXT records from a
standard OS object deck without doing additional I/O and having to cope with
interrupts. That is, throw away the ESD and insert a card in front of the
end card to set the psw address at location 5-7 from that card.
j.
Actually, probably stays on until the *DEVICE* end status is received..
But more likely stays on until the PSW is loaded from location 0 - and I
can't remember if it stays on or not if the PSW isn't valid. Anyways..

What you are describing closely looks like the original VM/370 3CARD
LOADER (DMKBSL)... Only you don't have to insert any additional card,
because the END card itself can contain that information. 3CARD LOADER
also does the same (throw away ESD and RLD cards.. Well, actually any
card that's not a TXT or END card).

Something like :

FOO CSECT
ORG *+X'10000'
STARTIT DS 0H
...
...
END STARTIT

will generate an END card with the address of "STARTIT" - so no need to
add any PUNCH statement there !

note that this works with IFOX or the XF assembler.. Not sure about
assembler F.

Funny enough, the modern version of 3CARD LOADER (the one provided with
VM/XA and above - aka HCPBSL) is still named 3CARD LOADER even though
it's 5 cards long (the 2nd card also holds a couple additional CCWs to
load the additional code card). They obviously couldn't make it hold
inside 3 cards anymore because HCPBSL is bimodal (i.e. it works both in
S/370 and XA+ modes)

With VM/370, if your IPLable program is more complicated (i.e. you have
multiple TEXT decks) you also have the option to use DMKLD00E LOADER
which is basically a standalone loader that handles ESD, RLD, etc - and
produces a neat load MAP. It's used by VM/370 for the CP, CMS and RSCS
nuclei (and later for the GCS nucleus)

--Ivan
John P. Hartmann
2010-04-22 10:40:31 UTC
Permalink
Actually, probably stays on until the *DEVICE* end status is received..
Undoubtedly. You don't want a stray device end. But the book is rather
vague on this point. Even the 360 one just says "When reading is completed
satisfactorily"
Post by Ivan Warren
But more likely stays on until the PSW is loaded from location 0 - and I
can't remember if it stays on or not if the PSW isn't valid. Anyways..
It stays in the load state.
What you are describing closely looks like the original VM/370 3CARD
Post by Ivan Warren
LOADER (DMKBSL)... Only you don't have to insert any additional card,
Yes, I was quite amused when I discovered that some years later. It is now
HCPBSL and has inflated to 240 bytes from the original 160, so it is five
cards, though the file name has not changed:

3CARD LOADER S2 F 80 5 1 10/11/05
11:56:52

It used to be that it was also a CMS command that would punch the three
cards, but that seems to be gone now.

j.


[Non-text portions of this message have been removed]
Gerhard Postpischil
2010-04-22 15:39:36 UTC
Permalink
Post by Ivan Warren
note that this works with IFOX or the XF assembler.. Not sure about
assembler F.
Works just fine with the earlier assemblers, and the three card
loader each preceded by a REPRO.

I found out by looking at the stand-alone printer UCS loader
deck, and it appears to be standard for many uses.

Gerhard Postpischil
Bradford, VT

Continue reading on narkive:
Loading...