|
View previous topic :: View next topic
|
| Author |
Message |
bipinpeter
Active User
.jpg)
Joined: 18 Jun 2007
Posts: 213
Location: Cochin/Kerala/India
|
|
|
|
Hi All,
I want to know that the possible reason of 'IEB339I COMMAND MISSING PRECEDING COL.71 ' error in IEBGENER execution.
Regards,
Bipin Peter |
|
| Back to top |
|
 |
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
Hello,
Sugggest you post the actual jcl and control statements. . .
Use copy/paste and the "Code" tag - do not post screenshots. |
|
| Back to top |
|
|
bipinpeter
Active User
Joined: 18 Jun 2007
Posts: 213
Location: Cochin/Kerala/India
|
|
|
|
Actuall i got the problem,but i dont know why it is impacting IEBGENER.
In my job i am calling a proc.In the proc i have two steps ,the first step is IEBGENER.
When i'm calling the proc ,by mistake i put a blan line after that in job.I think because of that the job abended. The intersting thing is that only the first step IEBGENER abended.The second step executed successfully.
I want to know that how the blan line affected the IEBGENER?
Regards,
Bipin Peter |
|
| Back to top |
|
|
gcicchet
Senior Member
Joined: 28 Jul 2006
Posts: 1702
Location: Australia
|
|
|
|
Hi,
the blank line generated something like this
| Quote: |
//SYSIN DD * GENERATED STATEMENT
|
, IEBGENER is expecting some parameters on that line and not a line of blanks.
The second //SYSIN was ignored
Gerry |
|
| Back to top |
|
|
bipinpeter
Active User
Joined: 18 Jun 2007
Posts: 213
Location: Cochin/Kerala/India
|
|
|
|
| But if i give blank line in the job,how the IEBGENER will take that?? I'm not giving any overrides or specifying any steps... |
|
| Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8796
Location: Welsh Wales
|
|
|
|
| As requested by Dick, please post the exact JCL andoutput from the run and maybe we can be more helpful. |
|
| Back to top |
|
|
bipinpeter
Active User
Joined: 18 Jun 2007
Posts: 213
Location: Cochin/Kerala/India
|
|
|
|
Hi,
Here is My job
| Code: |
***************************** Top of Data ******************************
//TESTJOB JOB (XXXXX,XX),'TEST JOB',CLASS=S,MSGCLASS=T,
// REGION=4096K
//*
//PRC JCLLIB ORDER=(ABC.XYZS.PROC.LIB)
//JOBLIB DD DSN=MSZA.FDSGGG.PROD.LNK,
// DISP=SHR
//*
//PROCEEX EXEC PROCEEX,
// LIB1='EFDC.FDFH.NODE.SYS.',
// SYSOT=*
**************************** Bottom of Data **************************** |
Here is my Proc
| Code: |
//PROCEEX PROC SYSOT=' ',
// LIB1='EFHG.FDFA.NODE.SYS.'
//STEP010 EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=&SYSOT
//SYSUT1 DD DSN=&LIB1.ABC(0),
// DISP=(SHR,KEEP,KEEP)
//SYSUT2 DD DSN=&LIB1.XYZ.ABC(+1),
// DISP=(NEW,CATLG,DELETE),UNIT=DLPMK,
// SPACE=(CYL,(10,1),RLSE)
//SYSIN DD DUMMY
//*
//STEP015 EXEC PGM=IEFBR14
//OUT01 DD DSN=&LIB1.ABC(0),
// DISP=(NEW,CATLG,DELETE),SPACE=(CYL,(1,1),RLSE),
// DCB=(LRECL=795,DSORG=PS,RECFM=FB),UNIT=DLPMK,
//* |
Regards,
Bipin Peter
Edited: Please use BBcode when You post some code/error, that's rather readable, Thanks... Anuj |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
Hello,
That's a start - now, please post the diagnostic output. . . (the first 3 sysout files).
I suspect the blank line is being treated as an override and is an invalid IEBGENER control statement.
I also suspect that the IEBGENER is not abended, but is actually terminated with a non-zero condition code. |
|
| Back to top |
|
|
bipinpeter
Active User
Joined: 18 Jun 2007
Posts: 213
Location: Cochin/Kerala/India
|
|
|
|
Yes Dick..IEBGENER ended with return code of 12.I want to know that why the IEBGENER tooks the blank line as override? I'm not specifying any step names in job.
Regards,
Bipin Peter |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
Look at the JCL and you will find a //SYSIN DD * generated for the blank line. When you override a DD statement in a PROC, the JCL Language Reference defines how this is done (I added emphasis):
| Quote: |
Location in the JCL
Place modifying OUTPUT JCL and DD statements in the following order, after the EXEC statement that calls the procedure:
* For each procedure step in the invoked procedure:
1. Overriding statements can appear in any order when they explicitly specify the step that is being overridden. Added statements can appear in any order when they specify the step explicitly.
2. Overriding and added statements that do not explicitly specify the step are applied to the step named in the previous overriding or added OUTPUT JCL or DD statement. If no previous override statement named a step, then they are applied to the first step in the procedure. |
So the blank became a SYSIN DD * statement which overrode the first step's SYSIN statement -- hence the IEBGENER took the blank line as the override. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
Hello,
Did you verify that there is a "generated statement" as Gerry mentioned?
That generated statement caused an override "SYSIN" dd to be generated and this override was applied to the first step - the IEBGENER. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
| Dick -- GMTA! |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
'Preciate it. . .
Or as my bride reminds me - a blind squirrel finds an acorn once in a while.
d |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
Put the blind squirrel in a slingshot and launch him through the branches of an oak tree ... bet he finds LOTS of acorns! You've just got to hunt in the right place.
We won't talk about what the squirrel thinks about being airborne, though. |
|
| Back to top |
|
|
bipinpeter
Active User
Joined: 18 Jun 2007
Posts: 213
Location: Cochin/Kerala/India
|
|
|
|
I executed the same job by changing the IEBGENER as the second step at that time it went fine..Why in this case it didnt pick up the blank override for IEBGENER?
Bipin |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
Hello,
The blank statement would still generate a SYSIN. It would not be a problem if the IEFBR14 was first - IEFBR14 does not use a SYSIN dd. When the IEBGENER executed, it had no problem with the sysin dd dummy, so all was well. |
|
| Back to top |
|
|
|
|
