|
View previous topic :: View next topic
|
| Author |
Message |
cennini
Warnings : 1
New User
Joined: 18 May 2009
Posts: 5
Location: Florence, Italy
|
|
|
|
Hi, is it any way to retrieve the name of the calling program in a routine ?
For example, program A1 can call program B, but also program A2 can call program B, and also program A3, and so far: how can I know in program B if i'm called by program A1 or A2 or A3 without any specific application field in communication area ? Is it any area in MVS to obtain this information ?
Thanks
Alberto |
|
| Back to top |
|
 |
Ketan Varhade
Active User
Joined: 29 Jun 2009
Posts: 197
Location: Mumbai
|
|
|
|
Hi,
What is the requirement, why do you want to know the called module,
In generally in practice when one sub routine is been called my many program then some identifier is been passed to the calling module, to identify the calling module |
|
| Back to top |
|
|
cennini
Warnings : 1
New User
Joined: 18 May 2009
Posts: 5
Location: Florence, Italy
|
|
|
|
| Ketan Varhade wrote: |
Hi,
What is the requirement, why do you want to know the called module,
In generally in practice when one sub routine is been called my many program then some identifier is been passed to the calling module, to identify the calling module |
Hi, I need to perform something different if the calling program is a particolar one. I don't have space in the communication area and I don't want to enlarge it and recompile all the calling program.
I would like to obtain this information from MVS system areas, but I don't know where is this information, but samewhere it must be stored, because it is used when the subroutine perform a GOBACK.
Alberto |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
| Alberto wrote: |
| I would like to obtain this information from MVS system areas, but I don't know where is this information, but samewhere it must be stored, because it is used when the subroutine perform a GOBACK |
no, you are wrong. You need to read about call chains.
Your description of the situation suggests that you have multiple function
requirements in your called module.
if you were not smart enough to plan ahead, you are stuck. enlarge your pass-along area and include a function code like the big-boys do. What if this second functionality includes more than one module- you spend all your time looking for module names instead of designing your subroutine properly with function codes. |
|
| Back to top |
|
|
cennini
Warnings : 1
New User
Joined: 18 May 2009
Posts: 5
Location: Florence, Italy
|
|
|
|
| dbzTHEdinosauer wrote: |
| Alberto wrote: |
| I would like to obtain this information from MVS system areas, but I don't know where is this information, but samewhere it must be stored, because it is used when the subroutine perform a GOBACK |
no, you are wrong. You need to read about call chains.
Your description of the situation suggests that you have multiple function
requirements in your called module.
if you were not smart enough to plan ahead, you are stuck. enlarge your pass-along area and include a function code like the big-boys do. What if this second functionality includes more than one module- you spend all your time looking for module names instead of designing your subroutine properly with function codes. |
I'm confident to find the way, but if you don't know how please stop replaying with your everybody-knowed soluction. Thanks |
|
| Back to top |
|
|
Binop B
Active User
Joined: 18 Jun 2009
Posts: 407
Location: Nashville, TN
|
|
|
|
Hi Cennini
Welcome to the forum... but not a good way to start by taking on one of our senior members... 
What Dick suggested is the most practical approach. Please understand he was only trying to help you...
| Quote: |
| I would like to obtain this information from MVS system areas, but I don't know where is this information, but samewhere it must be stored, because it is used when the subroutine perform a GOBACK. |
You are half correct when you said that the called program information is stored somewhere. As far as i have understood, what is actually getting stored in the next instruction address after the CALL statement. When a GOBACK instruction is executed it goes basically to this address. If you are having a little knowledge on assembler, you should be able to understand it. Otherwise it might look a little confusing.
As far as your initial question "to retrieve the name of the calling program in a routine" goes, I am not aware of anything and seems highly unlikely. Anyway if you do find it, please post the same. |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
cennini,
You are going to be chasing program names with your called module.
this means everytime a new/different program needs the same functionality, instead of supplying a decent function code, you will need to recode,recompile,relink,retest your called module because now you have to look for a 2nd (or 3rd) module name. Clever.
for a someone who does not know very much,
you are very flippant about deciding which info you will take and which you won't.
I had to respond because what you are advocating is real dribble - garbage.
And will continue to follow your posts
because what you advocate is non-professional solutions,
which I will notate for those who do not wish to be lead astray.
If you don't like it, tough. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
| Back to top |
|
|
cennini
Warnings : 1
New User
Joined: 18 May 2009
Posts: 5
Location: Florence, Italy
|
|
|
|
| dbzTHEdinosauer wrote: |
cennini,
You are going to be chasing program names with your called module.
this means everytime a new/different program needs the same functionality, instead of supplying a decent function code, you will need to recode,recompile,relink,retest your called module because now you have to look for a 2nd (or 3rd) module name. Clever.
for a someone who does not know very much,
you are very flippant about deciding which info you will take and which you won't.
I had to respond because what you are advocating is real dribble - garbage.
And will continue to follow your posts
because what you advocate is non-professional solutions,
which I will notate for those who do not wish to be lead astray.
If you don't like it, tough. |
Dick, I'm a consultant and my customer don't want to change the interface area and recompile all the calling programs (more than 2000).
Anyway, I founded the soluction addressing TCB of the calling program. Believe me, I can't do anything else.
Thanks
Alberto |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
| Quote: |
| program A1 can call program B .... |
learn to word better Your questions
Your wording implied ... to follow the call hierarchy ...
if You had specified that You wanted to know just the name of the main load
You should have told that from the beginning
and we would not have lost time in useless free consulting
and told You to chase the CDE chain with a couple of quirks for IMS and DB2 programs |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
Alberto,
since this module is called by some 2000 - to do the same thing,
and only 1 calls for a different thing:
I would have created a new module only to be called by the oddity.
Changing 2000 programs is not a problem. Testing them is............ |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
If this is any help, the current TCB address can be found in low-core at X'21C'.
Bill |
|
| Back to top |
|
|
cennini
Warnings : 1
New User
Joined: 18 May 2009
Posts: 5
Location: Florence, Italy
|
|
|
|
| Bill O'Boyle wrote: |
If this is any help, the current TCB address can be found in low-core at X'21C'.
Bill |
Bill, it works perfectly !! Thanks.
Alberto |
|
| Back to top |
|
|
|
|
