- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Internal PID to Extended PID conversion "problem"
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-02-2010 01:21 AM
тАО07-02-2010 01:21 AM
Internal PID to Extended PID conversion "problem"
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-02-2010 02:11 AM
тАО07-02-2010 02:11 AM
Re: Internal PID to Extended PID conversion "problem"
There is a routine
int exe_std$cvt_ipid_to_epid ( in ipid );
that returns the EPID given an IPID.
Regards,
Kris (aka Qkcl)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-02-2010 02:30 AM
тАО07-02-2010 02:30 AM
Re: Internal PID to Extended PID conversion "problem"
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-02-2010 02:41 AM
тАО07-02-2010 02:41 AM
Re: Internal PID to Extended PID conversion "problem"
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-02-2010 02:41 AM
тАО07-02-2010 02:41 AM
Re: Internal PID to Extended PID conversion "problem"
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-02-2010 02:42 AM
тАО07-02-2010 02:42 AM
Re: Internal PID to Extended PID conversion "problem"
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-02-2010 05:35 AM
тАО07-02-2010 05:35 AM
Re: Internal PID to Extended PID conversion "problem"
Purely Personal Opinion
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-02-2010 06:10 AM
тАО07-02-2010 06:10 AM
Re: Internal PID to Extended PID conversion "problem"
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-02-2010 10:03 AM
тАО07-02-2010 10:03 AM
Re: Internal PID to Extended PID conversion "problem"
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-02-2010 01:50 PM
тАО07-02-2010 01:50 PM
Re: Internal PID to Extended PID conversion "problem"
.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.