IBM Mainframe Forum

by **Frank Yaeger** » Tue May 10, 2011 6:28 am

daloporhecho,

But it sometimes does generate a dataset with allocation VB, 255, 27998 (instead of FB, 80, 6160) and then IEBGENER reports

...
ICE090I 0 OUTPUT LRECL = 80, BLKSIZE = 6160, TYPE = FB

The ICE090I message tells us that ICEGENER did NOT produce a VB output data set in this case. The message
indicates that ICEGENER produced an output data set with FB/80/6160. I'm not sure what you're using to tell you that the output data set has VB/255/27998, but if that's true, then something changed the attributes AFTER ICEGENER created the data set.

For anyone to help you, you would need to show the COMPLETE JES LOG for the job that produced the VB output data set including proof that a VB data set was actually produced.

Nothing, including using BSAM, would cause ICEGENER to create a VB output data set if it says its creating an FB output data set in the ICE090I message.

by **daloporhecho** » Tue May 10, 2011 9:44 am

Thank you Frank.
Here I prepared a complete step by step of what is happening to that GDG.

MYJCLA is the IEBGENER I stated before, quite simple stuff:

Select all

//STEP01 EXEC PGM=IEBGENER
//STEPLIB DD DSN=MYLIBRARY,DISP=SHR
//*
//SYSIN DD DUMMY
//*
//SYSUT1 DD DSN=MYGDG(0),DISP=OLD
//SYSUT2 DD DSN=MYGDG(+1),
// DISP=(,CATLG,DELETE),
// UNIT=MYUNIT,
// SPACE=(CYL,(40,20),RLSE),
// DCB=(GDG,RECFM=FB,LRECL=80,BLKSIZE=6160)
//SYSPRINT DD SYSOUT=R

MYJCLB is only this DD, I'm sure this is all you need to understand my point:

Select all

//TESTFL DD DSN=MYGDG(+1),
// DISP=(MOD,KEEP,DELETE)

This is what happens to the GDG step by step:

Select all

MYJCLA At 11:15 no problems, as it usually runs:
IGD103I SMS ALLOCATED TO DDNAME SYSUT1
----------------------------------------------------------------
IGD101I SMS ALLOCATED TO DDNAME (SYSUT2 )
DSN (MYGDG.G6317V00)
STORCLAS (SCSTD) MGMTCLAS (MCNOABK) DATACLAS (DCSTD)
VOL SER NOS= XA9345
----------------------------------------------------------------
IGD104I MYGDG.G6316V00 RETAINED, DDNAME=SYSUT1
----------------------------------------------------------------
IGD107I MYGDG.G6317V00 ROLLED IN, DDNAME=SYSUT2
----------------------------------------------------------------
IGD104I MYGDG.G6317V00 RETAINED, DDNAME=MYDD
----------------------------------------------------------------

MYJCLB At 11:18 doesn't provide allocation parameters for the GDG:
IGD101I SMS ALLOCATED TO DDNAME (TESTFL )
DSN (MYGDG.G6318V00)
STORCLAS (SCSTD) MGMTCLAS (MCNOABK) DATACLAS (DCSTD)
VOL SER NOS= XA9334
----------------------------------------------------------------
IGD104I MYGDG.G6318V00 RETAINED, DDNAME=TESTFL
----------------------------------------------------------------

MYJCLA At 11:25 doesn't abend but doesn't seem as normal either:
IGD103I SMS ALLOCATED TO DDNAME SYSUT1
----------------------------------------------------------------
IGD17356I GDG RECLAIM REQUEST WAS SUCCESSFULLY PROCESSED FOR DATA SET MYGDG.G6318V00
----------------------------------------------------------------
IGD101I SMS ALLOCATED TO DDNAME (SYSUT2 )
DSN (MYGDG.G6318V00)
STORCLAS (SCSTD) MGMTCLAS (MCNOABK) DATACLAS (DCSTD)
VOL SER NOS= XA9334
----------------------------------------------------------------
IGD104I MYGDG.G6317V00 RETAINED, DDNAME=SYSUT1
----------------------------------------------------------------
IGD107I MYGDG.G6318V00 ROLLED IN, DDNAME=SYSUT2
----------------------------------------------------------------
IGD104I MYGDG.G6318V00 RETAINED, DDNAME=MYDD
----------------------------------------------------------------

MYJCLA At 11:35 abend:
IGD103I SMS ALLOCATED TO DDNAME SYSUT1
----------------------------------------------------------------
IGD101I SMS ALLOCATED TO DDNAME (SYSUT2 )
DSN (MYGDG.G6319V00)
STORCLAS (SCSTD) MGMTCLAS (MCNOABK) DATACLAS (DCSTD)
VOL SER NOS= XA9338
----------------------------------------------------------------
ABEND: CONFLICTING DCB PARAMETERS
----------------------------------------------------------------
IGD104I MYGDG.G6318V00 RETAINED, DDNAME=SYSUT1
----------------------------------------------------------------
IGD107I MYGDG.G6319V00 ROLLED IN, DDNAME=SYSUT2
----------------------------------------------------------------

MYJCLA At 11:45 last run, all fine again:
IGD103I SMS ALLOCATED TO DDNAME SYSUT1
----------------------------------------------------------------
IGD101I SMS ALLOCATED TO DDNAME (SYSUT2 )
DSN (MYGDG.G6320V00)
STORCLAS (SCSTD) MGMTCLAS (MCNOABK) DATACLAS (DCSTD)
VOL SER NOS= XA9325
----------------------------------------------------------------
IGD104I MYGDG.G6319V00 RETAINED, DDNAME=SYSUT1
----------------------------------------------------------------
IGD107I MYGDG.G6320V00 ROLLED IN, DDNAME=SYSUT2
----------------------------------------------------------------
IGD104I MYGDG.G6320V00 RETAINED, DDNAME=MYDD
----------------------------------------------------------------

Nothing else happens to MYGDG other than these reports.

My guess is, the execution of MYJCLB at 11:18 got the GDG messed up by not providing its allocation parameters. For that reason MYJCLA that followed on couldn't see g6318 was already created by MYJCLB. The system noticed something was wrong (WHAT?) and RECLAIMED g6318, but apparently ignoring its definition as SYSUT2 stated explicitly a full and nice DCB not coincidental at all with the one provided by the already allocated g6318. Then the problem went on to the next execution to finally abend.

by **NicC** » Tue May 10, 2011 10:24 am

Your extracts are just that - extracts with no context. You start mention MYJCLB - what is that? Why is it deleteing the +1 generation? Your MYJCLA is just repeating the IEBGENER step from before - is that the only step in the job? Where else is the dataset being referred to - it must be otherwise you are just copying the same dataset day-in day-out which is pointless and a waste of resource.

by **BillyBoyo** » Tue May 10, 2011 12:13 pm

// DCB=(GDG,RECFM=FB,LRECL=80,BLKSIZE=6160)

Any my other question?

Your job completes, with FB.

Occasionally when the next one starts, file has VB.

Stop looking at your job at the moment and tell us what is happening between the first run of your job and the second.

Somewhere in there, the file is becoming VB.

by **BillyBoyo** » Tue May 10, 2011 12:59 pm

daloporhecho wrote:Nothing else happens to MYGDG other than these reports.

My guess is, the execution of MYJCLB at 11:18 got the GDG messed up by not providing its allocation parameters. For that reason MYJCLA that followed on couldn't see g6318 was already created by MYJCLB. The system noticed something was wrong (WHAT?) and RECLAIMED g6318, but apparently ignoring its definition as SYSUT2 stated explicitly a full and nice DCB not coincidental at all with the one provided by the already allocated g6318. Then the problem went on to the next execution to finally abend.

If "Nothing else happens to MYGDG other than these reports" what is the point of your job. Just purge all the outputs, delete from the catalog, remove the JCL and go back to sleep.

Of course something happens to MYDGD. Otherwise the whole operation is pointless. And occasionally something out-of-the-normal happens to it as well, somewhere else, a different job, even on-line.

Stop looking at your job. Stop it. Stop it. It works. Everyone says it creates FB, even the job itself says so.

S-o-m-e-t-h-i-n-g is happening to change the DCB of your file in between your jobs.

Just for fun, create a test version of your GDG, then try to edit it from TSO/ISPF as a "member" of a PDS. Then save it. Then look at the DCB. Get that one out of the way, as the DCB it has just smacks of PDS.

Answer the questions, don't mess about guessing we can all guess a million things, but won't help.

by **BillyBoyo** » Tue May 10, 2011 3:57 pm

Go to your storage people and get them ready for next time it happens. When it does, get them to show you every access that the system knows about to your file. Ask them nicely, don't give them all the rubbish gueses. If you have any of the VB files around still, you can do it now.

by **Anuj Dhawan** » Thu May 26, 2011 5:30 pm

/humor on
I read only this much:

daloporhecho wrote:Hello people, I hope you are all doing good. This is the problem.

/humor off

IBM Mainframe Forum

IEBGENER BSAM or EXCP?

Re: IEBGENER BSAM or EXCP?

Re: IEBGENER BSAM or EXCP?

Re: IEBGENER BSAM or EXCP?

Re: IEBGENER BSAM or EXCP?

Re: IEBGENER BSAM or EXCP?

Re: IEBGENER BSAM or EXCP?

Re: IEBGENER BSAM or EXCP?