Re: SBMRMTCMD - doesn't really submit?

On 23-Apr-2014 11:18 -0500, Gqcy wrote:

I want to SUBMIT a job on a remote IBMi...

do I need to:

SBMRMTCMD CMD(SBMJOB CMD(SAVLIB......) JOB(NIGHT_BU)
JOBD(QGPL/BACKUPJD)) DDMFILE(QGPL/REMOTEDDM)

because doing: SBMRMTCMD CMD(SAVLIB......) DDMFILE(QGPL/REMOTEDDM)
just hangs the screen

The CL command mnemonic SBM for the verb "submit" does not imply also that the /submitted/ request is asynchronous. Because the term "submit" is most typically associated with the Submit Job (SBMJOB) command, the expectation of the effect may be derived from a misguided inference.

The SBMJOB command is an [effectively] asynchronous job-start request to perform the request-message that is provided as input; as work to be enqueued to the specified Job Queue (JOBQ). Thus a request to Submit Remote Command (SBMRMTCMD) to issue a Save Library (SAVLIB) request will /send/ [aka "submit"] that backup request to be performed [in an effective batch environment] _synchronously_ on the target system identified by the Distributed Data Management (DDM) File. Whereas a request to SBMRMTCMD to issue a request of a SBMJOB to [indirectly request to asynchronously] perform a SAVLIB request will return control immediately after the indirect request is enqueued for asynchronous work on the target system identified by the DDMF.

Passing the Remote Command request as a Submit Job request not only enables the [presumably desired] asynchronous nature of processing provided by that nested /submit/ request, but also enables establishing additional desired work management [job name, job description (with library list), optionally user, routing, etc.] rather than running the request under the default [or custom] Work Management established for the communications connection.