------------------<snip>-------------------
Actually, I just had a bloody row about a DD dummy statement in the JCL for a
new release of a vendor product. It appears that a dd dummy generates a dsn of
NULLFILE in the JFCB (that would explain why I see dsn=nullfile quite a bit in
our productive JCL).
And yes, the application somehow has to be aware of that. In my case, an
'enhancement' was made that the OEM went and did an explicit RACF call with an
(of course not defined) HLQ that contained NULLFILE and the job got an abend913
(the unchanged JCL ran in the previous version). One of the things they asked
was why we had this data set name (I think it is some sort of RACF exit), and
it was clear that they wanted to always call RACF (no matter what dsn the
customer has defined in his RACF exit).
They should have fixed their JCL so's we didn't have to use the dd dummy in the first place.
That same vendor ins also incapable of honoring an sffdump dd dummy statement. They go and write the dump (that we don't want - they never find their problems in it, anyway) under another dd (dynamically allocated) into the spool, where we really don't want it!
------------------<unsnip>--------------------
Barb, it sounds to me like maybe it's time to re-evaluate the value of
the product vs. other offering by other vendors. I believe that NULLFILE
is the dsname provided by the base system (as opposed to RACF) for any
DUMMY file.
Suggestion: instead of DD DUMMY, try using DD DSN=SYS1.NULLFILE,DISP=SHR
and define a RACF profile for SYS1.NULLFILE with a UAC of ALTER.
That should put a name in the JFCB that the dumb-ass vendor can check
against RACF. Now if he'd just check the DSNAME and bypass RACF
processing for NULLFILE and SYS1.NULLFILE, the four instructions and two
literals would be cheap and go a LONG way toward customer satisfaction.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
