Re: Virtualizing External LTO with TR2 and above

[CRPence <CRPbottle@xxxxxxxxx>]

  In my experience, there is the possibility that UserID and Pwd can be 
optional for a SQL CONNECT to establish a DRDA connection to a remote 
database.  IIRC that may require use of Change Server Auth Entry 
(CHGSVRAUTE) for IP connections.

  Also available are the options of REXEC or AREXEC [the Run Remote 
Command (RUNRMTCMD) command], if the REXECD or AREXECD server\daemon is 
started and will accept commands.

  The remainder, below... probably not of much interest.  Just some 
thoughts I had when I was thinking about the inquiry.

  Long ago I would use SBMNETJOB to get work done asynchronously [also 
on other physical systems]; using automatic submission.  The target job 
would send back some feedback [message(s) and\or file(s)] when the work 
at the target system was completed; the sender could wait on the 
feedback\message, or could occasionally check [e.g. polling] for the 
feedback\file, or wait for the message as an event via a break handling 
program.  The feedback could also be in the form of another job, also 
probably auto-submitted.  Such a CL job stream could be used to issue 
the vary-on request after the completion of the vary-off activity on the 
other system.  Another similar app had the recipient of a file via 
SNDNETF awaiting an arrival message and then reacting to pre-defined 
rules vs just submitting a CL stream, depending on each of the sender, 
the file name, and possibly also the contents of the file; such a 
process could similarly feedback to the sender.

  Hmmm. I wonder if having DB2 MultiSystem to have a partitioned TABLE 
with one row per partition mapping the status of the device, with a 
TRIGGER on UPDATE with an external action to act on the device, might be 
able to be used to implement a correlation to which partition has the 
device active.  Being a purchasable option, I suppose not a very likely 
choice to implement even if it seems possible.

  But I suppose a similar concept using a TABLE on just the hosting 
partition could implement something.  And then rather than DRDA to issue 
a command via the external stored procedure QCMDEXC, a DRDA request to 
update the row to /claim/ the device for a partition could trigger the 
work at the hosting system.  The hosting system would of course run in a 
*LOCAL connection vs over DRDA.  Between host and hosted seems simple 
enough, but between one hosted and another hosted requires that the 
hosting partition be able to communicate to the hosted partition other 
than the one requesting the UPDATE.

Regards, Chuck

On 13 Apr 2013 13:03, Monnier, Gary wrote:
> You can use SQL to call remote procedure QCMDEXC. Unlike DDM and
> SBMRMTCMD you do have to supply a user ID and password for the
> "remote system".
>
> Kirk Goins  on Friday, April 12, 2013 4:04 PM wrote:
> > <<SNIP>>
> > So if I needed to send a cmd to another partition what is the best
> > way?
> > <<SNIP>>