View previous topic :: View next topic
|
Author |
Message |
ami777us
New User
Joined: 06 Apr 2007 Posts: 33 Location: USA
|
|
|
|
Is there a way to know in Cobol batch program the system-id or the Lpar that the program is running under? |
|
Back to top |
|
|
vebs
New User
Joined: 27 Oct 2007 Posts: 19 Location: UK
|
|
|
|
In the JESMSGLG DD of your Job history, you can check which LPAR did your job get executed on... and a lot of other information about job execution.
- Cheers ! |
|
Back to top |
|
|
Terry Heinze
JCL Moderator
Joined: 14 Jul 2008 Posts: 1249 Location: Richfield, MN, USA
|
|
|
|
I think Ami wants to know at execute time, not after the program has finished. |
|
Back to top |
|
|
ami777us
New User
Joined: 06 Apr 2007 Posts: 33 Location: USA
|
|
|
|
Yes, I want to know at the execute time. |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
LPAR name can be derived by a COBOL program but you've got to chase through some memory blocks to find it. Google "lpar name" and you should be able to find a program to do what you want. |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
Link below to Gilbert Saint-Flour's program "COB2SYS". One of the fields resolved in this program (amongst many others) is the LPAR-Name.
gsf-soft.com/Freeware/COB2SYS.shtml
Regards,
Bill |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10872 Location: italy
|
|
|
|
might look a sophisticated approach,
but it' s really one of the most foolish things to be done,
to have application programs rely on the hardware definitions and naming conventions
if You incur in a disaster recovery situation,
the environment and the hardware definitions will certainly be different,
and ... guess what
this kind of things would not certainly pass any audit on good IT practices,
just my 2€ , but that' s Your organization who might get into trouble |
|
Back to top |
|
|
ami777us
New User
Joined: 06 Apr 2007 Posts: 33 Location: USA
|
|
|
|
Thanks a lot. It worked! |
|
Back to top |
|
|
Terry Heinze
JCL Moderator
Joined: 14 Jul 2008 Posts: 1249 Location: Richfield, MN, USA
|
|
|
|
For the benefit of others, which option did you use? |
|
Back to top |
|
|
stodolas
Active Member
Joined: 13 Jun 2007 Posts: 632 Location: Wisconsin
|
|
|
|
enrico-sorichetti:
Maybe they run or they will be running the same job/program on multiple LPARs and have printouts from them. They want the program to dynamically find the LPAR it is running on so they don't have to hard code that in the JCL as a parm. |
|
Back to top |
|
|
mmwife
Super Moderator
Joined: 30 May 2003 Posts: 1592
|
|
|
|
Here's another approach. I think it's what you want:
Code: |
IDENTIFICATION DIVISION.
PROGRAM-ID. GETSYSID.
AUTHOR.
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
LINKAGE SECTION.
01 PSA-DATA.
05 FILLER PIC X(016).
05 CVT-ADDR POINTER.
01 CVT-DATA.
05 FILLER PIC X(196).
05 CVT-SMF-ADDR POINTER.
01 SMF-DATA.
05 FILLER PIC X(016).
05 SMF-SYS-ID PIC X(004).
PROCEDURE DIVISION.
SET ADDRESS OF PSA-DATA TO NULL
SET ADDRESS OF CVT-DATA TO CVT-ADDR
SET ADDRESS OF SMF-DATA TO CVT-SMF-ADDR
DISPLAY 'JOB RUNNING ON SYSID >' SMF-SYS-ID '<'
GOBACK
. |
|
|
Back to top |
|
|
|