GETJPI & image name of MASTER_PID

[Dale Grenier]

I've finally figured out how to get LIB$GETJPI working with COBOL to get process ID, process name, image name, etc. but I need to call a cobol app from within several other Cobol apps and can't determine how to get the Image Name of the Master Process (the name of the calling application). I've tried the test program below. The MASTER_PID comes back correctly but nothing is returned for the IMAGNAME in the second call. I'm sure the solution is very simple but being to calling these routines from within Cobol, the solution eludes me.

Thanks for any thoughts or solutions you may have.



IDENTIFICATION DIVISION.
PROGRAM-ID. GET_JPI.
*

ENVIRONMENT DIVISION.

DATA DIVISION.
WORKING-STORAGE SECTION.

01 JPI$_MASTER_PID PIC S9(9) COMP VALUE EXTERNAL JPI$_MASTER_PID.
01 JPI$_IMAGNAME PIC S9(9) COMP VALUE EXTERNAL JPI$_IMAGNAME.
01 STAT PIC S9(9) COMP.

01 MPID PIC X(09).
01 IMAGNAME PIC X(80).
************************************************************
PROCEDURE DIVISION.
BEGIN.

CALL 'LIB$GETJPI' USING BY REFERENCE JPI$_MASTER_PID
OMITTED,
OMITTED,
OMITTED,
BY DESCRIPTOR MPID
GIVING STAT.


DISPLAY "MASTER_PID RETURNED BY LIB$GETJPI: " MPID
DISPLAY "".

DISPLAY "Master_PID: " MPID.
CALL 'LIB$GETJPI' USING BY REFERENCE JPI$_IMAGNAME
BY REFERENCE JPI$_MASTER_PID,
OMITTED,
OMITTED,
BY DESCRIPTOR IMAGNAME
GIVING STAT.


DISPLAY "MASTER_IMGNAM RETURNED BY LIB$GETJPI: " IMAGNAME

STOP RUN.

[Hein van den Heuvel · Accepted solution]

Welcome to the HP ITRC OpenVMS forum.

Easy problem...

You need to pass the returned value of the masterpid from the first call as second argument to the second call. That should be the binary value, not the text value you currently obtain.

See program below with added "MPID-VALUE" variable. I also replaced IMAGNAME by PRCNAM... Same principle, but easier to test.

Run example:

$ run test
MASTER_PID RETURNED BY LIB$GETJPI: 00137229
My name RETURNED BY LIB$GETJPI: HEIN_1
Master RETURNED BY LIB$GETJPI: HEINEKEN

Program below.
Cheers,
Hein.

IDENTIFICATION DIVISION.
PROGRAM-ID. GET_JPI.
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.

01 JPI$_MASTER_PID PIC S9(9) COMP VALUE EXTERNAL JPI$_MASTER_PID.
01 JPI$_PRCNAM PIC S9(9) COMP VALUE EXTERNAL JPI$_PRCNAM.
01 STAT PIC S9(9) COMP.
01 MPID PIC X(09).
01 MPID-VALUE PIC S9(9) COMP.
01 IMAGNAME PIC X(80).
************************************************************
PROCEDURE DIVISION.
BEGIN.
CALL 'LIB$GETJPI' USING BY REFERENCE JPI$_MASTER_PID
OMITTED,
OMITTED,
MPID-VALUE,
BY DESCRIPTOR MPID
GIVING STAT.

DISPLAY "MASTER_PID RETURNED BY LIB$GETJPI: " MPID

CALL 'LIB$GETJPI' USING BY REFERENCE JPI$_PRCNAM
OMITTED,
OMITTED,
OMITTED,
BY DESCRIPTOR IMAGNAME
GIVING STAT.

DISPLAY "My name RETURNED BY LIB$GETJPI: " IMAGNAME

CALL 'LIB$GETJPI' USING BY REFERENCE JPI$_PRCNAM
MPID-VALUE,
OMITTED,
OMITTED,
BY DESCRIPTOR IMAGNAME
GIVING STAT.

DISPLAY "Master RETURNED BY LIB$GETJPI: " IMAGNAME

STOP RUN.

[Hoff]

You are to be commended on your efforts and your success here. Having experience getting COBOL calling into these sort of things, this is not easy.

It's certainly possible (and encouraged) to build up a library of calls from COBOL, and there are many useful examples in the support databases that can be of assistance toward that goal. COBOL itself is arguably one of the more difficult languages to call OpenVMS system functions from, particularly those functions involving pointers and itemlists. There are some links into the support databases at the top level of the ITRC site. http://www.itrc.hp.com. Once you master these argument-passing mechanisms, the remaining calls -- well, with the exception of one SMG call, SMG$SELECT_FROM_MENU :-) -- are easier.

Should you continue to pursue direct calls, I would encourage acquiring (or creating for yourself) examples of calling sys$getjpi[w], sys$getsyi[w], sys$getdvi[w] or other similar calls -- these are the most difficult calls from COBOL, but they are also salient examples -- microcosms -- of the classic OpenVMS programming interfaces.

As for what you are working on here with the job tree and the image names, dependencies on such things as the parent process and the calling image name tend to be non-modular; some details on why you're considering this approach might be in order, and whether or not there are alternative approaches.

If you're looking for tracebacks on failures and for logging and reporting problems (or for logging run-times and performance), there are approaches toward that end.

If you're looking to conditionalize processing based on the calling sequence of processes in the job tree, there are other approaches I'd pick (long) before I looked at the images and the job tree and processes.

Some background, please? What problem(s) might you be addressing here?

Stephen Hoffman
HoffmanLabs LLC

[Dale Grenier]

Thanks for the assistance, I now have a working application. Out existing applications use a "banner" page when ever an application is run to give a brief description of what the application does and allow the user to modify report settings before actually running the report. This is done by calling a generic library module that determines what program it is being called from and then displaying the appropriate docs and settings. I want to enhance this banner application but we do not have the source code for this particular one, so I am writing my own version from scratch with the enhancements I want. The final sticking point was determining what image was being run by the master process without having to resort to passing variables or setting a logical. The original banner program does neither of these so I wanted to keep them functionally the same. If there is a better alternative, I'm all ears.

Thanks again!

[Hein van den Heuvel]

>> If there is a better alternative, I'm all ears.

Yeah, sounds like you are SPAWNING the help application.

The better alternative is to put that code in a share-able library and use LIB$FIND_IMAGE_SYMBOL to activate it if and when needed.
In doing so the help will run in full process context and you can pass anything you darn well please. It wil also be cheaper on the system, notably if frequently re-activated.

It's the VMS way of doing things.

Cheers,
Hein.

[Dale Grenier]

Thanks again for for sharing your expertise.
I can tell I will be using this venue more often and should have been using it more in the past.