Hi everyone,
I played a bit with this over the past couple of days, with several
combinations of DDs, and it all points to the DD that's used to tell
allocation to leave the second DD as-is. It's incorrectly being processed
with a generated temporary data set name instead of letting the instream be.
I'm going to APAR this. I would appreciate it, though, if someone who has
access to a 2.1 system could run my example JCL (it's just using IEBGENER
and an instream PROC) to see if it's fixed there.
Cheers,
Ray
On 2014-02-07 06:25, Pommier, Rex wrote:
Ray,
Just out of curiosity, would it work if you added a third DD card to the
original SYSLPARM DD concatenation? The JCL ref manual doesn't explicitly
state the override needs something to override, but it might be worth a try.
Can you try something like:
//SYSLPARM DD DSN=&&tempds,DISP=(OLD,DELETE)
// DD *
some more binder parms overriding the first one
/*
// DD *
A comment line or do-nothing line (or possibly nothing at all)
/*
And then your override would have the second DD * to be overridden.
Or maybe the third DD could be DD DUMMY?
Rex
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Ray Mullins
Sent: Thursday, February 06, 2014 4:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Error overriding concatenated DD in PROC where one is instream data
Hello, long time absent.
In z/OS 1.13, I'm playing with instream data in a PROC for the first time to
try to simplify some bind JCL and I've run into an error. It's an atypical
situation, I realize.
In the PROC I have
//* Following is a data set created with ISRSCAN from a concatenation
//SYSLPARM DD DSN=&&tempds,DISP=(OLD,DELETE)
// DD *
some more binder parms overriding the first one
//*
Because one of the program objects needs different stuff, I've coded
//DRVASTRT EXEC MMB,symbolics
//B.SYSLPARM DD
// DD
// DD *
different parms to override a couple in the first two DDs
//*
The job hits this step and gives me
IEF344I MMDB B DRVASTRT SYSLPARM+001 - ALLOCATION FAILED DUE TO DATA
FACILITY SYSTEM ERROR
IGD17045I SPACE NOT SPECIFIED FOR ALLOCATION OF DATA SET
SYS14037.T114830.RA000.MMDB.R0484370
It seems like conversion/interpretation has skipped the fact that I'm not
overriding the second DD in the concatenation and is generating a data set
name, instead of noting that it's a blank DD and just leaving the original
DD alone.
From a logic standpoint, this makes sense, but I'm wondering if this is WAD
(thou shalt not override instream data) or maybe DD concatenation needs some
extra checks if the underlying DD is instream (or does not have a DSN). I am
curious as how this would be handled if the DD was a SUBSYS.
Yes, I could put the instream data in a PDS member, but for various reasons
that would complicate the underlying binder proc; let's just say we'd rather
not go there.
So, what's the consensus? WAD? APARable?
Cheers,
Ray
--
M. Ray Mullins
Roseville, CA, USA
http://www.catherdersoftware.com/
German is essentially a form of assembly language consisting entirely of far
calls heavily accented with throaty guttural sounds. ---ilvi
French is essentially German with messed-up pronunciation and spelling.
--Robert B Wilson
English is essentially French converted to 7-bit ASCII. ---Christophe Pierret
[for Alain LaBonté]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
