Reusable Server Kernel

Problem 6 (Minor): Worker API Distributed IUCV

==================== 1998-08-26 14:39:29 (-04.00) ====================
 
Name:        ** Suppressed **
Company:     ** Suppressed **
Telephone:   ** Suppressed **
E-mail:      ** Suppressed **
 
Text:
 
I put in a new command for the WORKER command set.  This command
will let the operator decide whether the machines of a given class
are to be managed as all-local (where the RSK does the autologging)
or as potentially distributed (where the server author or admin
takes responsibility for making sure they are logged on and
available).  For the latter case, the RSK suppresses all of its
XAUTOLOG/FORCE logic and just tries the IUCV CONNECT.  If it works,
great, else the application gets an error.  For the former case,
the RSK tries to XAUTOLOG as appropriate and FORCE when necessary
to reset an unresponsive worker.  This setting applies on a per-class
basis so that some classes can be RSK-managed while others are
managed by external means.
==================== 1998-08-26 13:03:44 (-04.00) ====================
 
Name:        ** Suppressed **
Company:     ** Suppressed **
Telephone:   ** Suppressed **
E-mail:      ** Suppressed **
 
Text:
 
It's more complicated than this, unfortunately.  The RSK decides
whether to XAUTOLOG based on the result of a CP QUERY USER
command - if the worker machine is found not to be logged on,
the RSK does the autolog and tries the IUCV CONNECT a little
later.  In other words, the RSK tries its IUCV CONNECT only
if CP QUERY USER first reports that the userid is logged on.
 
If your intent is to put the worker machines on another
system in the ISFC collection (autologging them yourself) then
the RSK will still not be able to find them because CP QUERY USER
will return the status of that userid on YOUR node.  I suppose I
could add a configuration option that would inform the RSK to
skip the CP QUERY USER check and just blindly try the IUCV CONNECT
instead.  I need to give this some more thought.
==================== 1998-08-26 11:31:30 (-04.00) ====================
 
Name:        ** Suppressed **
Company:     ** Suppressed **
Telephone:   ** Suppressed **
E-mail:      ** Suppressed **
 
Text:
 
At SHARE last week someone asked whether the worker API stuff
would work with worker machines located on another node in the
ISFC collection (that is, would Distributed IUCV work).  I
commented that I didn't think I had done anything explicit to
shut off Distributed IUCV but that I would check and report
back.
 
I inadvertently coded LOCAL=YES in my IUCV CONNECT for the
worker API.  This forced worker machines to be on the same
system as the main server.  I've changed this to LOCAL=NO but
am not refreshing the beta.  Note that if you elect to put
workers on other systems in the ISFC collection, you must make
sure they are autologged because the RSK will not be able to
issue the XAUTOLOG command and have it take effect on another
system.