Where will the control go after displaying the screen?

saidharrao · Posted: Thu Feb 15, 2007 6:56 pm

I have a basic question in IMS DC.

There is an IMS DB DC program of 500 lines. I am displaying a screen from this program. The corresponding ISRT call is there at the 200th line.

Ex:

Bitneuker · Posted: Thu Feb 15, 2007 7:47 pm

Basic questions deserve a basic answer. Once you sent the message you leave the application that sent the screen. After the user entered his data and hit the ENTER-key a message is sent to the message queue. In due time IMS will invoke the application belonging to the transaction because it has read a message from the message queue for it. Your application may or may be not in the region (depending how heavy traffic is) but will start at the beginning: performing a GU on the message queue. Usually before that a GU for the SPA in order to find out which part of the application has to be processed. Also keep in mind that only one application can serve hundreds of terminals. As processing by users is async each terminal has a SPA supplied when the first transaction code has been entered. That way the application knows what to do next without knowing from which terminal the message was sent.

So no.......it's not statement 201 though it might be if this is the statement where the terminal response is processed; but always after the GU of the message.

amitchaudhary · New User Joined: 13 May 2005 Posts: 8

The above answer was for pseudo conversation programs, for non conversational programs when the program sends the data on the screen using ISRT call the program ends and is not at all waiting for the user to enter data, thats how multiple users can run the same program. also as IMS DC is single threaded i.e. at a time there is only one request being processed from the Transaction queue) so in your case if you go out for a coffee and came back after 30 min so logically program should not wait for such a long time.

later on when u enter some data and press Enter the request goes in to the Transaction queue and the program will run from the start. now its your desing has to take care that you have to pass the key values from the second screen also to the main program so that he knows which data I have to process. if your MOD doesnot have that much space and you dont have any key field on the screen which identifies the key of the record which needs to be proceessed then its better to use SPA.

Bitneuker · Posted: Thu Feb 15, 2007 11:52 pm

Amit,

Please do some carefull reading before reacting; what you describe is exactly what I posted. When I write 'in due time' it means that the application will be invoked when it's scheduled because a message was causing it. In due time means that the transaction might have a low priority or there are a lot of messages to be processed from other terminals.

saidharrao · Posted: Fri Feb 16, 2007 5:07 pm

HI George and Amith,
Many thanks for your valuable and timely reply. I need some more help from you. In my program, I am throwing a screen namely screen1. Then I will receive the values from screen1 and manipulate. Based on that, I need to throw screen2 with some options. User will select one of those options and hits 'ENTER'. Based on the values entered in screen2, we have to throw the screen3 with some options and so on. And similary at any point of time we can switch to another transaction and that also based on the received values from any screen. All this has to be handled in a single program where there will be one program for each transaction.For this I thought of using SPA (Ofcourse I am not sure of how to use SPA). But is there any other way to handle this without using SPA?

Regards,

Bitneuker · Posted: Fri Feb 16, 2007 7:40 pm

Saidhar,

There are usually 2 ways of passing control to another application. One is by modifying the transactioncode in the SPA and the other one is to perform a change call (CHNG) followed by a message for the application to take over control. In this message you may send the information the application needs.

Personally I prefer using a SPA since you can store intermediate results (counters, switches etc) and your mainapplication will get control back after the alternate application has done it's work. So the logic of what the mainapplication should do after regaining control is easily stored in the SPA. For each application you may reserve space for it in the SPA.

For the CHNG-call you will need one PCB type TP and MODIFY=YES as well as in your application an IO-PCB followed by an ALTERNATE-IO-PCB. More info may be find following the first link in my signature and search for CHNG. Also some posts may be found in this forum.

Bitneuker · Posted: Fri Feb 16, 2007 7:48 pm

Also have a look at the topic of krishna_mf; he finally (almost) succeeded in having a CHNG-call work

saidharrao · Posted: Thu Feb 22, 2007 3:24 pm

Hi George,
Thanks a lot for the reply. Now I have another doubt. As I told earlier, I am throwing a screen from my program(note that I am having one program for each transaction).And based on the values that user has entered I have to throw another screen and so on. And everytime I have to compare whether the values that i have thrown to user are same when i reveived the user response. But if we store the values in working-storage before throwing the screen, the values will be gone before we reenter into the program.Then how to save these values. From your reply I found that we can use SPA for this.
1) Can SPA be used only for this reason (to store the intermediate values)? Is there any other method?(Read in the book that we can use a screen or a database other than SPA, but not efficient).

2) And if we use SPA, do we need to switch the transaction only through SPA or can we also do through ISRT call. I mean thoguh we have defined SPA, can we switch the transaction through CHNG call? that means we are using SPA only to store the intermediate values.

3) Let us suppose that we have 50 transactions in a system. I have defined 30 transaction with SPA and 20 without SPA. Can we still switch from one of those 20 to one of those 30 or vice versa? Remember we are NOT using SPA to switch between the transactions. Our purpose of having SPA here is only to store the intermediate values.

4) If we want to switch between the transactions using SPA then how to do that(Though you have mentioned in the earlier reply, can you please give more details?)? For this, is there anything that to be mentioned in the definition of transaction?

Awaiting your invaluable reply,

Regards,

Bitneuker · Posted: Thu Feb 22, 2007 4:27 pm

saidharrao · Posted: Thu Feb 22, 2007 6:41 pm

Hi George,
Thanks a lot. Your answers are helping us a lot in progressing with the project. I have one more query in this regard.

1) How costlier is a call to SPA? I mean, we issue a GU call as the first call in the procedure division to get the SPA copied into the program and each time we throw the screen, we issue an ISRT call to save the SPA.

Will these calls effect the performance of the system? Can we compare these calls with a normal Database call in terms of cost/time? Some people are telling that two calls of SPA(GU, ISRT) is equal to one databse call. Can you please clarify me on this?

Awaiting your one more valuable answer,
Regards,

Bitneuker · Posted: Thu Feb 22, 2007 6:53 pm

Like I wrote before the SPA may be in storage memory or on DASD. You will understand that memory-SPA is faster though both methods require the GU and ISRT at the IO-PCB. Calls at the IO-PCB are the most optimated calls that exist since you don't define your own DBD etc. for it; the IO-PCB refers to the message queue. Don't worry about the costs and/or performance. In my opinion the times we stored SPA-data in messages for optimisation reasons lies far behind us. Check with your system administrator what K your SPA is allowed for memory storage.

Bitneuker · Posted: Thu Feb 22, 2007 7:00 pm

To learn more about SPA follow the first link in my signature and search for SPA. Amongst others you will find this one and also this