IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

Retrieve the name of the calling program


IBM Mainframe Forums -> COBOL Programming
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
cennini
Warnings : 1

New User


Joined: 18 May 2009
Posts: 5
Location: Florence, Italy

PostPosted: Wed Aug 26, 2009 2:08 pm
Reply with quote

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
View user's profile Send private message
Ketan Varhade

Active User


Joined: 29 Jun 2009
Posts: 197
Location: Mumbai

PostPosted: Wed Aug 26, 2009 2:23 pm
Reply with quote

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
View user's profile Send private message
cennini
Warnings : 1

New User


Joined: 18 May 2009
Posts: 5
Location: Florence, Italy

PostPosted: Wed Aug 26, 2009 5:25 pm
Reply with quote

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
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Wed Aug 26, 2009 6:01 pm
Reply with quote

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
View user's profile Send private message
cennini
Warnings : 1

New User


Joined: 18 May 2009
Posts: 5
Location: Florence, Italy

PostPosted: Wed Aug 26, 2009 6:30 pm
Reply with quote

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
View user's profile Send private message
Binop B

Active User


Joined: 18 Jun 2009
Posts: 407
Location: Nashville, TN

PostPosted: Wed Aug 26, 2009 6:51 pm
Reply with quote

Hi Cennini

Welcome to the forum... but not a good way to start by taking on one of our senior members... icon_neutral.gif
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
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Wed Aug 26, 2009 6:52 pm
Reply with quote

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
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10886
Location: italy

PostPosted: Wed Aug 26, 2009 7:52 pm
Reply with quote

ok since I am in a good mood I will try to explain a few things

in well planned and written program there are rules about save area chaining
HLL ( high level languages ) are well behaved and follow the rules with some add ons

for assembler user written program the issue is a bit murky
the called program expects to find ... as a general rule
the entry address in register 15,
the return address in register 14,
the save area address in register 13
but that' s a programming convention, not a POP effect

see
publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dz9zr003/5.3.3?SHELF=DZ9ZBK03&DT=20040504121320#HDR05AH24
and
publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9ZR003/5.10.2.2?SHELF=DZ9ZBK03&DT=20040504121320

the bakr and pr stuff ( branch and stack / program return )
publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dz9zr003/10.2?ACTION=MATCHES&REQUEST=bakr&TYPE=FUZZY&SHELF=DZ9ZBK03&DT=20040504121320&CASE=&searchTopic=TOPIC&searchText=TEXT&searchIndex=INDEX&rank=RANK&ScrollTOP=FIRSTHIT#FIRSTHIT
have changed a bit the situation, but I do not expect the average application programmer to use it

the POP tells nothing about save areas
the convention for well behaved things is to use the second and third word of the savearea
as backward and forward links (*)
a good habit would be to initialize to 0 the current savearea forward chain

so nothing can be generally discovered by back following the saveara chain
unless a lot of other conventions are put in place

HLL language follow this last approach and their inernal setup lets the internal service
routines discover a bit more, but that' s all

for pl1 a source of additional info would be the are pointed by GPR 12 ( the TCA )

an assembler user program who wanted to discover more thing would have to be aware
of the calling language and sometimes even of the version/release of it
Back to top
View user's profile Send private message
cennini
Warnings : 1

New User


Joined: 18 May 2009
Posts: 5
Location: Florence, Italy

PostPosted: Wed Aug 26, 2009 7:55 pm
Reply with quote

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
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10886
Location: italy

PostPosted: Wed Aug 26, 2009 8:04 pm
Reply with quote

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
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Wed Aug 26, 2009 9:31 pm
Reply with quote

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
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA

PostPosted: Wed Aug 26, 2009 9:54 pm
Reply with quote

If this is any help, the current TCB address can be found in low-core at X'21C'.

Bill
Back to top
View user's profile Send private message
cennini
Warnings : 1

New User


Joined: 18 May 2009
Posts: 5
Location: Florence, Italy

PostPosted: Wed Aug 26, 2009 11:06 pm
Reply with quote

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
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> COBOL Programming

 


Similar Topics
Topic Forum Replies
No new posts Error to invoke MPP program through B... IMS DB/DC 3
No new posts Using API Gateway from CICS program CICS 0
No new posts Calling DFSORT from Cobol, using OUTF... DFSORT/ICETOOL 5
No new posts Calling Java method from batch COBOL ... COBOL Programming 5
No new posts Calling an Open C library function in... CICS 1
Search our Forums:

Back to Top