|
View previous topic :: View next topic
|
| Author |
Message |
jcr
New User
Joined: 12 Apr 2007
Posts: 8
Location: Australia
|
|
|
|
| Hi. I am fairly inexperienced with IMS. I am developing an IMS transaction (A), which will switch messages to transaction B. Before doing so, it needs to check to see if transaction B is available, ie. not stopped. How do I do this? Thanks. |
|
| Back to top |
|
 |
Sandy Zimmer
Active Member
Joined: 13 Jun 2007
Posts: 826
Location: Wilmington, DE
|
|
|
|
| In production environments, when IMS is up and running, all transactions are also up and running. If a transaction is stopped, it has probably caused an abend. I have never seen anyone program for your described situation. |
|
| Back to top |
|
|
jcr
New User
Joined: 12 Apr 2007
Posts: 8
Location: Australia
|
|
|
|
| Sandy Zimmer wrote: |
| In production environments, when IMS is up and running, all transactions are also up and running. If a transaction is stopped, it has probably caused an abend. I have never seen anyone program for your described situation. |
It's quite a standard thing to do. If transaction B has abended and is stopped, transaction A wants to know about it so that it can feed an appropriate error response back through the middleware to the front end, rather than blindly switch a message to a stopped tran. Transaction B is supposed to send a response message, and without this error handling, the front end will wait for that response. The front end needs to be told when to give up asap. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| If transaction B has abended and is stopped, |
If transaction B has abended, it needs to be restarted. . .
If this is a production environment that so routinely encounters this sort of situation, i believe time would be better spent correcting whatever causes these abends rather than waste time on having other transactons concern themselves if something has abended.
Abends should be the very rare exception, not the thing we expect and code for. . . |
|
| Back to top |
|
|
jcr
New User
Joined: 12 Apr 2007
Posts: 8
Location: Australia
|
|
|
|
| dick scherrer wrote: |
Hello,
| Quote: |
| If transaction B has abended and is stopped, |
If transaction B has abended, it needs to be restarted. . .
If this is a production environment that so routinely encounters this sort of situation, i believe time would be better spent correcting whatever causes these abends rather than waste time on having other transactons concern themselves if something has abended.
Abends should be the very rare exception, not the thing we expect and code for. . . |
Transaction B is part of a different business system to transaction A. The need for it to be restarted is obvious, but is not down to the control or responsibility of my application team. It's owned and supported by a whole different area. Tran A's checking of it's availability, before relying on it, is a very standard and preventative approach. It is not based on a normal processing situation, it is based on an exceptional situation. But it is a situation which must be handled. In my 22 years of mainframe business application development, it would always have been seen as shoddy and careless to leave out such exception handling. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| But it is a situation which must be handled |
I agree - but not in the application. If the environment is such that this is a requirement it is a rather poorly managed environment. . . Well-run environments do not have this as an issue.
| Quote: |
| It is not based on a normal processing situation, it is based on an exceptional situation |
If you code for it, it is no longer exceptional. . . Sandy has been at this (IMS) longer than you've been in IT and her observation is something i echo:
| Quote: |
| I have never seen anyone program for your described situation. |
| Quote: |
| In my 22 years of mainframe business application development, it would always have been seen as shoddy and careless to leave out such exception handling. |
In my more than twice that long, it is considered shoddy if the production systems are not always "up". . .
FWIW- i truly sympathize if the "other" environment is so shaky that code is needed to detect if it is running/available, but i believe the organization's efforts would be better spent ensuring the system was available. . . |
|
| Back to top |
|
|
jcr
New User
Joined: 12 Apr 2007
Posts: 8
Location: Australia
|
|
|
|
[quote="dick scherrer"]Hello,
| Quote: |
| But it is a situation which must be handled |
| Quote: |
| I agree - but not in the application. Well-run environments do not have this as an issue. |
Our application needs to know about it if it happens. Simple as that. The environment does seem to be well run, it is not an issue which is expected to occur. But if it does, our application can't just be dumb and continue to switch messages to it. It needs to feed back to a waiting front end.
| Quote: |
FWIW- i truly sympathize if the "other" environment is so shaky that code is needed to detect if it is running/available, but i believe the organization's efforts would be better spent ensuring the system was available. . . |
It isn't shaky at all. But if exceptional conditions aren't handled properly in a system as critical as this one, the impact is very severe if the unexpected happens. You don't cross bridges when you come to them, you prevent the need in the first place.
This wasn't meant to be a debate on design, nor a measurement contest. The design side is taken care of, and unless somebody has the knowledge of this system and the requirements, which I can not legally go into, the design side should be left alone. I simply asked a technical question on how to do something in IMS. I would have hoped that the readers' efforts were better spent helping me by answering the question, rather than turning it into a design debate. Thanks. |
|
| Back to top |
|
|
Sandy Zimmer
Active Member
Joined: 13 Jun 2007
Posts: 826
Location: Wilmington, DE
|
|
|
|
| OK - my 2 cents - in every environment that I have EVER worked, if someone would need to PROGRAM to detect something that unusual - the system needs to be stopped and made unavailable until the support staff fixes that situation. In my experience tech services and operations just turned these systems to OFF mode until they were satisfied that an abend would be a million to one situation. Wouldn't the client (users) of that system be jumping up and down demanding it be fixed? |
|
| Back to top |
|
|
jcr
New User
Joined: 12 Apr 2007
Posts: 8
Location: Australia
|
|
|
|
| Sandy Zimmer wrote: |
| OK - my 2 cents - in every environment that I have EVER worked, if someone would need to PROGRAM to detect something that unusual - the system needs to be stopped and made unavailable until the support staff fixes that situation. In my experience tech services and operations just turned these systems to OFF mode until they were satisfied that an abend would be a million to one situation. Wouldn't the client (users) of that system be jumping up and down demanding it be fixed? |
This is a very large company with many many systems of many different platforms, many of which all talk to one another, with many many different user areas. I simply need the application I'm developing to neatly feedback the unavailability of another application on which it depends. The reasons why I need that are of no relevance to this thread. So with regard to my original question, I am assuming nobody knows the answer. Thanks. |
|
| Back to top |
|
|
Sandy Zimmer
Active Member
Joined: 13 Jun 2007
Posts: 826
Location: Wilmington, DE
|
|
|
|
| How large? How many online users? How many systems? Your interpretation of a very "large" system can be very different from mine. How about international? If you had a "very large system". then you would have tech services and operations people sitting on master terminals monitoring round the clock - like I did. If you had that, then you would know that they would not put up with a scenario such as you present. We could figure out how to do your thing - but WHY? |
|
| Back to top |
|
|
jcr
New User
Joined: 12 Apr 2007
Posts: 8
Location: Australia
|
|
|
|
| Sandy Zimmer wrote: |
| If you had that, then you would know that they would not put up with a scenario such as you present. |
Of course. I'm not asking them, or anyone else, to put up with this scenario if it were to happen.
| Sandy Zimmer wrote: |
| We could figure out how to do your thing - but WHY? |
Do you have to ask why? My question is not a 'should I or shouldn't I' question. That issue has been dealt with by others.
My question is a technical 'how do I' question. That's all I'm after. Thanks. |
|
| Back to top |
|
|
Gary Jacek
New User
Joined: 17 Dec 2007
Posts: 64
Location: Victoria, BC, Canada
|
|
|
|
| To answer the initial question, the programmer could use the DLI CMD call to issue commands /DIS TRAN B followed by the DLI GCMD call to determine if transaction B is stopped. Recent versions of IMS will also provide the PSBname associated with transaction B. The programmer should also issue command /DIS PGM Bx where "Bx" is the program associated with transaction B. Successful transaction scheduling requires that both be started. |
|
| Back to top |
|
|
|
|
