|
View previous topic :: View next topic
|
| Author |
Message |
nightbuzzz
New User
Joined: 04 May 2007
Posts: 21
Location: kuala lumpur
|
|
|
|
Hi Al,
There is a scenario i am facing and want a little help..
My COBOL program gets executed multiple times in different JCL's and every time i have to identify in which JCL it is getting executed. How can i achieve that except passing the JOBNAME thru PARM.
Thanks in advance.
Mayank |
|
| Back to top |
|
 |
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10888
Location: italy
|
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
| nightbuzzz wrote: |
Hi Al,
There is a scenario i am facing and want a little help..
My COBOL program gets executed multiple times in different JCL's and every time i have to identify in which JCL it is getting executed. How can i achieve that except passing the JOBNAME thru PARM.
Thanks in advance.
Mayank |
Who is Al?
Do you mean that you need to know while your program is running which JOBNAME it has?
Or do you instead need to know afterwards, or just for maintenance, which JOBs executed your program, or which bits of JCL contain steps which could cause its execution?
Maybe since you mention the PARM you mean the former? What is the drawback that you see in using the PARM?
EDIT: I see the Cobol cat-is-out-of-the-bag. The reason not to do it in Cobol (in Production) is that noone provides copybooks for the Control Block layouts. If you write a little something in Assembler instead (search post posts on same sort of subject by Bill O'Boyle) then IBM supply the macros which are used. You have a system change from IBM involving Control Blocks, all documented through the changed Assembler macros. Changes to Cobol programs using it? For stuff you've just copied from somewhere? Not something you'd like your system-software-upgrade-verification-process hanging on, is it? |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
Al is Al Bundy.
Obtaining knowledge about programs executed is mostly an after the fact situation. Displaying some control block info is useless, if you cant write
that info to a file. Else you have to scan JES logs, beside that there is no
organization that allows the use of files not purposefull to the program.
So SMF will be your friend. |
|
| Back to top |
|
|
nightbuzzz
New User
Joined: 04 May 2007
Posts: 21
Location: kuala lumpur
|
|
|
|
Hi,
Sorry for the TYPO, its ALL.
My query is, i want to to know in my COBOL program that in which JOB it is getting executed.
My program runs multiple times in different JOBs.
Regards
Mayank |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
Well use the links from Mr. Sorichetti.
Now im terrible curious what your program is going to do, after you got
that jobname info. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
OK, we knew about Al really :-)
You've made it a little clearer, but failed to say why you think the PARM is not a solution for you.
If you don't like the PARM and can't say why, you or someone else could knock-together a callable Assembler module along the lines provided by Bill O'Boyle.
EDIT: Assembler for the reasons already stated. If it is just something in "development" and not "critical" to development, then you could reasonably use the Cobol route. |
|
| Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6248
Location: Mumbai, India
|
|
|
|
| Possibly, you could use the symbol translator utility EZACFSM1 and translate the &JOBNAME system variable into the actual jobname, and write the output to a dataset, to be looked at later - no? |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
| Or pass the &JOBNAME as the PARM.... |
|
| Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6248
Location: Mumbai, India
|
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
| Back to top |
|
|
Marso
REXX Moderator
Joined: 13 Mar 2006
Posts: 1353
Location: Israel
|
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
Marso,
Great find. Didn't realise IBM advocated control-block traversing in COBOL. 
Regards, |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
Hello,
| Bill Woodger wrote: |
| dick scherrer wrote: |
[...]
If you post your cobol code that retrieves the dsn, i'll amend several topics that refer to doing this, but no longer work due to changed control blocks.
[...] |
From the link provided by Anuj.
New release of z/OS, the information can change. z/OS 2 next year (apparently), so a bigger change, potentially, than just the 1.xx to 1.xx+1. IBM will change the Assembler macros if necessary. No-one, and not their dog, will change the bits of Cobol scattered over the internet. Or they might. Eventually. Hopefully correctly, maybe not.
I lke that from IBM - on the one hand "only use the macros" "don't rely on anything except what we say you can rely on", and then they throw a Cobol example at you anyway. Even redefining the pointers to add to them (what is wrong with SET UP BY?).
Glad that's cleared up.
/pointed tone on
It would be good, I feel, if we didn't encourage this unless TS/OPs say, with straight faces, "no, this isn't going into Production".
/pointed tone off |
|
|
| Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6248
Location: Mumbai, India
|
|
|
|
| Quote: |
| It would be good, I feel, if we didn't encourage this unless TS/OPs say, with straight faces, "no, this isn't going into Production". |
As they say - not evreything which can be done, should be done.  |
|
| Back to top |
|
|
|
|
