The longest record was 222 THIS TIME. Given that they chose that specific DCB,
you should be prepared for a different result at some future delivery. If you
change your VB parameters to allow a (much) longer record, your job will
process the current data with the same efficiency but will
No they are not terminated with CR or LF or anything. They are just different
length records with no length prefix or any suffix at all in a RECFM=U file.
I was the one who suspected that the original source file from the vendor was
from Unix somewhere due to the content. Goal here was to get
Peter,
I was scanning through this thread. It sounds like the records are
terminated with a 'CR' or 'CRLF' , i.e.; x'0d' or x'0d0a' , is this correct
Scott
On Tue, Jun 18, 2019 at 10:14 AM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On Tue, 18 Jun 2019 03:43:18
On Tue, 18 Jun 2019 03:43:18 +, Farley, Peter x23353 wrote:
>Very interesting. Collapsing the two steps and eliminating the intermediate
>Unix file also works, but I do have explicit DCB information in the JCL for
>both SYSUT1 and SYSUT2, so maybe that's what makes the IEBGENER process
Very interesting. Collapsing the two steps and eliminating the intermediate
Unix file also works, but I do have explicit DCB information in the JCL for
both SYSUT1 and SYSUT2, so maybe that's what makes the IEBGENER process work
here.
I had been told by the coworker who solicited my help that
On Tue, 18 Jun 2019 00:31:31 +, Farley, Peter x23353 wrote:
>Finally got my mount issue straightened out and got to try your suggestion.
>IDCAMS REPRO gave errors trying to copy to the Unix output file, but IEBGENER
>worked just fine.
>
>This did not work:
>
>//STEP0100 EXEC PGM=IDCAMS
Finally got my mount issue straightened out and got to try your suggestion.
IDCAMS REPRO gave errors trying to copy to the Unix output file, but IEBGENER
worked just fine.
This did not work:
//STEP0100 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
On 6/14/2019 8:08 AM, Paul Gilmartin wrote:
Is LRECL allowed to be greater than BLKSIZE? I could imagine coding
RECFM=U,BLKSIZE=1000,LRECL=1
to indicate that each logical record is divided into 10 blocks with no RDW.
LRECL=X (undefined or variable-spanned) lets you have literally
On Fri, 14 Jun 2019 10:46:40 -0400, Steve Smith wrote:
>+1 LRECL for RECFM=U is basically meaningless, and seems to have no
>function other than to cause WRNG.LN.ERORS (sick (sic- it's a joke)).
>
Is LRECL allowed to be greater than BLKSIZE? I could imagine coding
+1 LRECL for RECFM=U is basically meaningless, and seems to have no
function other than to cause WRNG.LN.ERORS (sick (sic- it's a joke)).
sas
On Fri, Jun 14, 2019 at 10:19 AM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On Fri, 14 Jun 2019 00:48:06 +, Farley,
On Fri, 14 Jun 2019 00:48:06 +, Farley, Peter x23353 wrote:
>For RECFM=U it is not the LRECL that governs I/O behavior it is the BLKSIZE (I
>believe that LRECL is ignored for U), so in this particular case anything up
>to 27998 would be legal and allowed.
>
To avoid confusion, and to avoid
Would an IND$FILE transfer work with the CRLF option without the ASCII option?
On Fri, Jun 14, 2019 at 12:49 AM Farley, Peter x23353
wrote:
>
> In fact I did try it, and Rexx ignored the LRECL=200, as expected. As I said
> in an earlier reply, the longest actual record (block) size was 222.
>
In fact I did try it, and Rexx ignored the LRECL=200, as expected. As I said
in an earlier reply, the longest actual record (block) size was 222.
Peter
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Seymour J Metz
Sent: Thursday, June 13, 2019 5:59 PM
To:
For RECFM=U it is not the LRECL that governs I/O behavior it is the BLKSIZE (I
believe that LRECL is ignored for U), so in this particular case anything up to
27998 would be legal and allowed.
Peter
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Paul Gilmartin
In principle I agree, but in this case recording the maximum length of all
records during the Rexx conversion process showed none longer than 222.
Whether the vendor records will always stay within that limit is of course
unknown to me since I do not know the vendor or the product.
The team
I would hope that REXX would ignore LRECL for RECFM=U. If you try it, please
let us know what happens.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Paul Gilmartin
On Thu, 13 Jun 2019 21:03:17 +, Seymour J Metz wrote:
>> DCB=(RECFM=U,LRECL=200,BLKSIZE=27998)
>
>Despite the LRECL, I take this to mean that the records can be up to 27998.
>
What do Rexx (and other utilities) do if a record/block exceeds 200? Either
for input or output.
-- gil
> DCB=(RECFM=U,LRECL=200,BLKSIZE=27998)
Despite the LRECL, I take this to mean that the records can be up to 27998.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Farley, Peter x23353
Sent:
Peter said...
*Yes, I did one in Rexx and it worked without an issue.*
Well done. I was a bit glib about 2 lines. One at a time is always safer.
I'm always amazed how REXX can crunch these oddball files.
Off topic but I've had some great success with SDSF RGEN this week. Solved
an issue we've
That wouldn't work here I'm afraid. Nothing against Paul, he does some amazing
stuff, just not here.
Peter
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Mike Schwab
Sent: Wednesday, June 12, 2019 6:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is there any
Yes, definitely no binary data at all, no trailing CR or NL or LF at all.
I guessed at the max size by browsing the file in HEX mode (too big to EDIT in
TSO), and browse in HEX shows you where the physical end of the record is.
And I did find some records longer than 200, max about 225, so I
Tried that too, but apparently my HFS file is having some trouble being mounted
and I have to get the storage guys involved to fix it. Bureaucratic nightmare.
When that's fixed I will definitely try it, thanks for the suggestion.
Peter
-Original Message-
From: IBM Mainframe Discussion
Well, 6 lines (DO WHILE RC = 0 ... END added for one-record-at-a-time
processing, plus 2 EXECIO ... (FINIS at the end.
Overkill, I know, but that's just me.
Peter
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Wayne Bickerdike
Sent: Wednesday, June 12, 2019 4:32
Yes, the records are actually one per physical block, about 140K records
(blocks) total.
Rexx handled it without a problem (one record at a time, EXECIO 1 ... rather
than EXECIO * ...).
Using Sri's JCL I did try a number of lrecl/blksize combinations, but they all
failed in the second REPRO
Hi Sri,
Tried that, the first step works without a problem but the second one fails
with a SYNAD error, "WRNG.LN.RECORD". I found out that some of the records are
actually up to 225 or so bytes, and changed the "200" values to 250 but still
got the SYNAD error.
The actual physical records
Yes, I did one in Rexx and it worked without an issue.
Peter
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of
Seymour J Metz
Sent: Wednesday, June 12, 2019 3:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Is there any way to convert RECFM=U to RECFM=V with a utility
I think Paul wrote one for his MVS 380 project.
On Wed, Jun 12, 2019 at 10:43 PM Tom Marchant
<000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote:
>
> On Wed, 12 Jun 2019 19:05:55 +, Farley, Peter x23353wrote:
>
> >The records are actually variable length data, up to 200 bytes of actual
>
On Wed, 12 Jun 2019 19:05:55 +, Farley, Peter x23353wrote:
>The records are actually variable length data, up to 200 bytes of actual data
>with no length prefix (no RDW/BDW). No binary data, only text characters. I
>suspect a *ix text-format file as the vendor source but have no proof of
Copy it to a UNIX file with FILEDATA=TEXT using IENGENER or other. Then
copy it back to a PS dataset with appreciate LRECL and RECFM. The first
step will copy each physical record to UNIX, and put a LF at the end to be
a regular UNIX text file. The second step will copy the UNIX file back to
FB or
Hmmm,
2 ines of REXX in batch, a couple more if run interactively for the ALLOC
statements...
On Thu, Jun 13, 2019 at 5:21 AM Sri h Kolusu wrote:
> > We have a vendor-generated file that comes in with
> > DCB=(RECFM=U,LRECL=200,BLKSIZE=27998) (don't ask why please, this
> > DCB setting is out
Are you saying the records are just one per physical block and that by
conventional usage the file should be defined as BLKSIZE=200 with no
LRECL? If this is a file with a very large number of unblocked records
using a physical block size of 200 or less, it would obviously be an
incredibly poor
> We have a vendor-generated file that comes in with
> DCB=(RECFM=U,LRECL=200,BLKSIZE=27998) (don't ask why please, this
> DCB setting is out of our hands).
Peter,
Give this JCL a try and see if it works for you
//***
//* COPY RECFM=U
Well, I would probably do it with assembler, but what's wrong with writing a
REXX script? or a Perl script, for that matter?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Farley, Peter x23353
33 matches
Mail list logo
