Paul, I just tried this, and this seems to work out OK. So I suppose I can do the following:
JOB 1 STEP1 : get dataset list and pass it onto for the job 2 generation JOB 2 STEP1 : do the mq fte work JOB 2 STEP9: put an enqueue OLD on the datasets obtained from JOB 1 I've tested with this basic job (below) and found that even though STEP9 has an OLD enqueue, intermediate steps (STEP2-8) in JOB 2 can work with the dataset(s). Not sure if the MQ FTE address space will complain about this job holding the datasets now... // FANCY PANTS JOB CARD //STEP000 EXEC PGM=BPXBATCH,PARM='sh sleep 10s' //* //STEP001 EXEC PGM=IEBGENER //SYSUT1 DD DISP=SHR,DSN=some.cool.dataset //SYSUT2 DD SYSOUT=* //SYSPRINT DD SYSOUT=* //SYSIN DD DUMMY //* //STEP002 EXEC PGM=IEFBR14,COND=(0,NE) //FILE1 DD DISP=OLD,DSN=some.cool.dataset //FILE2 DD DISP=OLD,DSN=some.cool.datasett //SYSPRINT DD SYSOUT=* //FILES DD SYSOUT=* //SYSTSPRT DD SYSOUT=* //SYSTERM DD SYSOUT=* //SYSIN DD DUMMY //SYSTSIN DD DUMMY – Vignesh Mainframe Infrastructure -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Paul Gilmartin Sent: Saturday, June 25, 2016 1:19 AM To: [email protected] Subject: Re: Dynamic enqueue creation On Fri, 24 Jun 2016 10:27:16 -0500, Walt Farrell wrote: >On Fri, 24 Jun 2016 15:17:50 +0000, Sankaranarayanan, Vignesh wrote: > >>This is to cope with MQ FTE's "feature" of not locking datasets for the >>duration of a transfer. >> >>Using ANT scripts to initiate a transfer of a list of datasets that >>resolve to a wildcard, we've found that in the time gap between the >>initial resolve of the wildcard and the transfer of datasets found in >>the wildcard, those datasets are processed by some other entity, >> That hazard exists for any process that generates the list and processes it in separate operations. >>leaving the MQ FTE step to fail saying dataset deleted (already processed). > If the MQ process were to fail more gracefully, issuing an error message and proceeding to the next entry you'd be better off. Data sets created in the window might yet pose a problem. >>There's the outcome=defer option in the ANT script but I don't believe >>it has led to the job to stay active until the MQ FTE transfer completes >>fully. > If your objects were members of a PDSE rather than data sets (but that would be a major design change) DESERV might be able to make a member list and establish lasting connections in an atomic operation. (I haven't tried it.) Or you could ENQ EXC on the entire library, locking out all other users. If your objects were UNIX files (but that would be a major design change) you might play games with directory links. Was MQ designed as a multi-user facility? It seems to lack locking, COMMIT, and ROLLBACK. >I am concerned that your allocation as OLD will prevent the subsequent use of >them for transfer in a later job-step. It may work, but it may not. That is, >if you have a data set allocated OLD by your exec, and then a later step in >your job tries to do a dynamic allocation either SHR or OLD I think that later >allocation may fail. > A batch job (drawbacks already discussed) could ENQ all in a monolithic operation, waiting for others to become available. >Plus, you have my initial concern that your use of ALLOC in the exec may >itself fail if someone else has the data set allocated already. > I do much of my Rexx work under z/OS UNIX with _BPX_SHAREAS=NO so I needn't worry about freeing resources before address space termination. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN MARKSANDSPENCER.COM ________________________________ Unless otherwise stated above: Marks and Spencer plc Registered Office: Waterside House 35 North Wharf Road London W2 1NW Registered No. 214436 in England and Wales. Telephone (020) 7935 4422 Facsimile (020) 7487 2670 www.marksandspencer.com Please note that electronic mail may be monitored. This e-mail is confidential. If you received it by mistake, please let us know and then delete it from your system; you should not copy, disclose, or distribute its contents to anyone nor act in reliance on this e-mail, as this is prohibited and may be unlawful. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
