MVSFORUMS.com

[CaptObvious]

Since migrating some OS maintenance into production I'm receiving the above message on several jobs which execute IEBGENER. The jobs in question do not specify a SYSIN dataset. A SYSIN DD DUMMY statement resolves the issue simply enough. However, going through our entire production JCL library to find all IEBGENER jobs which lack a SYSIN statement is not exactly desirable.

These jobs ran just fine prior to the migration without the SYSIN allocation. None of the maintenance affected IEBGENER directly, so it's not a case of a PE fix. My suspicion is that when we cloned the target resvols from the test LPAR (where maintenance was applied) to the production LPAR, some sort of IEBGENER customization was lost. All I can find in the utilities manual are vague references to SVC 99 performing dynamic file allocations, but I haven't seen any evidence of an SVC being called during execution of our past successful jobs, nor can I see any evidence of a SYSIN dataset being allocated, dynamically or otherwise.

Anyone have any idea of what kind of customization I'm talking about, and where to start looking?

[kolusu]

CaptObvious,

I think JES has an option of putting SYSIN DD automatically if it is missing from the JCL

Kolusu
_________________
Kolusu
www.linkedin.com/in/kolusu

[CaptObvious]

But if JES2 were allocating it, I should have expected to see a message like this:

IEF237I JES2 ALLOCATED TO SYSIN

There are no allocations for a SYSIN dataset during previous successful runs.

Compare the allocations with a recent failure:

IEF236I ALLOC. FOR IDXTXPRT FICHE1 DLI
IEF237I JES2 ALLOCATED TO SYSUT2
IEF237I JES2 ALLOCATED TO SYSPRINT
IEF237I 200D ALLOCATED TO SYSUT1
IEC130I SYSIN DD STATEMENT MISSING

With those from a previous success:

IEF236I ALLOC. FOR IDXTXPRT FICHE1 DLI
IEF237I JES2 ALLOCATED TO SYSUT2
IEF237I JES2 ALLOCATED TO SYSPRINT
IEF237I 200D ALLOCATED TO SYSUT1

[CaptObvious]

And on further review, JES2 provides a SYSIN statement for catalogued procedures. These jobs aren't calling any procs.

[German Castillo]

I know, It is not a clean solution, but you may consider using a SMF exit to do a dynamic allocation?
_________________
Best wishes,

German Castillo

[German Castillo]

Or maybe the open svc preallocation exit(?)
_________________
Best wishes,

German Castillo

[bablack]

To the best of my knowledge, IEBGENER has always required a SYSIN DD statement, at least a DUMMY. I just tried it on z/OS 1.4 and 1.7 and got the same errors you quoted.

Is it possible that you used to have some JCL scan exit that added a SYSIN DD DUMMY to steps that had none?

Another possibility: perhaps you used to have a IEBGENER-replacement from some software vendor (I think Software Engineering of America has one) and it didn't need a SYSIN. But whatever you changed has deactivated that replacement so you are now getting native IEBGENER. In the output from a job that used to work, get you get IEB messages or something else?

BTW, JES will add a SYSIN DD * if it encounters non-JCL statements without a preceding DD * (or DD DATA) but it doesn't add SYSIN to a step consisting only of valid JCL statements.[/quote]
_________________
Bruce A. Black
Senior Software Developer
Innovation Data Processing

[CaptObvious]

It looks like I've found the solution. The offending change was in DFSORT. There's a usermod which adds IEBGENER as an alias to ICEGENER, and what probably happened is the admin before me installed the usermod to production, but not test. Now I need an IPL with CLPA to make the change official.

[Frank Yaeger]

Yes, it's true that DFSORT's ICEGENER does not require a SYSIN DD statement. And to use ICEGENER when you specify PGM=IEBGENER, you have to set up ICEGENER as an automatic replacement for IEBGENER.
_________________
Frank Yaeger - DFSORT Development Team (IBM)
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration
DFSORT is on the Web at:
www.ibm.com/storage/dfsort