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
