topic Re: Internal PID to Extended PID conversion "problem" in Operating System - OpenVMS

Internal PID to Extended PID conversion "problem"

Mark Corcoran — Fri, 02 Jul 2010 08:21:22 GMT

I'm trying to assist a colleague who is for whatever reason obtaining details of an offending process, by finding a logical defined in its job table.

Obviously, knowing the job table name doesn't of itself tell you what the offending process is.

I advised him to use SDA to FORMAT /TYP=JIB the xxxxxxxx part of the LNM$JOB_xxxxxxxx table name.

From this, you can get the JIB$L_MPID value (Master Internal PID).

For the subsequent processing he needs to do, he needs to have the Extended PID (EPID), not the MPID.

I'm having difficulty in converting the MPID to the EPID...

The Internals & Data Structures manual says this about the EPID:

Bit 31 is always 0, to avoid negative PIDs (reading between the lines, in some places where PIDs can be passed, a negative value has a special meaning).

Bits 21-30 contain the Node Sequence Number and Node Index, which are derived from SCH$GW_LOCALNODE.

Bits 0-20 are split between the Process Index and the Process Sequence Number, with the number of bits allocated to each, being dependent on the value of the MAXPROCESSCNT SYSGEN parameter (which determines SCH$GL_PIXWIDTH, which is then used in deciding the field width).

On one cluster, if I look at my own process in SDA, I see that MPID=005407F2, and EPID=228547F2.

SCH$GL_PIXWIDTH is %X0C
SCH$GW_LOCALNODE is %X114

So, we have:

3 2 1 0
10987654321098765432109876543210
XBBBBBBBBBBAAAAAAAAAAAAAAAAAAAAA
100010100001010100011111110010 EPID(228547F2)
000000010101000000011111110010 MPID(5407F2)

Bit shifting the SCH$GW_LOCALNODE value so that it can be overlayed into BBBBBBBBBB:

100010100 SCH$GW(114)

If I perform a logical AND on the MPID and the bit-shifted SCH$GW_LOCALNODE value, I get:

100010100101000000011111110010 Calculated EPID(114407F2)

However, the actual EPID has bits 14 and 16 set, and bit 20 clear:

3 2 1 0
10987654321098765432109876543210
XBBBBBBBBBBAAAAAAAAAAAAAAAAAAAAA
100010100001010100011111110010 EPID(228547F2)
100010100101000000011111110010 Calculated EPID(114407F2)

Am I missing something out here?

I don't have my copy of the book to hand, though I was surprised to find it online as a scanned copy at Google Books.

Is there something I have skipped, or is it not as simple as bit shifting the SCH$GW_LOCALNODE value and doing a logical AND with the MPID value?

Even if there is a simpler way of getting the EPID from a job logical name table, I'm still perplexed by the MPID->EPID conversion.

If anyone can clear the wood so I can see the trees, I'd be much obliged!

Mark

Re: Internal PID to Extended PID conversion "problem"

Kris Clippeleyr — Fri, 02 Jul 2010 09:11:18 GMT

Hi,
There is a routine

int exe_std$cvt_ipid_to_epid ( in ipid );

that returns the EPID given an IPID.

Regards,
Kris (aka Qkcl)

Re: Internal PID to Extended PID conversion "problem"

Shriniketan Bhagwat — Fri, 02 Jul 2010 09:30:00 GMT

Hi,

Internal process ID of the target process. The internal PID, or internal process ID, is distinct from the extended PID, or PID. The internal PID does not include any node information, and is used only in internal routines that operate on a single node within a cluster. The two types of pids are described in the PCBDEF.SDL file. Note that the bit layout of the pids is dependent upon the version of OpenVMS in use, and may change from one version of OpenVMS to the next. However, the internal PID can be derived from the extended PID using the routine EXE_STD$CVT_EPID_TO_IPID. This routine takes a single argument (the extended pid, unsigned longword by value) and returns the internal pid (unsigned longword by value) as the return value of the routine. If an error occurs, the return value is set to zero.

Regards,
Ketan

Re: Internal PID to Extended PID conversion "problem"

Shriniketan Bhagwat — Fri, 02 Jul 2010 09:41:18 GMT

Hi,

Here is a link which explains about the CVT_EPID_TO_IPID. You may like to refer.

http://www.openvms.compaq.com/wizard/wiz_9234.html

Regards,
Ketan

Re: Internal PID to Extended PID conversion "problem"

Shriniketan Bhagwat — Fri, 02 Jul 2010 09:41:52 GMT

Hi,

Here are the usual suspects for PID-related conversions:

EXE$CVT_EPID_TO_IPID,
EXE$CVT_IPID_TO_EPID,
EXE$CVT_IPID_TO_KTB,
EXE$CVT_IPID_TO_PCB,
EXE_STD$CVT_EPID_TO_IPID,
EXE_STD$CVT_IPID_TO_EPID,
EXE_STD$CVT_IPID_TO_PCB

Regards,
Ketan

Re: Internal PID to Extended PID conversion "problem"

Mark Corcoran — Fri, 02 Jul 2010 09:42:22 GMT

Kris and Shriniketan, thanks for the suggestion - I'd already seen this, however...

It seems a bit of a chore to create an executable just to perform the conversion of MPID to EPID only, since he'd still have to manually do the ANA /SYS, READ SYSDEF.STB, FORMAT /TYP=JIB and then extract the MPID.

I'd be inclined to put the the whole lot into an executable, so it takes whatever input he currently has (to determine the job table name of the offending process), and simply spits out the EPID.

However, I'm busy with other things at the moment, and was keen to get him going with an automated solution in DCL however clunky it might be.

Re: Internal PID to Extended PID conversion "problem"

Ian Miller. — Fri, 02 Jul 2010 12:35:09 GMT

I wonder if your colleague needs to take a step back and look that what they are really trying to do.

Re: Internal PID to Extended PID conversion "problem"

Hein van den Heuvel — Fri, 02 Jul 2010 13:10:59 GMT

What Ian really wanted to say...

Check out:

http://eisner.encompasserve.org/~miller/
look for: LN$SDA

You may also want to alert your colleague to
SDA> CLUE PROC/LOGICAL

Hein

Re: Internal PID to Extended PID conversion "problem"

Jon Pinkley — Fri, 02 Jul 2010 17:03:08 GMT

Mark,

You don't say what version of VMS is involved, but if you are already in SDA, it is quite straight forward to let it do the conversion.

SDA> set proc/in=ipid ! undocumented featrue one of [process index|epid|ipid]
SDA> show proc

Although it is not documented that I am aware of, the set process/index command will accept epid or ipid in addition to process index.

Example:

SDA> set proc/in=078F0137
SDA> sho proc

Process index: 0137 Name: T42088412E_MON Extended PID: 209E3D37
--------------------------------------------------------------------
Process status: 00040001 RES,PHDRES
status2: 00000000

KTB address 8436CB00 HWPCB address FFFFFFFF.90334080
PKTA address 7FFEFF98 Callback vector address 00000000
Internal PID 078F0137 Callback error 00000000
Extended PID 209E3D37 Current CPU id 00000003
State LEF Flags 00000000

This doesn't answer your question about why manual conversion you did did not work, you shouldn't be doing that conversion yourself anyway, as the format is allowed to change at any time. The routines provided by other posters are there to make things less likely to break across VMS versions.
Of course since the method I gave is also undocumented, it is not guaranteed to work in the future either.

Jon

Re: Internal PID to Extended PID conversion "problem"

Hoff — Fri, 02 Jul 2010 20:50:52 GMT

If you want to see the JIB symbols (and you'll need to here), create and then MACRO this little file JIBDEF.MAR:

.LIBRARY /SYS$LIBRARY:LIB/
$JIBDEF GLOBAL
.end

And then SDA> READ JIBDEF.OBJ to load the definitions:

SDA> read jibdef.obj

for viewing other data structures (if you need those) either add DEF entries to the Macro32 file, or SDA> READ/EXEC to load stuff from the exec listings.

The following gets a "scratch" process loaded up into the "viewport", just to get the JIB and some other default SDA symbols set...

SDA> show proc/ind=0

(this gets a JIB symbol set for the current process, just for the purposes of this demo. You'd enter your JIB address here.)

SDA> exam jib+JIB$L_MPID
JIB+00064: 00010047 "G..."

Or specifying the JIB by its address (examine JIB, or translate that logical name table, etc) like this:

SDA> exam 827E1380+JIB$L_MPID
JIB+00064: 00010047 "G..."

SDA> sho proc/ind=47

Process index: 0047 Name: ...

(If you want, you can specify the full IPID as the parameter for the /INDEX qualifier, but the index (the lower part of the PID) works well enough and is a convenient short-cut. INDEX is the process INDEX, and SDA is smart enough to just look at the part of the PID (any type) that is the index; it's in the same spot and the same bit-width.