IEBGENER giving IEB351I I/O ERROR

umashankar pathak · Posted: Mon Mar 10, 2014 11:39 pm

Hi All,

I have come across the issue where IEBGENER giving IEB351I I/O ERROR ,P420301R,JS000300,0D02,D,SYSUT1 ,READ ,WRNG.LEN.RECORD,000 in below step:-
//JS000300 EXEC PGM=IEBGENER
//SYSIN DD DUMMY,DCB=BLKSIZE=80
//SYSPRINT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//SYSUT1 DD DSN=xxxx.xxxxxxxx.A42030.DATAFILE,DISP=SHR
//SYSUT2 DD DSN=xxxx.xxxxxxxx.A42030.DATAFILE(+1),
// DISP=(NEW,CATLG,DELETE),
// UNIT=SYSDA,
// DCB=(xxxx.ttttttt.xxxxxx,RECFM=FB,LRECL=80,BLKSIZE=0),
// SPACE=(CYL,(5,1),RLSE)
//*

SYSUT1 is a GDG base and have 4 generation all 4 has LREC=80 however first generation is empty and have BLKSIZE=27920 while alll other gen's has data with BLKSIZE=80...Not sure why its giving WRNG.LEN.RECORD...

Can anyone of you guide me in this.Thanks.

Regards,
Uma

Terry Heinze · Posted: Mon Mar 10, 2014 11:46 pm

What are the dataset characteristics of 'DSN=xxxx.xxxxxxxx.A42030.DATAFILE'? Please use Code tags where appropriate.

umashankar pathak · Posted: Mon Mar 10, 2014 11:53 pm

Hi Terry,

Thanks for response.

The dataset in SYSUT1 are GDG base.
[GDG base dataset name: xxxx.xxxxxxxx.A42030.DATAFILE

GDG dataset limit: 20 (Maximum number of generations, 1-255)

Active generations: 4 (Generations that are currently allocated)

Owner:

Expiration date:

Uncatalog options: NOEMPTY (EMPTY = All generations are uncataloged
NOEMPTY = Oldest generation is uncataloged)
Scratch options: SCRATCH (SCRATCH = Scratch when uncataloged
NOSCRATCH = Uncatalog only)

[/code]

Terry Heinze · Posted: Tue Mar 11, 2014 12:06 am

We need the DCB parameters of 'xxxx.xxxxxxxx.A42030.DATAFILE'. Just the generation being refereced by your SYSUT1, not the GDG base definition. In 3.4, do an (I)nquiry and paste the result here. As in:

umashankar pathak · Posted: Tue Mar 11, 2014 12:09 am

Data Set Name . . . : xxxx.xxxxxx.A42030.DATAFILE.G0030V00

General Data Current Allocation
Volume serial . . . : PRD003 Allocated tracks . : 1
Device type . . . . : 3390 Allocated extents . : 1
Organization . . . : PS
Record format . . . : FB
Record length . . . : 80
Block size . . . . : 27920 Current Utilization
1st extent tracks . : 1 Used tracks . . . . : 0
Secondary tracks . : 1 Used extents . . . : 0

Creation date . . . : 2014/03/03
Referenced date . . : 2014/03/10
Expiration date . . : ***None***

Terry Heinze · Posted: Tue Mar 11, 2014 2:22 am

GDG bases do not have a record length. They simply define some of the characteristics of the generations that comprise the base. Your JCL indicates you are trying to copy a GDG base to a GDG generation. I don't understand exactly what you are trying to do.

Rohit Umarjikar · Posted: Tue Mar 11, 2014 3:45 am

I believe you would like to copy entire GDG to a PS file, so why not to use SORT? and also using IEBGENER in SYSUT1 , you might wants to give Generation #.

may be the below link would help you,

ibmmainframes.com/about61865.html

steve-myers · Posted: Tue Mar 11, 2014 4:45 am

I suspect umashankar pathak has run into the uninitialized data set problem. It used to be when you allocated a data set there is nothing on the first track and an innocent program trying to read the data set will attempt to read whatever was there from a previous use of the space. More often than not it results in a wrong length record. ISPF never had this problem since it examines the VTOC to determine if the data set is empty and won't read the data set if it appears to be empty, but in this context IEBGENER is an innocent program.

Many systems write a DASD end of file record on the first track when they allocate a data set, but I'm not certain what triggers this behavior. Certainly this will prevent umashankar pathak's problem from occurring!

Rohit Umarjikar · Posted: Tue Mar 11, 2014 6:41 am

Also, could someone please move this to JCL forum

umashankar pathak · Posted: Tue Mar 11, 2014 7:00 pm

Thanks everyone for your reply....

Steve-myers -- it make sense.I guess same happened here.

Rohit:- If you want to copy the generation(s) in particular order yes we have to give the generation number in SYSUT1 but I have to copy all GDG entries to a flat file so I believe using a SORT won't help here.

Thanks again!!
Uma

Rohit Umarjikar · Posted: Tue Mar 11, 2014 8:46 pm

Why would SORT won't help?

umashankar pathak · Posted: Tue Mar 11, 2014 9:04 pm

Well I'm doing the straight copy so if my IEBGENER is giving issue I would expect the same issue with SORT....The files were deleted now so I can't test but next time if it will fail again I will try with SORT.Thanks.

dick scherrer · Posted: Wed Mar 12, 2014 1:00 am

Hello,

umashankar pathak · Posted: Wed Mar 12, 2014 1:20 am

Hello Dick,

Yes I agree SORT can copy all the generation to the flat file same like IEBGENER. I have used IEBGENER to copy all generation into flat file where it was showing me above error so in that context I wrote SORT also will give the same error.

Thanks for your time and help!

Regards
Uma

dick scherrer · Posted: Wed Mar 12, 2014 1:37 am

Ok. Thanks for the followup.

If (when) this happens again, come early so we may be able to diagnose what really happened.

Is there any way to ensure all of the generationis had the same dcb parameters? Is this a new process or a recently changed process?

umashankar pathak · Posted: Wed Mar 12, 2014 1:43 am

Yes its OLD process but I am new to the application so first time for me...it has 4 generations all with LREC=80 however first generation was empty and have BLKSIZE=27920 while alll other gen's had data with BLKSIZE=80.

Rohit Umarjikar · Posted: Wed Mar 12, 2014 5:04 am

May be you can try creating another GDG in Development env. and prepare the same generations as you mentioned in the problem and then before using the utility delete manually the first generation (Empty dataset) and see if you still gets the error, and if you don't get then what Steve has said could be the possible reason for the cause.

enrico-sorichetti · Posted: Wed Mar 12, 2014 1:35 pm

the problem is that for SMS managed datasets an endoffile is written at allocation time

so in a correct environment no ioerror should occur

steve-myers · Posted: Wed Mar 12, 2014 3:54 pm