Clients may desire to initiate a call to CICS from an IDMS program or dialog. This can be done, but only after the initial connection has been first established from CICS to IDMS.
Communication between IDMS & CICS must be initiated from CICS. Once that is done, IDMS can initiate actions in CICS via storage passed back and forth. CICS may also be able to start a timer-based task, and the IDMS task it invokes could check a queue to see if there are CICS tasks that have been requested (& stored in the queue). Finally, IDMS could initiate web services directly to communicate with SOLA or perhaps with CICS. More details on these options follow.
An IDMS task can be initiated by a CICS transaction by invoking a transaction id (transid) that invokes UCFCICS. If the CICS transaction acquires storage with id "PDAT", that will be passed over to IDMS and an IDMS TASK matching the CICS transid is invoked. When the IDMS task wants to send something back and start a CICS transid it must get new PDAT storage, putting into it data that the CICS trans will need, then #RETURN NXTTASK = 'taskcode'. This IDMS task code must invoke program RHDCUXFT and must be a valid CICS transid. RHDCUXFT uses the connection established when the transaction was initiated from CICS to pass the CICS transid and the PDAT storage over to UCFCICS who starts the named transid. This can go back and forth as many times as needed but it cannot originate from the IDMS side.
Here's an idea which extends the flexibility of this constraint and that may be feasible for you, but would not be simple. On the CICS side you could have a timer initiated transid that starts itself at some relevant interval and initiates the "PDAT" transaction. When the corresponding IDMS task is invoked on the back end it could check for the existence of a QUEUE record or some other mechanism that would indicate that a particular CICS transaction should be started. If that queue (or other condition) exists, the IDMS task prepares the PDAT storage and does #RETURN NXTTASK='xxxxx' to invoke RHDCUXFT and grabs the PDAT storage and does #RETURN NXTTASK='xxxxx' to invoke RHDCUXFT and start the CICS trans. If there is no queue record, the IDMS COBOL program just does plain #RETURN (DC RETURN in COBOL).
You could also accomplish this using an ADS application; it would have to create the QUEUE record or establish whatever the trigger is that would indicate that the CICS trans should be started, and potentially pass along whatever information is relevant as outlined above.
A second approach to establish communication from IDMS to CICS would be through initiating web service calls from IDMS, which would communicate with CICS.