Re: CKD details

[Anne & Lynn Wheeler]

sme...@gmu.edu (Seymour J Metz) writes:
> The 3330 was not the first disk drive with Set Sector; that honor
> belongs to the 2305, formally part of the S/360 series rather than the
> S/370, although I imagine that a lot more were sold for use on, e.g.,
> 370/165, than for 85 or 195.

re:
http://www.garlic.com/~lynn/2018.html#77 CKD details
http://www.garlic.com/~lynn/2018.html#79 CKD details

(resend) 2305 was also fixed-head disk (head per track, sort of
replacement for 2301 & 2303 fixed-head drums) ... so there was no arm
movement latency, just rotational delay.

most internal sites used 2305-2 as paging device, approx. 11mbyte
capacity, 1.5mbyte transfer.

There was 2305-1, same number of heads, but only half the tracks, two
heads positioned on track, offset 180degrees and transferred in parallel
for 3mbytes/sec (special two byte channel), half the number of tracks,
(little less than) half the capacity and half the rotational delay
... basically even/odd bytes that could start as soon as came under
either offset/opposing heads.
https://www-03.ibm.com/ibm/history/exhibits/storage/storage_2305.html
and
https://www-03.ibm.com/ibm/history/exhibits/storage/storage_PH2305.html

2305 also had "multiple exposure" support ... eight device addresses
... uniform formating of tracks ... software strategies for the eight
addresses could be used to let the controller maximize the transfer per
rotation.

very late 70s, early 80s, IBM contracted with vendor for electronic
disks (for paging use at internal datacenters) ... referenced as model
1655, could simulate 2305 or operate natively (more like FBA) ... no arm
motion, no retational delay. some old email
http://www.garlic.com/~lynn/2007e.html#email820805

as aside, 3380 3mbyte channel used "data streaming" ... channels had
used protocol that did end-to-end (half-duplex) handshaking on every
byte transferred, "data streaming" support would transfer multiple bytes
per end-to-end handshake ... allowed for increasing data transfer rate
as well as doubled maximum channel cabling distance.

trivia: ECKD was originally used for calypso ... speed-matching 3880
controller feature that allowed 3380 3mbyte/sec to used with 168 & 3033
1.5mbyte/sec channels (took enormous amount of work to get all the kinks
worked out, i've frequently commented it would have been less effort to
have just moved to FBA). some old email
http://www.garlic.com/~lynn/2007e.html#email820907b
a little more in these posts
http://www.garlic.com/~lynn/2010e.html#36 What was old is new again (water 
chilled)
http://www.garlic.com/~lynn/2015f.html#83 Formal definituion of Speed Matching 
Buffer

recent post trying to get 2nd "exposure" (device address) for the 3350
fixed-head feature (allowing data transfer overlapped with arm motion)
http://www.garlic.com/~lynn/2017k.html#44 Can anyone remember "drum" storage?

getting to play disk engineer in bldgs 14&15 posts
http://www.garlic.com/~lynn/subtopic.html#disk
CKD, FBA, multi-track search, etc posts
http://www.garlic.com/~lynn/submain.html#dasd

-- 
virtualization experience starting Jan1968, online at home since Mar1970

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: CKD details

[Seymour J Metz]

No, Seek and Set Sector are unrelated. Typically the Seek would be the first 
CCW after the Reserve, if any; Set Sector would normally be just prior to a 
Search. Both attempt to disconnect after data transfer.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of Ron 
hawkins <ronjhawk...@sbcglobal.net>
Sent: Wednesday, January 24, 2018 5:59 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: CKD details

Tony,

I am way in over my head here, and I am sure I will use the wrong terminology.

As I remember it RPS was implemented by passing seek and set sector to the DASD 
together so there was only one disconnect sequence? Without RPS there was a 
disconnect/reconnect sequence for the seek, followed by set sector.

Or something like that. My curiosity is crying out for someone to correct me 

Ron



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Harminc
Sent: Wednesday, January 24, 2018 10:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] CKD details

On 24 January 2018 at 10:57, Seymour J Metz <sme...@gmu.edu> wrote:
I wrote:
>> What use is Set Sector without a block multiplexor channel (which
>> allows disconnect/reconnect)? Were those available for some S/360
>> models?
> Of course they were available; the model number for the 230 should be a clue 
> that it was announced for the S/360.  For that matter, the model number of 
> the 2880 is a dead giveaway. Check bitsavers for the 360/85 and 360/195.

I understand the model numbering. But there's no *requirement* to use Set/Read 
Sector in your channel programing for a device that supports RPS; it's just a 
performance issue. A 3330 (and a fortiori, a 2305) should be able to be plugged 
into a 2860 selector channel and still work.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: CKD details

[Tony Harminc]

On 24 January 2018 at 17:59, Ron hawkins  wrote:
> Tony,
>
> I am way in over my head here, and I am sure I will use the wrong terminology.

Not to worry. I'm sure I've got things wrong too. And the old memory
isn't what it once was...

> As I remember it RPS was implemented by passing seek and set sector to the 
> DASD together so there was only one disconnect sequence? Without RPS there 
> was a disconnect/reconnect sequence for the seek, followed by set sector.

On any disk you can write a channel program that reads a record in one
go. You would chain together a Seek CCW to position the heads to the
right cylinder (and set the track number at the same time), a search
CCW to find your record by its number or key, a TIC ("branch) CCW to
loop back to the Search if it fails, and finally a Read CCW to get the
data.

But this is a really bad idea, because the channel is busy from the
start of the seek to the end of the read, and the physical head motion
is very slow compared to the data transfer speed. If you tried to
start another channel program against another device on the same
channel, it would get a Busy from the SIO.

So the traditional pre-RPS channel program has a stand-alone Seek. The
channel passes this to the CU/drive, and the channel program ends with
Channel End but no Device End. Now another device on the same channel
can have a channel program started against it. Then way way later,
when the access arm arrives at the right cylinder on the first drive,
a Device End is delivered. Now you issue that original program I
described, but this time there is no Seek time, and the channel is
busy only during the search loop and data transfer. But that can still
be bad, because your record may have just gone by as your Search CCW
executes the first time, and so the channel will be in a loop running
your search until the record comes around. On average obviously you'll
be half a revolution away from the start of your record.

Enter RPS. The Seek stuff is the same as above. But your channel
program now has a Set Sector CCW chained in before the Search loop,
which tells the device where rotationally it should start looking. The
control unit/device *on their own initiative* disconnect from the
channel, allowing it to be used for another data transfer on another
device. When your record is close to being under the head, the CU
reconnects to the channel, and with luck your Search CCW finds the
record on the very first try. If it's a little too soon, well your
record won't be much further away.

But... The reconnect can miss ("RPS miss") if the channel is too busy
for whatever reason. But the CU/device will retry, so your channel
program doesn't need to do anything.

Where does the sector number come from? Either the program can
calculate it or it can obtain it from when it wrote the record, using
a Read sector CCW chained in to the Write channel program.

> Or something like that. My curiosity is crying out for someone to correct me 

Doubtless someone will correct my fuzziness between the CU and the
device here...

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: CKD details

[Ron hawkins]

Tony,

I am way in over my head here, and I am sure I will use the wrong terminology.

As I remember it RPS was implemented by passing seek and set sector to the DASD 
together so there was only one disconnect sequence? Without RPS there was a 
disconnect/reconnect sequence for the seek, followed by set sector.

Or something like that. My curiosity is crying out for someone to correct me 

Ron



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Harminc
Sent: Wednesday, January 24, 2018 10:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] CKD details

On 24 January 2018 at 10:57, Seymour J Metz  wrote:
I wrote:
>> What use is Set Sector without a block multiplexor channel (which 
>> allows disconnect/reconnect)? Were those available for some S/360 
>> models?
> Of course they were available; the model number for the 230 should be a clue 
> that it was announced for the S/360.  For that matter, the model number of 
> the 2880 is a dead giveaway. Check bitsavers for the 360/85 and 360/195.

I understand the model numbering. But there's no *requirement* to use Set/Read 
Sector in your channel programing for a device that supports RPS; it's just a 
performance issue. A 3330 (and a fortiori, a 2305) should be able to be plugged 
into a 2860 selector channel and still work.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: CKD details

[Doug Fuerst]

 So did IBM for the 65/67. The 2880. And the 2860 handled every 2305 I 
found on them.


Doug Fuerst
Principal Consultant
BK Associates
718.921.2620 (O)
917.572.7364 (C)
d...@bkassociates.net



-- Original Message --
From: "Seymour J Metz" <sme...@gmu.edu>
To: IBM-MAIN@listserv.ua.edu
Sent: 24-Jan-18 4:55:25 PM
Subject: Re: CKD details

There's certainly no requirement to use Set Sector on any disk drive, 
but I question whether the 2860 could handle the data rate of a 2305.


BTW, a company called CIG had a block multiplexor channel that you 
could attach to a 360/65.



--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on 
behalf of Tony Harminc <t...@harminc.net>

Sent: Wednesday, January 24, 2018 1:28 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: CKD details

On 24 January 2018 at 10:57, Seymour J Metz <sme...@gmu.edu> wrote:
I wrote:

 What use is Set Sector without a block multiplexor channel (which
 allows disconnect/reconnect)? Were those available for some S/360
 models?
 Of course they were available; the model number for the 230 should be 
a clue that it was announced for the S/360. For that matter, the model 
number of the 2880 is a dead giveaway. Check bitsavers for the 360/85 
and 360/195.


I understand the model numbering. But there's no *requirement* to use
Set/Read Sector in your channel programing for a device that supports
RPS; it's just a performance issue. A 3330 (and a fortiori, a 2305)
should be able to be plugged into a 2860 selector channel and still
work.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: CKD details

[Seymour J Metz]

There's certainly no requirement to use Set Sector on any disk drive, but I 
question whether the 2860 could handle the data rate of a 2305.

BTW, a company called CIG had a block multiplexor channel that you could attach 
to a 360/65.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of 
Tony Harminc <t...@harminc.net>
Sent: Wednesday, January 24, 2018 1:28 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: CKD details

On 24 January 2018 at 10:57, Seymour J Metz <sme...@gmu.edu> wrote:
I wrote:
>> What use is Set Sector without a block multiplexor channel (which
>> allows disconnect/reconnect)? Were those available for some S/360
>> models?
> Of course they were available; the model number for the 230 should be a clue 
> that it was announced for the S/360.  For that matter, the model number of 
> the 2880 is a dead giveaway. Check bitsavers for the 360/85 and 360/195.

I understand the model numbering. But there's no *requirement* to use
Set/Read Sector in your channel programing for a device that supports
RPS; it's just a performance issue. A 3330 (and a fortiori, a 2305)
should be able to be plugged into a 2860 selector channel and still
work.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: CKD details

[Tony Harminc]

On 24 January 2018 at 10:57, Seymour J Metz  wrote:
I wrote:
>> What use is Set Sector without a block multiplexor channel (which
>> allows disconnect/reconnect)? Were those available for some S/360
>> models?
> Of course they were available; the model number for the 230 should be a clue 
> that it was announced for the S/360.  For that matter, the model number of 
> the 2880 is a dead giveaway. Check bitsavers for the 360/85 and 360/195.

I understand the model numbering. But there's no *requirement* to use
Set/Read Sector in your channel programing for a device that supports
RPS; it's just a performance issue. A 3330 (and a fortiori, a 2305)
should be able to be plugged into a 2860 selector channel and still
work.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: CKD details

[Anne & Lynn Wheeler]

sme...@gmu.edu (Seymour J Metz) writes:
> The 3330 was not the first disk drive with Set Sector; that honor
> belongs to the 2305, formally part of the S/360 series rather than the
> S/370, although I imagine that a lot more were sold for use on, e.g.,
> 370/165, than for 85 or 195.

re:
http://www.garlic.com/~lynn/2018.html#77 CKD details
http://www.garlic.com/~lynn/2018.html#79 CKD details

2305 was also fixed-head disk (head per track, sort of replacement for
2301 & 2303 fixed-head drums) ... so there was no arm movement latency,
just rotational delay.

most internal sites used 2305-2 as paging device, approx. 11mbyte
capacity, 1.5mbyte transfer.

There was 2305-1, same number of heads, but only half the tracks, two
heads positioned on track, offset 180degrees and transferred in parallel
for 3mbytes/sec (special two byte channel), half the number of tracks,
(little less than) half the capacity and half the rotational delay
... basically even/odd bytes that could start as soon as came under
either offset/opposing heads.
https://www-03.ibm.com/ibm/history/exhibits/storage/storage_2305.html
and
https://www-03.ibm.com/ibm/history/exhibits/storage/storage_PH2305.html

2305 also had "multiple exposure" support ... eight device addresses
... uniform formating of tracks ... software strategies for the eight
addresses could be used to let the controller maximize the transfer per
rotation.

very late 70s, early 80s, IBM contracted with vendor for electronic
disks (for paging use at internal datacenters) ... referenced as model
1655, could simulate 2305 or operate natively (more like FBA) ... no arm
motion, no retational delay. some old email
http://www.garlic.com/~lynn/2007e.html#email820805

as aside, 3380 3mbyte channel used "data streaming" ... channels had
used protocol that did end-to-end (half-duplex) handshaking on every
byte transferred, "data streaming" support would transfer multiple bytes
per end-to-end handshake ... allowed for increasing data transfer rate
as well as doubled maximum channel cabling distance.

trivia: ECKD was originally used for calypso ... speed-matching 3880
controller feature that allowed 3380 3mbyte/sec to used with 168 & 3033
1.5mbyte/sec channels (took enormous amount of work to get all the kinks
worked out, i've frequently commented it would have been less effort to
have just moved to FBA). some old email
http://www.garlic.com/~lynn/2007e.html#email820907b
a little more in these posts
http://www.garlic.com/~lynn/2010e.html#36 What was old is new again (water 
chilled)
http://www.garlic.com/~lynn/2015f.html#83 Formal definituion of Speed Matching 
Buffer

recent post trying to get 2nd "exposure" (device address) for the 3350
fixed-head feature (allowing data transfer overlapped with arm motion)
http://www.garlic.com/~lynn/2017k.html#44 Can anyone remember "drum" storage?

getting to play disk engineer in bldgs 14&15 posts
http://www.garlic.com/~lynn/subtopic.html#disk
CKD, FBA, multi-track search, etc posts
http://www.garlic.com/~lynn/submain.html#dasd

other past posts discussing 2305 & 1655
http://www.garlic.com/~lynn/2001c.html#17 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001l.html#53 mainframe question
http://www.garlic.com/~lynn/2002.html#31 index searching
http://www.garlic.com/~lynn/2002l.html#40 Do any architectures use instruction 
count instead of timer
http://www.garlic.com/~lynn/2003b.html#15 Disk drives as commodities. Was Re: 
Yamhill
http://www.garlic.com/~lynn/2003b.html#17 Disk drives as commodities. Was Re: 
Yamhill
http://www.garlic.com/~lynn/2003c.html#55 HASP assembly: What the heck is an 
MVT ABEND 422?
http://www.garlic.com/~lynn/2003m.html#39 S/360 undocumented instructions?
http://www.garlic.com/~lynn/2004d.html#73 DASD Architecture of the future
http://www.garlic.com/~lynn/2004e.html#3 Expanded Storage
http://www.garlic.com/~lynn/2005e.html#5 He Who Thought He Knew Something About 
DASD
http://www.garlic.com/~lynn/2005r.html#51 winscape?
http://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
http://www.garlic.com/~lynn/2006c.html#1 Multiple address spaces
http://www.garlic.com/~lynn/2006e.html#46 using 3390 mod-9s
http://www.garlic.com/~lynn/2006k.html#57 virtual memory
http://www.garlic.com/~lynn/2006r.html#36 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006s.html#30 Why magnetic drums was/are worse than 
disks ?
http://www.garlic.com/~lynn/2007e.html#59 FBA rant
http://www.garlic.com/~lynn/2007o.html#26 Tom's Hdw review of SSDs
http://www.garlic.com/~lynn/2007s.html#9 Poster of computer hardware events?
http://www.garlic.com/~lynn/2007u.html#4 Remembering the CDC 6600
http://www.garlic.com/~lynn/2008b.html#15 Flash memory arrays
http://www.garlic.com/~lynn/2010g.html#11 Mainframe Executive article on the 
death of tape
http://www.garlic.com/~lynn/2010g.html#22 Mainframe Executive article on the 
death of tape
http://www.garlic.com/~lynn/2010g.html#55 Mainframe Executive article on the 
death of tape

Re: CKD details

[Seymour J Metz]

Of course they were available; the model number for the 230 should be a clue 
that it was announced for the S/360.  For that matter, the model number of the 
2880 is a dead giveaway. Check bitsavers for the 360/85 and 360/195.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of 
Tony Harminc <t...@harminc.net>
Sent: Tuesday, January 23, 2018 6:37 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: CKD details

On 23 January 2018 at 13:56, Seymour J Metz <sme...@gmu.edu> wrote:
> The 3330 was not the first disk drive with Set Sector; that honor belongs to 
> the 2305, formally part of the S/360 series rather than the S/370, although I 
> imagine that a lot more were sold for use on, e.g., 370/165, than for 85 or 
> 195.

What use is Set Sector without a block multiplexor channel (which
allows disconnect/reconnect)? Were those available for some S/360
models?

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: CKD details

[Tony Harminc]

On 23 January 2018 at 13:56, Seymour J Metz  wrote:
> The 3330 was not the first disk drive with Set Sector; that honor belongs to 
> the 2305, formally part of the S/360 series rather than the S/370, although I 
> imagine that a lot more were sold for use on, e.g., 370/165, than for 85 or 
> 195.

What use is Set Sector without a block multiplexor channel (which
allows disconnect/reconnect)? Were those available for some S/360
models?

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: CKD details

[Anne & Lynn Wheeler]

sme...@gmu.edu (Seymour J Metz) writes:

> The 3330 was not the first disk drive with Set Sector; that honor
> belongs to the 2305, formally part of the S/360 series rather than the
> S/370, although I imagine that a lot more were sold for use on, e.g.,
> 370/165, than for 85 or 195.

re:
http://www.garlic.com/~lynn/2018.html#77 CKD details
http://www.garlic.com/~lynn/2018.html#79 CKD details

2305 was also fixed-head disk (head per track, sort of replacement for
2301 & 2303 fixed-head drums) ... so there was no arm movement latency,
just rotational delay.

most internal sites used 2305-2 as paging device, approx. 11mbyte
capacity, 1.5mbyte transfer.

There was 2305-1, same number of heads, but only half the tracks, two
heads positioned on track, offset 180degrees and transferred in parallel
for 3mbytes/sec (special two byte channel), half the number of tracks,
(little less than) half the capacity and half the rotational delay
... basically even/odd bytes that could start as soon as came under
either offset/opposing heads.
https://www-03.ibm.com/ibm/history/exhibits/storage/storage_2305.html
and
https://www-03.ibm.com/ibm/history/exhibits/storage/storage_PH2305.html

2305 also had "multiple exposure" support ... eight device addresses
... uniform formating of tracks ... software strategies for the eight
addresses could be used to let the controller maximize the transfer per
rotation.

very late 70s, early 80s, IBM contracted with vendor for electronic
disks (for paging use at internal datacenters) ... referenced as model
1655, could simulate 2305 or operate natively (more like FBA) ... no arm
motion, no retational delay. some old email
http://www.garlic.com/~lynn/2007e.html#email820805

as aside, 3380 3mbyte channel used "data streaming" ... channels had
used protocol that did end-to-end handshaking on every byte transferred,
"data streaming" support would transfer multiple bytes per end-to-end
handshake ... allowed for increasing data transfer rate as well as
doubled maximum channel cabling distance.

trivia: ECKD was originally used for calypso ... speed-matching 3880
controller feature that allowed 3380 3mbyte/sec to used with 168 & 3033
1.5mbyte/sec channels (took enormous amount of work to get all the kinks
worked out, i've frequently commented it would have been less effort to
have just moved to FBA). some old email
http://www.garlic.com/~lynn/2007e.html#email820907b
a little more in these posts
http://www.garlic.com/~lynn/2010e.html#36 What was old is new again (water 
chilled)
http://www.garlic.com/~lynn/2015f.html#83 Formal definituion of Speed Matching 
Buffer

recent post trying to get 2nd "exposure" (device address) for the 3350
fixed-head feature (allowing data transfer overlapped with arm motion)
http://www.garlic.com/~lynn/2017k.html#44 Can anyone remember "drum" storage?

getting to play disk engineer in bldgs 14&15 posts
http://www.garlic.com/~lynn/subtopic.html#disk
CKD, FBA, multi-track search, etc posts
http://www.garlic.com/~lynn/submain.html#dasd

other past posts discussing 2305 & 1655
http://www.garlic.com/~lynn/2001c.html#17 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001l.html#53 mainframe question
http://www.garlic.com/~lynn/2002.html#31 index searching
http://www.garlic.com/~lynn/2002l.html#40 Do any architectures use instruction 
count instead of timer
http://www.garlic.com/~lynn/2003b.html#15 Disk drives as commodities. Was Re: 
Yamhill
http://www.garlic.com/~lynn/2003b.html#17 Disk drives as commodities. Was Re: 
Yamhill
http://www.garlic.com/~lynn/2003c.html#55 HASP assembly: What the heck is an 
MVT ABEND 422?
http://www.garlic.com/~lynn/2003m.html#39 S/360 undocumented instructions?
http://www.garlic.com/~lynn/2004d.html#73 DASD Architecture of the future
http://www.garlic.com/~lynn/2004e.html#3 Expanded Storage
http://www.garlic.com/~lynn/2005e.html#5 He Who Thought He Knew Something About 
DASD
http://www.garlic.com/~lynn/2005r.html#51 winscape?
http://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
http://www.garlic.com/~lynn/2006c.html#1 Multiple address spaces
http://www.garlic.com/~lynn/2006e.html#46 using 3390 mod-9s
http://www.garlic.com/~lynn/2006k.html#57 virtual memory
http://www.garlic.com/~lynn/2006r.html#36 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006s.html#30 Why magnetic drums was/are worse than 
disks ?
http://www.garlic.com/~lynn/2007e.html#59 FBA rant
http://www.garlic.com/~lynn/2007o.html#26 Tom's Hdw review of SSDs
http://www.garlic.com/~lynn/2007s.html#9 Poster of computer hardware events?
http://www.garlic.com/~lynn/2007u.html#4 Remembering the CDC 6600
http://www.garlic.com/~lynn/2008b.html#15 Flash memory arrays
http://www.garlic.com/~lynn/2010g.html#11 Mainframe Executive article on the 
death of tape
http://www.garlic.com/~lynn/2010g.html#22 Mainframe Executive article on the 
death of tape
http://www.garlic.com/~lynn/2010g.html#55 Mainframe Executive article on the 
death of tape

Re: CKD details

[Christopher Y. Blaicher]

Yes, cells.  Doing too many things at once.

Chris Blaicher
Technical Architect
Mainframe Development
P: 201-930-8234  |  M: 512-627-3803    
E: cblaic...@syncsort.com

Syncsort Incorporated 
2 Blue Hill Plaza #1563
Pearl River, NY 10965
www.syncsort.com

Data quality leader Trillium Software is now a part of Syncsort.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Seymour J Metz
Sent: Tuesday, January 23, 2018 2:04 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CKD details

Shirley you mean cells. A  single sector might contain multiple records, 
depending on the device and on the record layouts.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of 
Christopher Y. Blaicher <cblaic...@syncsort.com>
Sent: Tuesday, January 23, 2018 9:48 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: CKD details

With all I put in the last post, I forgot to answer WHY 20 sectors at a minimum 
for a record.  It is because at a minimum a record consists of a COUNT and a 
DATA section. Each one takes a minimum of 10 sectors, so with even a 1 byte 
record you need 20 sectors.  If you had a 1 byte key and 1 byte of data you 
would need 30 sectors, 10 for each part.

Chris Blaicher
Technical Architect
Mainframe Development
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

Syncsort Incorporated
2 Blue Hill Plaza #1563
Pearl River, NY 10965
http://secure-web.cisco.com/1tr2nwUQE8UCOKlBckWSDEsS73jyrD5tkchlWz_x3UWkmi-GyWYzT6sI0opa2PLaHqtKYh9N6K4_BY-gs_dJezTZSGfI5OkwUyVWDHbefFcA9s0abuSW2YqPjdYa-OjDhWsHtZzGyIIBvxnb8cNCVpSPZZI5Dce_7S1AHPHa101MtzWbq82XPg5VRCQgPO9DnhsWLYUmEmbS72IO44Qz4A973zsDYkpf9v5zQ68DMzC2vAhv5vNcrnLjiDLuUDQ9xbFkg8IHYjfSEYDVPWv4YcMjslBpLecWTHFStPj7WtlXuVMvrbWBjcCKLS-Q59KUxYCk-6sWC8Ifit6ot_f9nvk_4EDwObxspsUKwY4gsVDr2LvVdqfxyvI2zK-Cs1l2P9UJidanG_iN7i_RV8cUCkXLdGpcKpt14PEtlH0jqKv4h9pM6zvHPN4ZeI3U64sie/http%3A%2F%2Fwww.syncsort.com

Data quality leader Trillium Software is now a part of Syncsort.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Christopher Y. Blaicher
Sent: Tuesday, January 23, 2018 8:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CKD details

See the following for how to calculate a sector 
https://secure-web.cisco.com/1-4xCrYaoIvd6moQu1tnY3-JDxDEVfGqTdaT9eR_T8lcfOTMZd1ZqkLdRfOBpKu_w6CucO8NILbbiePWe1dwLBleCsi9wLAQ6r0YUnbLI-JDtVjMISYH_vHRxn3AbPeQuPV4-_6vb8nUsRBzxzFxrPXfNmtDGBG9rXm02WNuOcCzLhtDjdsNHbatuqXWm3O0_hOxfKDYKqmIxtOWVxr_6Up8_WVVsLsxhJT0Q7-WyYLOYFH7h7HenBd777eQrLx82uebOVKhE_KJN5_TGL8qUh-XwSm4cJQRUGPlk29wHN4yTQwkgm_2qYFJU-ZsAqx9XbwqIb-LqJRHQk-lvnxqJGh72b0sXI8qIThw5V7AJqlUxyLwZ244dQdhkMwhkomvc3L8yx4-wCHK8p4eq_EzD2PmoGptCgENg0bgNN_7qKyoz-fWPge4EsIcRu54E42WZ/https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSSB27H_6.2.0%2Ffa2mr_sectval.html

Question 2: why 20 sectors at a minimum.  It's a long answer.
We tend to think of a record as three unified parts, COUNT, KEY and DATA, but 
really they are three mini-records (for lack of a better description). Each 
part needs enough cells for the data, plus 9 cells of CRC and other control 
information that we can never see.

So, for a COUNT field it takes 10 cells; for a KEY field, if present, and a 
DATA field the calculation is:

SECTORS = 9 + (KL + (6 * KN) + 6) / 34)
Where KN = (KL + 6) / 232
  KL = Key length
Change KL to DL and do the same calculation for the data area.

Question 3: Are you running under VM and using a mini-disk?  VM formats their 
R0 differently, I believe.

Hope this helps.

Chris Blaicher
Technical Architect
Mainframe Development
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

Syncsort Incorporated
2 Blue Hill Plaza #1563
Pearl River, NY 10965
http://secure-web.cisco.com/1tr2nwUQE8UCOKlBckWSDEsS73jyrD5tkchlWz_x3UWkmi-GyWYzT6sI0opa2PLaHqtKYh9N6K4_BY-gs_dJezTZSGfI5OkwUyVWDHbefFcA9s0abuSW2YqPjdYa-OjDhWsHtZzGyIIBvxnb8cNCVpSPZZI5Dce_7S1AHPHa101MtzWbq82XPg5VRCQgPO9DnhsWLYUmEmbS72IO44Qz4A973zsDYkpf9v5zQ68DMzC2vAhv5vNcrnLjiDLuUDQ9xbFkg8IHYjfSEYDVPWv4YcMjslBpLecWTHFStPj7WtlXuVMvrbWBjcCKLS-Q59KUxYCk-6sWC8Ifit6ot_f9nvk_4EDwObxspsUKwY4gsVDr2LvVdqfxyvI2zK-Cs1l2P9UJidanG_iN7i_RV8cUCkXLdGpcKpt14PEtlH0jqKv4h9pM6zvHPN4ZeI3U64sie/http%3A%2F%2Fwww.syncsort.com

Data quality leader Trillium Software is now a part of Syncsort.







ATTENTION: -

The information contained in this message (including any files transmitted with 
this message) may contain proprietary, trade secret or other confidential 
and/or legally privileged information. Any pricing information contained in 
this message or in any files transmitted with this message is always 
confidential and cannot be shared with any third parties without prior written 
approval from Syncsort. This message is intended to be read only by the 
individual or en

Re: CKD details

[Seymour J Metz]

Shirley you mean cells. A  single sector might contain multiple records, 
depending on the device and on the record layouts.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of 
Christopher Y. Blaicher <cblaic...@syncsort.com>
Sent: Tuesday, January 23, 2018 9:48 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: CKD details

With all I put in the last post, I forgot to answer WHY 20 sectors at a minimum 
for a record.  It is because at a minimum a record consists of a COUNT and a 
DATA section. Each one takes a minimum of 10 sectors, so with even a 1 byte 
record you need 20 sectors.  If you had a 1 byte key and 1 byte of data you 
would need 30 sectors, 10 for each part.

Chris Blaicher
Technical Architect
Mainframe Development
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

Syncsort Incorporated
2 Blue Hill Plaza #1563
Pearl River, NY 10965
http://secure-web.cisco.com/1tr2nwUQE8UCOKlBckWSDEsS73jyrD5tkchlWz_x3UWkmi-GyWYzT6sI0opa2PLaHqtKYh9N6K4_BY-gs_dJezTZSGfI5OkwUyVWDHbefFcA9s0abuSW2YqPjdYa-OjDhWsHtZzGyIIBvxnb8cNCVpSPZZI5Dce_7S1AHPHa101MtzWbq82XPg5VRCQgPO9DnhsWLYUmEmbS72IO44Qz4A973zsDYkpf9v5zQ68DMzC2vAhv5vNcrnLjiDLuUDQ9xbFkg8IHYjfSEYDVPWv4YcMjslBpLecWTHFStPj7WtlXuVMvrbWBjcCKLS-Q59KUxYCk-6sWC8Ifit6ot_f9nvk_4EDwObxspsUKwY4gsVDr2LvVdqfxyvI2zK-Cs1l2P9UJidanG_iN7i_RV8cUCkXLdGpcKpt14PEtlH0jqKv4h9pM6zvHPN4ZeI3U64sie/http%3A%2F%2Fwww.syncsort.com

Data quality leader Trillium Software is now a part of Syncsort.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Christopher Y. Blaicher
Sent: Tuesday, January 23, 2018 8:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CKD details

See the following for how to calculate a sector 
https://secure-web.cisco.com/1-4xCrYaoIvd6moQu1tnY3-JDxDEVfGqTdaT9eR_T8lcfOTMZd1ZqkLdRfOBpKu_w6CucO8NILbbiePWe1dwLBleCsi9wLAQ6r0YUnbLI-JDtVjMISYH_vHRxn3AbPeQuPV4-_6vb8nUsRBzxzFxrPXfNmtDGBG9rXm02WNuOcCzLhtDjdsNHbatuqXWm3O0_hOxfKDYKqmIxtOWVxr_6Up8_WVVsLsxhJT0Q7-WyYLOYFH7h7HenBd777eQrLx82uebOVKhE_KJN5_TGL8qUh-XwSm4cJQRUGPlk29wHN4yTQwkgm_2qYFJU-ZsAqx9XbwqIb-LqJRHQk-lvnxqJGh72b0sXI8qIThw5V7AJqlUxyLwZ244dQdhkMwhkomvc3L8yx4-wCHK8p4eq_EzD2PmoGptCgENg0bgNN_7qKyoz-fWPge4EsIcRu54E42WZ/https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSSB27H_6.2.0%2Ffa2mr_sectval.html

Question 2: why 20 sectors at a minimum.  It's a long answer.
We tend to think of a record as three unified parts, COUNT, KEY and DATA, but 
really they are three mini-records (for lack of a better description). Each 
part needs enough cells for the data, plus 9 cells of CRC and other control 
information that we can never see.

So, for a COUNT field it takes 10 cells; for a KEY field, if present, and a 
DATA field the calculation is:

SECTORS = 9 + (KL + (6 * KN) + 6) / 34)
Where KN = (KL + 6) / 232
  KL = Key length
Change KL to DL and do the same calculation for the data area.

Question 3: Are you running under VM and using a mini-disk?  VM formats their 
R0 differently, I believe.

Hope this helps.

Chris Blaicher
Technical Architect
Mainframe Development
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

Syncsort Incorporated
2 Blue Hill Plaza #1563
Pearl River, NY 10965
http://secure-web.cisco.com/1tr2nwUQE8UCOKlBckWSDEsS73jyrD5tkchlWz_x3UWkmi-GyWYzT6sI0opa2PLaHqtKYh9N6K4_BY-gs_dJezTZSGfI5OkwUyVWDHbefFcA9s0abuSW2YqPjdYa-OjDhWsHtZzGyIIBvxnb8cNCVpSPZZI5Dce_7S1AHPHa101MtzWbq82XPg5VRCQgPO9DnhsWLYUmEmbS72IO44Qz4A973zsDYkpf9v5zQ68DMzC2vAhv5vNcrnLjiDLuUDQ9xbFkg8IHYjfSEYDVPWv4YcMjslBpLecWTHFStPj7WtlXuVMvrbWBjcCKLS-Q59KUxYCk-6sWC8Ifit6ot_f9nvk_4EDwObxspsUKwY4gsVDr2LvVdqfxyvI2zK-Cs1l2P9UJidanG_iN7i_RV8cUCkXLdGpcKpt14PEtlH0jqKv4h9pM6zvHPN4ZeI3U64sie/http%3A%2F%2Fwww.syncsort.com

Data quality leader Trillium Software is now a part of Syncsort.







ATTENTION: -

The information contained in this message (including any files transmitted with 
this message) may contain proprietary, trade secret or other confidential 
and/or legally privileged information. Any pricing information contained in 
this message or in any files transmitted with this message is always 
confidential and cannot be shared with any third parties without prior written 
approval from Syncsort. This message is intended to be read only by the 
individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any use, disclosure, copying or distribution of this message, in any form, is 
strictly prohibited. If you have received this message in error, please 
immediately notify the sender and/or Syncsort and destroy all copies of this 
message in your possession, custody or control.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send em

Re: CKD details

[Seymour J Metz]

The 3330 was not the first disk drive with Set Sector; that honor belongs to 
the 2305, formally part of the S/360 series rather than the S/370, although I 
imagine that a lot more were sold for use on, e.g., 370/165, than for 85 or 195.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on behalf of 
Anne & Lynn Wheeler <l...@garlic.com>
Sent: Tuesday, January 23, 2018 12:59 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: CKD details

t...@harminc.net (Tony Harminc) writes:
> I assume it is the value used in the Set Sector/Read Sector CCWs. This
> came with the 3330 (real "analogue" disk) and is part of Rotational
> Position Sensing (RPS). It should have no logical relationship to the
> cell size; it's just a logical position (degrees, radians, IBM magic
> numbers because degrees and radians were NIH...?) on the track.

re:
http://secure-web.cisco.com/15Qvoob2Vhdm6iuUGhL1j9vy6Z0pnnh0_1zx9-7pssQwkGQj6WqQBa5q13LUe_gWxcObUVVxZJCm0ptns8GHOizb8OjMMFNI5KmCXFiG3ZClHBCF0V_dlinAq_J5MwUN7delJxdujwpASYBntt0YLDqjjAK4UWc20wzoXUG3bEMDArK8KPAf5iMdAs8qRiRiOEaRP_HceOU5iNyaQcY5ORiYNfG7guN5fpRpF_q_lJqx84PI8m3seBtHRZtt9_dVcosuXwbrzVTSnV0QfcXaksiYDrGr6p7PKu04X9hBRmKzFlkFq7Oa6UdmV3jVMSWvbg3OHxP-wFCRDBuM7evMy1zaVWQzvinYlq9GKm_f5GGQIvy0NtLPiJ07Y6MhForY6WWJY5NJUfVaVf9OUekQB5S0WjtBH8pUxTtdXn1VoA_g4VNASXAJZ4TxdNCWpeK9Z/http%3A%2F%2Fwww.garlic.com%2F%7Elynn%2F2018.html#77
 CKD details

it use to be all surfaces were data ... with the 3330, one surface
became dedicated to the sector position ... 20 r/w heads, 20 surfaces,
19 data r/w heads, 19 data surfaces ... the 20th surface has the
rotational position information recorded.

Supposedly the loss in total data capacity was more than offset in
better system throughput ... RPS "set sector" in channel program
reducing channel busy involved in constant search (although it couldn't
fix multi-track search for VTOCs and PDS directorys). All that goes away
in FBA ... as can be seen in justification description going from
512 FBA to 4096 FBA:
https://secure-web.cisco.com/1sFhpvpagwxYufeiUizMjVdLuq_FtR3ppZ6xQrGCXzJRGY-lLY5nyYauQIOTTQUiQBqdn3MDx3iKD_bBKEOBl0gWQgcR8Ss-RoYSadMizTEhrI6ZiPGqyGjHA4cvvnpugqItP_q68NBeCS2s-qsSRLd4B4ia2gGQCGFEbJKL5qCnUPkqu11e9Rr9VRjoR04df8vIx43mPPWM-nIZaymf8QeJ2jb7moKRLSeehPj0RID1LLAZ_Sqz8VxwXksknY2MPjBsYsmlgskUT_k6WHM-JB8Mcm3P_vp_ESaFG3G2AGawc_HaoeOyOQUgikQnA462G04KdnBDcXnfEUyxRHYEgJh7O9iKVNp3Zxs-RxuM9FCvYrcFEVl5Mpo__rI8_hmhb5y_YDzlinDJHkOizYAj9m-Mr6-gw13iSbtacDXOG1zs/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FAdvanced_Format

i've periodically mentioned pointing out that in the 70s, increase in
disk throughput wasn't keeping up with increase in overall system
performance. Some disk division executive in the early 80s took
exception with my statement that relative system disk throughput had
declined by an order of magnitude since the 60s (disk throughput
increase 3-5 times, processor throughput increase 40-50 times)
and assigned the division performance group to refute my claim.  After a
couple weeks the group comes back and essentially say that I had
slightly understated the problem ... not bothering to include RPS-miss
in the calculations (attempting to channel reconnect at the sector
number ... but channel busy with some other device ... and so have to
loose full revolution). They then turn the analysis into SHARE
presentation on how to organize disk farms for better throughput.

--
virtualization experience starting Jan1968, online at home since Mar1970

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: CKD details

[Anne & Lynn Wheeler]

t...@harminc.net (Tony Harminc) writes:
> I assume it is the value used in the Set Sector/Read Sector CCWs. This
> came with the 3330 (real "analogue" disk) and is part of Rotational
> Position Sensing (RPS). It should have no logical relationship to the
> cell size; it's just a logical position (degrees, radians, IBM magic
> numbers because degrees and radians were NIH...?) on the track.

re:
http://www.garlic.com/~lynn/2018.html#77 CKD details

it use to be all surfaces were data ... with the 3330, one surface
became dedicated to the sector position ... 20 r/w heads, 20 surfaces,
19 data r/w heads, 19 data surfaces ... the 20th surface has the
rotational position information recorded.

Supposedly the loss in total data capacity was more than offset in
better system throughput ... RPS "set sector" in channel program
reducing channel busy involved in constant search (although it couldn't
fix multi-track search for VTOCs and PDS directorys). All that goes away
in FBA ... as can be seen in justification description going from
512 FBA to 4096 FBA:
https://en.wikipedia.org/wiki/Advanced_Format

i've periodically mentioned pointing out that in the 70s, increase in
disk throughput wasn't keeping up with increase in overall system
performance. Some disk division executive in the early 80s took
exception with my statement that relative system disk throughput had
declined by an order of magnitude since the 60s (disk throughput
increase 3-5 times, processor throughput increase 40-50 times)
and assigned the division performance group to refute my claim.  After a
couple weeks the group comes back and essentially say that I had
slightly understated the problem ... not bothering to include RPS-miss
in the calculations (attempting to channel reconnect at the sector
number ... but channel busy with some other device ... and so have to
loose full revolution). They then turn the analysis into SHARE
presentation on how to organize disk farms for better throughput.

-- 
virtualization experience starting Jan1968, online at home since Mar1970

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: CKD details

[Tony Harminc]

On 23 January 2018 at 10:22, R.S.  wrote:
> Fortunately your explanation was clear enough to find out each "mini-record"
> has at least 10 cells (9 control plus a t least one for data).
>
> However you used word "SECTORS". I used  "34-byte DATA CELL", following the
> 3390 documentation (other names can be found elsewhere).
> It seems the documentation use SECTOR for something else. The SA22-1025-00
> says the 3390 device has 224 sectors per track and 222 for 3380. So, the
> SECTOR  cannot be the same as DATA CELL.
>
> I have no idea what is the SECTOR.

I assume it is the value used in the Set Sector/Read Sector CCWs. This
came with the 3330 (real "analogue" disk) and is part of Rotational
Position Sensing (RPS). It should have no logical relationship to the
cell size; it's just a logical position (degrees, radians, IBM magic
numbers because degrees and radians were NIH...?) on the track.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: CKD details

[R.S.]

W dniu 2018-01-23 o 17:50, Anne & Lynn Wheeler pisze:

cblaic...@syncsort.com (Christopher Y. Blaicher) writes:

Your right, things are a little confusing.
SECTORS - Think of it as 224 pieces of pie.  It is, I believe, physical.
CELL - Also physical, but I think of them as little chunks of data,
   which may be your data or control data for the hardware.
TRACK BALANCE - How much room is left on the track if you were to
   write a single block.  Look up TRKBAL macro.

That extra calculation is for device control information, part of
which I know is CRC, or at least that is what I was told.  All that
stuff other than the COUNT-KEY-DATA areas are for the hardware and we
mortals can't see it, but it is there.

and all that is now archaic fiction since no real CKD have been made for
decades, being simulated on industry standard fixed-block

this is the "real" format ... giving both 512byte FBA and the newer
4096byte FBA
https://en.wikipedia.org/wiki/Advanced_Format

part of the change justification is 4096byte is more "efficient"
... 15byte "gap, sync, address mark" for each phsical record and "512"
has 50byte ECC and 4096 has 100byte ECC for each record (eight 512 has
400byte ECC total) ... 512byte efficiency 88.7% and 4096byte efficiency
97.3%


That's true, it is emulated now. However from MVS point of view there 
are still HA, R0, C, K, D fields of records, etc. Even gaps are still 
there and it seem also CRC code still occupy virtual data cells.




Regards
--
Radoslaw Skorupka
Lodz, Poland




==


   --
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.
   


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: CKD details

[Anne & Lynn Wheeler]

cblaic...@syncsort.com (Christopher Y. Blaicher) writes:
> Your right, things are a little confusing.
> SECTORS - Think of it as 224 pieces of pie.  It is, I believe, physical.
> CELL - Also physical, but I think of them as little chunks of data,
>   which may be your data or control data for the hardware.
> TRACK BALANCE - How much room is left on the track if you were to
>   write a single block.  Look up TRKBAL macro.
>
> That extra calculation is for device control information, part of
> which I know is CRC, or at least that is what I was told.  All that
> stuff other than the COUNT-KEY-DATA areas are for the hardware and we
> mortals can't see it, but it is there.

and all that is now archaic fiction since no real CKD have been made for
decades, being simulated on industry standard fixed-block

this is the "real" format ... giving both 512byte FBA and the newer
4096byte FBA
https://en.wikipedia.org/wiki/Advanced_Format

part of the change justification is 4096byte is more "efficient"
... 15byte "gap, sync, address mark" for each phsical record and "512"
has 50byte ECC and 4096 has 100byte ECC for each record (eight 512 has
400byte ECC total) ... 512byte efficiency 88.7% and 4096byte efficiency
97.3%

-- 
virtualization experience starting Jan1968, online at home since Mar1970

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: CKD details

[Christopher Y. Blaicher]

Your right, things are a little confusing.
SECTORS - Think of it as 224 pieces of pie.  It is, I believe, physical.
CELL - Also physical, but I think of them as little chunks of data, which may 
be your data or control data for the hardware.
TRACK BALANCE - How much room is left on the track if you were to write a 
single block.  Look up TRKBAL macro.

That extra calculation is for device control information, part of which I know 
is CRC, or at least that is what I was told.  All that stuff other than the 
COUNT-KEY-DATA areas are for the hardware and we mortals can't see it, but it 
is there.

Chris Blaicher
Technical Architect
Mainframe Development
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

Syncsort Incorporated
2 Blue Hill Plaza #1563
Pearl River, NY 10965
www.syncsort.com

Data quality leader Trillium Software is now a part of Syncsort.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Tuesday, January 23, 2018 10:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CKD details

Fortunately your explanation was clear enough to find out each "mini-record" 
has at least 10 cells (9 control plus a t least one for data).

However you used word "SECTORS". I used  "34-byte DATA CELL", following the 
3390 documentation (other names can be found elsewhere).
It seems the documentation use SECTOR for something else. The
SA22-1025-00 says the 3390 device has 224 sectors per track and 222 for 3380. 
So, the SECTOR  cannot be the same as DATA CELL.

I have no idea what is the SECTOR.


BTW: I also do not understand the formula. For me it should be just
Numberofcells=9+RoundUP(KL/34)
of course you provided right formula as it is documented, but I simply don't 
understand the purpose of KN and 6 and 232. i'm pretty sure it is not just a 
magic, but what is the rationale behind?

Last but not least: THANK YOU VERY MUCH for the explanations you gave me, I 
appreciate it.

Regards
--
Radoslaw Skorupka
Lodz, Poland







W dniu 2018-01-23 o 15:48, Christopher Y. Blaicher pisze:
> With all I put in the last post, I forgot to answer WHY 20 sectors at a 
> minimum for a record.  It is because at a minimum a record consists of a 
> COUNT and a DATA section. Each one takes a minimum of 10 sectors, so with 
> even a 1 byte record you need 20 sectors.  If you had a 1 byte key and 1 byte 
> of data you would need 30 sectors, 10 for each part.
>
> Chris Blaicher
> Technical Architect
> Mainframe Development
> P: 201-930-8234  |  M: 512-627-3803
> E: cblaic...@syncsort.com
>
> Syncsort Incorporated
> 2 Blue Hill Plaza #1563
> Pearl River, NY 10965
> www.syncsort.com
>
> Data quality leader Trillium Software is now a part of Syncsort.
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Christopher Y. Blaicher
> Sent: Tuesday, January 23, 2018 8:30 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: CKD details
>
> See the following for how to calculate a sector 
> https://www.ibm.com/support/knowledgecenter/en/SSB27H_6.2.0/fa2mr_sectval.html
>
> Question 2: why 20 sectors at a minimum.  It's a long answer.
> We tend to think of a record as three unified parts, COUNT, KEY and DATA, but 
> really they are three mini-records (for lack of a better description). Each 
> part needs enough cells for the data, plus 9 cells of CRC and other control 
> information that we can never see.
>
> So, for a COUNT field it takes 10 cells; for a KEY field, if present, and a 
> DATA field the calculation is:
>
> SECTORS = 9 + (KL + (6 * KN) + 6) / 34)
> Where KN = (KL + 6) / 232
>KL = Key length
> Change KL to DL and do the same calculation for the data area.
>
> Question 3: Are you running under VM and using a mini-disk?  VM formats their 
> R0 differently, I believe.
>
> Hope this helps.
>
> Chris Blaicher
> Technical Architect
> Mainframe Development
> P: 201-930-8234  |  M: 512-627-3803
> E: cblaic...@syncsort.com
>
> Syncsort Incorporated
> 2 Blue Hill Plaza #1563
> Pearl River, NY 10965
> www.syncsort.com
>

==


--
 Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiad

Re: CKD details

[R.S.]

Fortunately your explanation was clear enough to find out each 
"mini-record" has at least 10 cells (9 control plus a t least one for 
data).


However you used word "SECTORS". I used  "34-byte DATA CELL", following 
the 3390 documentation (other names can be found elsewhere).
It seems the documentation use SECTOR for something else. The 
SA22-1025-00 says the 3390 device has 224 sectors per track and 222 for 
3380. So, the SECTOR  cannot be the same as DATA CELL.


I have no idea what is the SECTOR.


BTW: I also do not understand the formula. For me it should be just
Numberofcells=9+RoundUP(KL/34)
of course you provided right formula as it is documented, but I simply 
don't understand the purpose of KN and 6 and 232. i'm pretty sure it is 
not just a magic, but what is the rationale behind?


Last but not least: THANK YOU VERY MUCH for the explanations you gave 
me, I appreciate it.


Regards
--
Radoslaw Skorupka
Lodz, Poland







W dniu 2018-01-23 o 15:48, Christopher Y. Blaicher pisze:

With all I put in the last post, I forgot to answer WHY 20 sectors at a minimum 
for a record.  It is because at a minimum a record consists of a COUNT and a 
DATA section. Each one takes a minimum of 10 sectors, so with even a 1 byte 
record you need 20 sectors.  If you had a 1 byte key and 1 byte of data you 
would need 30 sectors, 10 for each part.

Chris Blaicher
Technical Architect
Mainframe Development
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

Syncsort Incorporated
2 Blue Hill Plaza #1563
Pearl River, NY 10965
www.syncsort.com

Data quality leader Trillium Software is now a part of Syncsort.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Christopher Y. Blaicher
Sent: Tuesday, January 23, 2018 8:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CKD details

See the following for how to calculate a sector 
https://www.ibm.com/support/knowledgecenter/en/SSB27H_6.2.0/fa2mr_sectval.html

Question 2: why 20 sectors at a minimum.  It's a long answer.
We tend to think of a record as three unified parts, COUNT, KEY and DATA, but 
really they are three mini-records (for lack of a better description). Each 
part needs enough cells for the data, plus 9 cells of CRC and other control 
information that we can never see.

So, for a COUNT field it takes 10 cells; for a KEY field, if present, and a 
DATA field the calculation is:

SECTORS = 9 + (KL + (6 * KN) + 6) / 34)
Where KN = (KL + 6) / 232
   KL = Key length
Change KL to DL and do the same calculation for the data area.

Question 3: Are you running under VM and using a mini-disk?  VM formats their 
R0 differently, I believe.

Hope this helps.

Chris Blaicher
Technical Architect
Mainframe Development
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

Syncsort Incorporated
2 Blue Hill Plaza #1563
Pearl River, NY 10965
www.syncsort.com



==


   --
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.
   


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: CKD details

[Christopher Y. Blaicher]

With all I put in the last post, I forgot to answer WHY 20 sectors at a minimum 
for a record.  It is because at a minimum a record consists of a COUNT and a 
DATA section. Each one takes a minimum of 10 sectors, so with even a 1 byte 
record you need 20 sectors.  If you had a 1 byte key and 1 byte of data you 
would need 30 sectors, 10 for each part.

Chris Blaicher
Technical Architect
Mainframe Development
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

Syncsort Incorporated
2 Blue Hill Plaza #1563
Pearl River, NY 10965
www.syncsort.com

Data quality leader Trillium Software is now a part of Syncsort.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Christopher Y. Blaicher
Sent: Tuesday, January 23, 2018 8:30 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CKD details

See the following for how to calculate a sector 
https://www.ibm.com/support/knowledgecenter/en/SSB27H_6.2.0/fa2mr_sectval.html

Question 2: why 20 sectors at a minimum.  It's a long answer.
We tend to think of a record as three unified parts, COUNT, KEY and DATA, but 
really they are three mini-records (for lack of a better description). Each 
part needs enough cells for the data, plus 9 cells of CRC and other control 
information that we can never see.

So, for a COUNT field it takes 10 cells; for a KEY field, if present, and a 
DATA field the calculation is:

SECTORS = 9 + (KL + (6 * KN) + 6) / 34)
Where KN = (KL + 6) / 232
  KL = Key length
Change KL to DL and do the same calculation for the data area.

Question 3: Are you running under VM and using a mini-disk?  VM formats their 
R0 differently, I believe.

Hope this helps.

Chris Blaicher
Technical Architect
Mainframe Development
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

Syncsort Incorporated
2 Blue Hill Plaza #1563
Pearl River, NY 10965
www.syncsort.com

Data quality leader Trillium Software is now a part of Syncsort.







ATTENTION: -

The information contained in this message (including any files transmitted with 
this message) may contain proprietary, trade secret or other confidential 
and/or legally privileged information. Any pricing information contained in 
this message or in any files transmitted with this message is always 
confidential and cannot be shared with any third parties without prior written 
approval from Syncsort. This message is intended to be read only by the 
individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any use, disclosure, copying or distribution of this message, in any form, is 
strictly prohibited. If you have received this message in error, please 
immediately notify the sender and/or Syncsort and destroy all copies of this 
message in your possession, custody or control.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: CKD details

[Christopher Y. Blaicher]

See the following for how to calculate a sector
https://www.ibm.com/support/knowledgecenter/en/SSB27H_6.2.0/fa2mr_sectval.html

Question 2: why 20 sectors at a minimum.  It's a long answer.
We tend to think of a record as three unified parts, COUNT, KEY and DATA, but 
really they are three mini-records (for lack of a better description). Each 
part needs enough cells for the data, plus 9 cells of CRC and other control 
information that we can never see.

So, for a COUNT field it takes 10 cells; for a KEY field, if present, and a 
DATA field the calculation is:

SECTORS = 9 + (KL + (6 * KN) + 6) / 34)
Where KN = (KL + 6) / 232
  KL = Key length
Change KL to DL and do the same calculation for the data area.

Question 3: Are you running under VM and using a mini-disk?  VM formats their 
R0 differently, I believe.

Hope this helps.

Chris Blaicher
Technical Architect
Mainframe Development
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

Syncsort Incorporated
2 Blue Hill Plaza #1563
Pearl River, NY 10965
www.syncsort.com

Data quality leader Trillium Software is now a part of Syncsort.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Tuesday, January 23, 2018 7:15 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CKD details

Another set of questions:

1. What is sector???
3390 specification says it has 224 sectors per track (3380 had 222 sectors per 
track).
I cannot find any explanation for that. Size of data cell is 34 bytes

2. In the 3390 reference I read the record can occupy 20 to 1729 data cells 
(excluding standard R0).
Why 20? For 3390 device 20 cells is 680 bytes. Is it minimum for any record, 
including i.e. very small Count plus 4 bytes of Data?


3. HA (Home Address)
I used File Manager to print it out and indeed it is 5-byte long, but it seems 
to be NOT in format of CCHHR.
IMHO it is xCCHH, where x is one byte with x'00' (in my case), but it is first 
byte.

Regards
--
Radoslaw Skorupka
Lodz, Poland







W dniu 2018-01-22 o 15:51, R.S. pisze:
> I'm looking for some reference describing track format of CKD disk.
>
> What I know is
> Index Point - Home Address - R0 - other Rn
>
> Some questions:
> 1. IP is just a "start of track", contains no data - Y/N ?
> 2. What is a format of HA?
> 3. What is a format of R0?
> 4. What is a format of Count field? How long is it? Is it 10 bytes?
> 5. What is maximum length of K and D?
>
> Any documentation?
>





==


--
 Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

 This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

 mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN





ATTENTION: -

The information contained in this message (including any files transmitted with 
this message) may contain proprietary, trade secret or other confidential 
and/or legally privileged information. Any pricing information contained in 
this message or in any files transmitted with this message is always 
confidential and cannot be shared with an

Re: CKD details

[R.S.]

Another set of questions:

1. What is sector???
3390 specification says it has 224 sectors per track (3380 had 222 
sectors per track).

I cannot find any explanation for that. Size of data cell is 34 bytes

2. In the 3390 reference I read the record can occupy 20 to 1729 data 
cells (excluding standard R0).
Why 20? For 3390 device 20 cells is 680 bytes. Is it minimum for any 
record, including i.e. very small Count plus 4 bytes of Data?



3. HA (Home Address)
I used File Manager to print it out and indeed it is 5-byte long, but it 
seems to be NOT in format of CCHHR.
IMHO it is xCCHH, where x is one byte with x'00' (in my case), but it is 
first byte.


Regards
--
Radoslaw Skorupka
Lodz, Poland







W dniu 2018-01-22 o 15:51, R.S. pisze:

I'm looking for some reference describing track format of CKD disk.

What I know is
Index Point - Home Address - R0 - other Rn

Some questions:
1. IP is just a "start of track", contains no data - Y/N ?
2. What is a format of HA?
3. What is a format of R0?
4. What is a format of Count field? How long is it? Is it 10 bytes?
5. What is maximum length of K and D?

Any documentation?







==


   --
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.
   


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: CKD details

[Christopher Y. Blaicher]

Correct - That was a description of EAV CKD field.

Chris Blaicher
Technical Architect
Mainframe Development
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

Syncsort Incorporated
2 Blue Hill Plaza #1563
Pearl River, NY 10965
www.syncsort.com

Data quality leader Trillium Software is now a part of Syncsort.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Monday, January 22, 2018 12:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CKD details

W dniu 2018-01-22 o 16:49, Christopher Y. Blaicher pisze:
[...]
> Extended format data sets use a modified form and here each letter is a 
> nibble:
> cccHRRKK   Still 8 bytes
[...]

I think you mean EAV, not extended format - is it right?

Regards
--
Radoslaw Skorupka
Lodz, Poland




==


--
 Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

 This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

 mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN





ATTENTION: -

The information contained in this message (including any files transmitted with 
this message) may contain proprietary, trade secret or other confidential 
and/or legally privileged information. Any pricing information contained in 
this message or in any files transmitted with this message is always 
confidential and cannot be shared with any third parties without prior written 
approval from Syncsort. This message is intended to be read only by the 
individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any use, disclosure, copying or distribution of this message, in any form, is 
strictly prohibited. If you have received this message in error, please 
immediately notify the sender and/or Syncsort and destroy all copies of this 
message in your possession, custody or control.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: CKD details

[Tony Harminc]

On 22 January 2018 at 09:51, R.S.  wrote:
> I'm looking for some reference describing track format of CKD disk.
>
> What I know is
> Index Point - Home Address - R0 - other Rn
>
> Some questions:
> 1. IP is just a "start of track", contains no data - Y/N ?
> 2. What is a format of HA?
> 3. What is a format of R0?
> 4. What is a format of Count field? How long is it? Is it 10 bytes?
> 5. What is maximum length of K and D?
>
> Any documentation?

A good place to start is
http://bitsavers.org/pdf/ibm/38xx/3880/GA26-1661-9_3880_Storage_Control_Description_Sep87.pdf

Of course this is 30+ years old, but almost nothing has changed.
Extended format (which you seem to be interested in) is not covered.
But this book is good because if covers not only the data layout, but
the format and rules for the CCWs to use the disk devices, the various
status presentations

Three stages of DASD programming, all described pretty well in the
book, though not laid out historically:

Early (S/360 2311, 2314, etc.). Selector channel (one active channel
program at a time). Typical Read channel program has standalone SEEK,
then when that finishes, SEEK again, Set File Mask, SEARCH, READ. A
few strange DASDs like 2321 datacell, 230x drum/fixed head disks, all
with quirks.

RPS (S/370 3330, 3350) Block Multiplexor channels. Control unit can
disconnect from the channel during seek and while the right spot on
disk comes around, then reconnect. During this disconnection some
other data transfer can proceed. You manage the rotational position
with Get/Set Sector CCWs, and your channel program is suspended until
CU reconnection.

ECKD (3380, 3375, 3390) 3 MB/s channels "data streaming". New CCWs
like Define Extent.

Key point: 99% upward compatible. Your channel program written in 1968
for 2311 can run in 2018 on a 3390. Perhaps not optimal, but... Can
any other architecture say that?

I don't know how Extended format interacts with drives and CCWs. Maybe
not at all...

Do I hear Lynn Wheeler's keyboard clicking yet?

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: CKD details

[R.S.]

W dniu 2018-01-22 o 16:49, Christopher Y. Blaicher pisze:
[...]

Extended format data sets use a modified form and here each letter is a nibble:
cccHRRKK   Still 8 bytes

[...]

I think you mean EAV, not extended format - is it right?

Regards
--
Radoslaw Skorupka
Lodz, Poland




==


   --
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.
   


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: CKD details

[Christopher Y. Blaicher]

In the following each letter is a byte
CC - Cylinder number
HH - Head number
R - Record number
K - Key length
DD - Data length

Extended format data sets use a modified form and here each letter is a nibble:
cccHRRKK   Still 8 bytes
 -low 16 bits of cylinder number
ccc - high 12 bits of cylinder number
H - 4 bit head number
RR - 8 bit record number
KK - 8 bit key length
 - 16 bit data length

Chris Blaicher
Technical Architect
Mainframe Development
P: 201-930-8234  |  M: 512-627-3803    
E: cblaic...@syncsort.com

Syncsort Incorporated 
2 Blue Hill Plaza #1563
Pearl River, NY 10965
www.syncsort.com

Data quality leader Trillium Software is now a part of Syncsort.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Monday, January 22, 2018 10:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CKD details

Thank you for prompt response, I appreciate it.
Further question: what is CCHHRKDD?
CCHHR is clear (Cylinder, Head, Record), but KDD? Is it Key Data x2?

-- 
Radoslaw Skorupka
Lodz, Poland







W dniu 2018-01-22 o 16:13, Christopher Y. Blaicher pisze:
> See manual SA22-1025-00 and comments below
>
> Chris Blaicher
> Technical Architect
> Mainframe Development
> P: 201-930-8234  |  M: 512-627-3803
> E: cblaic...@syncsort.com
>
> Syncsort Incorporated
> 2 Blue Hill Plaza #1563
> Pearl River, NY 10965
> www.syncsort.com
>
> Data quality leader Trillium Software is now a part of Syncsort.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of R.S.
> Sent: Monday, January 22, 2018 9:52 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: CKD details
>
> I'm looking for some reference describing track format of CKD disk.
>
> What I know is
> Index Point - Home Address - R0 - other Rn
>
> Some questions:
> 1. IP is just a "start of track", contains no data - Y/N ?[Blaicher, 
> Christopher Y.] YES, there is also an END-OF-TRACK
> 2. What is a format of HA?[Blaicher, Christopher Y.] Typically just CCHHR
> 3. What is a format of R0?[Blaicher, Christopher Y.]  Count field of CCHH0, 
> key length 0, data length 8, data is all zeros
> 4. What is a format of Count field? How long is it? Is it 10 bytes?[Blaicher, 
> Christopher Y.]  CCHHRKDD
> 5. What is maximum length of K and D?[Blaicher, Christopher Y.]  Max key is 
> 255, max data is track capacity
>
> Any documentation?
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
> ==
>
>
>  --
>   Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
> przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być 
> jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś 
> adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej 
> przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, 
> rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie 
> zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, 
> prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale 
> usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub 
> zapisane na dysku.
>
>   This e-mail may contain legally privileged information of the Bank and is 
> intended solely for business use of the addressee. This e-mail may only be 
> received by the addressee and may not be disclosed to any third parties. If 
> you are not the intended addressee of this e-mail or the employee authorized 
> to forward it to the addressee, be advised that any dissemination, copying, 
> distribution or any other similar activity is legally prohibited and may be 
> punishable. If you received this e-mail by mistake please advise the sender 
> immediately by using the reply facility in your e-mail software and delete 
> permanently this e-mail including any copies of it either printed or saved to 
> hard drive.
>
>   mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
> www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
> Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
> KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. 
> kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> 
>
>
>
> ATTENTION: -
>
> The information contained i

Re: CKD details

[R.S.]

Thank you for prompt response, I appreciate it.
Further question: what is CCHHRKDD?
CCHHR is clear (Cylinder, Head, Record), but KDD? Is it Key Data x2?

--
Radoslaw Skorupka
Lodz, Poland







W dniu 2018-01-22 o 16:13, Christopher Y. Blaicher pisze:

See manual SA22-1025-00 and comments below

Chris Blaicher
Technical Architect
Mainframe Development
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

Syncsort Incorporated
2 Blue Hill Plaza #1563
Pearl River, NY 10965
www.syncsort.com

Data quality leader Trillium Software is now a part of Syncsort.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Monday, January 22, 2018 9:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: CKD details

I'm looking for some reference describing track format of CKD disk.

What I know is
Index Point - Home Address - R0 - other Rn

Some questions:
1. IP is just a "start of track", contains no data - Y/N ?[Blaicher, 
Christopher Y.] YES, there is also an END-OF-TRACK
2. What is a format of HA?[Blaicher, Christopher Y.] Typically just CCHHR
3. What is a format of R0?[Blaicher, Christopher Y.]  Count field of CCHH0, key 
length 0, data length 8, data is all zeros
4. What is a format of Count field? How long is it? Is it 10 bytes?[Blaicher, 
Christopher Y.]  CCHHRKDD
5. What is maximum length of K and D?[Blaicher, Christopher Y.]  Max key is 
255, max data is track capacity

Any documentation?

--
Radoslaw Skorupka
Lodz, Poland




==


 --
  Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

  This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

  mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN





ATTENTION: -

The information contained in this message (including any files transmitted with 
this message) may contain proprietary, trade secret or other confidential 
and/or legally privileged information. Any pricing information contained in 
this message or in any files transmitted with this message is always 
confidential and cannot be shared with any third parties without prior written 
approval from Syncsort. This message is intended to be read only by the 
individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any use, disclosure, copying or distribution of this message, in any form, is 
strictly prohibited. If you have received this message in error, please 
immediately notify the sender and/or Syncsort and destroy all copies of this 
message in your possession, custody or control.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
.




==


   --
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób 

Re: CKD details

[Christopher Y. Blaicher]

See manual SA22-1025-00 and comments below

Chris Blaicher
Technical Architect
Mainframe Development
P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

Syncsort Incorporated
2 Blue Hill Plaza #1563
Pearl River, NY 10965
www.syncsort.com

Data quality leader Trillium Software is now a part of Syncsort.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of R.S.
Sent: Monday, January 22, 2018 9:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: CKD details

I'm looking for some reference describing track format of CKD disk.

What I know is
Index Point - Home Address - R0 - other Rn

Some questions:
1. IP is just a "start of track", contains no data - Y/N ?[Blaicher, 
Christopher Y.] YES, there is also an END-OF-TRACK
2. What is a format of HA?[Blaicher, Christopher Y.] Typically just CCHHR
3. What is a format of R0?[Blaicher, Christopher Y.]  Count field of CCHH0, key 
length 0, data length 8, data is all zeros
4. What is a format of Count field? How long is it? Is it 10 bytes?[Blaicher, 
Christopher Y.]  CCHHRKDD
5. What is maximum length of K and D?[Blaicher, Christopher Y.]  Max key is 
255, max data is track capacity

Any documentation?

--
Radoslaw Skorupka
Lodz, Poland




==


--
 Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

 This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

 mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII 
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców 
KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN





ATTENTION: -

The information contained in this message (including any files transmitted with 
this message) may contain proprietary, trade secret or other confidential 
and/or legally privileged information. Any pricing information contained in 
this message or in any files transmitted with this message is always 
confidential and cannot be shared with any third parties without prior written 
approval from Syncsort. This message is intended to be read only by the 
individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any use, disclosure, copying or distribution of this message, in any form, is 
strictly prohibited. If you have received this message in error, please 
immediately notify the sender and/or Syncsort and destroy all copies of this 
message in your possession, custody or control.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN