On Thu, 4 Jul 1996 19:22:50 EDT Jeanette Nutsford said:
>Jeff kell replied to my comments on Local Variables and said -
>
>>Using the PIN rather than an arbitrary index is a little more predictable,
>>but difficult to obtain in other than a father/son relationship.  [snip]
>
>Thanks Jeff, I had not thought of using the pin number.  This could work for
>the variables that I am creating although I still need the unique temporary
>file for each process for other reasons.  [...]
 
The same can be applied to filenames, particularly with HFS filenames (put
all your files in a directory with the PIN number in it).  I've done similar
code but in this application each son process was unique, and used filenames
with the program name (actually suffix identifier).
 
>I need to pass data from one process to another I am using variable names
>without the numeric portion (for all processes in the tree) or I pass the
>numeric number from the father to the son in sendmail/receivemail when it is
>only required between these 2 processes.
>BTW I use the HPCIGETVAR and HPCIPUTVAR to create and read the variables.
 
For IPC I have code that allows sons to communicate with the father using a
shared data segment (this is vintage 1978 SPL code pre-dating message files).
The father tracks the sons in an array, and the son is invoked with PARM= its
index in the table.  There may be better ways to do this now (obviously) but
the code is still in production (see 1981 Orlando proceedings for the paper).
This version uses fixed-length message blocks, but I have another version
that does variable-length records.  It was optimized so that peer-to-peer
transfers were possible, activating the father to awaken the target process,
but was optimized to skip this step if the queue length for the target son
was non-zero.  It used a local RIN to synchronize things and that fit well
with the suspend/activate intrinsics.  It was "cool" at the time but message
files came along (though IPC transfers only beat me by 15%).  COBOL programs
used this code.  But I digress...
 
>Every section in our COBOL programs has a piece of code at the beginning
>(provided by a Macro) which tests a JCW variable created by the father [...]
>If this JCW is set then a 'trace record' is written to a common tracefile with
>the son's [..] variable number to identify which process is active and what it
>is doing.  This was easy to do using HP COBOL II Defines (Macros) and has
>provided us with an easy means of getting a trace file from production
>programs.
 
Interesting concept.  One of our "models" for coding involved a main program
which accepted a "command" from the user.  The command is interpreted against
a table of commands, authorization flags, etc., and results in a "module" and
"command" number.  This is for traditional multiple-source-file programs with
commands implemented in separate subprograms (modules).  Extending this to
command numbers, we could group similar commands into common source files and
avoid duplication.  The current trend is for "big programs" that $INCLUDE the
subprograms in a nested source program (easier to share modules) but the old
method worked quite well.  One trick was to code each "module" so that if it
was called with command number=0 it displayed WHEN-COMPILED.
 
>>This gets into the Posix realm (your infamous Berlin wall, Jeanette) with
>>the "environment" concept.  ENV information is inherited yet local to each
>>process (unless you 'export' it).  Of course most of the time this involves
>>separate shells rather than direct process creation (Hey, that might work
>>for MPE if you invoke CI with info="run myprog" for strictly local vars, but
>>won't help inter-process communication/status checking).
>
>One of the key issues for application development on the HP3000 is the need to
>understand what you can do under each part of MPE/iX (MPE and POSIX).
>Everytime I see a post like yours Jeff, I realise that there is a lot I do not
>understand about the differences.
 
Let me address this separately in a follow-up message to keep the subject
intact; I'd very much like to address this issue.
 
Jeff Kell <[log in to unmask]>