moezbud
New User
Joined: 03 May 2016 Posts: 12 Location: usa
|
|
|
|
We have a new process that we implemented that is not working very efficiently.
Basically, we have a CICS program that receives a request for all customer information. The program then reads a customer master that has many (sometimes dozens) of trailers. Each trailer has a key to an account on a different application. The program cycles through the trailers sequentially, reads the information from the master indicated on the trailer and then formats part of a response back to the caller. When all of the trailers are processed, one full response is returned to the calling program.
The problem is that one application in particular is very slow for each individual response (we're not just reading a file on our system - we have to call a program that transmits the query out to another vendor and finally returns it back to the program) . So, if the customer has a lot of accounts on this application, we can sometimes time out when we're processing sequentially like this.
I started looking into processing the transaction asynchronously. I want to fire off all of my requests to the slow application first, process all remaining trailers and then come back and collect all of the responses that come back from my initial requests.
I was pretty excited when I saw the Run and Fetch APIs. They address exactly what I'm looking for. Unfortunately, we don't have that CICS version.
Instead, it sounds like START and RETRIEVE may be what I need to go with. Is it correct that I can shoot off a START for each one of my "slow" application requests and come back with a RETRIEVE at the end of my processing to pick them back up? If so, what kind of response do I get if the RETRIEVE isn't ready yet? Can I just move onto the next one (recycling through until I finally get them all)?
Or, is there a better way of doing this? i.e. Would it be better to have each of the started transactions write their responses to a temporary queue and just have my main, calling program read the queue as a final step? Or... something else?
Thanks for any input! |
|