Re: Copy RECFM=VBS/LRECL=X to zFS?
Gil, Of course I can't be sure without access to the OCO source code, but I can make an educated guess based on the C RTL implementation. I had not investigated the command ref doc for cp, I was just responding to the OP's original issue that using cp did not work. Mea culpa. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Thursday, September 2, 2021 1:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Copy RECFM=VBS/LRECL=X to zFS? On Thu, 2 Sep 2021 04:47:52 +, Farley, Peter x23353 wrote: > >By practical experimentation, I found that z/OS Unix awk uses fopen(). > How can you be sure? You haven't seen the source code. >I'll bet the cat utility does too but that cp uses open(). > From the UNIX Command Ref. for "cp": 1. To specify an MVS data set name, precede the name with double slashes (//). For example, to specify the fully qualified data set names 'turbo.gammalib' and 'turbo.gammalib(pgm1)', write: "//'turbo.gammalib'" "//'turbo.gammalib(pgm1)'" ... -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Copy RECFM=VBS/LRECL=X to zFS?
On Thu, 2 Sep 2021 04:47:52 +, Farley, Peter x23353 wrote: > >By practical experimentation, I found that z/OS Unix awk uses fopen(). > How can you be sure? You haven't seen the source code. >I'll bet the cat utility does too but that cp uses open(). > From the UNIX Command Ref. for "cp": 1. To specify an MVS data set name, precede the name with double slashes (//). For example, to specify the fully qualified data set names 'turbo.gammalib' and 'turbo.gammalib(pgm1)', write: "//'turbo.gammalib'" "//'turbo.gammalib(pgm1)'" ... -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Copy RECFM=VBS/LRECL=X to zFS?
But ONLY if the utility is coded to use fopen() and not open(); fopen() supports the DD:ddname syntax, open() does not. By practical experimentation, I found that z/OS Unix awk uses fopen(). I'll bet the cat utility does too but that cp uses open(). Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Wednesday, September 1, 2021 12:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Copy RECFM=VBS/LRECL=X to zFS? The DD:ddname format for a "legacy" dataset is a supported and documented feature of the C runtime library (even if not specifically for cat). Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, August 31, 2021 1:51 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Copy RECFM=VBS/LRECL=X to zFS? On Tue, 31 Aug 2021 15:27:38 -0500, Kirk Wolf wrote: >OK Gil, you will absolutely love this. >( I swear I didn't know this until just now :-) > >$ cp "//'KIRK.TEST.VBX'" /tmp/test.vbxcp >cp: FSUMF148 //'KIRK.TEST.VBX': spanned records are not supported > >$ cat "//'KIRK.TEST.VBX'" > /tmp/test.vbxcp # works. records > 32768 >are copied correctly (at least up to the 57K one I tried) > Never underestimate the C/C++ RTL. I think the default is FILEDATA(TEXT) >PS> I bet that /bin/cat with a DD:MYVBX would work too! > Even though that's not documented as supported. Would you distribute to customers code dependent on an unsupported feature? How are attributes supplied on the DD statement merged with attributes supplied on the "cp" command? -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Copy RECFM=VBS/LRECL=X to zFS?
I would argue that cat should not document it, any more than the COBOL compiler doc should cover all the possible permutations of //SYSPUNCH DD ... They should reference the C library documentation and say "any of those formats." I agree on the merging to DCB attributes. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Wednesday, September 1, 2021 10:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Copy RECFM=VBS/LRECL=X to zFS? On Wed, 1 Sep 2021 09:34:07 -0700, Charles Mills wrote: >The DD:ddname format for a "legacy" dataset is a supported and documented >feature of the C runtime library (even if not specifically for cat). > The "cat" developers are understandably unwilling to document and support that behavior of "cat". At very least they'd need to specify the behavior when allocation options conflict with options on the "cat" command. (I suppose "unpredictable" would suffice.) Bottom line: if it breaks, either immediately or at the next release, you get to keep both pieces. Related: I once allocated a RECFM=VB data set, overriding to RECFM=U and fetched it from DD:SYSUTx with FTP BINARY. I expected to see BDWs/RDWs. Didn't. In effect, FTP used the attributes from the DSCB and ignored the allocated attributes. "cat" might have similarly unexpected behavior. -- gil -- 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
Re: Copy RECFM=VBS/LRECL=X to zFS?
On Wed, 1 Sep 2021 09:34:07 -0700, Charles Mills wrote: >The DD:ddname format for a "legacy" dataset is a supported and documented >feature of the C runtime library (even if not specifically for cat). > The "cat" developers are understandably unwilling to document and support that behavior of "cat". At very least they'd need to specify the behavior when allocation options conflict with options on the "cat" command. (I suppose "unpredictable" would suffice.) Bottom line: if it breaks, either immediately or at the next release, you get to keep both pieces. Related: I once allocated a RECFM=VB data set, overriding to RECFM=U and fetched it from DD:SYSUTx with FTP BINARY. I expected to see BDWs/RDWs. Didn't. In effect, FTP used the attributes from the DSCB and ignored the allocated attributes. "cat" might have similarly unexpected behavior. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Copy RECFM=VBS/LRECL=X to zFS?
The DD:ddname format for a "legacy" dataset is a supported and documented feature of the C runtime library (even if not specifically for cat). Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, August 31, 2021 1:51 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Copy RECFM=VBS/LRECL=X to zFS? On Tue, 31 Aug 2021 15:27:38 -0500, Kirk Wolf wrote: >OK Gil, you will absolutely love this. >( I swear I didn't know this until just now :-) > >$ cp "//'KIRK.TEST.VBX'" /tmp/test.vbxcp >cp: FSUMF148 //'KIRK.TEST.VBX': spanned records are not supported > >$ cat "//'KIRK.TEST.VBX'" > /tmp/test.vbxcp ># works. records > 32768 are copied correctly (at least up to the 57K >one I tried) > Never underestimate the C/C++ RTL. I think the default is FILEDATA(TEXT) >PS> I bet that /bin/cat with a DD:MYVBX would work too! > Even though that's not documented as supported. Would you distribute to customers code dependent on an unsupported feature? How are attributes supplied on the DD statement merged with attributes supplied on the "cp" command? -- gil -- 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
Re: Copy RECFM=VBS/LRECL=X to zFS?
On Tue, 31 Aug 2021 15:27:38 -0500, Kirk Wolf wrote: >OK Gil, you will absolutely love this. >( I swear I didn't know this until just now :-) > >$ cp "//'KIRK.TEST.VBX'" /tmp/test.vbxcp >cp: FSUMF148 //'KIRK.TEST.VBX': spanned records are not supported > >$ cat "//'KIRK.TEST.VBX'" > /tmp/test.vbxcp ># works. records > 32768 are copied correctly (at least up to the 57K >one I tried) > Never underestimate the C/C++ RTL. I think the default is FILEDATA(TEXT) >PS> I bet that /bin/cat with a DD:MYVBX would work too! > Even though that's not documented as supported. Would you distribute to customers code dependent on an unsupported feature? How are attributes supplied on the DD statement merged with attributes supplied on the "cp" command? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Copy RECFM=VBS/LRECL=X to zFS?
On Tue, 31 Aug 2021 13:30:17 -0700, Sri h Kolusu wrote: >> Thanks, but it doesn't seem to work.� Records that are over 32752 bytes >> are truncated. >> (Was that supposed to be an NBSP?) >> FMNBB298 10 record(s) copied: 6 truncated: 0 fields truncated > >Can you please try with LRECL=X in the JCL definition and also use PAD=ON >in the sysin to pad to the maximum length? > Do you *really* think that's what he wants? For LRRECL=X, the maximum is "unlimited". >//PATHDISP=(KEEP,DELETE),FILEDATA=TEXT,LRECL=X > >//SYSINDD * >$$FILEM SET PAD=ON >$$FILEM DSC >/* -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Copy RECFM=VBS/LRECL=X to zFS?
> Thanks, but it doesn't seem to work. Records that are over 32752 bytes > are truncated. > > FMNBB298 10 record(s) copied: 6 truncated: 0 fields truncated Kirk, Can you please try with LRECL=X in the JCL definition and also use PAD=ON in the sysin to pad to the maximum length? //PATHDISP=(KEEP,DELETE),FILEDATA=TEXT,LRECL=X //SYSINDD * $$FILEM SET PAD=ON $$FILEM DSC /* Thanks, Kolusu -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Copy RECFM=VBS/LRECL=X to zFS?
OK Gil, you will absolutely love this. ( I swear I didn't know this until just now :-) $ cp "//'KIRK.TEST.VBX'" /tmp/test.vbxcp cp: FSUMF148 //'KIRK.TEST.VBX': spanned records are not supported $ cat "//'KIRK.TEST.VBX'" > /tmp/test.vbxcp # works. records > 32768 are copied correctly (at least up to the 57K one I tried) PS> I bet that /bin/cat with a DD:MYVBX would work too! Kirk Wolf Dovetailed Technologies http://dovetail.com On 8/31/21 2:23 PM, Kirk Wolf wrote: Gil, You're never wrong, but rarely helpful :-) Kirk Wolf Dovetailed Technologies http://dovetail.com On 8/31/21 12:13 PM, Paul Gilmartin wrote: On Tue, 31 Aug 2021 09:50:30 -0700, Sri h Kolusu wrote: Is there an IBM Utility that will do this? Preferrable with FILEDATA=TEXT processing mode on the output file IDCAAMS REPRO? (I haven't checked its requirements.) As a last resort, Rexx: Override stdin to RECFM=U and interpret the SDWs ad-hoc. Output with CHAROUT(); separate records with '15'x. (In the past I have reported problems mixing CHARIN() with LINEIN() or CHAROUT() with LINEOUT(). I don't know that those have been repaired. I doubt BPXWUNIX would be useful; don't know about CozBATCH.) If your shop has IBM File-Manager then you can use the following JCL I suspect the OP is an ISV and would prefer as few "if"s as possible. //STEP0100 EXEC PGM=FILEMGR //SYSPRINT DD SYSOUT=* //DDIN DD DISP=SHR,DSN=Your.MVS.LRECLX.Dataset //DDOUT DD PATH='/yourdir/lreclx.copy', // PATHMODE=(SIRWXU,SIRWXG,SIRWXO), // PATHOPTS=(OWRONLY,OCREAT,OEXCL), // PATHDISP=(KEEP,DELETE),FILEDATA=TEXT //SYSIN DD * $$FILEM DSC -- gil -- 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
Re: Copy RECFM=VBS/LRECL=X to zFS?
On Tue, 31 Aug 2021 14:23:25 -0500, Kirk Wolf wrote: > >You're never wrong, but rarely helpful :-) > Have you any constructive criticism? >On 8/31/21 12:13 PM, Paul Gilmartin wrote: >> On Tue, 31 Aug 2021 09:50:30 -0700, Sri h Kolusu wrote: >>... >> As a last resort, Rexx: >> >> Override stdin to RECFM=U and interpret the SDWs ad-hoc. >> Output with CHAROUT(); separate records with '15'x. >> >> [problems with] CHAROUT() with LINEOUT(). I don't know that those >>have been repaired. >> I have an Email from 2009 mentioning OA27527. If there was a resolution I haven't saved it. Rexx EXECIO has for several releases supported RECFM=VBS. The Ref. mentions no restrrictions concerning LREC=X. I'm skeptical; I'm composing an RCF. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Copy RECFM=VBS/LRECL=X to zFS?
Thanks, but it doesn't seem to work. Records that are over 32752 bytes are truncated. FMNBB298 10 record(s) copied: 6 truncated: 0 fields truncated Kirk Wolf Dovetailed Technologies http://dovetail.com On 8/31/21 11:50 AM, Sri h Kolusu wrote: Is there an IBM Utility that will do this? Preferrable with FILEDATA=TEXT processing mode on the output file Kirk, If your shop has IBM File-Manager then you can use the following JCL //STEP0100 EXEC PGM=FILEMGR //SYSPRINT DD SYSOUT=* //DDIN DD DISP=SHR,DSN=Your.MVS.LRECLX.Dataset //DDOUTDD PATH='/yourdir/lreclx.copy', //PATHMODE=(SIRWXU,SIRWXG,SIRWXO), //PATHOPTS=(OWRONLY,OCREAT,OEXCL), //PATHDISP=(KEEP,DELETE),FILEDATA=TEXT //SYSINDD * $$FILEM DSC /* Thanks, Kolusu -- 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
Re: Copy RECFM=VBS/LRECL=X to zFS?
Gil, You're never wrong, but rarely helpful :-) Kirk Wolf Dovetailed Technologies http://dovetail.com On 8/31/21 12:13 PM, Paul Gilmartin wrote: On Tue, 31 Aug 2021 09:50:30 -0700, Sri h Kolusu wrote: Is there an IBM Utility that will do this? Preferrable with FILEDATA=TEXT processing mode on the output file IDCAAMS REPRO? (I haven't checked its requirements.) As a last resort, Rexx: Override stdin to RECFM=U and interpret the SDWs ad-hoc. Output with CHAROUT(); separate records with '15'x. (In the past I have reported problems mixing CHARIN() with LINEIN() or CHAROUT() with LINEOUT(). I don't know that those have been repaired. I doubt BPXWUNIX would be useful; don't know about CozBATCH.) If your shop has IBM File-Manager then you can use the following JCL I suspect the OP is an ISV and would prefer as few "if"s as possible. //STEP0100 EXEC PGM=FILEMGR //SYSPRINT DD SYSOUT=* //DDIN DD DISP=SHR,DSN=Your.MVS.LRECLX.Dataset //DDOUTDD PATH='/yourdir/lreclx.copy', //PATHMODE=(SIRWXU,SIRWXG,SIRWXO), //PATHOPTS=(OWRONLY,OCREAT,OEXCL), //PATHDISP=(KEEP,DELETE),FILEDATA=TEXT //SYSINDD * $$FILEM DSC -- gil -- 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
Re: Copy RECFM=VBS/LRECL=X to zFS?
On Tue, 31 Aug 2021 09:50:30 -0700, Sri h Kolusu wrote: >> Is there an IBM Utility that will do this? >> Preferrable with FILEDATA=TEXT processing mode on the output file > IDCAAMS REPRO? (I haven't checked its requirements.) As a last resort, Rexx: Override stdin to RECFM=U and interpret the SDWs ad-hoc. Output with CHAROUT(); separate records with '15'x. (In the past I have reported problems mixing CHARIN() with LINEIN() or CHAROUT() with LINEOUT(). I don't know that those have been repaired. I doubt BPXWUNIX would be useful; don't know about CozBATCH.) >If your shop has IBM File-Manager then you can use the following JCL > I suspect the OP is an ISV and would prefer as few "if"s as possible. >//STEP0100 EXEC PGM=FILEMGR >//SYSPRINT DD SYSOUT=* >//DDIN DD DISP=SHR,DSN=Your.MVS.LRECLX.Dataset >//DDOUTDD PATH='/yourdir/lreclx.copy', >//PATHMODE=(SIRWXU,SIRWXG,SIRWXO), >//PATHOPTS=(OWRONLY,OCREAT,OEXCL), >//PATHDISP=(KEEP,DELETE),FILEDATA=TEXT >//SYSINDD * >$$FILEM DSC -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Copy RECFM=VBS/LRECL=X to zFS?
Never mind: 4. Data sets with spanned record lengths are not allowed. Grrr. VBS is the red-headed stepchild of DFSMS. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Tuesday, August 31, 2021 9:49 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Copy RECFM=VBS/LRECL=X to zFS? Did you try OPUT? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Kirk Wolf Sent: Tuesday, August 31, 2021 9:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Copy RECFM=VBS/LRECL=X to zFS? Is there an IBM Utility that will do this? Preferrable with FILEDATA=TEXT processing mode on the output file (adding newlines at record boundaries). Trying IEBGENER and ICEGENER both result in 013-A8 -- Kirk Wolf Dovetailed Technologies http://dovetail.com -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Copy RECFM=VBS/LRECL=X to zFS?
> Is there an IBM Utility that will do this? > Preferrable with FILEDATA=TEXT processing mode on the output file Kirk, If your shop has IBM File-Manager then you can use the following JCL //STEP0100 EXEC PGM=FILEMGR //SYSPRINT DD SYSOUT=* //DDIN DD DISP=SHR,DSN=Your.MVS.LRECLX.Dataset //DDOUTDD PATH='/yourdir/lreclx.copy', //PATHMODE=(SIRWXU,SIRWXG,SIRWXO), //PATHOPTS=(OWRONLY,OCREAT,OEXCL), //PATHDISP=(KEEP,DELETE),FILEDATA=TEXT //SYSINDD * $$FILEM DSC /* Thanks, Kolusu -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Copy RECFM=VBS/LRECL=X to zFS?
Did you try from within the z/FS? Doug Fuerst d...@bkassociates.net -- Original Message -- From: "Kirk Wolf" To: IBM-MAIN@listserv.ua.edu Sent: 31-Aug-21 12:30:23 Subject: Copy RECFM=VBS/LRECL=X to zFS? Is there an IBM Utility that will do this? Preferrable with FILEDATA=TEXT processing mode on the output file (adding newlines at record boundaries). Trying IEBGENER and ICEGENER both result in 013-A8 -- Kirk Wolf Dovetailed Technologies http://dovetail.com -- 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
Re: Copy RECFM=VBS/LRECL=X to zFS?
Did you try OPUT? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Kirk Wolf Sent: Tuesday, August 31, 2021 9:30 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Copy RECFM=VBS/LRECL=X to zFS? Is there an IBM Utility that will do this? Preferrable with FILEDATA=TEXT processing mode on the output file (adding newlines at record boundaries). Trying IEBGENER and ICEGENER both result in 013-A8 -- Kirk Wolf Dovetailed Technologies http://dovetail.com -- 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
Re: Copy RECFM=VBS/LRECL=X to zFS?
Am 31.08.2021 um 18:30 schrieb Kirk Wolf: Is there an IBM Utility that will do this? Preferrable with FILEDATA=TEXT processing mode on the output file (adding newlines at record boundaries). Trying IEBGENER and ICEGENER both result inￜ 013-A8 I think the IBM Sort should do this part. Please try it. all other have a limt on 32k Buffer Spanned records could be more oversize. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Copy RECFM=VBS/LRECL=X to zFS?
Is there an IBM Utility that will do this? Preferrable with FILEDATA=TEXT processing mode on the output file (adding newlines at record boundaries). Trying IEBGENER and ICEGENER both result in 013-A8 -- Kirk Wolf Dovetailed Technologies http://dovetail.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RECFM=VBS,LRECL=X
On Wed, 2 May 2018 23:27:55 +0100, David W Noon wrote: >>> >> Suppose there is no guarantee that every logical record fit in available >> virtual memory? >> >How do you process such a logical record in a finite address space? The >only way I can think of is to segment the record and process it >piecewise. That would require BSAM, since the buffer pool will fit into >memory, and the record segments will be limited in size to fit into a >buffer. > >You then have an issue of related fields not being in the same segment >or not being in segments close enough to have the related fields >accessed concurrently. > Windowing. If it's feasible to choose a segment size large enough that any two related fields fit in no more than two consecutive segments you need only two buffers. Purge the older one; swap the buffers; and read in a newer segment. >I would then feel that the data stream design is flawed. I would want it >normalized, when possible. The problem with that is that many "small >platform" people know little or nothing about normal forms. > Tunnel vision. Some real world data naturally arrive in a featureless stream; no neat separation into segments, records, or blocks. The world won't change to accommodate your preferred design, and you can't intimidate it by using cultural pejoratives such as "many 'small platform' people know little ..." >...[Indeed, it >is mainly DB2 and IMS people who understand it on the mainframe.] The >problem remains if the record layout is already in at least 1NF. > Consider LIGO: https://www.ligo.caltech.edu/ Its data inexorably arrive as a stream. Some amazing science comes from processing that stream. That couldn't have been done if the researchers had spurned those input data because they were in a "flawed design" rather than a normal form. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RECFM=VBS,LRECL=X
On Wed, 2 May 2018 16:43:02 -0500, Paul Gilmartin (000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: RECFM=VBS,LRECL=X" (in <1556897214786710.wa.paulgboulderaim@listserv.ua.edu>): > On Wed, 2 May 2018 22:30:00 +0100, David W Noon wrote: [snip] >> If you are using QSAM, the access method should do it. With RECFM=VBS >> you are required to use move mode processing and QSAM should do the >> buffer management, including reassembling each logical record as it move >> the data to you work area. >> > Suppose there is no guarantee that every logical record fit in available > virtual memory? How do you process such a logical record in a finite address space? The only way I can think of is to segment the record and process it piecewise. That would require BSAM, since the buffer pool will fit into memory, and the record segments will be limited in size to fit into a buffer. You then have an issue of related fields not being in the same segment or not being in segments close enough to have the related fields accessed concurrently. I would then feel that the data stream design is flawed. I would want it normalized, when possible. The problem with that is that many "small platform" people know little or nothing about normal forms. [Indeed, it is mainly DB2 and IMS people who understand it on the mainframe.] The problem remains if the record layout is already in at least 1NF. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RECFM=VBS,LRECL=X
On Wed, 2 May 2018 22:30:00 +0100, David W Noon wrote: >> ... >> I don't recall whether Rexx reassembles spanned records or whether I >> needed to override with RECFM(U) and process the streams myself. > >If you are using QSAM, the access method should do it. With RECFM=VBS >you are required to use move mode processing and QSAM should do the >buffer management, including reassembling each logical record as it move >the data to you work area. > Suppose there is no guarantee that every logical record fit in available virtual memory? >AFAIAA, REXX EXECIO uses QSAM. > >I have processed VBS records using BSAM. It is a bit of a chore ensuring >that the spanning indicator bits in the RDWs are set correctly. > >> I don't know which utilities are sensitive to which BFTEK values. > >I have not seen BFTEK do anything particularly useful. > Thinking further, it might make more sense to allocate a UNIX file as FILEDATA=BINARY, RECFM=VB, LRECL=1028 (arbitrarily). SDB will choose a BLKSIZE and QSAM or BSAM will insert RDWs (every 1024 bytes) and BDWs. gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RECFM=VBS,LRECL=X
On Wed, 2 May 2018 15:27:25 -0500, Kirk Wolf wrote: >> >> RECFM=VBS,LRECL=X would seem natural for processing UNIX files. >> >> Not sure exactly what you mean by "processing". Do you mean as a format >for making a copy of a Unix line-oriented file with a possibly very large >line length? > Yes. Or even non line-oriented. Sometimes scientific data come that way. Decades ago I read of someone who had 200 BPI tapes with no gaps generated by a data acquisition device. (The digital logic to insert gaps would have been too expensive in that era.) He dealt with it by reading it with a non-terminating channel program and writing to a higher density with gaps. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RECFM=VBS,LRECL=X
On Wed, 2 May 2018 14:39:57 -0500, Paul Gilmartin (000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: RECFM=VBS,LRECL=X" (in <7993773034062407.wa.paulgboulderaim@listserv.ua.edu>): > On Wed, 2 May 2018 13:23:21 -0500, Kirk Wolf wrote: > >> Does anyone use this with your z/OS data sets? >> > I've experimented with it. I was semi-pleased to discover that while > BPXWYN rejects LRECL(X) as a syntax error it accepts LRECL(32768) instead. > > I don't recall whether Rexx reassembles spanned records or whether I > needed to override with RECFM(U) and process the streams myself. If you are using QSAM, the access method should do it. With RECFM=VBS you are required to use move mode processing and QSAM should do the buffer management, including reassembling each logical record as it move the data to you work area. AFAIAA, REXX EXECIO uses QSAM. I have processed VBS records using BSAM. It is a bit of a chore ensuring that the spanning indicator bits in the RDWs are set correctly. > I don't know which utilities are sensitive to which BFTEK values. I have not seen BFTEK do anything particularly useful. > RECFM=VBS,LRECL=X would seem natural for processing UNIX files. UNIX files for input? No, these lack BDW and RDW fields and cannot be processed by QSAM as anything other than RECFM=U (or perhaps RECFM=F[B]). If they are text files, you still need to scan the buffer to find the '\n' character that terminates each text record. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RECFM=VBS,LRECL=X
> > > RECFM=VBS,LRECL=X would seem natural for processing UNIX files. > > Not sure exactly what you mean by "processing". Do you mean as a format for making a copy of a Unix line-oriented file with a possibly very large line length? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RECFM=VBS,LRECL=X
On Wed, 2 May 2018 13:23:21 -0500, Kirk Wolf wrote: >Does anyone use this with your z/OS data sets? > I've experimented with it. I was semi-pleased to discover that while BPXWYN rejects LRECL(X) as a syntax error it accepts LRECL(32768) instead. I don't recall whether Rexx reassembles spanned records or whether I needed to override with RECFM(U) and process the streams myself. I don't know which utilities are sensitive to which BFTEK values. RECFM=VBS,LRECL=X would seem natural for processing UNIX files. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RECFM=VBS,LRECL=X
I use to with SMF datasets, now I just let IFASMFDP figure it out with SMS. Lizette > -Original Message- > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of > Kirk Wolf > Sent: Wednesday, May 02, 2018 11:23 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: RECFM=VBS,LRECL=X > > Does anyone use this with your z/OS data sets? > > Kirk Wolf > Dovetailed Technologies > http://dovetail.com > > -- > 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
RECFM=VBS,LRECL=X
Does anyone use this with your z/OS data sets? Kirk Wolf Dovetailed Technologies http://dovetail.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
