Document revision date: 19 July 1999

You can use SYS$GETJPI with SYS$PROCESS_SCAN to search for processes that match an item list with one criterion. For example, if you specify a search for processes owned by one user name, SYS$GETJPI returns only those processes that match the specified user name.

Example 3-6 demonstrates how to perform a SYS$PROCESS_SCAN search on the local node to select all processes that are owned by user SMITH.

Example 3-6 Using SYS$GETJPI and SYS$PROCESS_SCAN to Select Process Information by User Name

PROGRAM PROCESS_SCAN IMPLICIT NONE ! Implicit none INCLUDE '($jpidef) /nolist' ! Definitions for $GETJPI INCLUDE '($pscandef) /nolist' ! Definitions for $PROCESS_SCAN INCLUDE '($ssdef) /nolist' ! Definitions for SS$_NAMES STRUCTURE /JPIITMLST/ ! Structure declaration for UNION ! $GETJPI item lists MAP INTEGER*2 BUFLEN, 2 CODE INTEGER*4 BUFADR, 2 RETLENADR END MAP MAP ! A longword of 0 terminates INTEGER*4 END_LIST ! an item list END MAP END UNION END STRUCTURE STRUCTURE /PSCANITMLST/ ! Structure declaration for UNION ! $PROCESS_SCAN item lists MAP INTEGER*2 BUFLEN, 2 CODE INTEGER*4 BUFADR, 2 ITMFLAGS END MAP MAP ! A longword of 0 terminates INTEGER*4 END_LIST ! an item list END MAP END UNION END STRUCTURE RECORD /PSCANITMLST/ ! Declare the item list for 2 PSCANLIST(12) ! $PROCESS_SCAN RECORD /JPIITMLST/ ! Declare the item list for 2 JPILIST(3) ! $GETJPI INTEGER*4 SYS$GETJPIW, ! System service entry points 2 SYS$PROCESS_SCAN INTEGER*4 STATUS, ! Status variable 2 CONTEXT, ! Context from $PROCESS_SCAN 2 PID ! PID from $GETJPI INTEGER*2 IOSB(4) ! I/O Status Block for $GETJPI CHARACTER*16 2 PRCNAM ! Process name from $GETJPI INTEGER*2 PRCNAM_LEN ! Process name length LOGICAL*4 DONE ! Done with data loop !******************************************** !* Initialize item list for $PROCESS_SCAN * !******************************************** ! Look for processes owned by user SMITH PSCANLIST(1).BUFLEN = LEN('SMITH') PSCANLIST(1).CODE = PSCAN$_USERNAME PSCANLIST(1).BUFADR = %LOC('SMITH') PSCANLIST(1).ITMFLAGS = 0 PSCANLIST(2).END_LIST = 0 !******************************************** !* End of item list initialization * !******************************************** STATUS = SYS$PROCESS_SCAN ( ! Set up the scan context 2 CONTEXT, 2 PSCANLIST) IF (.NOT. STATUS) CALL LIB$SIGNAL (%VAL(STATUS)) ! Loop calling $GETJPI with the context DONE = .FALSE. DO WHILE (.NOT. DONE) ! Initialize $GETJPI item list JPILIST(1).BUFLEN = 4 JPILIST(1).CODE = JPI$_PID JPILIST(1).BUFADR = %LOC(PID) JPILIST(1).RETLENADR = 0 JPILIST(2).BUFLEN = LEN(PRCNAM) JPILIST(2).CODE = JPI$_PRCNAM JPILIST(2).BUFADR = %LOC(PRCNAM) JPILIST(2).RETLENADR = %LOC(PRCNAM_LEN) JPILIST(3).END_LIST = 0 ! Call $GETJPI to get the next SMITH process STATUS = SYS$GETJPIW ( 2 , ! No event flag 2 CONTEXT, ! Process context 2 , ! No process name 2 JPILIST, ! Item list 2 IOSB, ! Always use IOSB with $GETJPI! 2 , ! No AST 2 ) ! No AST arg ! Check the status in both STATUS and the IOSB, if ! STATUS is OK then copy IOSB(1) to STATUS IF (STATUS) STATUS = IOSB(1) ! If $GETJPI worked, display the process, if done then ! prepare to exit, otherwise signal an error IF (STATUS) THEN TYPE 1010, PID, PRCNAM(1:PRCNAM_LEN) 1010 FORMAT (' ',Z8.8,' ',A) ELSE IF (STATUS .EQ. SS$_NOMOREPROC) THEN DONE = .TRUE. ELSE CALL LIB$SIGNAL(%VAL(STATUS)) END IF END DO END

3.2.4.3 Requesting Information About Processes That Match Multiple Values for One Criterion

You can use SYS$PROCESS_SCAN to search for processes that match one of a number of values for a single criterion, such as processes owned by several specified users.

Each value must be specified in a separate item list entry, and the item list entries must be connected with the PSCAN$M_OR item-specific flag. SYS$GETJPI selects each process that matches any of the item values.

For example, to look for processes with user names SMITH, JONES, or JOHNSON, substitute code such as that shown in Example 3-7 to initialize the item list in Example 3-6.

Example 3-7 Using SYS$GETJPI and SYS$PROCESS_SCAN with Multiple Values for One Criterion

!******************************************** !* Initialize item list for $PROCESS_SCAN * !******************************************** ! Look for users SMITH, JONES and JOHNSON PSCANLIST(1).BUFLEN = LEN('SMITH') PSCANLIST(1).CODE = PSCAN$_USERNAME PSCANLIST(1).BUFADR = %LOC('SMITH') PSCANLIST(1).ITMFLAGS = PSCAN$M_OR PSCANLIST(2).BUFLEN = LEN('JONES') PSCANLIST(2).CODE = PSCAN$_USERNAME PSCANLIST(2).BUFADR = %LOC('JONES') PSCANLIST(2).ITMFLAGS = PSCAN$M_OR PSCANLIST(3).BUFLEN = LEN('JOHNSON') PSCANLIST(3).CODE = PSCAN$_USERNAME PSCANLIST(3).BUFADR = %LOC('JOHNSON') PSCANLIST(3).ITMFLAGS = 0 PSCANLIST(4).END_LIST = 0 !******************************************** !* End of item list initialization * !********************************************

3.2.4.4 Requesting Information About Processes That Match Multiple Criteria

You can use SYS$PROCESS_SCAN to search for processes that match values for more than one criterion. When multiple criteria are used, a process must match at least one value for each specified criterion.

Example 3-8 demonstrates how to find any batch process owned by either SMITH or JONES. The program uses syntax like the following logical expression to initialize the item list:

((username = "SMITH") OR (username = "JONES")) AND (MODE = JPI$K_BATCH)

Example 3-8 Selecting Processes That Match Multiple Criteria

!******************************************** !* Initialize item list for $PROCESS_SCAN * !******************************************** ! Look for BATCH jobs owned by users SMITH and JONES PSCANLIST(1).BUFLEN = LEN('SMITH') PSCANLIST(1).CODE = PSCAN$_USERNAME PSCANLIST(1).BUFADR = %LOC('SMITH') PSCANLIST(1).ITMFLAGS = PSCAN$M_OR PSCANLIST(2).BUFLEN = LEN('JONES') PSCANLIST(2).CODE = PSCAN$_USERNAME PSCANLIST(2).BUFADR = %LOC('JONES') PSCANLIST(2).ITMFLAGS = 0 PSCANLIST(3).BUFLEN = 0 PSCANLIST(3).CODE = PSCAN$_MODE PSCANLIST(3).BUFADR = JPI$K_BATCH PSCANLIST(3).ITMFLAGS = 0 PSCANLIST(4).END_LIST = 0 !******************************************** !* End of item list initialization * !********************************************

See the OpenVMS System Services Reference Manual for more information about SYS$PROCESS_SCAN item codes and flags.

3.2.5 Specifying a Node as Selection Criterion

Several SYS$PROCESS_SCAN item codes do not refer to attributes of a process, but to the VMScluster node on which the target process resides. When SYS$PROCESS_SCAN encounters an item code that refers to a node attribute, it creates an alphabetized list of node names. SYS$PROCESS_SCAN then directs SYS$GETJPI to compare the selection criteria against processes on these nodes.

SYS$PROCESS_SCAN ignores a node specification if it is running on a node that is not part of a VMScluster system. For example, if you request that SYS$PROCESS_SCAN select all nodes with the hardware model name VAX 6360, this search returns information about local processes on a nonclustered system, even if it is a MicroVAX system.

A remote SYS$GETJPI operation currently requires the system to send a message to the CLUSTER_SERVER process on the remote node. The CLUSTER_SERVER process then collects the information and returns it to the requesting node. This has several implications for clusterwide searches:

• All remote SYS$GETJPI operations are asynchronous and must be synchronized properly. Many applications that are not correctly synchronized might seem to work on a single node because some SYS$GETJPI operations are actually synchronous; however, these applications fail if they attempt to examine processes on remote nodes. For more information on how to synchronize SYS$GETJPI operations, see Chapter 16.
• The CLUSTER_SERVER process is always a current process, because it is executing on behalf of SYS$GETJPI.
• Attempts by SYS$GETJPI to examine a node do not succeed during a brief period between the time a node joins the cluster and the time that the CLUSTER_SERVER process is started. Searches that occur during this period skip such a node. Searches that specify only such a booting node fail with a SYS$GETJPI status of SS$_UNREACHABLE.
• SS$_NOMOREPROC is returned after all processes on all specified nodes have been scanned.

The SYS$PROCESS_SCAN system service can scan the entire cluster for processes. For example, to scan the cluster for all processes owned by SMITH, use code like that in Example 3-9 to initialize the item list to find all processes with a nonzero cluster system identifier (CSID) and a user name of SMITH.

Example 3-9 Searching the Cluster for Process Information

!******************************************** !* Initialize item list for $PROCESS_SCAN * !******************************************** ! Search the cluster for jobs owned by SMITH PSCANLIST(1).BUFLEN = 0 PSCANLIST(1).CODE = PSCAN$_NODE_CSID PSCANLIST(1).BUFADR = 0 PSCANLIST(1).ITMFLAGS = PSCAN$M_NEQ PSCANLIST(2).BUFLEN = LEN('SMITH') PSCANLIST(2).CODE = PSCAN$_USERNAME PSCANLIST(2).BUFADR = %LOC('SMITH') PSCANLIST(2).ITMFLAGS = 0 PSCANLIST(3).END_LIST = 0 !******************************************** !* End of item list initialization * !********************************************

3.2.5.2 Checking Specific Nodes on the Cluster for Processes

You can specify a list of nodes as well. Example 3-10 demonstrates how to design an item list to search for batch processes on node TIGNES, VALTHO, or 2ALPES.

Example 3-10 Searching for Process Information on Specific Nodes in the Cluster

!******************************************** !* Initialize item list for $PROCESS_SCAN * !******************************************** ! Search for BATCH jobs on nodes TIGNES, VALTHO and 2ALPES PSCANLIST(1).BUFLEN = LEN('TIGNES') PSCANLIST(1).CODE = PSCAN$_NODENAME PSCANLIST(1).BUFADR = %LOC('TIGNES') PSCANLIST(1).ITMFLAGS = PSCAN$M_OR PSCANLIST(2).BUFLEN = LEN('VALTHO') PSCANLIST(2).CODE = PSCAN$_NODENAME PSCANLIST(2).BUFADR = %LOC('VALTHO') PSCANLIST(2).ITMFLAGS = PSCAN$M_OR PSCANLIST(3).BUFLEN = LEN('2ALPES') PSCANLIST(3).CODE = PSCAN$_NODENAME PSCANLIST(3).BUFADR = %LOC('2ALPES') PSCANLIST(3).ITMFLAGS = 0 PSCANLIST(4).BUFLEN = 0 PSCANLIST(4).CODE = PSCAN$_MODE PSCANLIST(4).BUFADR = JPI$K_BATCH PSCANLIST(4).ITMFLAGS = 0 PSCANLIST(5).END_LIST = 0 !******************************************** !* End of item list initialization * !********************************************

3.2.5.3 Conducting Multiple Simultaneous Searches with SYS$PROCESS_SCAN

Only one asynchronous remote SYS$GETJPI request per SYS$PROCESS_SCAN context is permitted at a time. If you issue a second SYS$GETJPI request using a context before a previous remote request using the same context has completed, your process stalls in a resource wait until the previous remote SYS$GETJPI request completes. This stall in the RWAST state prevents your process from executing in user mode or receiving user-mode ASTs.

If you want to run remote searches in parallel, create multiple contexts by calling SYS$PROCESS_SCAN once for each context. For example, you can design a program that calls SYS$GETSYI in a loop to find the nodes in the VMScluster system and creates a separate SYS$PROCESS_SCAN context for each remote node. Each of these separate contexts can run in parallel. The DCL command SHOW USERS uses this technique to obtain user information more quickly.

Only requests to remote nodes must wait until the previous search using the same context has completed. If the SYS$PROCESS_SCAN context specifies the local node, any number of SYS$GETJPI requests using that context can be executed in parallel (within the limits implied by the process quotas for ASTLM and BYTLM).

To perform a synchronous search in which the program waits until all requested information is available, use SYS$GETJPIW with an iosb argument.

See the OpenVMS System Services Reference Manual for more information about process identification, SYS$GETJPI, and SYS$PROCESS_SCAN.

3.2.6 Programming with SYS$GETJPI

The following sections describe some important considerations for programming with SYS$GETJPI.

3.2.6.1 Using Item Lists Correctly

When SYS$GETJPI collects data, it makes multiple passes through the item list. If the item list is self-modifying---that is, if the addresses for the output buffers in the item list point back at the item list---SYS$GETJPI replaces the item list information with the returned data. Therefore, incorrect data might be read or unexpected errors might occur when SYS$GETJPI reads the item list again. To prevent confusing errors, Compaq recommends that you do not use self-modifying item lists.

The number of passes that SYS$GETJPI needs depends on which item codes are referenced and the state of the target process. A program that appears to work normally might fail when a system has processes that are swapped out of memory, or when a process is on a remote node.

3.2.6.2 Improving Performance by Using Buffered $GETJPI Operations

To request information about a process located on a remote node, SYS$GETJPI must send a message to the remote node, wait for the response, and then extract the data from the message received. When you perform a search on a remote system, the program must repeat this sequence for each process that SYS$GETJPI locates.

To reduce the overhead of such a remote search, use SYS$PROCESS_SCAN with the PSCAN$_GETJPI_BUFFER_SIZE item code to specify a buffer size for SYS$GETJPI. When the buffer size is specified by SYS$PROCESS_SCAN, SYS$GETJPI packs information for several processes into one buffer and transmits them in a single message. This reduction in the number of messages improves performance.

For example, if the SYS$GETJPI item list requests 100 bytes of information, you might specify a PSCAN$_GETJPI_BUFFER_SIZE of 1000 bytes so that the service can place information for at least 10 processes in each message. (SYS$GETJPI does not send fill data in the message buffer; therefore, information for more than 10 processes can be packed into the buffer.)

The SYS$GETJPI buffer must be large enough to hold the data for at least one process. If the buffer is too small, the error code SS$_IVBUFLEN is returned from the SYS$GETJPI call.

You do not have to allocate space for the SYS$GETJPI buffer; buffer space is allocated by SYS$PROCESS_SCAN as part of the search context that it creates. Because SYS$GETJPI buffering is transparent to the program that calls SYS$GETJPI, you do not have to modify the loop that calls SYS$GETJPI.

If you use PSCAN$_GETJPI_BUFFER_SIZE with SYS$PROCESS_SCAN, all calls to SYS$GETJPI using that context must request the same item code information. Because SYS$GETJPI collects information for more than one process at a time within its buffers, you cannot change the item codes or the lengths of the buffers in the SYS$GETJPI item list between calls. SYS$GETJPI returns the error SS$_BADPARAM if any item code or buffer length changes between SYS$GETJPI calls. However, you can change the buffer addresses in the SYS$GETJPI item list from call to call.

The SYS$GETJPI buffered operation is not used for searching the local node. When a search specifies both multiple nodes and SYS$GETJPI buffering, the buffering is used on remote nodes but is ignored on the local node. Example 3-11 demonstrates how to use a SYS$GETJPI buffer to improve performance.

Example 3-11 Using a SYS$GETJPI Buffer to Improve Performance

!******************************************** !* Initialize item list for $PROCESS_SCAN * !******************************************** ! Search for jobs owned by users SMITH and JONES ! across the cluster with $GETJPI buffering PSCANLIST(1).BUFLEN = 0 PSCANLIST(1).CODE = PSCAN$_NODE_CSID PSCANLIST(1).BUFADR = 0 PSCANLIST(1).ITMFLAGS = PSCAN$M_NEQ PSCANLIST(2).BUFLEN = LEN('SMITH') PSCANLIST(2).CODE = PSCAN$_USERNAME PSCANLIST(2).BUFADR = %LOC('SMITH') PSCANLIST(2).ITMFLAGS = PSCAN$M_OR PSCANLIST(3).BUFLEN = LEN('JONES') PSCANLIST(3).CODE = PSCAN$_USERNAME PSCANLIST(3).BUFADR = %LOC('JONES') PSCANLIST(3).ITMFLAGS = 0 PSCANLIST(4).BUFLEN = 0 PSCANLIST(4).CODE = PSCAN$_GETJPI_BUFFER_SIZE PSCANLIST(4).BUFADR = 1000 PSCANLIST(4).ITMFLAGS = 0 PSCANLIST(5).END_LIST = 0 !******************************************** !* End of item list initialization * !********************************************

3.2.6.3 Fulfilling Remote SYS$GETJPI Quota Requirements

A remote SYS$GETJPI request uses system dynamic memory for messages. System dynamic memory uses the process quota BYTLM. Follow these steps to determine the number of bytes required by a SYS$GETJPI request:

1. Add the following together:
   • The size of the SYS$PROCESS_SCAN item list
   • The total size of all reference buffers for SYS$PROCESS_SCAN (the sum of all buffer length fields in the item list)
   • The size of the SYS$GETJPI item list
   • The size of the SYS$GETJPI buffer
   • The size of the calling process RIGHTSLIST
   • Approximately 300 bytes for message overhead
2. Double this total.
   The total is doubled because the messages consume system dynamic memory on both the sending node and the receiving node.

This formula for BYTLM quota applies to both buffered and nonbuffered SYS$GETJPI requests. For buffered requests, use the value specified in the SYS$PROCESS_SCAN item, PSCAN$_GETJPI_BUFFER_SIZE, as the size of the buffer. For nonbuffered requests, use the total length of all data buffers specified in the SYS$GETJPI item list as the size of the buffer.

If the BYTLM quota is insufficient, SYS$GETJPI (not SYS$PROCESS_SCAN) returns the error SS$_EXBYTLM.

3.2.6.4 Using the SYS$GETJPI Control Flags

The JPI$_GETJPI_CONTROL_FLAGS item code, which is specified in the SYS$GETJPI item list, provides additional control over SYS$GETJPI. Therefore, SYS$GETJPI may be unable to retrieve all the data requested in an item list because JPI$_GETJPI_CONTROL_FLAGS requests that SYS$GETJPI not perform certain actions that may be necessary to collect the data. For example, a SYS$GETJPI control flag may instruct the calling program not to retrieve a process that has been swapped out of the balance set.

If SYS$GETJPI is unable to retrieve any data item because of the restrictions imposed by the control flags, it returns the data length as 0. To verify that SYS$GETJPI received a data item, examine the data length to be sure that it is not 0. To make this verification possible, be sure to specify the return length for each item in the SYS$GETJPI item list when any of the JPI$_GETJPI_CONTROL_FLAGS flags is used.

Unlike other SYS$GETJPI item codes, the JPI$_GETJPI_CONTROL_FLAGS item is an input item. The item list entry should specify a longword buffer. The desired control flags should be set in this buffer.

Because the JPI$_GETJPI_CONTROL_FLAGS item code tells SYS$GETJPI how to interpret the item list, it must be the first entry in the SYS$GETJPI item list. The error code SS$_BADPARAM is returned if it is not the first item in the list.

The following are the SYS$GETJPI control flags.

JPI$M_NO_TARGET_INSWAP

When you specify JPI$M_NO_TARGET_INSWAP, SYS$GETJPI does not retrieve a process that has been swapped out of the balance set. Use JPI$M_NO_TARGET_INSWAP to avoid the additional load of swapping processes into a system. For example, use this flag with SHOW SYSTEM to avoid bringing processes into memory to display their accumulated CPU time.

If you specify JPI$M_NO_TARGET_INSWAP and request information from a process that has been swapped out, the following consequences occur:

• Data stored in the virtual address space of the process is not accessible.
• Data stored in the process header (PHD) may not be accessible.
• Data stored in resident data structures, such as the process control block (PCB) or the job information block (JIB), is accessible.

You must examine the return length of an item to verify that the item was retrieved. The information may be located in a different data structure in another release of the operating system.

JPI$M_NO_TARGET_AST

When JPI$M_NO_TARGET_AST is specified, SYS$GETJPI does not deliver a kernel-mode AST to the target process. JPI$M_NO_TARGET_AST is used to avoid executing a target process in order to retrieve information.

If you specify JPI$M_NO_TARGET_AST and cannot deliver an AST to a target process, the following consequences occur:

• Data stored in the virtual address space of the process is not accessible.
• Data stored in system data structures, such as the process header (PHD), the process control block (PCB), or the job information block (JIB), is accessible.

You must examine the return length of an item to verify that the item was retrieved. The information may be located in a different data structure in another release of the operating system.

The use of the flag JPI$M_NO_TARGET_AST also implies that SYS$GETJPI does not swap in a process, because SYS$GETJPI would only bring a process into memory to deliver an AST to that process.

JPI$M_IGNORE_TARGET_STATUS

When JPI$M_IGNORE_TARGET_STATUS is specified, SYS$GETJPI attempts to retrieve as much information as possible, even if the process is suspended or being deleted. JPI$M_IGNORE_TARGET_STATUS is used to retrieve all possible information from a process. For example, this flag is used with SHOW SYSTEM to display processes that are suspended, being deleted, or in miscellaneous wait states.

Example 3-12 demonstrates how to use SYS$GETJPI control flags to avoid swapping processes during a SYS$GETJPI call.

Example 3-12 Using SYS$GETJPI Control Flags to Avoid Swapping a Process into the Balance Set

PROGRAM CONTROL_FLAGS IMPLICIT NONE ! Implicit none INCLUDE '($jpidef) /nolist' ! Definitions for $GETJPI INCLUDE '($pscandef) /nolist' ! Definitions for $PROCESS_SCAN INCLUDE '($ssdef) /nolist' ! Definitions for SS$_ names STRUCTURE /JPIITMLST/ ! Structure declaration for UNION ! $GETJPI item lists MAP INTEGER*2 BUFLEN, 2 CODE INTEGER*4 BUFADR, 2 RETLENADR END MAP MAP ! A longword of 0 terminates INTEGER*4 END_LIST ! an item list END MAP END UNION END STRUCTURE STRUCTURE /PSCANITMLST/ ! Structure declaration for UNION ! $PROCESS_SCAN item lists MAP INTEGER*2 BUFLEN, 2 CODE INTEGER*4 BUFADR, 2 ITMFLAGS END MAP MAP ! A longword of 0 terminates INTEGER*4 END_LIST ! an item list END MAP END UNION END STRUCTURE RECORD /PSCANITMLST/ ! Declare the item list for 2 PSCANLIST(5) ! $PROCESS_SCAN RECORD /JPIITMLST/ ! Declare the item list for 2 JPILIST(6) ! $GETJPI INTEGER*4 SYS$GETJPIW, ! System service entry points 2 SYS$PROCESS_SCAN INTEGER*4 STATUS, ! Status variable 2 CONTEXT, ! Context from $PROCESS_SCAN 2 PID, ! PID from $GETJPI 2 JPIFLAGS ! Flags for $GETJPI INTEGER*2 IOSB(4) ! I/O Status Block for $GETJPI CHARACTER*16 2 PRCNAM, ! Process name from $GETJPI 2 NODENAME ! Node name from $GETJPI INTEGER*2 PRCNAM_LEN, ! Process name length 2 NODENAME_LEN ! Node name length CHARACTER*80 2 IMAGNAME ! Image name from $GETJPI INTEGER*2 IMAGNAME_LEN ! Image name length LOGICAL*4 DONE ! Done with data loop !******************************************** !* Initialize item list for $PROCESS_SCAN * !******************************************** ! Look for interactive and batch jobs across ! the cluster with $GETJPI buffering PSCANLIST(1).BUFLEN = 0 PSCANLIST(1).CODE = PSCAN$_NODE_CSID PSCANLIST(1).BUFADR = 0 PSCANLIST(1).ITMFLAGS = PSCAN$M_NEQ PSCANLIST(2).BUFLEN = 0 PSCANLIST(2).CODE = PSCAN$_MODE PSCANLIST(2).BUFADR = JPI$K_INTERACTIVE PSCANLIST(2).ITMFLAGS = PSCAN$M_OR PSCANLIST(3).BUFLEN = 0 PSCANLIST(3).CODE = PSCAN$_MODE PSCANLIST(3).BUFADR = JPI$K_BATCH PSCANLIST(3).ITMFLAGS = 0 PSCANLIST(4).BUFLEN = 0 PSCANLIST(4).CODE = PSCAN$_GETJPI_BUFFER_SIZE PSCANLIST(4).BUFADR = 1000 PSCANLIST(4).ITMFLAGS = 0 PSCANLIST(5).END_LIST = 0 !******************************************** !* End of item list initialization * !******************************************** STATUS = SYS$PROCESS_SCAN ( ! Set up the scan context 2 CONTEXT, 2 PSCANLIST) IF (.NOT. STATUS) CALL LIB$SIGNAL (%VAL(STATUS)) ! Initialize $GETJPI item list JPILIST(1).BUFLEN = 4 JPILIST(1).CODE = IAND ('FFFF'X, JPI$_GETJPI_CONTROL_FLAGS) JPILIST(1).BUFADR = %LOC(JPIFLAGS) JPILIST(1).RETLENADR = 0 JPILIST(2).BUFLEN = 4 JPILIST(2).CODE = JPI$_PID JPILIST(2).BUFADR = %LOC(PID) JPILIST(2).RETLENADR = 0 JPILIST(3).BUFLEN = LEN(PRCNAM) JPILIST(3).CODE = JPI$_PRCNAM JPILIST(3).BUFADR = %LOC(PRCNAM) JPILIST(3).RETLENADR = %LOC(PRCNAM_LEN) JPILIST(4).BUFLEN = LEN(IMAGNAME) JPILIST(4).CODE = JPI$_IMAGNAME JPILIST(4).BUFADR = %LOC(IMAGNAME) JPILIST(4).RETLENADR = %LOC(IMAGNAME_LEN) JPILIST(5).BUFLEN = LEN(NODENAME) JPILIST(5).CODE = JPI$_NODENAME JPILIST(5).BUFADR = %LOC(NODENAME) JPILIST(5).RETLENADR = %LOC(NODENAME_LEN) JPILIST(6).END_LIST = 0 ! Loop calling $GETJPI with the context DONE = .FALSE. JPIFLAGS = IOR (JPI$M_NO_TARGET_INSWAP, JPI$M_IGNORE_TARGET_STATUS) DO WHILE (.NOT. DONE) ! Call $GETJPI to get the next process STATUS = SYS$GETJPIW ( 2 , ! No event flag 2 CONTEXT, ! Process context 2 , ! No process name 2 JPILIST, ! Itemlist 2 IOSB, ! Always use IOSB with $GETJPI! 2 , ! No AST 2 ) ! No AST arg ! Check the status in both STATUS and the IOSB, if ! STATUS is OK then copy IOSB(1) to STATUS IF (STATUS) STATUS = IOSB(1) ! If $GETJPI worked, display the process, if done then ! prepare to exit, otherwise signal an error IF (STATUS) THEN IF (IMAGNAME_LEN .EQ. 0) THEN TYPE 1010, PID, NODENAME, PRCNAM ELSE TYPE 1020, PID, NODENAME, PRCNAM, 2 IMAGNAME(1:IMAGNAME_LEN) END IF ELSE IF (STATUS .EQ. SS$_NOMOREPROC) THEN DONE = .TRUE. ELSE CALL LIB$SIGNAL(%VAL(STATUS)) END IF END DO 1010 FORMAT (' ',Z8.8,' ',A6,':: ',A,' (no image)') 1020 FORMAT (' ',Z8.8,' ',A6,':: ',A,' ',A) END

	privacy and legal statement
5841PRO_007.HTML