RE: RUNRMTCMD to Unix box.... -- MIDRANGE-L

The only reasons (that I know of off the top of my head ;-) for a spool file to 
be in FIN.

1) The spool file was opened, but nothing was written
2) The spool file was printed (with SAVE(*NO))
3) The spool file was deleted

Does the RUNRMTCMD actually kick off something on the development box?

I'd take a look at the rexec daemon on the development UNIX box.  It might be 
setup to run the command "detached".  In other words, the rexec daemon starts a 
separate process for the command, thus the feedback you'd normally get in the 
spool file isn't there.  In the rexec daemon supplied with iSeries access for 
Windows, you have the following options:

Normal Mode: 

In normal mode, the console window owned by CWBRXD will be used if the command 
requires use of a console window. Normal mode also means that the new process 
the command is run in will be a "child process" of the CWBRXD process, which 
allows the command output to be captured and sent back to the user who sent the 
command.

New Console Mode: 

In new console mode, the command is run in its own console window rather than 
in the console window owned by CWBRXD. As in normal mode, the new process is 
run as a "child process" of the CWBRXD process, which allows the command output 
to be captured and sent back to the user who sent the command. The new console 
window created may appear on the desktop, and it may take a little longer to 
run the command because the new console window must be created first.  However, 
interactive console applications, when run in their own console window, do not 
keep subsequent commands from running as they might do if running in normal 
mode (i.e. in the console window owned by CWBRXD). An example of such a console 
application is edit.com, a text editor that comes with Windows.

Detached Mode: 

In detached mode, the command is run in its own console window rather than in 
the console window owned by CWBRXD, but it is also detached from the CWBRXD 
process. Because of this, the command's output, if the command is an executable 
program, often cannot be captured and sent back to the user who sent the 
command. Rather than seeing the command's output, the sender of the command 
might see a message stating the command produced none. If the output is not 
returned to the command sender, it is more difficult to determine if the 
command ran as expected. However, some applications will not run correctly or 
at all unless run detached from the CWBRXD process, so this mode may be 
necessary. One such example is xcopy.exe, which may not work unless run in 
detached mode.

The detached mode is what I'm thinking might be your problem.

HTH,

Charles Wilt
iSeries Systems Administrator / Developer
Mitsubishi Electric Automotive America
ph: 513-573-4343
fax: 513-398-1121
 

> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx
> [mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of
> todd.sabella@xxxxxxxxxxxxx
> Sent: Tuesday, March 29, 2005 4:31 PM
> To: MIDRANGE-L@xxxxxxxxxxxx
> Subject: RUNRMTCMD to Unix box....
> 
> 
> 
> 
> 
> 
> 
> Here's what's happening.....
> 
> On our development AS/400 system, performing a RUNRMTCMD 
> command to our
> production Unix box works fine.  When I run the following command, the
> system generates the QSYSPRT spool file in RDY status.  The spool file
> contains the results of the ls Unix command....Everything 
> looks good....
> 
> RUNRMTCMD CMD('ls') RMTLOCNAME(ProductionUnix *IP) RMTUSER('username')
> RMTPWD('password')
> 
> When I perform the same command to our development Unix box, 
> the system
> generates the QSYSPRT spool file in FIN status.  Therefore 
> the contents
> cannot be displayed and the message "File QSYSPRT number 1 no 
> longer in the
> system." is shown.
> 
> Anyone ever run across this before??  I am trying to rule out 
> any issues on
> the AS/400.   I assume there is some difference between our 
> development and
> production Unix servers which is causing the problem.
> 
> Todd
> --
> "NOTICE:  The information contained in this electronic mail 
> transmission is
> intended by Convergys Corporation for the use of the named 
> individual or
> entity to which it is directed and may contain information that is
> privileged or otherwise confidential.  If you have received 
> this electronic
> mail transmission in error, please delete it from your system without
> copying or forwarding it, and notify the sender of the error 
> by reply email
> or by telephone (collect), so that the sender's address records can be
> corrected."
> 
> -- 
> This is the Midrange Systems Technical Discussion 
> (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
> 
>