|
midrange.com
Thanks for the info....I did some digging on the 2 Unix boxes and found
that the rexec daemon is set up differently. It looks like the Unix Admin
is going to have to put the IP address of the AS/400 into a file which will
allow the rexec daemon to process commands from the AS/400.
Todd
"Wilt, Charles"
<CWilt@xxxxxxxxxxxx> To: "Midrange Systems
Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Sent by: cc:
midrange-l-bounces@m Subject: RE: RUNRMTCMD to
Unix box....
idrange.com
03/29/2005 04:48 PM
Please respond to
Midrange Systems
Technical Discussion
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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
