Posted: Wed Aug 25, 2004 1:15 am Post subject: Maximum LRECL for a PS
Hi,
I want to define a PS dataset with LRECL 55000.
But am getting message when I do JSCAN, LRECL can be maximum of 32760.
Is this the limit that MVS allows or Do I need to increase Block Size of my dataset allcoations.
Hi Siva,
According to the MVS JCL Reference guide,
"BLKSIZE specifies the maximum length, in bytes, of a block. The number of bytes that you specify for BLKSIZE depends on the device type and the record format for the data set. The maximum is 32,760 for DASD data sets and 2,147,483,648 for tape, except for data sets on magnetic tape with ISO/ANSI Version 3 labels, where the minimum value for BLKSIZE is 18 bytes and the maximum is 2048 bytes. To allow a block size greater than 2048, use installation exit routine IFG0193G, described in z/OS DFSMS Installation Exits."
Hence I guess, the maximum length that can specified should not exceed 32760 in your case.
Thanks,
Meg
Joined: 26 Nov 2002 Posts: 12376 Topics: 75 Location: San Jose
Posted: Wed Aug 25, 2004 6:02 am Post subject:
sivakumar,
Quote:
I want to define a PS dataset with LRECL 55000.
What kind of language on the mainframe supports such LRECL? Cobol does not support it. I am doubtful if C supports it.
As meg mentioned earlier the max lrecl you can have is
1 to 32,760 for non-VSAM data sets.
1 to 32,761 for VSAM key-sequenced (KS), entry-sequenced (ES), or relative record (RR) data sets. (LRECL does not apply to VSAM linear space, RECORG=LS, data sets.)
For VSAM key-sequenced (KS) data sets, a record length must be specified, either explicitly with the LRECL or LIKE parameter, or in the data class for the data set. The record length must be greater than the key length.
Note: When RECFM is F or U, the length must not exceed DCB BLKSIZE. For RECFM=D or V, the length must not exceed BLKSIZE minus 4. For RECFM=VS, the length can exceed BLKSIZE. For unblocked records when DCB RKP=0, the length is for only the data portion of the record. LRECL=0 is valid only for RECFM=U.
It is rare to ever see a BLKSIZE actually even mentioned in a design spec. To most people, this is just trivia. Not even worth mentioning, unless you happen to be cleaning up someone else's mess - because (say for example) they might have hard-coded (bad) block sizes everywhere.
You shop almost certainly uses DFHSM (or equivalent). And with DFHSM, it is very-Bad practise to hard-code blocksizes. Furthermore you really should speak to someone in YOUR shop about this stuff to supplement what you have learned here. How about the Storage Management people for example?
And what Meg and Kolusu said is only true if you are using 3390 DASD types. Are you? How do you know that you are not using 3380 DASD types? The optimal blksize for a 3380 is completely different. Many shops still have 3380s.
Optimal blksize = half a track. Which means... to get all data off that track takes 2 physical I/Os. If you do not have optimal blksize, then to get all the data off one track takes a minimum of 3+ I/Os. All of a sudden, you need 50+% extra I/O. And I/O is very CPU intensive = a real good way to waste $$ and space.
Posted: Thu Aug 26, 2004 4:43 pm Post subject: Whoops-e-daisy - My Mistake! Biggest IT error in 100 years!
Siva,
You'll have to dis-regard my last two posts!!
I got LRECL and BLKSIZE mixed up.
That's because I have just arrived in new shop, and have been asked to come up with plans to save CPU and DASD, and one of the first things I looked at was the JCL, and found all hard-coded Blocksizes, and alot of it complete c***.
How about VB, LRECL=2125, BLKSIZE=7000?? And that's just an entree.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
FAQ
Search
Quick Manuals
Register
Profile
Log in to check your private messages
Log in
