Nigel Wolfendale wrote:
I have a job with four steps:
Step 1 IEFBR14 - allocate a specific dataset = (MOD,DELETE) - to make sure it
is not there
Step 2 allocate it (NW,CATALOG,DELETE) - this step does not open the dataset
Step 3 Use Connect Direct to write to this dataset from the LAN - the dataset
name is in the CD statements - so it needs to be dynamically allocated.
Step 4 IEFBR14 - DISP=SHR
Even though this step says DISP=SHR, the previous DISP=MOD/DISP=NEW will make
the allocation for Step 4 appear to be exclusive. I imagine C:D is attempting a
non-exclusive allocation from it's address space and is failing because of the
allocation in your address space.
The last step is planned to be a program which extracts data from the dataset -
this step is here just to demonstrate the problem.
When we run the job we get message IKJ56225I - dataset is allocated to another
job or user - try again later (or words to that effect), now the job won't run.
If we remove the fourth step then it runs OK
Removing Step 4 works because the allocation enqueue is released after the last
referencing step.
We are on z/OS 1.10 (JES2) - we use MIA (MIM)
We have several systems - no parallel sysplex, and virtually no shared disk.
This behaviour seems intuitively wrong - but is it normal - am I missing
something ?
A trick I have used in similar situations is to use IDCAMS to ALTER NEWNAME the
dataset and then reference the new name in subsequent JCL.
Bob
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
