Long time ago IFASMFDP had a default BLKSIZE of
4096, but today uses SDB to match to device
characteristics. However, LRECL is set to 32767
and SMF did write records that long. At last
check, still did use DCBE, so features like LBI
could not be used for it's output files.
Note that if you SMS compress the output file,
BLKIZE becomes logical as the data is physically
written full track (roughly 56K bytes).
Michael
At 10:09 AM 5/18/2023, Lennie Dymoke-Bradshaw wrote:
Radoslaw,
If you specify the LRECL and/or BLKSIZE in your
program, then you can set a value that appears
to flout the JCL rules. For example it used to
be that IFASMFDP wrote data sets with a BLKSIZE
of 32767. I am unsure if it still does.
Lennie Dymoke-Bradshaw
https://rsclweb.com
Dance like no one is watching. Encrypt like everyone is.â
-----Original Message-----
From: IBM Mainframe Discussion List
<[email protected]> On Behalf Of Radoslaw Skorupka
Sent: 18 May 2023 10:36
To: [email protected]
Subject: Re: VBS file read in windows - end of record issue
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 [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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
