×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
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>>
midrange.com
