Your scenario is a perfect example of why NOT to use your own process
table. MPE maintains this process table for you, and you have access to
it by using the PROCINFO intrinsic.

If you need to get a status of a child process the first thing you need
to do is rebuild your internal process table based on information
returned from the PROCINFO intrinsic, using the following steps:

Call PROCINFO to retrieve the total number of child processes, using
Item# 3 or 4.

Call PROCINFO again to populate your table with the PIN's of all the
child processes, using Item# 6 or 7.

 A variable number of PINs are returned; item must be a 16-bit signed
integer array.  The first element of the array must be set by the
calling process to indicate the array size.  The array size should
include the array size element (for example, for four PINs, the first
entry that contains the array size should be 5).  PINs are stored into
the array, one PIN per element, starting with the second element  and
continuing until the array is filled or all PINs are returned. If the
array is not filled, the remaining unused elements are padded with
zeros. The non-zero PINs can then be moved into you internal table.

For each child process call PROCINFO again to retrieve detail process
info, such as:

Process Priority, Item#8
State & Activation information, Item#9
Program name, item #10

You can also use the GETPROCINFO intrinsic.

I believe that once you have the correct child process numbers in your
table your problem may go away. I had a similar situation with child
process numbers, and as soon as I stopped maintaining my own table my
problems were solved.

Best regards,
Michael Anderson



>-----Original Message-----
>From:  [log in to unmask] [SMTP:[log in to unmask]]
>Sent:  Wednesday, February 11, 1998 7:55 PM
>To:    [log in to unmask]
>Subject:       Need CREATEPROCESS help
>
>This past weekend we upgraded from 4.0 to 5.5 on two HP3000s.
>Now we have a problem with processes created with the
>CREATEPROCESS intrinsic.  Father programs create the processes
>and keep the PINs in tables, and periodically check the status of
>the PINs.  The processes sometimes die or get hung, for various
>reasons, and the operator used to be able to KILL (PIN) to free it.
>Now a status check shows that the PIN is active,
>and GLANCE shows that it is indeed, except that the PIN
>became available and is now identifying a different process belonging
>to some other user running a different program.  The son process
>that originally had the PIN neglected to inform the father process
>that it was going away, and now the father can't KILL the pin and
>can't free up the terminal it was running on.  The people have tried
>turning off the terminals, resetting the DTC port, and other things,
>but the terminal and the port remain unavailable.  Since this began
>to happen Monday, right after the upgrade, I wondered if anyone
>knows what might cause this behaviour and what to do about it.
>These terminals that are taking a vacation are on the factory floor,
>so we are seeing a definite performance hit from 5.5.
>
>Cecile Chi