Additional considerations: SBMRMTCMD command

This topic describes additional considerations for the SBMRMTCMD command.

Override use example

The DDMFILE parameter on the SBMRMTCMD command is used to determine which target server the command (CMD parameter) should be sent to. Overrides that apply to the DDM file (not the remote file) are taken into account for this function. For example, if a file override was in effect for a DDM file because of the following commands, which override FILEA with FILEX, then the target server that the Delete File (DLTF) command is sent to is the one associated with the remote location information specified in DDM FILEX (the values point to the DENVER system, in this case).

CRTDDMF  FILE(SRCLIB/FILEA)  RMTFILE(SALES/CAR)
   RMTLOCNAME(CHICAGO)
CRTDDMF  FILE(SRCLIB/FILEX)  RMTFILE(SALES/CAR)
   RMTLOCNAME(DENVER)
OVRDBF   FILE(FILEA)  TOFILE(SRCLIB/FILEX)
SBMRMTCMD  CMD('DLTF RMTLIB/FRED')  DDMFILE(SRCLIB/FILEA)

This SBMRMTCMD command deletes the file named FRED from the DENVER server.

DDM conversations

When a SBMRMTCMD command is run on the target server, it has a target server job associated with it. Successive SBMRMTCMD commands submitted using the same DDM file and DDM conversation might run in the same or different target server jobs, depending on the value of the DDMCNV job attribute. The value of the DDMCNV job attribute determines whether the DDM conversation is dropped or remains active when the submitted function has completed. If the conversation is dropped, the next SBMRMTCMD command runs using a different target job. If several commands are submitted, either DDMCNV(*KEEP) should be in effect, or display station pass-through should be used instead of DDM.

Command syntax verifying

The syntax of the command character string being submitted by the CMD parameter is not verified by the source server. In the case of a user-defined command, for example, the command definition object might or might not exist on the source server.

Command running results

Because the submitted command runs as part of the target server's job, the attributes of that job (such as the library search list, user profile, wait times, and running priority) might cause a different result than if the command were run locally. If you find that you are having difficulty submitting a command and, for example, the reason is the target server uses a different library list, you can use the SBMRMTCMD command to edit the library list.

Error message handling

For errors detected by the target server when processing the submitted command, the source server attempts to send the same error information that was created on the target server to the user. However, if the source server does not have an equivalent message for the one created on the target server, the message sent to the source server user has the message identifier and is of the message type and severity that was created on the target server; the message text sent for the error is default message text.

If the target server is a system other than an iSeries™ server or System/36™, messages sent to the source server have no message identifiers or message types. The only information received from such a target server is the message text and a severity code. When a high severity code is returned from the target server, the source server user receives a message that the SBMRMTCMD command ended abnormally. Other messages sent by the target server are received as informational with no message identifiers.

For example, you might see the following statements in your job log when both the source and target are iSeries servers:

INFO CPI9155 'Following messages created on target server.'
DIAG CPD0028 'Library ZZZZ not found.'
ESCP CPF0006 'Errors occurred in command.'

When a target server other than an iSeries server returns the same message to an iSeries source server, the job log looks like this:

INFO CPI9155 'Following messages created on target server.'
INFO nomsgid 'Library ZZZZ not found.'
INFO nomsgid 'Errors occurred in command.'
ESCP CPF9172 'SBMRMTCMD command ended abnormally.'

The target server messages can be viewed on the source server by using pass-through and either the Work with Job (WRKJOB) or Work with Job Log (WRKJOBLOG) command. If the target job ends, the messages are in the target server's output queue, where they can be displayed by the Work with Output Queue (WRKOUTQ) command.

If the SBMRMTCMD command is used to call a CL program on the target server, any escape message that is not monitored and is created by the program is changed into an inquiry message and is sent to the system operator. If you don't want the target system operator to have to respond to this inquiry message before the job can continue, you can refer to the CL topic in the iSeries Information Center and do either of the following items on the target server:

If you want to specify a default reply for a specific job, you can use the INQMSGRPY parameter on either the Create Job Description (CRTJOBD) or Change Job Description (CHGJOBD) command to specify either *DFT or *SYSRPYL in the job description for the target job. You can also do the same thing if you use the SBMRMTCMD command to submit the Change Job (CHGJOB) command to the target server.
If you want to specify a default reply message for a specific inquiry message in the job, you can use the Add Reply List Entry (ADDRPYLE) command (on the target server) to add an entry for that message to the system-wide automatic message reply list (SYSRPYL). Then, if INQMSGRPY(*SYSRPYL) is specified in the job description, this default reply can be sent whenever that inquiry message occurs in the job.

Independent auxiliary storage pools (ASPs)

If the target system has online independent ASPs, the independent ASP group of the target job is established when the conversation is started and might not be changed. User-defined or CL commands that attempt to change the independent ASP group of the target job (for example, SETASPGRP or DLTUSRPRF) might fail if submitted to a target system that has online independent ASPs.