See the references on XLRI.
This should be a good start -
<https://www.ibm.com/docs/en/zos/2.1.0?topic=records-processing-longer-than-32760-bytes>Processing
Records Longer than 32 760 Bytes - IBM Documentation
This also might help -
<https://www.ibm.com/docs/en/zos/2.1.0?topic=definition-additional-syntax-lreclbytes>Additional
syntax for LRECL=(bytes) - IBM Documentation
You will perhaps need to review transmittal modes in -
<https://www-40.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R4sc236855/$file/idad400_v2r4.pdf>z/OS:
z/OS DFSMS Using Data Sets (ibm.com)
LRECL=16384K in JCL ends up providing a lrecl of 16384k-1, but guess
the folks coding JCL interpretation thought 16384K was enough of a keyword.
LRECL=X gives you a lrecl of 32768 which appears to signal that SDW
are present and that BFTEK=A (which doesn't support logical records
longer than 32767) will not work to reassemble the logical
record. For such file, reassembly (de-segmentation) of the logical
record is left to the application program.
Note that when working with records longer than 32767 the length of
the record is now three bytes long (i.e. 16384K - 1). Also see DCB
field DCBXLREC.
Michael
At 04:35 AM 5/18/2023, Radoslaw Skorupka wrote:
Content-Transfer-Encoding: 8bit
Well, can you show me a JCL job to allocate such dataset?
My experience say that any attempt to create PS dataset with LRECL >
~32kB ends with JCL error and IEF638I
JCL Reference clearly say that for non-VSAM dataset the maximum is
32760. For VSAM it is 32761.
"Additional Syntax" says it is possible to use LRECL=nnnnnK when
nnnnn is up to 16,383. However it is possible only for ISO/ANSI V3 tapes.
And there is LRECL=X, which is applicable only to QSAM VS/VBS. It is
not cheating in the meaning I provided earlier, but it is not quite
simple dataset usage.
Note: despite of the above it is possible to allocate PS VBS file
with LRECL=32767, but the LRECL cannot be specified in JCL. LIKE is the trick.
Regarding a little bit off-topic compressed extended format
datasets: system reports "legal" BLKSIZE 32760 (SDB was used).
What's inside - it is covered by media manager IMHO.
(irrelevant)
My local "cheating" definition used before: user creates
records/segments, *including* SDW. IMHO tools like File Manager
allow such cheating. However it is just track editing play, not dataset usage.
Regards
--
Radoslaw Skorupka
Lodz, Poland
W dniu 17.05.2023 o 21:14, Michael Oujesky pisze:
Having read and written records longer than three MB, it is not
"cheating". Especially with RMF 74.5 records with 59 "broken"
(split) records to reassemble into one very long record. See the
SMF manual on RMF record reassembly area.
JCL allows LRECL=16384K. And SMS compressed files write full
tracks (roughly 56KB).
Michael
At 01:20 PM 5/17/2023, Radoslaw Skorupka wrote:
Content-Transfer-Encoding: 8bit
Well, not really.
There is LRECL=X, but besides we have not very strict limitation
of LRECL. It is 32760 or 32767.
First value is limited by JCL syntax, but the second is available
when allocation PS using LIKE= keyword.
Of course one may automagically write segments with custom-created
SDWs, but I would call it cheating.
BTW: The purpose of VBS was not veeeeeeery long record, but
records up to 32k, even on DASD with shorter track. Hint: the
track is natural limit of BLKSIZE. It is no longer important since
3380 (80's), because track size exceeded 32k.
--
Radoslaw Skorupka
Lodz, Poland
W dniu 16.05.2023 o 18:52, Michael Oujesky pisze:
Just another tidbit, but when combining the record segments,
while the VBS architecture does not specify a maximum record
length, you can expect the full records to be up to 16,777,215
(16384K - 1) bytes in length.
Realizing that the RDW is actually a SDW.
Michael
At 01:26 AM 5/16/2023, Michael Stein wrote:
On Tue, May 16, 2023 at 04:14:07AM +0000, Prashant Joshi wrote:
>> Did you specify binary mode on the python open call? --
> Yes. And I can read the data.
How are you reading the data. Assuming an open like:
myfile = open("filename", "rb")
You need to either read it all into memory:
alldata = myfile.read()
or read specific lengths which is messier as you need to read specific
lengths, first 4 bytes for the RDW and then the length of the record
in the RDW-4 (as you already read the RDW).
The 4 byte RDW includes the length of the record in the first 2 bytes
(bigendian order) and the spanning bits in the last 2 bytes.
Either way you need to walk your way through the binary data, any code
looking for CR or NL or space isn't correct.
A description of VBS records formats:
z/OS 2.4 DFSMS Using Data Sets SC23-6855-40
https://www-40.ibm.com/servers/resourcelink/svc00100.nsf/pages/zOSV2R4sc236855/$file/idad400_v2r4.pdf
pdf page 273 Variable-Length Record Formats
(near bottom of page and continues on to more pages)
> its just that I don't get proper end of reord. Hence every time I
> read record, I get random record length (multiple records/half records
> combined)
There aren't any "end of records" in a VBS file. At the begining of
the file you know you are at the start of a RDW (Well, BDW/RDW but I'm
assuming the FTP removed the BDWs).
You can find the next record by going the length specified in the RDW
into the file -- that is the start of the next RDW. Continue until
you've processed all the records.
More help will likely require you to show some code and/or data so
we can see what is going on...
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
