Question on processing z/OS UNIX files using QSAM
Steve Comstock
FILEDATA parameter: FILEDATA=RECORD; this implies data is
stored with each record having a 4 byte prefix that specifies
the length of the following data (different format than RDWs
for RECFM of VB).
When reading such a file using QSAM, the access method strips
off the prefix and passes just the data back to the program.
My question is: where is the record length? I can't see it
documented in the z/OS 1.11 pubs, and I don't have access to
1.11 to check macro definitions.
--
Kind regards,
-Steve Comstock
The Trainer's Friend, Inc.
303-393-8716
http://www.trainersfriend.com
z/OS Application development made easier
* Our classes include
+ How things work
+ Programming examples with realistic applications
+ Starter / skeleton code
+ Complete working programs
+ Useful utilities and subroutines
+ Tips and techniques
==> Ask about being added to our opt-in list: <==
==> * Early announcement of new courses <==
==> * Early announcement of new techincal papers <==
==> * Early announcement of new promotions <==
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
des...@verizon.net
> In z/OS 1.11, a new option was provided for the DD statement
> FILEDATA parameter: FILEDATA=RECORD; this implies data is
> stored with each record having a 4 byte prefix that specifies
> the length of the following data (different format than RDWs
> for RECFM of VB).
>
> When reading such a file using QSAM, the access method strips
> off the prefix and passes just the data back to the program.
> My question is: where is the record length? I can't see it
> documented in the z/OS 1.11 pubs, and I don't have access to
> 1.11 to check macro definitions.
SYS1.MACLIB(IGGRPFX):
RPFX DSECT Record Prefix
DS 0F
RPFX00 DS X reserved byte
RPFXLLL DS XL3 Length of record that
* immediately follows this prefix
McKown, John
<quote>
When RECFM=F(B(S))
------------------
* And the file accessed has a filedata type of binary, if the
last record in the file is smaller than LRECL bytes; it is
padded with zeros when it is read.
* And the file accessed has a
filedata type of text, if any record in the file is smaller than
LRECL bytes; it is padded with blanks when it is read. If any
record is longer than LRECL bytes, it results in an I/O error
due to incorrect length when it is read.
* And the file accessed
has a filedata type of record, if any record in the file is
smaller or larger than LRECL bytes, it results in an I/O error
due to incorrect length when it is read.
When RECFM=V(B)
---------------
* And the file accessed has a filedata type of binary, each
record is returned as length LRECL, except, possibly, for the
last one.
* And the file accessed has a filedata type of text, if any
record in the file consists of zero bytes (that is, a text
delimiter is followed by another text delimiter), the returned
record consists of an RDW and no data bytes. If any record is
longer than LRECL bytes, it results in an I/O error due to
incorrect length when it is read.
* And the file accessed has a filedata type of record, if any
record in the file consists of zero bytes (that is, a record
prefix (IGGRPFX) contains a zero length), the returned record
consists of an RDW with no data bytes. If any record is longer
than LRECL bytes, it results in an I/O error due to incorrect
length when it is read.
When RECFM=U
------------
* And the file accessed has a filedata type of binary, each
record is returned with a length equal to block size, except,
possibly, for the last one.
* And the file accessed has a
filedata type of text, if any record in the file consists of
zero bytes (that is, a text delimiter is followed by another
text delimiter), the returned record consists of one blank. If
any record is longer than the block size, it results in an I/O
error due to incorrect length when it is read.
* And the file accessed has a filedata type of record, if any
record in the file consists of zero bytes (that is, a record
prefix (IGGRPFX) contains a zero length) or any record is longer
than BLKSIZE bytes, it results in an I/O error due to incorrect
length when it is read.
3.9.3.3 JCL Parameters for UNIX Files
You can use the following JCL parameters when working with UNIX
files.
FILEDATA Use the FILEDATA keyword to describe the
organization of a UNIX file so that the system can determine how
to process the file. The access methods use both EBCDIC text
and binary formats for UNIX files. With BPAM, files can have
differing values for the FILEDATA parameter. Each DD statement
can have its own FILEDATA value. If you do not code the FILEDATA
keyword on the DD statement, the FILEDATA value that is
associated with each file takes effect.
BINARY
Indicates the data is a byte-stream and does not contain
record delimiters or record prefixes.
Each record is the maximum length. Binary is the default
value. Code FILEDATA=BINARY for records files without line
delimiters or record prefixes.
TEXT
Indicates that the data consists of records separated by a
delimiter of the EBCDIC newline character (X'15'). Code
FILEDATA=TEXT if records are text and each record ends
with a line delimiter. On output, the access method inserts
a record delimiter
at the end of each record. On input, the access method uses
the delimiter to find the end of each record and adds
trailing blanks if the record format (RECFM) is fixed and
is shorter than the LRECL value.
RECORD
Indicates that the data consists of records with prefixes. The
record prefix contains the length of the record that follows.
On output, the access method inserts a record prefix at the
beginning of each record. On input, the access method uses the
record prefix to determine the length of each record. The
access method does not return the prefix as part of the
record.Code FILEDATA=RECORD when you cannot code
FILEDATA=TEXT because
your data might contain bytes that are considered delimiters.
Note: the record prefix for FILEDATA=RECORD is mapped by the
IGGPRFX macro. This is different from the record descriptor
word (RDW) that is in z/OS physical sequential format-V data
sets.
</quote>
So it appears that if you read the file and you've used RECFM=VB, then QSAM will pass back a standard RDW to your program.
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john....@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
Steve Comstock
Well, the same text is in the doc. But think about this for
a minute. Suppose I'm using QSAM to write to a z/OS UNIX
file with FILEDATA=RECORD.
For this to work, of course, the DD statement must have
RECFM and LRECL and perhaps BLKSIZE.
Now, if I code PUT outfile,outrec
Steve Comstock
[Pressed Send too soon]
Anyway, that's the wording in the docs. Maybe I didn't read it closely
enough. Let me think this out here.
For the moment, only concerned with accessing z/OS UNIX files
defined with FILEDATA=RECORD.
If DD statement has RECFM=U and BLKSIZE=4000, say, then
put outfile,outrec would write 4000 bytes
if the file were input, then
get infile,inrec would retrieve 4000 bytes:
- unless there were less than 4000 bytes left in the file
- where would I look to see the actual bytes read?
(guess: the blocksize value in the DCB; but it's not
clear to me from the doc)
And, it looks like you're right about RECFM of V / VB:
an RDW-prefixed record would be presented.
Otherwise, you retreive or write LRECL bytes (RECFM F / FB)
or you get an I/O error.
Guess that meets my information needs. Thanks for getting me
to read the material available more closely.
Paul Gilmartin
>McKown, John wrote:
>>
>> So it appears that if you read the file and you've used RECFM=VB, then QSAM will pass back a standard RDW to your program.
>>
It would be nice if they made this more explicit, viz.:
o On output the RDW is removed and a prefix indicating a length
of RDW COUNT-4 is added.
o On input, after removing the prefix, an RDW having a COUNT of
length+4 is added.
Yes, it's easy to guess that, but why should the reader need
to guess.
>Anyway, that's the wording in the docs. Maybe I didn't read it closely
>enough. Let me think this out here.
>
>For the moment, only concerned with accessing z/OS UNIX files
>defined with FILEDATA=RECORD.
>
>If DD statement has RECFM=U and BLKSIZE=4000, say, then
>
> put outfile,outrec would write 4000 bytes
>
>if the file were input, then
>
> get infile,inrec would retrieve 4000 bytes:
>
> - unless there were less than 4000 bytes left in the file
>
I believe, on the contrary, that for RECFM=U, a block
is considered a record. This is the way ISPF LMGET/LMPUT work
when I use them to manipulate RECFM=U files. (LMGET/LMPUT
are the only way I know to access RECFM=U files in Rexx.)
> - where would I look to see the actual bytes read?
> (guess: the blocksize value in the DCB; but it's not
> clear to me from the doc)
>
In assembler? Well, it's been decades since I did this.
I believe one tweaks the BLKSIZE in the DCB before each
write (being careful to restore it before CLOSE; else
it gets written back to the DSCB). For READ, subtract
the RBC in the CSW/IOB/(I forget) from BLKSIZE to get
the bytes read. It would almost be better to indicate
I/O error on reading a zero-length logical record with
FILEDATA=RECORD,RECFM=U rather than padding it with a
blank, because it's invalid on physical devices.
>And, it looks like you're right about RECFM of V / VB:
>an RDW-prefixed record would be presented.
>
>Otherwise, you retreive or write LRECL bytes (RECFM F / FB)
>or you get an I/O error.
>
>Guess that meets my information needs. Thanks for getting me
>to read the material available more closely.
>
>--
>Kind regards,
>-Steve Comstock
-- gil