Skip,
Not a specific reply to your points, but as the OP may I say thanks for the
help and education, here's what I finally decided:
In my app created are five PDS's plus thirteen files of varying LRECL's.
Eight of the thirteen are LRECL < 80. Without horrendous program changes
they can be made 80 (in general the files have a 1000 or so recs).
That leaves me with five PDS's and five > 80 LRECL files. Since one of my
objectives was a less 'mixed' 3.4 list I decided on judicious renaming. The
two high order nodes for everything are always the same so I made all the
PDS third node names start with A and that got them to the top of the list,
the remaining 5 follow .. is OK for my needs.
Again thanks for the help.
Sorry to say, next question is just a few minutes away:-)
Graham Hobbs
----- Original Message -----
From: "Skip Robinson" <[email protected]>
Newsgroups: bit.listserv.ibm-main
To: <[email protected]>
Sent: Monday, April 22, 2013 11:50 AM
Subject: Re: Files in PDS's with different LRECL's
Some of the posts in this thread seem to view DCB attributes as a stick-on
label that can be peeled off and replaced as needed. While hardware knows
nothing of LRECL--hence the Logical nature--block size is very much a
physical attribute of a file on CKD DASD. You may get away with output to
a file with overriding attributes, but attempting to read data back via
QSAM will fail for FB data if physical BLKSIZE is not an integral multiple
of LRECL for any block being read.
All in all, I can't imagine what 'convenience' would be achieved by
creating write-only PDS(E) members.
.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
[email protected]
From: Paul Gilmartin <[email protected]>
To: [email protected],
Date: 04/22/2013 07:59 AM
Subject: Re: Files in PDS's with different LRECL's
Sent by: IBM Mainframe Discussion List <[email protected]>
On 2013-04-20, at 03:02, R.S. wrote:
BTDT.
FOr PDSE you'll get an error, for PDS your file may be (will be)
corrupted.
I tried this with PDSE.
For RECFM=VB, I can increase the LRECL with overriding JCL with
no error reported and no apparent data corruption. Attempting
to decrease the LRECL results in IEC141I 013-EC.
For RECFM=FB, Attempting to increase the LRECL results in IEC141I 013-EC.
I like the PDSE implementation: it maintains compatibility
with PDS in the safe cases, and reports an error (as PDS
fails to) in the cases in which your file may be (will be)
corrupted.
Other cases and PDS are left as an exercise for the student.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
