I have requirement to invoke the existing MPP IMS Online program through a BMP batch process, where reading the transaction details from a input file and write it to IMS Queue per transaction data layout, this will trigger the existing IMS online screen program and get the response for IMS-DB enquiry per I/O layout for the BMP program.
Here I followed below steps in a batch program via BMP process-
Code:
1. Setup transaction data for Online program
CALL PLITDLI (ARG3, CHNG, ALT_PTR, 'TRANCODE ');
2. Insert transaction data to the IMS Queue
CALL PLITDLI (ARG3,ISRT,ALT_PTR,IOAREA);
3. Read the response in batch program
CALL PLITDLI (ARG3,GU,IO_PTR,IOAREA);
My program is failing at 3rd step when reading the response from IMS Queue with Status Code = 'AD'
Note: I am using a existing PSB which is doing I/O operation for ALT_PTR with PCB option 'MODIFY = 'Y'
Can anyone please suggest if I am missing anything or what could be reason for the error.
I have requirement to invoke the existing MPP IMS Online program through a BMP batch process, where reading the transaction details from a input file and write it to IMS Queue per transaction data layout, this will trigger the existing IMS online screen program and get the response for IMS-DB enquiry per I/O layout for the BMP program.
Here I followed below steps in a batch program via BMP process-
Code:
1. Setup transaction data for Online program
CALL PLITDLI (ARG3, CHNG, ALT_PTR, 'TRANCODE ');
2. Insert transaction data to the IMS Queue
CALL PLITDLI (ARG3,ISRT,ALT_PTR,IOAREA);
3. Read the response in batch program
CALL PLITDLI (ARG3,GU,IO_PTR,IOAREA);
My program is failing at 3rd step when reading the response from IMS Queue with Status Code = 'AD'
Note: I am using a existing PSB which is doing I/O operation for ALT_PTR with PCB option 'MODIFY = 'Y'
Can anyone please suggest if I am missing anything or what could be reason for the error.
Also, how we know if my MPP program is triggered after ISRT function put message to Queue successfully ( STATUS CODE = ' ') ?
Thanks for the reply. Now the BMP batch process is completing successful i.e the job completed with MAXCC = 0.
But the online transaction program(which should start with transaction trigger) is not getting started, means through my BMP batch program I am inserting the transaction data to IMS Queue through CHG, ISRT and reading IOAREA through GU DLI call, but as a result getting same message as input not the expected output enquiry data.
I put some display statement in Online program to check if program initiated once transaction TRAN1 is added to queue. But no display statement found in online IMSLOG.
Also, check the /for dis tran TRAN1 and seeing the ENCQT count is increasing on every run. That means my transaction is writing to IMS Queue but the associate online transaction program is not getting started and when reading this IOARA through GU call reading the same Input transaction data.
The Online IMS log showing the log of BMP process as started and stopped.
Can I get any suggestion on - why the online program is not getting initiated though the Transaction is getting inserted to IMS Queue.
Joined: 17 Dec 2007 Posts: 66 Location: Victoria, BC, Canada
Hi Ravi
Your Step3 is really mean to allow WFI (Wait For Input) BMP programs to retrieve transaction input from the input queue, or a program that issues CMD calls to retrieve the results of the command.
I can anticipate a few problems with your processing here.
First, if you are inserting a large number of TRAN1 onto the input queue from your BMP, have you considered how that may impact real users submitting the same TRAN1 transaction and waiting for response?
Quite often I have fielded trouble calls where real users complained of abysmal response time, only to find that a BMP had placed 10,000 transaction instances on the input queue. If each transaction takes only 1 second elapsed time, and the transaction cannot be run as parallel instances in many message processing regions, that poor online user will wait nearly 3 hours for response. This is very poor design.
Quite often I have seen BMP that have placed far more than 10,000 transaction instances on the input queue. This results in a message queue full condition, and an IMS automatic shutdown. Before you plan to do this, you should alert your IMS sysprog of the volumes to expect so they may configure the message queues to acomodate this new workload. Trigger this kind of problem in production at your peril.
Because of how IMS treats the BMP and the online transactions (your TRAN1) as separate units of work, your design only works if the BMP is set up to “fire and forget”. In effect, it initiates your TRAN1 but expects no response from TRAN1. This is also a poor design as your BMP has no confirmation about when or if the work is complete.
Since you appear to need some data back from TRAN1, you are much better off taking the code from TRAN1 and incorporating it into your BMP program, rather than invoking TRAN1. I understand this may not be possible if TRAN1 runs on a different IMS Control Region compared to your BMP. An example of this would be in a Multiple Systems Coupling environment where the BMP must run on IMSA but your TRAN1 runs on IMSB and IMSA has no access to databases used by IMSB.