On Tue, 5 May 2015 09:45:57 -0400, Steve Thompson wrote: > >How does the O/S know that this data set will never be used? Is >it because of the PGM=IEFBR14? > Yes.
>Can't I have a STEPLIB with IEFBR14 in it? > IBM's design decision to HDELETE withoout HRECALL is based on the presumption that that any PGM named IEFBR14 will not use such a data set. >Suppose that I am using some utility that needs works space. So I do: > >//SYSUT?? DD DSN=A.B.C,DISP=(NEW,DELETE),SPACE=(CYL,1000), >// UNIT=3390,DCB=(WHATEVER) > >The system should just KNOW that it should not do the allocation >because it's gonna be deleted any way? > Given that PGM=IEFBR14, yes. >Do you have any idea how many SEV1 Critsits IBM would be looking >at if they were to suddenly do this? > No. How many? On 2015-05-05, at 07:59, R.S. wrote: >[...] > But it raises a question: what is actual purpose of IEFBR14? >The only uses of IEFBR14 I have ever observed are: >a) "IEFBR14+DISP" combo - but this is "misues" >b) some exercices with CONDs in JCL learning process (marginal use of course). I use it in practice, not just learning, as STEP0 so the otherwise first step can be suppressed with COND or IF. Someone else raised the issue that the cost of allocation, two trips through DADSM, considerable disk I/O, etc. is neglgiible. Yet, in days of yore, the operator needed to START DUMMY after VARY OFF in order to drive Allocation to ensure the unit was truly offline. I assume the design decision not to have VARY itself drive allocation was based on those performance considerations. --gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
