Re: Copy RECFM=VBS/LRECL=X to zFS?

[Farley, Peter x23353]

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?

[Paul Gilmartin]

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?

[Farley, Peter x23353]

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?

[Charles Mills]

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?

[Paul Gilmartin]

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?

[Charles Mills]

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?

[Paul Gilmartin]

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?

[Paul Gilmartin]

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?

[Sri h Kolusu]

> 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?

[Kirk Wolf]

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?

[Paul Gilmartin]

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?

[Kirk Wolf]

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?

[Kirk Wolf]

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?

[Paul Gilmartin]

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?

[Charles Mills]

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?

[Sri h Kolusu]

> 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?

[Doug]

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?

[Charles Mills]

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?

[Wolfgang Fritz]

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?

[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

--
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: Copy DSNTYPE=BASIC to DSNTYPE=EXTREQ with LRECL=X

[Mark Jacobs]

I tried to copy a LRECL=X file using ICEGENER, that failed with an Abend 
013-E1, so I assume that DF/Sort can't handle it using SORT FIELDS=COPY.

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com

‐‐‐ Original Message ‐‐‐
On Thursday, August 6, 2020 6:03 PM, David W Noon  
wrote:

> On Thu, 6 Aug 2020 21:47:26 +, Dymoke-bradshaw, Lennie
> lennie_dymokebradshaw...@bmc.com wrote abour Re: Copy DSNTYPE=BASIC to
> DSNTYPE=EXTREQ with LRECL=X:
>
> > Matthew,
> > Each of those will ensure the output data set is extended format. That is 
> > not the issue.
> > The issue is what program do I use to copy the data when LRECL=X.
>
> Have you tried SORT FIELDS=COPY or the like? DF/SORT or Syncsort.
>
> --
>
> Regards,
>
> Dave [RLU #314465]
> ---
> david.w.n...@gmail.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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Copy DSNTYPE=BASIC to DSNTYPE=EXTREQ with LRECL=X

[David W Noon]

On Thu, 6 Aug 2020 21:47:26 +, Dymoke-bradshaw, Lennie
 wrote abour Re: Copy DSNTYPE=BASIC to
DSNTYPE=EXTREQ with LRECL=X:

> Matthew,
> 
> Each of those will ensure the output data set is extended format. That is not 
> the issue. 
> The issue is what program do I use to copy the data when LRECL=X.
Have you tried SORT FIELDS=COPY or the like? DF/SORT or Syncsort.
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
david.w.n...@gmail.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: Copy DSNTYPE=BASIC to DSNTYPE=EXTREQ with LRECL=X

[Dymoke-Bradshaw, Lennie]

Matthew,

Each of those will ensure the output data set is extended format. That is not 
the issue. 
The issue is what program do I use to copy the data when LRECL=X.

Lennie Dymoke-Bradshaw

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Matthew Stitt
Sent: 06 August 2020 20:56
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Copy DSNTYPE=BASIC to DSNTYPE=EXTREQ with LRECL=X

My first thought is to use DSNTYPE on the output DD statement.  Second thought 
is to set up SMS DATACLAS and/or routine to make the output dataset EXTREQ.

Matthew

On Thu, 6 Aug 2020 17:20:12 +, Dymoke-Bradshaw, Lennie 
 wrote:

>Greetings,
>
>My requirement is in the title here.
>
>I want to copy data sets which have a DSNTYPE of BASIC to data sets with a 
>DSNTYPE of EXTREQ (i.e. extended format). However these data sets have LRECL=X 
>(i.e. LRECL larger than 32760).
>
>IDCAMS REPRO will not copy LRECL=X data sets.
>IEBGENER will copy LRECL=X but not if the attributes are different (as in this 
>case).
>
>I need a solution which works at access method level, so no solution using 
>DFSMSdss is acceptable.
>Anyone have any ideas?
>
>Lennie Dymoke-Bradshaw
>Consultant working on contract for BMC Mainframe Services by RSM 
>Partners 'Dance like no one is watching. Encrypt like everyone is.'

--
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 DSNTYPE=BASIC to DSNTYPE=EXTREQ with LRECL=X

[Matthew Stitt]

My first thought is to use DSNTYPE on the output DD statement.  Second thought 
is to set up SMS DATACLAS and/or routine to make the output dataset EXTREQ.

Matthew

On Thu, 6 Aug 2020 17:20:12 +, Dymoke-Bradshaw, Lennie 
 wrote:

>Greetings,
>
>My requirement is in the title here.
>
>I want to copy data sets which have a DSNTYPE of BASIC to data sets with a 
>DSNTYPE of EXTREQ (i.e. extended format). However these data sets have LRECL=X 
>(i.e. LRECL larger than 32760).
>
>IDCAMS REPRO will not copy LRECL=X data sets.
>IEBGENER will copy LRECL=X but not if the attributes are different (as in this 
>case).
>
>I need a solution which works at access method level, so no solution using 
>DFSMSdss is acceptable.
>Anyone have any ideas?
>
>Lennie Dymoke-Bradshaw
>Consultant working on contract for BMC Mainframe Services by RSM Partners
>'Dance like no one is watching. Encrypt like everyone is.'

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Copy DSNTYPE=BASIC to DSNTYPE=EXTREQ with LRECL=X

[Dymoke-Bradshaw, Lennie]

Greetings,

My requirement is in the title here.

I want to copy data sets which have a DSNTYPE of BASIC to data sets with a 
DSNTYPE of EXTREQ (i.e. extended format). However these data sets have LRECL=X 
(i.e. LRECL larger than 32760).

IDCAMS REPRO will not copy LRECL=X data sets.
IEBGENER will copy LRECL=X but not if the attributes are different (as in this 
case).

I need a solution which works at access method level, so no solution using 
DFSMSdss is acceptable.
Anyone have any ideas?

Lennie Dymoke-Bradshaw
Consultant working on contract for BMC Mainframe Services by RSM Partners
'Dance like no one is watching. Encrypt like everyone is.'

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IDCAMS Sysin LRECL GT 80 bytes

[Mark Jacobs]

TIL. Thanks.

Mark Jacobs

Sent from ProtonMail, Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com

‐‐‐ Original Message ‐‐‐
On Thursday, February 6, 2020 9:35 AM, John McKown 
 wrote:

> On Thu, Feb 6, 2020 at 8:23 AM Mark Jacobs <
> 0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote:
>
> > Does IDCAMS work with sysin control cards from a dataset with an lrecl
> > greater than 80 bytes? I've tried datasets with lrecl=240 and 255, and it
> > looks like it's not accepting any operands past column 71.
> > Mark Jacobs
> > Sent from ProtonMail, Swiss-based encrypted
> > email.
> > GPG Public Key -
> > https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com
>
> PARM MARGINS(left-margin,right-margin)
>
> Defaults to 2,72
>
> https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.idai200/parm.htm
>
> -
>
> People in sleeping bags are the soft tacos of the bear world.
> Maranatha! <><
>
> John McKown
>
> 
>
> 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: IDCAMS Sysin LRECL GT 80 bytes

[Allan Staller]

This is documented in the AMS manual.

" Commands can begin at, or to the right of, the left margin. For batch 
processing jobs, the default margins
are 2 and 72.
Commands are separated from their parameters by one or more separators (blanks, 
commas, or
comments). For some parameters, parentheses are used as separators. Comments 
are strings of
characters surrounded by /* and */. Comments can contain any characters except 
*/.

The DCB of SYSIN is not required to be LRECL=80, but, by default IDCAMS will 
only look a columns 2-72"
This implies you can tell IDCAMS to look beyond col 72, but I did not look up 
how to perform such an action.

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mark Jacobs
Sent: Thursday, February 6, 2020 8:23 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: IDCAMS Sysin LRECL GT 80 bytes

[CAUTION: This Email is from outside the Organization. Do not click links or 
open attachments unless you trust the sender.]

Does IDCAMS work with sysin control cards from a dataset with an lrecl greater 
than 80 bytes? I've tried datasets with lrecl=240 and 255, and it looks like 
it's not accepting any operands past column 71.

Mark Jacobs

Sent from 
[ProtonMail](https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotonmail.comdata=02%7C01%7Callan.staller%40HCL.COM%7C50935c89dfba4690676608d7ab1027db%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637165958218420715sdata=ncAM1jRB0UbtbAcY8cJ%2B3QHlI9HlYwjVlDYxNYjyWAs%3Dreserved=0),
 Swiss-based encrypted email.

GPG Public Key - 
https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapi.protonmail.ch%2Fpks%2Flookup%3Fop%3Dget%26search%3Dmarkjacobs%40protonmail.comdata=02%7C01%7Callan.staller%40HCL.COM%7C50935c89dfba4690676608d7ab1027db%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637165958218420715sdata=FQ1Ar03keRXC9NbTL71i71m%2Feg1UTtyB7gX4ZHjUwXg%3Dreserved=0

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::

The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IDCAMS Sysin LRECL GT 80 bytes

[John McKown]

On Thu, Feb 6, 2020 at 8:23 AM Mark Jacobs <
0224d287a4b1-dmarc-requ...@listserv.ua.edu> wrote:

> Does IDCAMS work with sysin control cards from a dataset with an lrecl
> greater than 80 bytes? I've tried datasets with lrecl=240 and 255, and it
> looks like it's not accepting any operands past column 71.
>
> Mark Jacobs
>
> Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted
> email.
>
> GPG Public Key -
> https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com
>
>
PARM MARGINS(left-margin,right-margin)

Defaults to 2,72


https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.idai200/parm.htm

-- 
People in sleeping bags are the soft tacos of the bear world.
Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

IDCAMS Sysin LRECL GT 80 bytes

[Mark Jacobs]

Does IDCAMS work with sysin control cards from a dataset with an lrecl greater 
than 80 bytes? I've tried datasets with lrecl=240 and 255, and it looks like 
it's not accepting any operands past column 71.

Mark Jacobs

Sent from [ProtonMail](https://protonmail.com), Swiss-based encrypted email.

GPG Public Key - 
https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SYNCSORT question: Why error INCOMPATIBLE LRECL usint TRAILER1 but not without?

[Farley, Peter x23353]

Bingo!  Thank you for the help, that did the trick!

I also ditched the "6:" positioning in TRAILER1, I thought that I needed to 
account for the RDW in the TRAILER1 specs, but not so.

Working fine now, many thanks.  Now on to bigger and better things like 
SUBTOTALS . . .  

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David W Noon
Sent: Wednesday, December 18, 2019 6:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SYNCSORT question: Why error INCOMPATIBLE LRECL usint TRAILER1 but 
not without?

EXTERNAL EMAIL

On Wed, 18 Dec 2019 22:28:12 +, Farley, Peter X23353 
 wrote abour SYNCSORT question: Why error 
INCOMPATIBLE LRECL usint TRAILER1 but not without?:

[snip]
> //SORTOUT  DD  DISP=(,CATLG,CATLG),
> // DSN=output-VB-file,
> // UNIT=SYSDA,SPACE=(CYL,(010,010),RLSE),
> //     DSORG=PS,RECFM=VBA,LRECL=045,BLKSIZE=0

Your SORTOUT has a 4-byte RDW, an ASA control character and up to 40 print 
positions in any given logical record.

[snip]
>  TRAILER1=(6:C'TOTALS',4X,TOT=(5,11,ZD),23X),
6 + 4 + 11 + 23 = 44, which is > 40.

I would ditch the 23 trailing spaces.
--


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: SYNCSORT question: Why error INCOMPATIBLE LRECL usint TRAILER1 but not without?

[David W Noon]

On Wed, 18 Dec 2019 22:28:12 +, Farley, Peter X23353
 wrote abour SYNCSORT question: Why error
INCOMPATIBLE LRECL usint TRAILER1 but not without?:

[snip]
> //SORTOUT  DD  DISP=(,CATLG,CATLG),
> // DSN=output-VB-file,
> // UNIT=SYSDA,SPACE=(CYL,(010,010),RLSE),
> // DSORG=PS,RECFM=VBA,LRECL=045,BLKSIZE=0

Your SORTOUT has a 4-byte RDW, an ASA control character and up to 40
print positions in any given logical record.

[snip]
>  TRAILER1=(6:C'TOTALS',4X,TOT=(5,11,ZD),23X),
6 + 4 + 11 + 23 = 44, which is > 40.

I would ditch the 23 trailing spaces.
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
david.w.n...@gmail.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

SYNCSORT question: Why error INCOMPATIBLE LRECL usint TRAILER1 but not without?

[Farley, Peter x23353]

I have a fairly simple sort process where I want to provide a total record 
count at report end and later on I want to add a total of the numeric column of 
data that starts in column 7 of the input file.

When I just sort and reformat the data (input and output files are both 
RECFM=VB) it works just fine.  When I add a TRAILER1 keyword to sum the record 
count column that is added dynamically in the sort control cards I get this 
error:

WER247A  SORTOUT  HAS INCOMPATIBLE LRECL

Can anyone tell me what I am doing wrong here?

Peter

Sample data input (note that the actual input file has a header record with 
binary zeroes in columns 1-3 and a trailer record with X'FF' in those 
positions, neither of which is shown here):

084 XB000116900
084  B000116900
084 XS000116900
084  S000116897
084  S371134140
084  S1
084  B371134140
235 XB013780560
235  B013780560
235  B013780560
235 XB013780560
235 XB195766224
235  B195766224
235  B195766224

Sample output WITHOUT TRAILER1 keyword (note leading space for ASA CC):

 084, ,B,B,002,3712510.40
 084, ,S,S,003,4712510.37
 084, ,B,B,001,0001169.00
 084, ,S,S,001,0001169.00
 235, ,B,B,004,4190935.68
 235, ,B,B,003,2233273.44

JCL and control cards WITH TRAILER1 keyword:

//SUMTRDS  EXEC PGM=SORT,
// PARM='EQUALS,MSGDD=SORTLIST,VLTEST=2,VLTESTI=2' SYNCSORT
//SORTLIST DD  SYSOUT=*
//SORTIN   DD  DISP=SHR,DSN=input-VB-file
//SORTOUT  DD  DISP=(,CATLG,CATLG),
// DSN=output-VB-file,
// UNIT=SYSDA,SPACE=(CYL,(010,010),RLSE),
// DSORG=PS,RECFM=VBA,LRECL=045,BLKSIZE=0
//SYSINDD  *
  SORT FIELDS=(16,03,A,19,3,A),FORMAT=CH
  SUM  FIELDS=(5,11,ZD,22,17,ZD)
  OMIT COND=(16,03,CH,EQ,X'00',OR,
 16,03,CH,EQ,X'FF')
* ADD FIXED COUNTING NUM BETWEEN RDW AND DATA.
  INREC IFTHEN=(WHEN=INIT,BUILD=(1,4,5:C'001',16:5))
  OUTFIL FNAMES=SORTOUT,
 TRAILER1=(6:C'TOTALS',4X,TOT=(5,11,ZD),23X),
 BUILD=(1,4,C' ',16,3,C',',19,1,C',',21,1,C',',21,1,C',',
5,11,C',',22,15,C'.',37,2)
//*

SORT message output with TRAILER1 keyword:

SYSIN :
  SORT FIELDS=(16,03,A,19,3,A),FORMAT=CH
  SUM  FIELDS=(5,11,ZD,22,17,ZD)
  OMIT COND=(16,02,CH,EQ,X'',OR,
 16,02,CH,EQ,X'')
* ADD FIXED COUNTING NUM BETWEEN RDW AND DATA.
  INREC IFTHEN=(WHEN=INIT,BUILD=(1,4,5:C'001',16:5))
* FORMAT ONLY CLI/WI/CXL/B/S, COUNT AND NET
  OUTFIL FNAMES=SORTOUT,
 TRAILER1=(6:C'TOTALS',4X,TOT=(5,11,ZD),23X),
 BUILD=(1,4,C' ',16,3,C',',19,1,C',',21,1,C',',21,1,C',',
5,11,C',',22,15,C'.',37,2)
WER813I  INSTALLATION OPTIONS IN MFX LOAD LIBRARY WILL BE USED
WER276B  SYSDIAG= 3230061, 11212936, 11212936, 10866125
WER164B  65,540K BYTES OF VIRTUAL STORAGE AVAILABLE, MAX REQUESTED,
WER164B 156K BYTES RESERVE REQUESTED, 1,000K BYTES USED
WER146B  24K BYTES OF EMERGENCY SPACE ALLOCATED
WER108I  SORTIN   : RECFM=VB   ; LRECL=  8004; BLKSIZE= 27998
WER073I  SORTIN   : DSNAME=input-VB-file
WER257I  INREC RECORD LENGTH =  8015
WER110I  SORTOUT  : RECFM=VBA  ; LRECL=45; BLKSIZE= 27998
WER074I  SORTOUT  : DSNAME=output-VB-file
WER247A  SORTOUT  HAS INCOMPATIBLE LRECL
WER211B  SYNCSMF  CALLED BY SYNCSORT; RC=

--


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: load library lrecl=??

[Greg Price]

On 2018-09-06 1:41 PM, Brian Westerman wrote:

Apparently some of the libraries shipped by some vendors or at least the 
directions to define them specify RECFM=U,LRECL=256.


Maybe the vendor instruction writers looked at their data sets and 
copied the attributes they saw.


So, I had this TSO command called REVIEW which read PDS directories 
using RECFM=F,LRECL=256,BLKSIZE=256 with QSAM. Years later I noticed 
that it seemed to be setting the LRECL of RECFM=U data sets to 256, 
although I maintain that it did not do that when first developed.


So, with DCB attribute merging, the VTOC entry got zero fields updated 
from the JFCB even though it was only opened for INPUT. Or maybe I added 
a feature which could update the PDS, and it was on these occasions 
which added a non-zero LRECL to the VTOC entry. The result was that my 
RECFM=U data sets processed by this program ended up with LRECL=256.


Whatever the actual details were that caused this update, the 
LRECL-changing phenomenon all went away when I removed the LRECL value 
from the directory-reading DCB. Looking at the source now, it says 
RECFM=F and BLKSIZE=256, but the "problem" as not occurred with this combo.


Once the LRECL is set, it won't go away unless removed by "unnatural" 
means. So maybe someone used this or a similar program on their library 
at some stage.


Cheers,
Greg

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: load library lrecl=??

[Brian Westerman]

Good,

I was hoping that I wasn't missing something.  It does appear to be ignored for 
RECFM=U.

Thanks

Brian



On Thu, 6 Sep 2018 09:04:25 -0400, Steve Smith  wrote:

>LRECL has no meaning for RECFM=U as far as the system goes.  It is recorded
>in the DSCB, but that is all. Anyway, only QSAM ever uses LRECL for any
>dataset.  So there's no good reason for specifying LRECL on a load
>library.  It can default to 0 just fine, because it's meaningless.
>
>As far as directory reading goes, the DCB would need to specify DSORG,
>RECFM, BLKSIZE overrides, and KEYLEN with BSAM; again LRECL is irrelevant.
>For QSAM it would be needed, but letting it default to the DSCB would be
>fatuous.
>
>
>sas
>
>--
>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: load library lrecl=??

[Steve Smith]

LRECL has no meaning for RECFM=U as far as the system goes.  It is recorded
in the DSCB, but that is all. Anyway, only QSAM ever uses LRECL for any
dataset.  So there's no good reason for specifying LRECL on a load
library.  It can default to 0 just fine, because it's meaningless.

As far as directory reading goes, the DCB would need to specify DSORG,
RECFM, BLKSIZE overrides, and KEYLEN with BSAM; again LRECL is irrelevant.
For QSAM it would be needed, but letting it default to the DSCB would be
fatuous.


sas

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: load library lrecl=??

[Paul Gilmartin]

On 2018-09-05, at 21:49:56, Mike Schwab wrote:

> I am guessing the LRECL-256 is handy when reading the directory?
>   
You still need to override to DSORG=PS.

> The loader handles reading the actual programs. 

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: load library lrecl=??

[Mike Schwab]

I am guessing the LRECL-256 is handy when reading the directory?
The loader handles reading the actual programs.
On Wed, Sep 5, 2018 at 10:41 PM Brian Westerman
 wrote:
>
> Hi,
>
> I had an "interesting" conversation today.  Apparently some of the libraries 
> shipped by some vendors or at least the directions to define them specify 
> RECFM=U,LRECL=256.  I had never considered LRECL as an valid option when 
> defining a load library and so always coded RECFM=U,LRECL=0.
>
> Is there any advantage to LRECL=256 that I am missing?
>
> I'm used to seeing load library block sizes in various values, but LRECL I 
> had thought was always a constant.  I looked it up in the IBM manual and the 
> best I can see is that it says that LRECL=0 is "only valid for RECFM=U 
> datasets".  Which doesn't tell me very much or answer the question.
>
> I know that LRECL=256 works, apparently SoftwareAG has shipped their load 
> libraries as RECFM=U,LRECL=256,BLKSIZE=6144 for more years than I have been a 
> systems programmer, but I can't find anywhere where there seem to be any 
> "rules".
>
> Anyone have a answer for this?  Is it possible that for RECFM=U that LRECL is 
> plain old "ignored:?
>
> Brian
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

load library lrecl=??

[Brian Westerman]

Hi,

I had an "interesting" conversation today.  Apparently some of the libraries 
shipped by some vendors or at least the directions to define them specify 
RECFM=U,LRECL=256.  I had never considered LRECL as an valid option when 
defining a load library and so always coded RECFM=U,LRECL=0.

Is there any advantage to LRECL=256 that I am missing?  

I'm used to seeing load library block sizes in various values, but LRECL I had 
thought was always a constant.  I looked it up in the IBM manual and the best I 
can see is that it says that LRECL=0 is "only valid for RECFM=U datasets".  
Which doesn't tell me very much or answer the question.

I know that LRECL=256 works, apparently SoftwareAG has shipped their load 
libraries as RECFM=U,LRECL=256,BLKSIZE=6144 for more years than I have been a 
systems programmer, but I can't find anywhere where there seem to be any 
"rules".

Anyone have a answer for this?  Is it possible that for RECFM=U that LRECL is 
plain old "ignored:?

Brian

--
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

[Paul Gilmartin]

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

[David W Noon]

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

[Paul Gilmartin]

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

[Paul Gilmartin]

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

[David W Noon]

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

[Kirk Wolf]

>
>
> 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

[Paul Gilmartin]

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

[Lizette Koehler]

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

[Kirk Wolf]

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

Re: [EXTERNAL] LRECL=255 vs LRECL=259

[Edward Gould]

> On Nov 16, 2016, at 12:28 PM, Paul Gilmartin 
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
> On Wed, 16 Nov 2016 11:12:53 -0600, Edward Gould wrote:
>> 
>> I think smp (NOTE without the e) was the problem a long time ago.
>> There was a gotcha in that IEBUPDTE does *NOT* support VB records.
>> IBM needed to support VB but their utilities did NOT.
>> IBM then forced the issue of changing clists to FB. BUT by then everyone was 
>> using VB.
>> Even today there is no IBM system utility that supports VB, and IBM 
>> continues to send out FB clists.
>> 
> How is this still a thing!?
> 
> What's a "utility"?  IEBGENER and IEBCOPY and Rexx support VB.  I'd
> substitute "not all" for "no”.
IBM won’t re-open the code for IEBUPDTE its stabilized. Plus it was never 
designed for VB records.
IBM didn’t want to reship the entire member (IEBCOPY) .
This was design issue (architect) of IBM’s 
This has been an issue since day 1 of SMP. IBM its in your corner.

> 
> I'll try to deconstruct this.  255 was the largest record that could be 
> extracted from
> a buffer with the IC; BCTR; EX; MVC cliche. IC can't handle more than 255 and
> LH is undesirable because the RDW might be unaligned, resulting in a 
> specification
> exception.  3120 is probably optimum for some model DASD.
> 
> To Ed J. I'll suggest Postel's law.  Deal with anything the user presents you 
> in
> an existing data set up to 32756.  For a new data set if it's your choice, 
> 255.
> 3120?  SDB?
TSO has been stabalized and won’t (can’t) fix it . Yell at IBM.

> 
> Puzzle:  What's the smallest BLKSIZE that SDB will select for a blocked data
> set on a 3390?  I have an empirical answer, but someone else might find
> a smaller one.
> 
>> There could be a solution that IBM would support VB/FB concatenation.
>> 
> To me, it would be a boon if Rexx supported PDS/UNIX concatenation.
> It usually works, but since it's "unsupported" I can't seek relief in the
> instances when it doesn't.  It's a nuisance to copy EXECs back and
> forth when I use them in both environments.
> 
>> There are several obstacles to doing this and IBM doesn’t (IMO) want to 
>> spend the time to do so.
>> 
> BSAM/QSAM can treat a UNIX file as either VB or FB according to the
> allocation options.
> 
> And SMP/E (but not IEBUPDTE) can deal with VB with GIMDTS.
> 
> And IBM is offering me a fixtest for a problem I reported for the SDSF
> Rexx interface's failing for a SYSIN with RECFM=VB,LRECL=32753.
> 
> -- 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: [EXTERNAL] LRECL=255 vs LRECL=259

[Paul Gilmartin]

On Wed, 16 Nov 2016 11:12:53 -0600, Edward Gould wrote:
>
>I think smp (NOTE without the e) was the problem a long time ago.
>There was a gotcha in that IEBUPDTE does *NOT* support VB records.
>IBM needed to support VB but their utilities did NOT.
>IBM then forced the issue of changing clists to FB. BUT by then everyone was 
>using VB.
>Even today there is no IBM system utility that supports VB, and IBM continues 
>to send out FB clists.
> 
How is this still a thing!?

What's a "utility"?  IEBGENER and IEBCOPY and Rexx support VB.  I'd
substitute "not all" for "no".

I'll try to deconstruct this.  255 was the largest record that could be 
extracted from
a buffer with the IC; BCTR; EX; MVC cliche. IC can't handle more than 255 and
LH is undesirable because the RDW might be unaligned, resulting in a 
specification
exception.  3120 is probably optimum for some model DASD.

To Ed J. I'll suggest Postel's law.  Deal with anything the user presents you in
an existing data set up to 32756.  For a new data set if it's your choice, 255.
3120?  SDB?

Puzzle:  What's the smallest BLKSIZE that SDB will select for a blocked data
set on a 3390?  I have an empirical answer, but someone else might find
a smaller one.

>There could be a solution that IBM would support VB/FB concatenation.
>
To me, it would be a boon if Rexx supported PDS/UNIX concatenation.
It usually works, but since it's "unsupported" I can't seek relief in the
instances when it doesn't.  It's a nuisance to copy EXECs back and
forth when I use them in both environments.

>There are several obstacles to doing this and IBM doesn’t (IMO) want to spend 
>the time to do so.
> 
BSAM/QSAM can treat a UNIX file as either VB or FB according to the
allocation options.

And SMP/E (but not IEBUPDTE) can deal with VB with GIMDTS.

And IBM is offering me a fixtest for a problem I reported for the SDSF
Rexx interface's failing for a SYSIN with RECFM=VB,LRECL=32753.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [EXTERNAL] LRECL=255 vs LRECL=259

[Edward Gould]

> On Nov 16, 2016, at 10:12 AM, Mick Graley  wrote:
> 
> I think Ed might be right here on the SYSGEN option history, however TSO
> EDIT doesn't seem to support it fully these days.
> I have access to 5 very different systems each with different heritage.
> Two of them are >30 years old and will date back to the SYSGEN days, one of
> them I'm not sure of it's age, but the other two are much younger.
> All of them use an FB 80 SYSPROC concatenation except for one of the older
> systems which uses a VB 255 SYSPROC concatenation.
> TSO EDIT creates a VB,255,3120 data set for type CLIST on all the systems
> except for the older FB 80 system, which creates a corrupt FB,80,3120 data
> set. I'm guessing that the original SYSGEN option of FB was copied across
> for this system, but it doesn't look like TSO EDIT fully supports it as
> it's obviously still using variable length edit buffers, but writing full
> FB 80 byte records to the new PDS with the line numbers at the beginning of
> the record rather than in columns 72-80. Here is a transcript of a TSO
> session on the older FB system to demonstrate this:
> 
> READY
> listds temp.clist
> IKJ58503I DATA SET xx.TEMP.CLIST NOT IN CATALOG
> READY
> e temp(hello) cl
> IKJ52320I DATA SET OR MEMBER NOT FOUND, ASSUMED TO BE NEW
> INPUT
> 00010 proc 0
> 00020 write hello mick
> 00030 end
> 00040
> E
> l
> 00010 PROC 0
> 00020 WRITE HELLO MICK
> 00030 END
> IKJ52500I END OF DATA
> end save
—_SNIP
I think smp (NOTE without the e) was the problem a long time ago.
There was a gotcha in that IEBUPDTE does *NOT* support VB records.
IBM needed to support VB but their utilities did NOT.
IBM then forced the issue of changing clists to FB. BUT by then everyone was 
using VB.
Even today there is no IBM system utility that supports VB, and IBM continues 
to send out FB clists.

There could be a solution that IBM would support VB/FB concatenation.

There are several obstacles to doing this and IBM doesn’t (IMO) want to spend 
the time to do so.

Ed

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [EXTERNAL] LRECL=255 vs LRECL=259

[Mick Graley]

I think Ed might be right here on the SYSGEN option history, however TSO
EDIT doesn't seem to support it fully these days.
I have access to 5 very different systems each with different heritage.
Two of them are >30 years old and will date back to the SYSGEN days, one of
them I'm not sure of it's age, but the other two are much younger.
All of them use an FB 80 SYSPROC concatenation except for one of the older
systems which uses a VB 255 SYSPROC concatenation.
TSO EDIT creates a VB,255,3120 data set for type CLIST on all the systems
except for the older FB 80 system, which creates a corrupt FB,80,3120 data
set. I'm guessing that the original SYSGEN option of FB was copied across
for this system, but it doesn't look like TSO EDIT fully supports it as
it's obviously still using variable length edit buffers, but writing full
FB 80 byte records to the new PDS with the line numbers at the beginning of
the record rather than in columns 72-80. Here is a transcript of a TSO
session on the older FB system to demonstrate this:

 READY
listds temp.clist
 IKJ58503I DATA SET xx.TEMP.CLIST NOT IN CATALOG
 READY
e temp(hello) cl
 IKJ52320I DATA SET OR MEMBER NOT FOUND, ASSUMED TO BE NEW
 INPUT
 00010 proc 0
 00020 write hello mick
 00030 end
 00040
 E
l
 00010 PROC 0
 00020 WRITE HELLO MICK
 00030 END
 IKJ52500I END OF DATA
end save
 READY
listds temp.clist
 xx.TEMP.CLIST
 --RECFM-LRECL-BLKSIZE-DSORG
   FB803120PO
 --VOLUMES--
   vv
 READY
print inda(temp.clist(hello)) char

 RECORD SEQUENCE NUMBER - 1

 0010PROC 05...IBMOSVS2
..&&..QS
.

 RECORD SEQUENCE NUMBER - 2

 0020WRITE HELLO MICK..IBMOSVS2
..&&..QS
.

 RECORD SEQUENCE NUMBER - 3

 0030ENDTE HELLO MICK..IBMOSVS2
..&&..QS
.

 IDC0005I NUMBER OF RECORDS PROCESSED WAS 3

 READY

exec temp.clist(hello)

 0010PROC 05 -È--  IBMOSVS2ØØ -- °  - &   Ø&  -  -QS  -

 IKJ56545I THIS STATEMENT HAS AN INVALID SYMBOLIC VARIABLE

 READY



Same member shown in ISPF/PDF browse:
0010PROC 05..È. ..IBMOSVS2
...ØØ°&...Ø&..QS.
0020WRITE HELLO MICK..IBMOSVS2
...ØØ°&...Ø&..QS.
0030ENDTE HELLO MICK..IBMOSVS2
...ØØ°&...Ø&..QS.


As you would expect, editing a new member in an existing FB 80 CLIST data
set works fine and puts the line numbers in the right place.

Interesting stuff!

Cheers,

Mick.


On 16 November 2016 at 04:38, Edward Gould <edgould1...@comcast.net> wrote:

> > On Nov 15, 2016, at 1:16 PM, Dyck, Lionel B. (TRA) <lionel.d...@va.gov>
> wrote:
> >
> > I'm in the 255 camp and just tried a simple experiment.
> >
> > From TSO issue the Edit command:  E T(ABC) CL
> >
> > This opens the old editor on dataset t.clist member abc and after adding
> a few records and saving I checked the dcb which was VB,255,3120
> >
> > Not the ideal blksize but the lrecl is what I expected.
> >
> > hth
> >
>
> Lionel:
>
> At least in mvs 3.8 there was a sysgen macro you could specify FB VB and
> lrecl blksize etc.
> Since system dissapeared I am not sure what the defaults are now days.
>
> Ed
>
> --
> 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: [EXTERNAL] LRECL=255 vs LRECL=259

[Bill Godfrey]

On 2016-11-15 12:16, Dyck, Lionel B. wrote:
> I'm in the 255 camp and just tried a simple experiment.
> 
> From TSO issue the Edit command:  E T(ABC) CL
> 
> This opens the old editor on dataset t.clist member abc and after adding a 
> few records and saving I checked the dcb which was VB,255,3120
> 
> Not the ideal blksize but the lrecl is what I expected.
>
In old TSO EDIT (alias E), 255 is not only the default lrecl for clist data 
sets, it's the maximum.

edit test1 clist new emode lrecl(256)
IKJ52335I INVALID LINE VALUE FOR CLIST, USING 255+
IKJ52335I LINE SIZE FOR CLIST MAY NOT EXCEED 255

edit test1 data new emode lrecl(256)
IKJ52335I INVALID LINE VALUE FOR DATA, USING 80+

IKJ52335I LINE SIZE FOR DATA MAY NOT EXCEED 255 

if PDS member test2.clist(a) exists and the PDS is VB with lrecl 256, EDIT 
can't handle it.
edit test2(a) clist
IKJ52336I 256 INVALID LINE VALUE FOR CLIST DATA SET

That might be the reason why, historically, clist data sets have used lrecl 255 
and not 259, even though they work as 259.

Bill

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LRECL=255 vs LRECL=259

[scott Ford]

Ed,
Lrecl=255 here

Scott

On Tuesday, November 15, 2016, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On 2016-11-15 12:16, Dyck, Lionel B. (TRA) wrote:
> > I'm in the 255 camp and just tried a simple experiment.
> >
> > From TSO issue the Edit command:  E T(ABC) CL
> >
> > This opens the old editor on dataset t.clist member abc and after adding
> a few records and saving I checked the dcb which was VB,255,3120
> >
> > Not the ideal blksize but the lrecl is what I expected.
> >
> It really should use SDB.  Please submit an RFE.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu <javascript:;> 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: [EXTERNAL] LRECL=255 vs LRECL=259

[Paul Gilmartin]

On 2016-11-15 12:16, Dyck, Lionel B. (TRA) wrote:
> I'm in the 255 camp and just tried a simple experiment.
> 
> From TSO issue the Edit command:  E T(ABC) CL
> 
> This opens the old editor on dataset t.clist member abc and after adding a 
> few records and saving I checked the dcb which was VB,255,3120
> 
> Not the ideal blksize but the lrecl is what I expected.
> 
It really should use SDB.  Please submit an RFE.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [EXTERNAL] LRECL=255 vs LRECL=259

[Edward Gould]

> On Nov 15, 2016, at 1:16 PM, Dyck, Lionel B. (TRA) <lionel.d...@va.gov> wrote:
> 
> I'm in the 255 camp and just tried a simple experiment.
> 
> From TSO issue the Edit command:  E T(ABC) CL
> 
> This opens the old editor on dataset t.clist member abc and after adding a 
> few records and saving I checked the dcb which was VB,255,3120
> 
> Not the ideal blksize but the lrecl is what I expected.
> 
> hth
> 

Lionel:

At least in mvs 3.8 there was a sysgen macro you could specify FB VB and lrecl 
blksize etc.
Since system dissapeared I am not sure what the defaults are now days.

Ed

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Old MF shops - was - RE: LRECL=255 vs LRECL=259

[Ed Jaffe]

On 11/15/2016 2:23 PM, Lester, Bob wrote:

HI Ed,

 One more, then I'll go back to lurking

 Was SPAC related to SPIZ?  I seem to remember that SPIZ was Security 
Pacific (something), but then it gets cloudy...


I know of no SPIZ.

When I started there, it was Security Pacific National Bank (SPNB). Then 
they spun off their IT services into a separate entity called Security 
Pacific Automation Corp (SPAC) which serviced SPNB with aspirations to 
possibly service third parties as well.


A couple/few years later they were absorbed by Bank of America (BofA) 
and that was that...


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Old MF shops - was - RE: LRECL=255 vs LRECL=259

[Jesse 1 Robinson]

SPAC was Security Pacific Automation Company, a wholly owned subsidiary of the 
parent corporation. When U.S. banking was (partially) deregulated in the 80s, 
SPAC was set up to contain all of IT, including people, hardware, and software. 
SPAC was then allowed to compete for outside business along the lines of a 
service bureau. In a similar vein, banking business units were allowed to look 
outside for service if they weren't happy with SPAC offerings. 

I don't remember 'SPIZ', but it's plausible that such a unit existed. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lester, Bob
Sent: Tuesday, November 15, 2016 2:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Old MF shops - was - RE: LRECL=255 vs LRECL=259

HI Ed,

One more, then I'll go back to lurking

Was SPAC related to SPIZ?  I seem to remember that SPIZ was Security 
Pacific (something), but then it gets cloudy...

Thanks!
BobL

-Original Message-
From: Lester, Bob
Sent: Tuesday, November 15, 2016 3:12 PM
To: 'IBM Mainframe Discussion List' <IBM-MAIN@LISTSERV.UA.EDU>
Subject: RE: Old MF shops - was - RE: LRECL=255 vs LRECL=259 [ EXTERNAL ]

Hi Ed,

Dang fat fingers!  That should be BofB, or more formally, FNBofB.

Thanks!
BobL

-Original Message-
From: Lester, Bob
Sent: Tuesday, November 15, 2016 3:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Old MF shops - was - RE: LRECL=255 vs LRECL=259 [ EXTERNAL ]

HI Ed,

Does BofA predate BoB?

Sorry, I realize it's not Friday yet, but

Thanks!
BobL

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Tuesday, November 15, 2016 2:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LRECL=255 vs LRECL=259 [ EXTERNAL ]

On 11/15/2016 11:51 AM, Jesse 1 Robinson wrote:
> Ed, you and I shared some of that life at Security Pacific Bank. Too late to 
> check on SPAC now, but my recollection from before I met you until today, I 
> have always used/encountered LRECL 255.

SPAC is one of the places I remember using LRECL=259, but as you say it can't 
be checked now. BofA cannibalized and then decommissioned those systems long 
ago...

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Old MF shops - was - RE: LRECL=255 vs LRECL=259

[Lester, Bob]

HI Ed,

One more, then I'll go back to lurking

Was SPAC related to SPIZ?  I seem to remember that SPIZ was Security 
Pacific (something), but then it gets cloudy...

Thanks!
BobL

-Original Message-
From: Lester, Bob 
Sent: Tuesday, November 15, 2016 3:12 PM
To: 'IBM Mainframe Discussion List' <IBM-MAIN@LISTSERV.UA.EDU>
Subject: RE: Old MF shops - was - RE: LRECL=255 vs LRECL=259 [ EXTERNAL ]

Hi Ed,

Dang fat fingers!  That should be BofB, or more formally, FNBofB.

Thanks!
BobL

-Original Message-
From: Lester, Bob 
Sent: Tuesday, November 15, 2016 3:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Old MF shops - was - RE: LRECL=255 vs LRECL=259 [ EXTERNAL ]

HI Ed,

Does BofA predate BoB?

Sorry, I realize it's not Friday yet, but

Thanks!
BobL

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Tuesday, November 15, 2016 2:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LRECL=255 vs LRECL=259 [ EXTERNAL ]

On 11/15/2016 11:51 AM, Jesse 1 Robinson wrote:
> Ed, you and I shared some of that life at Security Pacific Bank. Too late to 
> check on SPAC now, but my recollection from before I met you until today, I 
> have always used/encountered LRECL 255.

SPAC is one of the places I remember using LRECL=259, but as you say it can't 
be checked now. BofA cannibalized and then decommissioned those systems long 
ago...

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.phoenixsoftware.com_=CwICaQ=huW-Z3760n7oNORvLCN2eJBo4X7nIGCr9Ffht-z0f4k=1KMMjoSvFEwY7ZoooplFIrKcOeeTJVI4X6Bc3o6vdK4=jd9f-0qwkZdGAlNqQsyWuO89ZG9lEzhspx2X-sl1va0=pjROUYXKYMAly0x3r2CPygo1uXzKc5JusL4u3gw4iAY=
 

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

This e-mail transmission may contain information that is proprietary, 
privileged and/or confidential and is intended exclusively for the person(s) to 
whom it is addressed. Any use, copying, retention or disclosure by any person 
other than the intended recipient or the intended recipient's designees is 
strictly prohibited. If you are not the intended recipient or their designee, 
please notify the sender immediately by return e-mail and delete all copies. 
OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or 
disclose the content of all email communications.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Old MF shops - was - RE: LRECL=255 vs LRECL=259

[Lester, Bob]

Hi Ed,

Dang fat fingers!  That should be BofB, or more formally, FNBofB.

Thanks!
BobL

-Original Message-
From: Lester, Bob 
Sent: Tuesday, November 15, 2016 3:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Old MF shops - was - RE: LRECL=255 vs LRECL=259 [ EXTERNAL ]

HI Ed,

Does BofA predate BoB?

Sorry, I realize it's not Friday yet, but

Thanks!
BobL

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Tuesday, November 15, 2016 2:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LRECL=255 vs LRECL=259 [ EXTERNAL ]

On 11/15/2016 11:51 AM, Jesse 1 Robinson wrote:
> Ed, you and I shared some of that life at Security Pacific Bank. Too late to 
> check on SPAC now, but my recollection from before I met you until today, I 
> have always used/encountered LRECL 255.

SPAC is one of the places I remember using LRECL=259, but as you say it can't 
be checked now. BofA cannibalized and then decommissioned those systems long 
ago...

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.phoenixsoftware.com_=CwICaQ=huW-Z3760n7oNORvLCN2eJBo4X7nIGCr9Ffht-z0f4k=1KMMjoSvFEwY7ZoooplFIrKcOeeTJVI4X6Bc3o6vdK4=jd9f-0qwkZdGAlNqQsyWuO89ZG9lEzhspx2X-sl1va0=pjROUYXKYMAly0x3r2CPygo1uXzKc5JusL4u3gw4iAY=
 

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

This e-mail transmission may contain information that is proprietary, 
privileged and/or confidential and is intended exclusively for the person(s) to 
whom it is addressed. Any use, copying, retention or disclosure by any person 
other than the intended recipient or the intended recipient's designees is 
strictly prohibited. If you are not the intended recipient or their designee, 
please notify the sender immediately by return e-mail and delete all copies. 
OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or 
disclose the content of all email communications.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Old MF shops - was - RE: LRECL=255 vs LRECL=259

[Lester, Bob]

HI Ed,

Does BofA predate BoB?

Sorry, I realize it's not Friday yet, but

Thanks!
BobL

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Tuesday, November 15, 2016 2:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: LRECL=255 vs LRECL=259 [ EXTERNAL ]

On 11/15/2016 11:51 AM, Jesse 1 Robinson wrote:
> Ed, you and I shared some of that life at Security Pacific Bank. Too late to 
> check on SPAC now, but my recollection from before I met you until today, I 
> have always used/encountered LRECL 255.

SPAC is one of the places I remember using LRECL=259, but as you say it can't 
be checked now. BofA cannibalized and then decommissioned those systems long 
ago...

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.phoenixsoftware.com_=CwICaQ=huW-Z3760n7oNORvLCN2eJBo4X7nIGCr9Ffht-z0f4k=1KMMjoSvFEwY7ZoooplFIrKcOeeTJVI4X6Bc3o6vdK4=jd9f-0qwkZdGAlNqQsyWuO89ZG9lEzhspx2X-sl1va0=pjROUYXKYMAly0x3r2CPygo1uXzKc5JusL4u3gw4iAY=
 

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

This e-mail transmission may contain information that is proprietary, 
privileged and/or confidential and is intended exclusively for the person(s) to 
whom it is addressed. Any use, copying, retention or disclosure by any person 
other than the intended recipient or the intended recipient's designees is 
strictly prohibited. If you are not the intended recipient or their designee, 
please notify the sender immediately by return e-mail and delete all copies. 
OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or 
disclose the content of all email communications.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LRECL=255 vs LRECL=259

[Ed Jaffe]

On 11/15/2016 11:51 AM, Jesse 1 Robinson wrote:

Ed, you and I shared some of that life at Security Pacific Bank. Too late to 
check on SPAC now, but my recollection from before I met you until today, I 
have always used/encountered LRECL 255.


SPAC is one of the places I remember using LRECL=259, but as you say it 
can't be checked now. BofA cannibalized and then decommissioned those 
systems long ago...


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LRECL=255 vs LRECL=259

[Farley, Peter x23353]

I'll chime in on this.  I regularly use LRECL=259 for private PDS's when they 
need to be VB specifically to get 255 on any line, or to receive JES and other 
report listings where I don’t know the incoming LRECL a priori.

LRECL=255 is probably OK for any of my actual usage, I just prefer 259.

If I were a vendor, I would probably "go along to get along" and use 255 if 
that's what the client(s) want.  Not enough difference to take a firm stand on 
it one way or the other.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Tuesday, November 15, 2016 2:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: LRECL=255 vs LRECL=259

My whole life I have seen variable length CLIST/EXEC libraries allocated 
as RECFM=VB w/LRECL=259. Clearly, the intent was to allow up to 
255-character source lines.

At PSI, we provide the option for customers to allocate our CLIST/EXEC 
libraries either RECFM=FB w/LRECL=80 or RECFM=VB w/LRECL=259. One 
customer claims the industry-standard for RECFM=VB CLIST/EXEC libraries 
is LRECL=255 rather than LRECL=259. LRECL=255 would allow for only 
251-character source lines, which seems rather strange to me.

Of course, my personal observations and experiences provide nothing more 
than anecdotal evidence. Like a man with two watches being unsure of the 
time, I am now unsure if LRECL=259 is widespread practice or if I was 
observing only outliers.

Any insight would be appreciated...

-- 


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: LRECL=255 vs LRECL=259

[Jesse 1 Robinson]

Ed, you and I shared some of that life at Security Pacific Bank. Too late to 
check on SPAC now, but my recollection from before I met you until today, I 
have always used/encountered LRECL 255. I know that limits record data to 251, 
but is there something special in having 4 extra bytes? It's just a custom that 
seems to prevail in most shops that have standardized on VB. 

The big divide is whether to use FB or VB. Since those cannot be concatenated, 
it's a huge and generally irrevocable choice. 

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Tuesday, November 15, 2016 11:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):LRECL=255 vs LRECL=259

My whole life I have seen variable length CLIST/EXEC libraries allocated as 
RECFM=VB w/LRECL=259. Clearly, the intent was to allow up to 255-character 
source lines.

At PSI, we provide the option for customers to allocate our CLIST/EXEC 
libraries either RECFM=FB w/LRECL=80 or RECFM=VB w/LRECL=259. One customer 
claims the industry-standard for RECFM=VB CLIST/EXEC libraries is LRECL=255 
rather than LRECL=259. LRECL=255 would allow for only 251-character source 
lines, which seems rather strange to me.

Of course, my personal observations and experiences provide nothing more than 
anecdotal evidence. Like a man with two watches being unsure of the time, I am 
now unsure if LRECL=259 is widespread practice or if I was observing only 
outliers.

Any insight would be appreciated...

-- 

Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LRECL=255 vs LRECL=259

[Gord Tomlin]

I've never seen LRECL=259 in my life...well, until now!

--

Regards, Gord Tomlin
Action Software International
(a division of Mazda Computer Corporation)
Tel: (905) 470-7113, Fax: (905) 470-6507

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LRECL=255 vs LRECL=259

[Paul Gilmartin]

On Tue, 15 Nov 2016 14:11:55 -0500, Tony Harminc wrote:
>
>But does it matter much? Concatenating or copying between VB 255 and
>VB 259 should "just work" in almost all cases, whereas trying to mix &
>match either of those with FB 80 is trouble.
>
In JCL, I use DISP=NEW,LRECL=222,BLKSIZE=SDB.  Ergonomic; least
hand motion.  If I needed more, I'd use 333.

ISPF used to have the 255 limit.  No longer AFAIK.  Old phobias
die hard.

And UNIX files are wonderful.  Whatever attributes you specify
in the DCB, the access method makes them look that way.  It
should have ever been thus so you could mix FB and VB simply
by overriding the DCB in JCL.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LRECL=255 vs LRECL=259

[Paul Gilmartin]

On Tue, 15 Nov 2016 10:59:43 -0800, Ed Jaffe wrote:
>
>At PSI, we provide the option for customers to allocate our CLIST/EXEC
>libraries either RECFM=FB w/LRECL=80 or RECFM=VB w/LRECL=259. One
>customer claims the industry-standard for RECFM=VB CLIST/EXEC libraries
>is LRECL=255 rather than LRECL=259. LRECL=255 would allow for only
>251-character source lines, which seems rather strange to me.
>
Why limit them at all?  Why not "whatever they want?"

It should matter little.  Nowadays (at last!) in a concatenation the largest
value prevails (or is that only for BLKSIZE?)

And if you need a larger member in a PDS, just copy it in with overriding
LRECL which sticks in the DSCB.

What was R.S. trying to tell me?  That at least it's not an undocumented
limitation?  I see nothing relevant in SG24-6106 (but what keywords?)

One of these days, I need to RFE for support of UNIX files in SYSEXEC
concatenation.  It works, sort of, but since it's unsupported an SR
is pointless.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [EXTERNAL] LRECL=255 vs LRECL=259

[Ed Jaffe]

On 11/15/2016 11:16 AM, Dyck, Lionel B. (TRA) wrote:

I'm in the 255 camp and just tried a simple experiment.

 From TSO issue the Edit command:  E T(ABC) CL

This opens the old editor on dataset t.clist member abc and after adding a few 
records and saving I checked the dcb which was VB,255,3120

Not the ideal blksize but the lrecl is what I expected.

hth


Thanks, Lionel!

TSO EDIT allocating (by default) LRECL=255 is enough evidence to suggest 
to me that LRECL=255 is the way to go.


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [EXTERNAL] LRECL=255 vs LRECL=259

[Dyck, Lionel B. (TRA)]

I'm in the 255 camp and just tried a simple experiment.

From TSO issue the Edit command:  E T(ABC) CL

This opens the old editor on dataset t.clist member abc and after adding a few 
records and saving I checked the dcb which was VB,255,3120

Not the ideal blksize but the lrecl is what I expected.

hth

--
Lionel B. Dyck (TRA Contractor)
Mainframe Systems Programmer 
Enterprise Infrastructure Support (Station 200) (005OP6.3.10)

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Tuesday, November 15, 2016 1:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] LRECL=255 vs LRECL=259

My whole life I have seen variable length CLIST/EXEC libraries allocated as 
RECFM=VB w/LRECL=259. Clearly, the intent was to allow up to 255-character 
source lines.

At PSI, we provide the option for customers to allocate our CLIST/EXEC 
libraries either RECFM=FB w/LRECL=80 or RECFM=VB w/LRECL=259. One customer 
claims the industry-standard for RECFM=VB CLIST/EXEC libraries is LRECL=255 
rather than LRECL=259. LRECL=255 would allow for only 251-character source 
lines, which seems rather strange to me.

Of course, my personal observations and experiences provide nothing more than 
anecdotal evidence. Like a man with two watches being unsure of the time, I am 
now unsure if LRECL=259 is widespread practice or if I was observing only 
outliers.

Any insight would be appreciated...

-- 

Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.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: LRECL=255 vs LRECL=259

[Richards, Robert B.]

Put me in the 255 camp. I've never seen a 259 LRECL

I not sure if I ever got close to using 251/255 anyway, even indenting by two 
for all Do/End, Select/When, If/Else statements and four or five levels of 
nesting! :-)

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Tuesday, November 15, 2016 2:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: LRECL=255 vs LRECL=259

My whole life I have seen variable length CLIST/EXEC libraries allocated as 
RECFM=VB w/LRECL=259. Clearly, the intent was to allow up to 255-character 
source lines.

At PSI, we provide the option for customers to allocate our CLIST/EXEC 
libraries either RECFM=FB w/LRECL=80 or RECFM=VB w/LRECL=259. One customer 
claims the industry-standard for RECFM=VB CLIST/EXEC libraries is LRECL=255 
rather than LRECL=259. LRECL=255 would allow for only 251-character source 
lines, which seems rather strange to me.

Of course, my personal observations and experiences provide nothing more than 
anecdotal evidence. Like a man with two watches being unsure of the time, I am 
now unsure if LRECL=259 is widespread practice or if I was observing only 
outliers.

Any insight would be appreciated...

-- 

Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.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: LRECL=255 vs LRECL=259

[Tony Harminc]

On 15 November 2016 at 13:59, Ed Jaffe <edja...@phoenixsoftware.com> wrote:
> Of course, my personal observations and experiences provide nothing more
> than anecdotal evidence. Like a man with two watches being unsure of the
> time, I am now unsure if LRECL=259 is widespread practice or if I was
> observing only outliers.

My 40ish years of anecdotal evidence suggests 255.

But does it matter much? Concatenating or copying between VB 255 and
VB 259 should "just work" in almost all cases, whereas trying to mix &
match either of those with FB 80 is trouble.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: LRECL=255 vs LRECL=259

[Roach, Dennis]

I have only seen fb80 and vb255. Never saw vb259.

Dennis Roach, CISSP, PMP
AIG
IAM Access Administration – Infrastructure | Identity & Access Management

2929 Allen Parkway, America Building, 3rd Floor | Houston, TX 77019
Phone:  713-831-8799

dennis.ro...@aig.com | www.aig.com 


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Ed Jaffe
Sent: Tuesday, November 15, 2016 1:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: LRECL=255 vs LRECL=259

My whole life I have seen variable length CLIST/EXEC libraries allocated as 
RECFM=VB w/LRECL=259. Clearly, the intent was to allow up to 255-character 
source lines.

At PSI, we provide the option for customers to allocate our CLIST/EXEC 
libraries either RECFM=FB w/LRECL=80 or RECFM=VB w/LRECL=259. One customer 
claims the industry-standard for RECFM=VB CLIST/EXEC libraries is LRECL=255 
rather than LRECL=259. LRECL=255 would allow for only 251-character source 
lines, which seems rather strange to me.

Of course, my personal observations and experiences provide nothing more than 
anecdotal evidence. Like a man with two watches being unsure of the time, I am 
now unsure if LRECL=259 is widespread practice or if I was observing only 
outliers.

Any insight would be appreciated...

-- 

Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.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

LRECL=255 vs LRECL=259

[Ed Jaffe]

My whole life I have seen variable length CLIST/EXEC libraries allocated 
as RECFM=VB w/LRECL=259. Clearly, the intent was to allow up to 
255-character source lines.


At PSI, we provide the option for customers to allocate our CLIST/EXEC 
libraries either RECFM=FB w/LRECL=80 or RECFM=VB w/LRECL=259. One 
customer claims the industry-standard for RECFM=VB CLIST/EXEC libraries 
is LRECL=255 rather than LRECL=259. LRECL=255 would allow for only 
251-character source lines, which seems rather strange to me.


Of course, my personal observations and experiences provide nothing more 
than anecdotal evidence. Like a man with two watches being unsure of the 
time, I am now unsure if LRECL=259 is widespread practice or if I was 
observing only outliers.


Any insight would be appreciated...

--

Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMF LRECL (was Re: SCRT input from z/OS 1.12 and 2.2)

[Vernooij, CP (ITOPT1) - KLM]

I am surprised about what you and others reply, when I am referring to the 
discovery of America by Christoffel Columbus in 1492. And to my surprise there 
is actually no real article in the English and other Wikipedias about at, but 
an extensive one in the Dutch and German versions.

Anyway, in Columbus' time, the church and other leaders said that the earth was 
flat and therefor it was the truth and if you sailed to the end, you would fall 
off. There were scientists that already knew/believed the earth was round and 
for that reason Columbus tried to find an easier and shorter way to the Indies 
by sailing west i.s.o. east and all the way around Cape Town.

That is what I meant when I said, if we all obeyed the rules, we (Columbus) 
would never have discovered America. Of course others have discovered the 
continent already before him, but that was unknown at that time.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: 13 April, 2016 16:56
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMF LRECL (was Re: SCRT input from z/OS 1.12 and 2.2)

On Wed, 13 Apr 2016 03:01:12 -0500, Elardus Engelbrecht wrote:

>Vernooij, CP (ITOPT1) - KLM wrote:
>
>>I was actually referring to Columbus, sailing to the west in order to find a 
>>shorter way to the Indies, in spite of the 'rule' that he would reach the end 
>>of earth and fall off.
> 
That "rule" was a fiction invented by Washington Irving according to a 
Scientific
American article circa October, 1992.  It was known for millennia that the earth
is spherical and there were respectable estimates of its size.

>Of course I later read some of those Terry Pratchet parodies, something about 
>a world sitting on giant elephants, all supported by a turtle.
> 
Traditional Hindu mythology.  What are the Dutch mythologies?

https://xkcd.com/1498/


On Wed, 13 Apr 2016 01:05:00 -0500, Elardus Engelbrecht wrote:
>
>I was "raised and trained" to have all my SMF datasets to be of one LRECL, 
>usually 32760 or 32767 simply to avoid such nice abends later. Why can you 
>have different LRECLs for the SMF data as input [1]? Is there a reason (beside 
>device geometry) why you need different LRECLs for your SMF records?
> 
32767?  But 32768 is a useful argument to BPXWDYN.  Nowadays in a concatenation
the greatest LRECL dominates.

-- gil
 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMF LRECL (was Re: SCRT input from z/OS 1.12 and 2.2)

[Paul Gilmartin]

On Wed, 13 Apr 2016 03:01:12 -0500, Elardus Engelbrecht wrote:

>Vernooij, CP (ITOPT1) - KLM wrote:
>
>>I was actually referring to Columbus, sailing to the west in order to find a 
>>shorter way to the Indies, in spite of the 'rule' that he would reach the end 
>>of earth and fall off.
> 
That "rule" was a fiction invented by Washington Irving according to a 
Scientific
American article circa October, 1992.  It was known for millennia that the earth
is spherical and there were respectable estimates of its size.

>Of course I later read some of those Terry Pratchet parodies, something about 
>a world sitting on giant elephants, all supported by a turtle.
> 
Traditional Hindu mythology.  What are the Dutch mythologies?

https://xkcd.com/1498/


On Wed, 13 Apr 2016 01:05:00 -0500, Elardus Engelbrecht wrote:
>
>I was "raised and trained" to have all my SMF datasets to be of one LRECL, 
>usually 32760 or 32767 simply to avoid such nice abends later. Why can you 
>have different LRECLs for the SMF data as input [1]? Is there a reason (beside 
>device geometry) why you need different LRECLs for your SMF records?
> 
32767?  But 32768 is a useful argument to BPXWDYN.  Nowadays in a concatenation
the greatest LRECL dominates.

-- gil


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMF LRECL (was Re: SCRT input from z/OS 1.12 and 2.2)

[Elardus Engelbrecht]

Vernooij, CP (ITOPT1) - KLM wrote:

>I was actually referring to Columbus, sailing to the west in order to find a 
>shorter way to the Indies, in spite of the 'rule' that he would reach the end 
>of earth and fall off.

Reminds me of that little tongue-in-cheek club 'Flat Earth' ran by us young 
guys in school and student dorms.

Boosted by lots of booze, we have listed reasons [1] why the earth was really 
really flat, pancake flat, not round. Posters with those 'reasons' were placed, 
but teared off by concerned adults thinking a weird cult has been brewing 
somewhere...  ;-)

Of course I later read some of those Terry Pratchet parodies, something about a 
world sitting on giant elephants, all supported by a turtle.

;-D

Groete / Greetings
Elardus Engelbrecht

[1] - I wish I kept those funny 'reasons' for archival retrieval later, but I 
remember that we were really worried about the beer vats which will reach the 
end and then fall off without being emptied out by us... LOL

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMF LRECL (was Re: SCRT input from z/OS 1.12 and 2.2)

[Vernooij, CP (ITOPT1) - KLM]

I was actually referring to Columbus, sailing to the west in order to find a 
shorter way to the Indies, in spite of the 'rule' that he would reach the end 
of earth and fall off.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Edward Finnell
Sent: 13 April, 2016 9:19
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: SMF LRECL (was Re: SCRT input from z/OS 1.12 and 2.2)

The History Channel had a piece on Jamestown excavation. It seems their  
first mission was to find a dependable source of sassafras a curative for  
syphilis which was rampant.
 
 
In a message dated 4/13/2016 1:26:36 A.M. Central Daylight Time,  
kees.verno...@klm.com writes:

Well  anyway, this is why we discovered America  though.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMF LRECL (was Re: SCRT input from z/OS 1.12 and 2.2)

[Edward Finnell]

The History Channel had a piece on Jamestown excavation. It seems their  
first mission was to find a dependable source of sassafras a curative for  
syphilis which was rampant.
 
 
In a message dated 4/13/2016 1:26:36 A.M. Central Daylight Time,  
kees.verno...@klm.com writes:

Well  anyway, this is why we discovered America  though.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: SMF LRECL (was Re: SCRT input from z/OS 1.12 and 2.2)

[Vernooij, CP (ITOPT1) - KLM]

If it is not explicitly forbidden (and even then still) there will always be 
people that try it.
Well anyway, this is why we discovered America though.

Kees.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Elardus Engelbrecht
Sent: 13 April, 2016 8:05
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: SMF LRECL (was Re: SCRT input from z/OS 1.12 and 2.2)

Al Sherkow wrote:

>Today, 12 April 2016, a new release of the JAVA version of SCRT, now 23.13.2 
>came out. One of the fixes resolves this issue: "This mod-level release fixes 
>an ABEND S02 when using multiple SMF datasets having different LRECLs."

I was "raised and trained" to have all my SMF datasets to be of one LRECL, 
usually 32760 or 32767 simply to avoid such nice abends later. Why can you have 
different LRECLs for the SMF data as input [1]? Is there a reason (beside 
device geometry) why you need different LRECLs for your SMF records?

Groete / Greetings
Elardus Engelbrecht

[1] - All my SMF reading programs obtain the DCB details as they are from the 
dataset attributes. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

SMF LRECL (was Re: SCRT input from z/OS 1.12 and 2.2)

[Elardus Engelbrecht]

Al Sherkow wrote:

>Today, 12 April 2016, a new release of the JAVA version of SCRT, now 23.13.2 
>came out. One of the fixes resolves this issue: "This mod-level release fixes 
>an ABEND S02 when using multiple SMF datasets having different LRECLs."

I was "raised and trained" to have all my SMF datasets to be of one LRECL, 
usually 32760 or 32767 simply to avoid such nice abends later. Why can you have 
different LRECLs for the SMF data as input [1]? Is there a reason (beside 
device geometry) why you need different LRECLs for your SMF records?

Groete / Greetings
Elardus Engelbrecht

[1] - All my SMF reading programs obtain the DCB details as they are from the 
dataset attributes.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Lrecl

[Clark Morris]

On 28 Nov 2015 11:50:44 -0800, in bit.listserv.ibm-main you wrote:

>All:
>
>Our STC use several files and I want to verify that the files have the
>correct logical record length. The STCs are written LE Cobol.
>I would like to know before I open the file if the file that is created or
>allocated is correct in record length. For example, if the Logical Record
>Length is 121 as defined in the program tries to open a file with a LRECL
>300 bytes. Can i do the following ?

It is simple.  Assign a status code (2 bytes) to any file you want to
check and then check the status code after ALL I-O operations for the
file.  The status codes and their meanings are in the COBOL manual.
Status codes 00 and 97 are the only codes I normally accept on open.
One of the status codes returned on open is for wrong length record.
The presence of a status code on the SELECT statement for a file means
that the default error handling is bypassed.

CLark Morris
>
>1. Call a Assembler subroutine using RDJFCB and determine the lrecl on the
>volume for the dataset and allocation ?
>2. If the lrecl i want to pass back a RTNCD in R15 and then then have Cobol
>fail 
>
>
>Regards,
>Scott
>
>--
>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: Lrecl

[Frank Swarbrick]

> Date: Sun, 29 Nov 2015 05:26:26 -0600
> From: elardus.engelbre...@sita.co.za
> Subject: Re: Lrecl
> To: IBM-MAIN@LISTSERV.UA.EDU
> 
> Paul Gilmartin  wrote:
> 
> >I don't know how much of this is supported by COBOL except that coding BLOCK 
> >CONTAINS 0 RECORDS allows SDB to operate.  Omitting the BLOCK CONTAINS 
> >clause is equivalent to coding BLOCK CONTAINS 1 RECORD(S). A supremely 
> >stupid default except, perhaps, in that it supports unit record devices.
> 
> True. I don't like that, but have accepted do it the 'COBOL way'. G.
> 
> So, I always include that BLOCK CONTAINS clause. 

Enterprise COBOL 4.2 (I believe) added support for the BLOCK0 compiler option 
(my RFE!), which causes "BLOCK CONTAINS 0" to be the default if the BLOCK 
CONTAINS clause is omitted.

Use it.  Love it.  If I recall correctly, "BLOCK0" is actually how the COBOL 
standard is defined.  NOBLOCK0 is still the default for "backwards 
compatibility" reasons.  So it might be more appropriate to refer to the "BLOCK 
CONTAINS 1" default as "the IBM way", not "the COBOL way".  :-)

Frank



  
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Lrecl

[Paul Gilmartin]

On Sun, 29 Nov 2015 13:20:01 -0500, Shmuel Metz (Seymour J.) wrote:

> on 11/28/2015 at 08:21 PM, Paul Gilmartin
>
>>A supremely stupid default except, perhaps, in that it supports unit
>>record devices.
>
>A DCB OPEN exit would have supported UR eqipment and not have been so
>rigid.
> 
Indeed so, but that would have required making that exit device type savvy,
tantamount to imbedding SDB in COBOL, which would have been the wrong
place.  Wherever SDB finally landed is a better place.

Yet, it's regrettable that not even a rudimentary SDB was supplied in OS/360
ab ovo.  I suppose resource constraints forbade.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Lrecl

[Shmuel Metz (Seymour J.)]

In <1806999179817213.wa.paulgboulderaim@listserv.ua.edu>, on
11/28/2015
   at 08:21 PM, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> said:

>A supremely stupid default except, perhaps, in that it supports unit
>record devices.

A DCB OPEN exit would have supported UR eqipment and not have been so
rigid.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Lrecl

[Elardus Engelbrecht]

Paul Gilmartin  wrote:

>Long ago I dealt with this problem in Assembler.  I left LRECL=0 in the DCB.  
>It would be merged in from either the DSCB or JCL, JCL dominating. I took the 
>DCB OPEN exit.  If the value was still 0, unavailable from either of those 
>sources, I supplied a default LRECL; likewise for BLKSIZE and RECFM.  
>Nowadays, SDB gets control last and supplies its default.   

Good approach, but I prefer to a$$ume that LRECL is fixed and known and then 
let the system abend the job if an incorrect LRECL is used. But then it is just 
me.


>I don't know how much of this is supported by COBOL except that coding BLOCK 
>CONTAINS 0 RECORDS allows SDB to operate.  Omitting the BLOCK CONTAINS clause 
>is equivalent to coding BLOCK CONTAINS 1 RECORD(S). A supremely stupid default 
>except, perhaps, in that it supports unit record devices.

True. I don't like that, but have accepted do it the 'COBOL way'. G.

So, I always include that BLOCK CONTAINS clause. 


(from Shmuel) 
>>3. If it's a concatenation, test whether LRECL and RECFM are the same in 
>>every dataset. See ARL, probably in the RDJFCB documentation.

Hmmm, I really need to RTFM on that. Interesting. Thanks Shmuel!


>If RECFM=V* you may reasonably override to a larger value of LRECL;

Including VBS (spanned records) too?


>if RECFM=F* it's inadvisable to try to change LRECL.

Yup. You get some nice abends for that change. Easy to fix all values to an 
expected LRECL value, but it depends on what you as programmer expects.


Note: DFSORT has some clever magic tricks to figure out the LRECL, RECFM, DSORG 
of input data I wish I can see how that is done...

Paul, thanks for your notes. It is very interesting! ;-)

Groete / Greetings
Elardus Engelbrecht

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Lrecl

[Norbert Friemel]

On Sun, 29 Nov 2015 05:26:26 -0600, Elardus Engelbrecht wrote:

>
>>I don't know how much of this is supported by COBOL except that coding BLOCK 
>>CONTAINS 0 RECORDS allows SDB to operate.  Omitting the BLOCK CONTAINS clause 
>>is equivalent to coding BLOCK CONTAINS 1 RECORD(S). A supremely stupid 
>>default except, perhaps, in that it supports unit record devices.
>
>True. I don't like that, but have accepted do it the 'COBOL way'. G.
>
>So, I always include that BLOCK CONTAINS clause. 
>
>

... or use the BLOCK0 compiler option in COBOL 4.2 and later: 
http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/igy3cg50/2.11
http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/igy3pg50/2.4.7

Norbert Friemel

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Lrecl

[Paul Gilmartin]

On Sun, 29 Nov 2015 05:26:26 -0600, Elardus Engelbrecht wrote:
>
>>Long ago I dealt with this problem in Assembler.  I left LRECL=0 in the DCB.  
>>It would be merged in from either the DSCB or JCL, JCL dominating. I took the 
>>DCB OPEN exit.  If the value was still 0, unavailable from either of those 
>>sources, I supplied a default LRECL; likewise for BLKSIZE and RECFM.  
>>Nowadays, SDB gets control last and supplies its default.   
>
>Good approach, but I prefer to a$$ume that LRECL is fixed and known and then 
>let the system abend the job if an incorrect LRECL is used. But then it is 
>just me.
> 
I will take little credit/responsibility; I was a novice and had intense 
mentoring.

It was in a runtime library for a FOSS (almost; there were some amusing license
clauses) Pascal system.  Many HLLs have similar behaviors.  Rexx, for example
supplies default but not overriding values of RECFM and LRECL.  It used to
supply a default BLKSIZE but that was changed by APAR to allow SDB to
operate.  That actually broke some code (mine and others') because the oldest
SDB sometimes chose a BLKSIZE incompatible with explicitly coded LRECL.
That also was fixed by APAR, but IBM support recommended that I *always*
code BLKSIZE -- an ironic consequence of the introduction of SDB.

Many IBM utilities not only supply defaults but even override explicitly coded
values of DCB attributes, especially for SYSIN and SYSPRINT.  I once had a
RECFM=VB PDS corrupted when a user allocated an assembler SYSPRINT to
one of its members.  I changed it back, recovering most of the members and
leaving it broken for the offender.

>>If RECFM=V* you may reasonably override to a larger value of LRECL;
> 
(Unless a client QSAM program has a fixed buffer size coded.)

>Including VBS (spanned records) too?
>
I'd hesitate to change anything else to RECFM=32768 (LRECL=X).  Rexx lately
accommodates VBS but not 32768.

>
>>if RECFM=F* it's inadvisable to try to change LRECL.
>
>Yup. You get some nice abends for that change. Easy to fix all values to an 
>expected LRECL value, but it depends on what you as programmer expects.
> 
Particularly writing to a PDS or MOD to a PS.


>Note: DFSORT has some clever magic tricks to figure out the LRECL, RECFM, 
>DSORG of input data I wish I can see how that is done...
> 
Frequently, any submission to this forum that mentions DFSORT or ICETOOL
elicits a very expert followupl

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Lrecl

[Charles Mills]

Of course, there are a bunch of cases to deal with. Output and input to begin 
with. Then the two annoying cases that are kind of a combination of input and 
output: MOD is the obvious one, but the other is a new member of an existing 
PDS(E).

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Saturday, November 28, 2015 12:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Lrecl

One possible approach is to open a DCB with LRECL=0 in assembler and see what 
you get. That is the result of the merge of what is in the DSCB + what is in 
the allocation (JCL or SVC 99). It is probably the simplest, best picture.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Lrecl

[Scott Ford]

All:

Our STC use several files and I want to verify that the files have the
correct logical record length. The STCs are written LE Cobol.
I would like to know before I open the file if the file that is created or
allocated is correct in record length. For example, if the Logical Record
Length is 121 as defined in the program tries to open a file with a LRECL
300 bytes. Can i do the following ?

1. Call a Assembler subroutine using RDJFCB and determine the lrecl on the
volume for the dataset and allocation ?
2. If the lrecl i want to pass back a RTNCD in R15 and then then have Cobol
fail 


Regards,
Scott

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Lrecl

[Charles Mills]

One possible approach is to open a DCB with LRECL=0 in assembler and see what 
you get. That is the result of the merge of what is in the DSCB + what is in 
the allocation (JCL or SVC 99). It is probably the simplest, best picture.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Saturday, November 28, 2015 12:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Lrecl

I don't know the full answer to your question for certain but I do know that 
RDJFCB will not generally give you the true LRECL of a dataset. I believe it 
will only give you whatever LRECL is coded in the JCL (or, presumably, the 
equivalent SVC 99) if any. So if the dataset is recorded with an LRECL 300, 
then if the JCL user codes DD ...,LRECL=121,... then the JFCB LRECL will 
contain 121. If the user omits the LRECL from the DD then it will contain 0. 
There is no mapping from dataset to JFCB, at least not before the OPEN.

I am trying to recall if SVC 99 info retrieval will do this. I think perhaps 
you have to use OBTAIN and CAMLST to read the VTOC DSCB.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Scott Ford
Sent: Saturday, November 28, 2015 11:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Lrecl

All:

Our STC use several files and I want to verify that the files have the correct 
logical record length. The STCs are written LE Cobol.
I would like to know before I open the file if the file that is created or 
allocated is correct in record length. For example, if the Logical Record 
Length is 121 as defined in the program tries to open a file with a LRECL
300 bytes. Can i do the following ?

1. Call a Assembler subroutine using RDJFCB and determine the lrecl on the 
volume for the dataset and allocation ?
2. If the lrecl i want to pass back a RTNCD in R15 and then then have Cobol 
fail 

--
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: Lrecl

[Charles Mills]

I don't know the full answer to your question for certain but I do know that 
RDJFCB will not generally give you the true LRECL of a dataset. I believe it 
will only give you whatever LRECL is coded in the JCL (or, presumably, the 
equivalent SVC 99) if any. So if the dataset is recorded with an LRECL 300, 
then if the JCL user codes DD ...,LRECL=121,... then the JFCB LRECL will 
contain 121. If the user omits the LRECL from the DD then it will contain 0. 
There is no mapping from dataset to JFCB, at least not before the OPEN.

I am trying to recall if SVC 99 info retrieval will do this. I think perhaps 
you have to use OBTAIN and CAMLST to read the VTOC DSCB.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Scott Ford
Sent: Saturday, November 28, 2015 11:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Lrecl

All:

Our STC use several files and I want to verify that the files have the correct 
logical record length. The STCs are written LE Cobol.
I would like to know before I open the file if the file that is created or 
allocated is correct in record length. For example, if the Logical Record 
Length is 121 as defined in the program tries to open a file with a LRECL
300 bytes. Can i do the following ?

1. Call a Assembler subroutine using RDJFCB and determine the lrecl on the 
volume for the dataset and allocation ?
2. If the lrecl i want to pass back a RTNCD in R15 and then then have Cobol 
fail 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Lrecl

[Scott Ford]

Charles,

That also dawned on me while I typed the question..
Scott

On Sat, Nov 28, 2015 at 3:08 PM, Charles Mills <charl...@mcn.org> wrote:

> I don't know the full answer to your question for certain but I do know
> that RDJFCB will not generally give you the true LRECL of a dataset. I
> believe it will only give you whatever LRECL is coded in the JCL (or,
> presumably, the equivalent SVC 99) if any. So if the dataset is recorded
> with an LRECL 300, then if the JCL user codes DD ...,LRECL=121,... then the
> JFCB LRECL will contain 121. If the user omits the LRECL from the DD then
> it will contain 0. There is no mapping from dataset to JFCB, at least not
> before the OPEN.
>
> I am trying to recall if SVC 99 info retrieval will do this. I think
> perhaps you have to use OBTAIN and CAMLST to read the VTOC DSCB.
>
> Charles
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Scott Ford
> Sent: Saturday, November 28, 2015 11:51 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Lrecl
>
> All:
>
> Our STC use several files and I want to verify that the files have the
> correct logical record length. The STCs are written LE Cobol.
> I would like to know before I open the file if the file that is created or
> allocated is correct in record length. For example, if the Logical Record
> Length is 121 as defined in the program tries to open a file with a LRECL
> 300 bytes. Can i do the following ?
>
> 1. Call a Assembler subroutine using RDJFCB and determine the lrecl on the
> volume for the dataset and allocation ?
> 2. If the lrecl i want to pass back a RTNCD in R15 and then then have
> Cobol fail 
>
> --
> 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: Lrecl

[Shmuel Metz (Seymour J.)]

In
<ca+qm75-bmt-wtvquyx6q1dkqrquhlu7mgm2pwie4v631yq2...@mail.gmail.com>,
on 11/28/2015
   at 02:50 PM, Scott Ford <idfzos...@gmail.com> said:

>Our STC use several files and I want to verify that the files have
>the correct logical record length. The STCs are written LE Cobol. I
>would like to know before I open the file if the file that is created
>or allocated is correct in record length. For example, if the Logical
>Record Length is 121 as defined in the program tries to open a file
>with a LRECL 300 bytes. Can i do the following ?

>1. Call a Assembler subroutine using RDJFCB and determine the lrecl
>on the volume for the dataset and allocation ?
>2. If the lrecl i want to pass back a RTNCD in R15 and then then have
>Cobol fail 

3. If it's a concatenation, test whether LRECL and RECFM are the same
in every dataset. See ARL, probably in the RDJFCB documentation.

Piece of cake.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see <http://patriot.net/~shmuel/resume/brief.html> 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Lrecl

[Paul Gilmartin]

On Sat, 28 Nov 2015 17:40:09 -0500, Shmuel Metz wrote:
>
>on 11/28/2015  at 02:50 PM, Scott Ford said:
>
>>Our STC use several files and I want to verify that the files have
>>the correct logical record length. The STCs are written LE Cobol. I
>>would like to know before I open the file if the file that is created
>>or allocated is correct in record length. For example, if the Logical
>>Record Length is 121 as defined in the program tries to open a file
>>with a LRECL 300 bytes. Can i do the following ?
>
Long ago I dealt with this problem in Assembler.  I left LRECL=0 in the
DCB.  It would be merged in from either the DSCB or JCL, JCL dominating.
I took the DCB OPEN exit.  If the value was still 0, unavailable from either
of those sources, I supplied a default LRECL; likewise for BLKSIZE and
RECFM.  Nowadays, SDB gets control last and supplies its default.   I
don't know how much of this is supported by COBOL except that coding
BLOCK CONTAINS 0 RECORDS allows SDB to operate.  Omitting the BLOCK
CONTAINS clause is equivalent to coding BLOCK CONTAINS 1 RECORD(S).
A supremely stupid default except, perhaps, in that it supports unit record
devices.

>3. If it's a concatenation, test whether LRECL and RECFM are the same
>in every dataset. See ARL, probably in the RDJFCB documentation.
> 
I believe that in days of yore the LRECL merged into the DCB by OPEN
if coded as 0 in the DCB and omitted in JCL was the LRECL from the
DSCB of the first catenand.  Stupid design.  I believe IBM actually fixed
something, and nowadays it's the maximum LRECL among the DSCBs
in the concatenation.

If RECFM=V* you may reasonably override to a larger value of LRECL;
if RECFM=F* it's inadvisable to try to change LRECL.

-- 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=32767?

[Shmuel Metz (Seymour J.)]

In 3288864492454705.wa.paulgboulderaim@listserv.ua.edu, on
12/16/2014
   at 01:18 AM, Paul Gilmartin
000433f07816-dmarc-requ...@listserv.ua.edu said:

Why is this considered an error?

The buffer length had to fit in a signed[1] half word, and they didn't
change that when the large block interface came along.

In fact, 32761 is accepted;

That I don't understand; I would have expected the cutoff to be 32760.

On what rationale is this based?

The dead hand of history.

[1] Even had it been longer, the 16-bit data length in the count
field would still have imposed[2] a 64Ki-1 restriction.

[2] Yes, I know about track overflow, but there are issues.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
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=32767?

[Shmuel Metz (Seymour J.)]

In 20141216105556.66da404ee6d280833b79b...@gmx.net, on 12/16/2014
   at 10:55 AM, nitz-...@gmx.net nitz-...@gmx.net said:

These two make up the 6 byte

BDW+RDW is 8 bytes.

without exceeding geometry.

I've seen geometry used to refer to the number of tracks per
cylinder, but never for the length field of the count. I guess it
makes sense. But note that the length filed is 16 bits unsigned, so
it's not the source oif the access method limit.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
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=32767?

[Shmuel Metz (Seymour J.)]

In 002901d01953$e00d4390$a027cab0$@q.com, on 12/16/2014
   at 09:15 AM, retired mainframer retired-mainfra...@q.com said:

Isn't the RDW already included in the LRECL (VBA print files are 137
which leaves 133 for data which includes carriage control)?  Isn't
the BDW always excluded from the LRECL since only one is present in a
block which may contain more than one record)?

Aren't the RDW and BDW both 4 bytes each?

Yes*3.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see http://patriot.net/~shmuel/resume/brief.html 
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
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=32767?

[nitz-...@gmx.net]

  6 //DD7  DD  UNIT=SYSALLDA,SPACE=(1,0),RECFM=VBS,LRECL=32767 
  6 IEF638I SPECIFIED NUMERIC EXCEEDS MAXIMUM ALLOWED IN THE LRECL 
 SUBPARAMETER OF THE DCB FIELD
 Why is this considered an error?
 
 In fact, 32761 is accepted; 32762 causes the error.  On what rationale is 
 this based?
 The same limts appear to apply to RECFM=VB.
 I haven't tried OPENing any such data set.

The explanation I came up with when I tested boundary conditions (VBG) was 
that 32767 is the maximum allowed for fixed records. And that length was 
determined by DASD geometry (in the past). A variable length record always has 
a length field preceding the actual record data. And since this is blocked, you 
also need length for the block descriptor. These two make up the 6 byte that 
you cannot specify for lrecl without exceeding geometry. I haven't tested (or 
if I did, I forgot the results) if it makes a difference when you use 
RECFM=V(S). The layout is described somewhere in SC26-7410 Using data sets.

Barbara

--
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=32767?

[R.S.]

W dniu 2014-12-16 o 08:18, Paul Gilmartin pisze:

I get:

  6 //DD7  DD  UNIT=SYSALLDA,SPACE=(1,0),RECFM=VBS,LRECL=32767

   STMT NO. MESSAGE
  6 IEF638I SPECIFIED NUMERIC EXCEEDS MAXIMUM ALLOWED IN THE LRECL 
SUBPARAMETER OF THE DCB FIELD

Why is this considered an error?

In fact, 32761 is accepted; 32762 causes the error.  On what rationale is this 
based?
The same limts appear to apply to RECFM=VB.
I haven't tried OPENing any such data set.

(I like to test boundary conditions.)


I don't know what the rationale is (is any at all?), but I know the 
following:
a) official documentations says you can specify 1 to 32760 for PS and 1 
to 32761 for VSAM (ES, KS, RR)
b) you can use PS RECFM=VBS,LRECL=32767, but you cannot specify the 
LRECL on DD.
c) you can also use LRECL=X for PS V(B)S , but I have never seen it in 
use. X means LRECL32760.
d) to allocate first new PS dataset with LRECL=32676 a trick is needed. 
Later you can use LIKE.


--
Radoslaw Skorupka
Lodz, Poland






--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl 
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2014 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.696.052 złote.



--
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=32767?

[Martin Packer]

On VSAM I suspect it's 32K-7 bytes. The 7 for a CIDF (for the CI) and a 
RDF (for the one record you could stuff into a 32K CI).

Cheers, Martin

Martin Packer,
zChampion, Principal Systems Investigator,
Worldwide Banking Center of Excellence, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker
Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker



From:   R.S. r.skoru...@bremultibank.com.pl
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   16/12/2014 11:11
Subject:Re: RECFM=VBS,LRECL=32767?
Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU



W dniu 2014-12-16 o 08:18, Paul Gilmartin pisze:
 I get:

   6 //DD7  DD  UNIT=SYSALLDA,SPACE=(1,0),RECFM=VBS,LRECL=32767

STMT NO. MESSAGE
   6 IEF638I SPECIFIED NUMERIC EXCEEDS MAXIMUM ALLOWED IN THE 
LRECL SUBPARAMETER OF THE DCB FIELD

 Why is this considered an error?

 In fact, 32761 is accepted; 32762 causes the error.  On what rationale 
is this based?
 The same limts appear to apply to RECFM=VB.
 I haven't tried OPENing any such data set.

 (I like to test boundary conditions.)

I don't know what the rationale is (is any at all?), but I know the 
following:
a) official documentations says you can specify 1 to 32760 for PS and 1 
to 32761 for VSAM (ES, KS, RR)
b) you can use PS RECFM=VBS,LRECL=32767, but you cannot specify the 
LRECL on DD.
c) you can also use LRECL=X for PS V(B)S , but I have never seen it in 
use. X means LRECL32760.
d) to allocate first new PS dataset with LRECL=32676 a trick is needed. 
Later you can use LIKE.

-- 
Radoslaw Skorupka
Lodz, Poland






--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być 
jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś 
adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej 
przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, 
rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie 
zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, 
prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale 
usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub 
zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. 
If you are not the intended addressee of this e-mail or the employee 
authorized to forward it to the addressee, be advised that any 
dissemination, copying, distribution or any other similar activity is 
legally prohibited and may be punishable. If you received this e-mail by 
mistake please advise the sender immediately by using the reply facility 
in your e-mail software and delete permanently this e-mail including any 
copies of it either printed or saved to hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl 
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego 
Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 
526-021-50-88. Według stanu na dzień 01.01.2014 r. kapitał zakładowy 
mBanku S.A. (w całości wpłacony) wynosi 168.696.052 złote.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

--
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=32767?

[R.S.]

W dniu 2014-12-16 o 12:13, Martin Packer pisze:

On VSAM I suspect it's 32K-7 bytes. The 7 for a CIDF (for the CI) and a
RDF (for the one record you could stuff into a 32K CI).

Please, note the VSAM can have SPANNED records, longer than 32k. The 
limit is CA size minus CIDFs and RDFs.

So, I couldn't name it rationale or my English is poor. ;-)


Regards

--
Radoslaw Skorupka
Lodz, Poland






---
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl 
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2014 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.696.052 złote.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN