You might consider the CLASSMAX. Assign the transaction to a unique
class number. Then set the CLASSMAX for that class number to 1. Similar
in concept to running with a single JES initiator handing an
"serialized" job class.
On Fri, 2011-07-08 at 12:07 -0700, John Weber wrote:
> We are looking to restrict a transaction from being run concurrently. We
> have launched two other
> transactions (the code below) that ENQ/DEQ this one transaction. Using
> displays we were
> expecting to see all of the displays of these two other transactions to
> follow one after the other;
> instead they are mingled. This suggests that they didn't run one after the
> other.
>
> Is the following code sufficient or even unworkable? I have read that
> ENQ/DEQ can be used for
> transactions and not only with shared memory resources.
>
> Also, does some other ENQ information need to be set up?
>
> Thank you so much...
>
> XXXX refers to the transaction id and XXXXXXXX refers to the program
> associated with this id.
>
> 000024 EXEC CICS
> 000025 ENQ RESOURCE(XXXX)
> 000027 RESP (WS-CICS-RESPONSE)
> 000028 END-EXEC
>
> 000038 EXEC CICS
> 000039 LINK PROGRAM('XXXXXXXX')
> 000040 RESP (WS-CICS-RESPONSE)
> 000041 COMMAREA (WS-PARAMETER)
> 000042 END-EXEC
>
> 000044 EXEC CICS
> 000045 DEQ RESOURCE(XXXX)
> 000046 RESP (WS-CICS-RESPONSE)
> 000047 END-EXEC
>
> ----------------------------------------------------------------------
> 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
--
John McKown
Maranatha! <><
----------------------------------------------------------------------
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
