Your job will continue to enq the dataset until the last step that allocates it in the JCL. When you remove step 4, the dataset is no longer enqueued by your job after step 2. That being said, I don't see why that would stop step 3 from executing.
Step 3 is basically scheduling your C:D process. It doesn't actually execute it. You can not assume the copy is finished when step 3 is finished. You can put multiple tasks/steps in your C:D process, as well as IF-statements. You might be able to run step4 as a 'RUN TASK' within the C:D process. For a lot of our jobs we have the C:D process set a TWS special resource to trigger the rest of the processing within TWS. Bart -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of NIGEL WOLFENDALE Sent: Monday, August 08, 2011 11:27 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Allocation Conflict with Job Bart, I wondered about that - yes we (I say we - I'm the sysprog trying to sort out his allocation problem - I know virtually nothing about C:D) are using DMBATCH - so that means the CD address space is doing the transfer ? However it is the DMBATCH step (step 3 in my scenario) that is waiting for datasets - we don't get to step 4. Nigel Nigel Wolfendale nigel.wolfend...@btinternet.com ________________________________ From: "van der Grijn, Bart (B)" <bvandergr...@dow.com> To: IBM-MAIN@bama.ua.edu Sent: Monday, 8 August, 2011 16:08:49 Subject: Re: Allocation Conflict with Job I assume Step 3 actually scheduled the C:D process to be run by the C:D started task using the DMBATCH program. It doesn't actually perform the copy. So when you run Step 4, how do you know the C:D process has finished? Have you considered running the 'Step 4' program as a step in the C:D process? Bart -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Nigel Wolfendale Sent: Monday, August 08, 2011 10:17 AM To: IBM-MAIN@bama.ua.edu Subject: Allocation Conflict with Job 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 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 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 ? ---------------------------------------------------------------------- ---------------------------------------------------------------------- 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
