Could you use an VRRDS instead of an ESDS ? Seems like a zero length record would be supported (at least the doc indicates a record of any size and I believe 0 is a size.
Matt Hogstrom [email protected] +1-919-656-0564 PGP Key: 0x90ECB270 Facebook <https://facebook.com/matt.hogstrom> LinkedIn <https://linkedin/in/mhogstrom> Twitter <https://twitter.com/hogstrom> “It may be cognitive, but, it ain’t intuitive." — Hogstrom > On Dec 27, 2019, at 7:31 PM, Frank Swarbrick <[email protected]> > wrote: > > I understand that. I thought the CRLF would be "in the clear", which would > make the record (in the sequential file, sent from an ASCII system) 0 length. > But that was an invalid assumption. The "field" that includes the CRLF is > base64 encoded rather than containing an actual CRLF. > > I'm not sure how INSPECT...REPLACING can be used since there is not a 1-byte > to 1-byte correspondence... > > ________________________________ > From: IBM Mainframe Discussion List <[email protected]> on behalf of > David W Noon <[email protected]> > Sent: Friday, December 27, 2019 5:22 PM > To: [email protected] <[email protected]> > Subject: Re: VSAM record length 0 > > On Fri, 27 Dec 2019 23:46:12 +0000, Frank Swarbrick > <[email protected]> wrote abour Re: VSAM record length 0: > >> It turns out I was not quite on the right track. The 'record format' >> of the file does allow for a CRLF sequence embedded in it, but it does >> it by Base64 encoding the data, rather than including an "additional" >> CRLF as I had assumed. > > A CR/LF pair is normally just a line terminator, especially when the > record is Base64 encoded. Normally you just drop the line terminator. > > If you plan on keeping the data encoded as Base64, there should be no > zero-length records. Since Base64 data are a byte stream, the only > record boundaries are going to be by some kind of convention: CR/LF on > Microsoft platforms; CR on Apple; and LF on UNIX. > >> So now the question is, does z/OS have a Base64 decoding routine? >> I see that Enterprise PL/I has one, but I don't see anything for >> Enterprise COBOL. I can probably call a function from the C Runtime >> if there is one. (And no, I am probably not going to call a Java >> routine...) > > You can implement Base64 encoding/decoding in COBOL, typically by using > one or two INSPECT ... REPLACING verbs. Take a look at RFC 3548 to see > the standard algorithm: > <https://tools.ietf.org/html/rfc3548.html> > > HTH. > -- > Regards, > > Dave [RLU #314465] > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* > [email protected] (David W Noon) > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* > > ---------------------------------------------------------------------- > 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
