>Because the application may not check to determine if it is a dummy file. >The application may require the data from the JFCB
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! Regards, Barbara NItz -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail ---------------------------------------------------------------------- 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
