In a recent note, Gerhard said: > Date: Mon, 30 May 2005 00:00:09 EDT > > I haven't tried this for several decades, but a DD DUMMY under MVT would > always > work, whereas a DSN=NULLFILE required a valid unit, etc. to avoid allocation > failure. I found this out the hard way when I had a program that allocated a > direct 327x, and I had to find a convenient way to override the allocation in > a > PROC (I used the BLKSIZE to request alternate allocation: 0 for SYSIN/SYSPRINT > simulation, 5 for VTAM, etc.). I'd guess that in an SMS system all bets are > off? > Ancient history; the stuff of legend. I had a colleague who, likewise within the past decade, declined to use DSN=NULLFILE because of bitter memories of exclusive ENQ conflicts with SYSDSN NULLFILE. I was unable to duplicate his experience, also.
It's easy to suspect that at some point in time IBM resolved all such problems by adopting a tactic of converting DSN=NULLFILE to DUMMY early in the JCL conversion process, and that the few (only?) contributor[s] to this thread that maintain (without presenting evidence) that the behaviors differ perhaps have lingering memories of the status quo ante. Perhaps a reader with access to internal historical information can confirm or refute my surmise. -- gil -- StorageTek INFORMATION made POWERFUL ---------------------------------------------------------------------- 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
