View previous topic :: View next topic
|
Author |
Message |
Bitneuker
CICS Moderator
Joined: 07 Nov 2005 Posts: 1104 Location: The Netherlands at Hole 19
|
|
|
|
Hi folks,
During moderating this part of the forum we are often confronted with questions and advises floating between the posts of a topic. Amongst many (like Devzee) Sandy is a known member with very good ideas about IMS. Many good advised, not exactly covering the topic, might get lost in the 'deepness of reactions' and I think we should safeguard these. So....... this sticky is here to collect all golden advises on how to do what is best. It is not meant to be an open topic for nonsense; just a collection of wisdom about IMS. If anyone contributes and it's sensible your advise will be kept and treated as a diamant; if you post is nonsense or try to insult your post will be deleted and you risk a ban.
For now, as a starter, the following items for take off. Feel free to add items but keep in mind they are supposed to be key-items.
storing intermediate results techniques (SPA or whatever)
positioning (and remaining) in the databases (including command codes)
data- and processanalysis (including SI and bi-directional pointers)
funny stuff like formerly made mistakes |
|
Back to top |
|
|
Bitneuker
CICS Moderator
Joined: 07 Nov 2005 Posts: 1104 Location: The Netherlands at Hole 19
|
|
|
|
My own first post in this sticky is the following.......
IMS DC/DC is a very complex area because of it's hierarchical structrure and message processing techniques. A lot of people, well experienced in 'standard' design have no clue about the featherlite feeling one has to have in order to deal with IMS. It takes a new way of thinking and not just to think in the future but also in the past and the present (positioning). If you don't have these gift you are probably lost and should not even try to get into this wonderfull world called IMS. Alternatives for IMS like relational databases turn out to be less performant but they don't require the same knowledge of a technique. From the early start of IMS I was granted to grow in this system and believe me: once you understand it nothing can compete with it.
Of course it takes some training and education to get the skills to use IMS as it was supposed to be used. Elderly developpers who have been thourougly trained think of IMS as a normal way to handle. New ones will eventualy also see the benefits of this system if they are willing to take the time and effort to invest in it. |
|
Back to top |
|
|
Sandy Zimmer
Active Member
Joined: 13 Jun 2007 Posts: 826 Location: Wilmington, DE
|
|
|
|
George, I am going to add that there are varied approaches to the same problem.....what you always need to think about is what works best...for now and in the future. I always tried to put documentation within my programs - the more complex - the more I documented. If it is within the program, it won't disappear unless the program disappears. When someone else goes into your program, there it is - they don't need to spend hours looking for it or sit there forever trying to figure out what you have done. You are correct - there is nothing that can compete with IMS - it is super fast and the backup/backout capibilites cannot be surpassed. |
|
Back to top |
|
|
Bitneuker
CICS Moderator
Joined: 07 Nov 2005 Posts: 1104 Location: The Netherlands at Hole 19
|
|
|
|
An MPP is a Message Processing Program running in an online region. Normally there is only one occurence of the program running and serving many terminals at the same time. If there's heavy trafic in the region and a lot of programs are active it's common your application will be reloaded from the programlibrary with all it's initials set to the virgin value. However, if there's little trafic in the region your MPP might reside there. This includes that, if you don't save and restore values set or caused by an earlier transaction from a different terminal, your MPP might use those values and cause misfunction of the businessprocess. How should this MPP know from which terminal the message came and how to proceed processing.........?
Lesson: Always save your intermediate results and switches between transactions, init them before processing the next message and restore them from wherever you stored them and after that process your message. After processing your message store the relevant fields in order to be able to proceed to the next message processing; your MPP has to know where the user left it and what the expectation is for further processing. For this storage you can use a SPA (Scratch Pad Area), the MID/MOD, a kind of SPA-database or whatever. Just keep in mind that, if you don't safeguard information, the results of a conversation from a specific terminal don't guarantee the conversational intermediates are safe and may lead to wrong business processes. |
|
Back to top |
|
|
Bitneuker
CICS Moderator
Joined: 07 Nov 2005 Posts: 1104 Location: The Netherlands at Hole 19
|
|
|
|
In order to improve performance regarding transaction/message processing concatenate 'X'3F' at the last relevant information thus telling IMS to ignore the useless rest of the message. It saves time and money. |
|
Back to top |
|
|
naveengec
New User
Joined: 24 Mar 2007 Posts: 35 Location: pune
|
|
|
|
Hi Bitneuker, it will be really useful if you can elaborate the last scrap. Where do we need to put 'X'3F', is it in MFS or in MPP program. |
|
Back to top |
|
|
Sandy Zimmer
Active Member
Joined: 13 Jun 2007 Posts: 826 Location: Wilmington, DE
|
|
|
|
You can also send a shorter message - adjust the message length for the ACTUAL length of the data being sent. You cannot, however, send a zero message length. |
|
Back to top |
|
|
|