In a recent note, Ted MacNEIL said:
> Date: Thu, 26 Apr 2007 01:47:35 +0000
>
> I don't thinks that's accurate.
> DSN allocation is not cleared until EOJ.
> Hence the scramble with GDG's in a job, especially if you create more than
> one in
> the same one.
>
I don't understand this "allocation" thing at all. Are you
saying that if I do:
//STEP1 EXEC PGM=IEFBR14
//SYSUT1 DD DISP=(MOD,DELETE),DSN=FOO.BAR
...
//STEP99 EXEC PGM=IEFBR14
//SYSUT1 DD DISP=(NEW,CATLG),DSN=FOO.BAR
.. the data set remains "allocated" through any intervening
steps, even while it doesn't exist?
> The same thing can be proven with allocation for step N.
> Allocate a DSN under TSO and then submit a job.
> Even if a job will not touch the file for hours, the job will hang in ENQ.
> It's even 'worse' in a JES3 environment.
>
Is that "allocated" or just ENQueued?
> The only way around it is dynamic allocations; then you have synchronisation
> issu
> es.
>
> All OS's have enq-like structures, or they have data integrity issues.
>
> Don't try to outsmart them; you'll outsmart yourself!
>
Indeed. Cf. OA20339: NFS SERVER HOLDS ENQUEUES ON MVS DATASETS.
MVSNFS does its own ENQueues and maintains a reference count
(incorrectly). It's a mystery to me why it holds ENQueues other
than those that allocation maintains (presumably correctly).
But that was Walt's question, wasn't it?
But, MVSNFS uses ISPF conventions for PDS member serialization
in order to avoid unnecessary conflicts, and maintains ISPF-style
member statistics. More utilities should do the same. (Or, as
Shane evidently expects, I feel there should be a common service
to do that.) MVSNFS doesn't run ISPF under the covers, does it?
-- 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
