Re: 256 bytes again

[Rick Fochtman]

-
Does DSN=FORMAT4.DSCB not work in your JCL? I only use it for IDCAMS so 
maybe it doesn't work in the general case.

-
No, it doesn't work in the general case. Some utilities and service aids 
actually look at the DSNAME in the JFCB and will make the appropriate 
adjustments to open the actual VTOC dataset. AMASPZAP comes to mind for 
me; that's where I most often use it.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 256 bytes again

[Schwarz, Barry A]

Does DSN=FORMAT4.DSCB not work in your JCL?  I only use it for IDCAMS so
maybe it doesn't work in the general case.

-Original Message-
From: William H. Blair 
Sent: Tuesday, February 26, 2008 7:20 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: 256 bytes again

Shmuel (Seymour J.) Metz wrote:

> What do you specify to read a VTOC?

You simply specify the DSNAME of the VTOC. Since you can't do that in
JCL easily, the best way is to specify any DSNAME (or no DSNAME) on the
JCL DD statement:

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 256 bytes again

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 02/26/2008
   at 09:20 PM, "William H. Blair" <[EMAIL PROTECTED]> said:

>You simply specify the DSNAME of the VTOC.

That's the right answer to the wrong question. What do you specify for the
DCB parameters. And the question was rhetorical ;-)
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 256 bytes again

[William H. Blair]

Shmuel (Seymour J.) Metz wrote:

> What do you specify to read a VTOC?

You simply specify the DSNAME of the VTOC. Since you can't do that
in JCL easily, the best way is to specify any DSNAME (or no DSNAME)
on the JCL DD statement:

//SYSRES DD DISP=SHR,UNIT=3390,VOL=SER=SYSRES

and then stuff the VTOC's DSNAME (that is, the KEY of its DSCB, in
this case, the Format 4 [F4] DSCB in the VTOC) into the JFCB which
you must first read into storage:

 RDJFCB (VTOC),MF=(E,...)
 MVC   JFCBDSNM(44),=44X'04' 
 OPEN  (VTOC,INPUT),TYPE=J,MF=(E,...)
 ...
VTOC DCB   ...,DDNAME=SYSRES,... 

The KEY of the F4 DSCB is 44 X'04 characters.  (The KEY of a F1
DSCB [for an ordinary data set] is the DSNAME.)

I have left out the details of the mechanics of the interaction
between RDJFCB, DCB, and OPEN TYPE=J. There are many examples of
how to use them properly online and, of course, in the IBM SRLs. 

--
WB

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: SPAM: Re: 256 bytes again

[Rick Fochtman]

-

he guy who precipitated all this extra  discussion was 
trying to get the thread oriented to remembering that the key  length
must be  considered when determining how many blocks will fit on the 
track.
   



That's part of it. There's also code that reads the directory and examines
the key; the buffer length for such code must be 264 rather than 256. 
 


-
BLDL/FIND use a channel programm that still requires a key as well. The 
basic search (IIRC) is:


  CCW   Search-Key-High-Or-Equal
  CCW   Transfer-in-Channel *-8
  CCW   Read-Data

Other CCWs in the program are device-dependant, and AFAIK 3390 SLEDs are 
still supported.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 256 bytes again

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 02/25/2008
   at 08:51 AM, "R.S." <[EMAIL PROTECTED]> said:

>No. First - when you calculate number of blocks, you have to take into 
>consideration many physical aspects of data storing, like Count field, 
>gaps, data cell size, data cell existence, track size, R0, etc

Only if you're doing it yourself instead of using the IBM provided
services, which take those into account for you.

>I don't know TRKALC,

Indeed.

>but I can imagine, that program assuming there is no Key

I can imagine the sun turning into a banana.

>However it doesn't change the fact

Repeating an assertion doesn't make it a fact.

>Contrary to VTOC the Key in directory contains redundant, "index" 
>information only

BSAM doesn't distinguish between redundant and non-redundant keys. If the
key doesn't count for a directory then it doesn't count for a VTOC.

>Saying directory block is 254 bytes is plain incorrect, because it's 
>not. The byte, you mention is part of the content.

As is the key.

>According to documentation, you can read directory sequentially by 
>providing LRECL=256. Again - 256.

What do you specify to read a VTOC?

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 256 bytes again

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 02/24/2008
   at 09:37 PM, "R.S." <[EMAIL PROTECTED]> said:

>The documentation is correct.

No.

>One could add Count and Key to the size, but *he shouldn't*.

It's not what you don't know that hurts you, it's not what you know that
isn't so. Failure to take the key into account when it's relevant will
lead to other failures.

The code IBM provides already takes the count area into account, so you
only need to include it when you're doing thing like Read CKD. The key
length, however, affects lots of other things.

>However common definition is that we provide size of the block by 
>providing length of Data in CKD.

No, it's just that the common context is keylen=0.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 256 bytes again

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 02/25/2008
   at 07:32 AM, "(IBM Mainframe Discussion List)" <[EMAIL PROTECTED]>
said:

>he guy who precipitated all this extra  discussion was 
>trying to get the thread oriented to remembering that the key  length
>must be  considered when determining how many blocks will fit on the 
>track.

That's part of it. There's also code that reads the directory and examines
the key; the buffer length for such code must be 264 rather than 256. 
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 256 bytes again

[Scott Rowe]

As do I

>>> Jim McAlpine <[EMAIL PROTECTED]> 2/25/2008 4:08 AM >>>
Sorry, the pedantry remark wasn't aimed at you.  BTW I agree with you that
256 bytes is the correct value.

Jim McAlpine


Note that my email domain has changed from jo-annstores.com to joann.com.  
Please update your address book and other records to reflect this change.

CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains 
confidential and privileged information intended only for the addressee.  If 
you are not the intended recipient, please be advised that you have received 
this material in error and that any forwarding, copying, printing, 
distribution, use or disclosure of the material is strictly prohibited.  If you 
have received this material in error, please (i) do not read it, (ii) reply to 
the sender that you received the message in error, and (iii) erase or destroy 
the material. Emails are not secure and can be intercepted, amended, lost or 
destroyed, or contain viruses. You are deemed to have accepted these risks if 
you communicate with us by email. Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 256 bytes again

[(IBM Mainframe Discussion List)]

 
 
In a message dated 2/25/2008 1:52:25 A.M. Central Standard Time,  
[EMAIL PROTECTED] writes:
>No. First - when you calculate number of blocks, you have to take into  
consideration many physical aspects of data storing, like Count field,  
gaps, data cell size, data cell existence, track size, R0, etc. I don't  
know TRKALC
 
The hardware engineers who invent the new type of disk track, decide what  
its length will be, determine the size of the various gaps, produce the control 
 
unit microcode to implement and enforce these decisions, etc., provide a set 
of  constants that can be plugged into generic formulas that are used by 
TRKCALC  to calculate the effective size on the track of a new "record" (also 
called  "block" by some) on that track and/or how many exactly like that will 
fit 
on the  track.  These constants are made available to the operating system by  
returning them in response to the Read Device Characteristics CCW command 
code,  and the format of these constants is documented in the various control 
unit 
 reference books.  The operating system reads the device characteristics  
data when a DASD device is varied online.  Also some of these constants are  
stored in the Format 4 DSCB (keyed record overhead, e.g.).  The Format 4  DSCB 
also contains the number of DSCBs per track and the number of PDS directory  
blocks per track.  These two values were computed based on the constants  found 
in 
the device characteristics data.
 
Typically, programmers do not need to concern themselves with these  
constants nor with the formulas for computing the effective size on the track 
of  a 
block with key length X and data length Y.  The formula has grown  increasingly 
convoluted (my opinion) over the years as new device types have  been devised. 
 All a programmer usually needs to do is to set up the  parameter list 
correctly and invoke the TRKCALC service.
 
One way to see how many directory blocks fit on a track is to dump the  
Format 4 DSCB with AMASPZAP.  Another way is to allocate a PDS with a large  
number 
of directory blocks and do an AMASPZAP dump of the first few tracks  of the 
data set.  You can then vary downwards the number of directory  blocks to be 
allocated and see if there is also room on the track for an EOF  record after 
the end of the directory or not, if you are interested in  that.
 
The bottom line is that a PDS directory block has had a constant key length  
of 8 and data area of 256 since day one of Version 1 of OS/360 back in the  
mid-1960s.  The only variable has been how many fit on a track of each  
different DASD device type.  The guy who precipitated all this extra  
discussion was 
trying to get the thread oriented to remembering that the key  length must be 
considered when determining how many blocks will fit on the  track.  At least I 
think that was his intent.  I also don't think that  the thread had gone 
astray in that area, so I believe that this whole extra  detailed discussion 
has 
been unnecessary and a molehill has been turned into a  Mount Everest.
 
The fact that two different IBM books describe the same entity or concept  
with slightly different terms does not necessarily mean that either of the 
books 
 is incorrect.  It means that they were written by different people, or  
perhaps by the same person at different times.  Hardware-oriented people  
typically speak of a CKD thing that is recorded on a DASD track as a "record",  
whereas software-oriented people typically speak of that same thing as a  
"block".  
The term "block size" might be used by some in  certain contexts to mean only 
the length of the data field of the CKD  thing, or it might be used by some 
other people (or even by those same people in  a different context) to mean the 
effective size on the track of the entire CKD  thing, which would include the 
count field, the gap after the count field, the  key field (if any), the gap 
after the key field (only present if there is a key  field), the data field (if 
any), and the gap after the data field.
 
So you are correct that the "block size" is 256.  And that guy is also  
correct in saying that the "block size" is not 256.  Both of you were  thinking 
of 
different contexts when using the words "block" and "size".   The "Using Data 
Sets" book says "PDS member entries ... are blocked into  256-byte blocks."  
If that is the only context you care about, then the  block size is 256.  But 
on that same page in the book is a diagram showing  that the "PDS Directory 
Block" (the title of the diagram) has a count field and  also an 8-byte key.  
So, 
according to this diagram, the key is part of the  directory "block".  When 
you allocate a new PDS, you specify the number of  directory "blocks", and each 
such block, when written on the track, has an  8-byte key field in it.  The 
term "block size" is used throughout many IBM  books to mean only the length of 
the data field of a DASD CKD thing.  But  underlying all allo

Re: 256 bytes again

[Jim McAlpine]

On 2/24/08, R.S. <[EMAIL PROTECTED]> wrote:
>
> Disclaimer: maybe it's boring, but at least it is on-topic. Apologize
> for pedantry.
>
> I just thought about 256 bytes as PDS directory block size.
> It was commented as wrong value.
> However the same value is mentioned in IBM documentation. OK,
> documenation can be wrong (recently I submitted RCF for ugly errror in
> RDF description of "Using Data Sets").
> However ...it's not. The documentation is correct.


Sorry, the pedantry remark wasn't aimed at you.  BTW I agree with you that
256 bytes is the correct value.

Jim McAlpine

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 256 bytes again

[R.S.]

Gerhard Postpischil wrote:

R.S. wrote:
Indeed, 256 bytes is a size of directory block. This is size of Data 
in CKD. One could add Count and Key to the size, but *he shouldn't*.


Example: my PS FB 80 dataset was allocated with SDB (system determined 
blocksize). Disk is 3390, the blocksize is 27920 bytes. So, when 
writing sequentially i.e. copying some data using IEBGENER I'll get 
block in size of 27920 bytes (possibly except last block). Everyone 
would agree (ok, there's one guy - you know). My dataset has blocksize 
= 27920 bytes. This is length of Data. There's no Key, but there is 
Count. I did not mention it. My ISPF did not also. Nobody mentions.


There are at least two guys 

If you use TRKCALC to obtain the number of blocks per track, or the 
track balance, and you do not specify the key length, your results will 
be incorrect, and you'll get an I/O error trying to write a block that 
doesn't fit on the track. So there are cases where your advice of 
"shouldn't" results in a problem. Ignoring the key length makes as much 
sense as ignoring the length field itself, and claiming the directory 
block is 254 bytes.
No. First - when you calculate number of blocks, you have to take into 
consideration many physical aspects of data storing, like Count field, 
gaps, data cell size, data cell existence, track size, R0, etc. I don't 
know TRKALC, but I can imagine, that program assuming there is no Key - 
and the assumption is bad - gives bad results. Indeed I can put more 
256B long "regular" data blocks on the track than directory blocks. 
However it doesn't change the fact that directory block is 256 bytes long.
Contrary to VTOC the Key in directory contains redundant, "index" 
information only (name of the last member described in the block).


Saying directory block is 254 bytes is plain incorrect, because it's 
not. The byte, you mention is part of the content. Like CDF in VSAM CI. 
According to documentation, you can read directory sequentially by 
providing LRECL=256. Again - 256.


To confound things still further, I've seen references to the data 
portion of a block as a "record".
Yes. Unfortunately. Sometimes it's called 'physical record'. 
Inconsistent naming is misleading.


--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Są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.2008 r. kapitał zakładowy BRE Banku SA  wynosi 
118.642.672 złote i został w całości wpłacony.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 256 bytes again

[Gerhard Postpischil]

R.S. wrote:
Indeed, 256 bytes is a size of directory block. This is size of Data in 
CKD. One could add Count and Key to the size, but *he shouldn't*.


Example: my PS FB 80 dataset was allocated with SDB (system determined 
blocksize). Disk is 3390, the blocksize is 27920 bytes. So, when writing 
sequentially i.e. copying some data using IEBGENER I'll get block in 
size of 27920 bytes (possibly except last block). Everyone would agree 
(ok, there's one guy - you know). My dataset has blocksize = 27920 
bytes. This is length of Data. There's no Key, but there is Count. I did 
not mention it. My ISPF did not also. Nobody mentions.


There are at least two guys 

If you use TRKCALC to obtain the number of blocks per track, or 
the track balance, and you do not specify the key length, your 
results will be incorrect, and you'll get an I/O error trying to 
write a block that doesn't fit on the track. So there are cases 
where your advice of "shouldn't" results in a problem. Ignoring 
the key length makes as much sense as ignoring the length field 
itself, and claiming the directory block is 254 bytes.


To confound things still further, I've seen references to the 
data portion of a block as a "record".



Gerhard Postpischil
Bradford, VT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

256 bytes again

[R.S.]

Disclaimer: maybe it's boring, but at least it is on-topic. Apologize 
for pedantry.


I just thought about 256 bytes as PDS directory block size.
It was commented as wrong value.
However the same value is mentioned in IBM documentation. OK, 
documenation can be wrong (recently I submitted RCF for ugly errror in 
RDF description of "Using Data Sets").

However ...it's not. The documentation is correct.

Indeed, 256 bytes is a size of directory block. This is size of Data in 
CKD. One could add Count and Key to the size, but *he shouldn't*.


Example: my PS FB 80 dataset was allocated with SDB (system determined 
blocksize). Disk is 3390, the blocksize is 27920 bytes. So, when writing 
sequentially i.e. copying some data using IEBGENER I'll get block in 
size of 27920 bytes (possibly except last block). Everyone would agree 
(ok, there's one guy - you know). My dataset has blocksize = 27920 
bytes. This is length of Data. There's no Key, but there is Count. I did 
not mention it. My ISPF did not also. Nobody mentions.


Now we come to some conclusion: *It's a matter of definition.*  However 
common definition is that we provide size of the block by providing 
length of Data in CKD.



Regards
--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Są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.2008 r. kapitał zakładowy BRE Banku SA  wynosi 
118.642.672 złote i został w całości wpłacony.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html