Discussion:
RECFM=VBS,LRECL=X
(too old to reply)
Kirk Wolf
2018-05-02 18:22:03 UTC
Permalink
Raw Message
Does anyone use this with your z/OS data sets?

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Lizette Koehler
2018-05-02 18:24:57 UTC
Permalink
Raw Message
I use to with SMF datasets, now I just let IFASMFDP figure it out with SMS.

Lizette
-----Original Message-----
Kirk Wolf
Sent: Wednesday, May 02, 2018 11:23 AM
Subject: RECFM=VBS,LRECL=X
Does anyone use this with your z/OS data sets?
Kirk Wolf
Dovetailed Technologies
http://dovetail.com
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-05-02 19:38:33 UTC
Permalink
Raw Message
Post by Kirk Wolf
Does anyone use this with your z/OS data sets?
I've experimented with it. I was semi-pleased to discover that while
BPXWYN rejects LRECL(X) as a syntax error it accepts LRECL(32768) instead.

I don't recall whether Rexx reassembles spanned records or whether I
needed to override with RECFM(U) and process the streams myself.

I don't know which utilities are sensitive to which BFTEK values.

RECFM=VBS,LRECL=X would seem natural for processing UNIX files.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Kirk Wolf
2018-05-02 20:26:10 UTC
Permalink
Raw Message
Post by Paul Gilmartin
RECFM=VBS,LRECL=X would seem natural for processing UNIX files.
Not sure exactly what you mean by "processing". Do you mean as a format
for making a copy of a Unix line-oriented file with a possibly very large
line length?

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
David W Noon
2018-05-02 21:28:42 UTC
Permalink
Raw Message
On Wed, 2 May 2018 14:39:57 -0500, Paul Gilmartin
(0000000433f07816-dmarc-***@LISTSERV.UA.EDU) wrote about "Re:
RECFM=VBS,LRECL=X" (in
Post by Paul Gilmartin
Post by Kirk Wolf
Does anyone use this with your z/OS data sets?
I've experimented with it. I was semi-pleased to discover that while
BPXWYN rejects LRECL(X) as a syntax error it accepts LRECL(32768) instead.
I don't recall whether Rexx reassembles spanned records or whether I
needed to override with RECFM(U) and process the streams myself.
If you are using QSAM, the access method should do it. With RECFM=VBS
you are required to use move mode processing and QSAM should do the
buffer management, including reassembling each logical record as it move
the data to you work area.

AFAIAA, REXX EXECIO uses QSAM.

I have processed VBS records using BSAM. It is a bit of a chore ensuring
that the spanning indicator bits in the RDWs are set correctly.
Post by Paul Gilmartin
I don't know which utilities are sensitive to which BFTEK values.
I have not seen BFTEK do anything particularly useful.
Post by Paul Gilmartin
RECFM=VBS,LRECL=X would seem natural for processing UNIX files.
UNIX files for input? No, these lack BDW and RDW fields and cannot be
processed by QSAM as anything other than RECFM=U (or perhaps
RECFM=F[B]). If they are text files, you still need to scan the buffer
to find the '\n' character that terminates each text record.
--
Regards,

Dave [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
***@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

 

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-05-02 21:29:11 UTC
Permalink
Raw Message
Post by Kirk Wolf
Post by Paul Gilmartin
RECFM=VBS,LRECL=X would seem natural for processing UNIX files.
Not sure exactly what you mean by "processing". Do you mean as a format
for making a copy of a Unix line-oriented file with a possibly very large
line length?
Yes. Or even non line-oriented. Sometimes scientific data come that way. Decades
ago I read of someone who had 200 BPI tapes with no gaps generated by a data
acquisition device. (The digital logic to insert gaps would have been too expensive
in that era.) He dealt with it by reading it with a non-terminating channel program
and writing to a higher density with gaps.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-05-02 21:41:38 UTC
Permalink
Raw Message
Post by David W Noon
Post by Paul Gilmartin
...
I don't recall whether Rexx reassembles spanned records or whether I
needed to override with RECFM(U) and process the streams myself.
If you are using QSAM, the access method should do it. With RECFM=VBS
you are required to use move mode processing and QSAM should do the
buffer management, including reassembling each logical record as it move
the data to you work area.
Suppose there is no guarantee that every logical record fit in available virtual memory?
Post by David W Noon
AFAIAA, REXX EXECIO uses QSAM.
I have processed VBS records using BSAM. It is a bit of a chore ensuring
that the spanning indicator bits in the RDWs are set correctly.
Post by Paul Gilmartin
I don't know which utilities are sensitive to which BFTEK values.
I have not seen BFTEK do anything particularly useful.
Thinking further, it might make more sense to allocate a UNIX file as FILEDATA=BINARY,
RECFM=VB, LRECL=1028 (arbitrarily). SDB will choose a BLKSIZE and QSAM or BSAM will
insert RDWs (every 1024 bytes) and BDWs.

gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
David W Noon
2018-05-02 22:26:33 UTC
Permalink
Raw Message
On Wed, 2 May 2018 16:43:02 -0500, Paul Gilmartin
(0000000433f07816-dmarc-***@LISTSERV.UA.EDU) wrote about "Re:
RECFM=VBS,LRECL=X" (in
[snip]
Post by Paul Gilmartin
Post by David W Noon
If you are using QSAM, the access method should do it. With RECFM=VBS
you are required to use move mode processing and QSAM should do the
buffer management, including reassembling each logical record as it move
the data to you work area.
Suppose there is no guarantee that every logical record fit in available virtual memory?
How do you process such a logical record in a finite address space? The
only way I can think of is to segment the record and process it
piecewise. That would require BSAM, since the buffer pool will fit into
memory, and the record segments will be limited in size to fit into a
buffer.

You then have an issue of related fields not being in the same segment
or not being in segments close enough to have the related fields
accessed concurrently.

I would then feel that the data stream design is flawed. I would want it
normalized, when possible. The problem with that is that many "small
platform" people know little or nothing about normal forms. [Indeed, it
is mainly DB2 and IMS people who understand it on the mainframe.] The
problem remains if the record layout is already in at least 1NF.
--
Regards,

Dave [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
***@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

 

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-05-03 00:40:17 UTC
Permalink
Raw Message
Post by David W Noon
Post by Paul Gilmartin
Suppose there is no guarantee that every logical record fit in available
virtual memory?
How do you process such a logical record in a finite address space? The
only way I can think of is to segment the record and process it
piecewise. That would require BSAM, since the buffer pool will fit into
memory, and the record segments will be limited in size to fit into a
buffer.
You then have an issue of related fields not being in the same segment
or not being in segments close enough to have the related fields
accessed concurrently.
Windowing. If it's feasible to choose a segment size large enough that
any two related fields fit in no more than two consecutive segments
you need only two buffers. Purge the older one; swap the buffers; and
read in a newer segment.
Post by David W Noon
I would then feel that the data stream design is flawed. I would want it
normalized, when possible. The problem with that is that many "small
platform" people know little or nothing about normal forms.
Tunnel vision.

Some real world data naturally arrive in a featureless stream; no neat
separation into segments, records, or blocks. The world won't change to
accommodate your preferred design, and you can't intimidate it by using
cultural pejoratives such as "many 'small platform' people know little ..."
Post by David W Noon
... [Indeed, it
is mainly DB2 and IMS people who understand it on the mainframe.] The
problem remains if the record layout is already in at least 1NF.
Consider LIGO: https://www.ligo.caltech.edu/
Its data inexorably arrive as a stream. Some amazing science comes
from processing that stream. That couldn't have been done if the
researchers had spurned those input data because they were in a
"flawed design" rather than a normal form.

-- gil

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