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
