If I am reading the following quote from Murach's CICS Desk Reference right, I can issue multiple CICS START commands to the same CICS transaction passing it data and only one instance of the transaction will be started if the started transaction does multiple RETRIEVEs. "Usually, if two or more START commands specify the same expiration time and the same trans-id, one tasks will be started for each START command. However, if data is passed to the started task, only one task is started. If this task repeatedly issues RETRIEVE commands to process all of the data sent to it, then no additional tasks are started. But if it does not, the task is started again and again until all of the passed data has been processed."
However, when I try to do this CICS starts multiple copies of the started transaction. The started transaction does not have a terminal related to it. So I guess my question is can I do multiple starts on the same transaction and have CICS only start one copy of that transaction or should I be using a Transient Data Queue?
The CICS Desk Reference that you referred to is correct, but it may not have stated that the ability of a single STARTed transaction to issue multiple RETRIEVE commands to obtain the data associated with a series of START commands only applies to STARTed transactions associated with a CICS terminal. This is clearly documented in the CICS Application Programmers Guide. A START for a non-terminal transaction will always invoke a unique transaction and once STARTed the transaction may issue only a single RETRIEVE command to obtain any data associated with the START command that caused the transaction to be scheduled.
You may choose to use Transient Data rather than have the STARTed transaction associated with a CICS terminal, but there may well be design considerations to consider in that case as well. If you do so insure that the RDO definition for the intrapartition TDQUEUE, if you are using any of the CICS TS releases, specifies RECOVSTATUS(LOGICAL) to ensure that messages from more than one task issuing WRITEQ TD commands to the same TDQUEUE are not interleaved. If more than one task attempts to write to the same TDQUEUE and more than one message constitutes a single logical unit of work (LUW), then you will have to deal with the case where the transaction reading the TDQUEUE must determine when it has read the last message within an LUW. If a subsequent READQ TD is issued another message may be retrieved that belongs to a subsequent LUW and the QUEUEZERO condition may be raised before all messages associated with that LUW can be retrieved. The TDQUEUE must be defined and installed prior to any attempt to write to the queue, unlike TS queues, but this could be accomplished dynamically by using an EXEC CICS CREATE command to define a TDQUEUE with a unique name prior to writing to it. The task which reads the TDQUEUE could then read multiple records from the TDQUEUE until it encounters the QUEUEZERO condition and then issue and EXEC CICS DISCARD command to delete the queue definition.