|
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-
bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Friday, September 27, 2013 2:55 PM
To: Midrange Systems Technical Discussion
Subject: Re: Help setting up RUNRMTCMD...
Robert,
You were perfectly clear. You are hoping to pass the directory to run the
command in to the program on the PC, right? Again, perfectly clear.
Now, read what I said about the START command again.
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
From: Robert Rogerson <rogersonra@xxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>,
Date: 09/27/2013 03:49 PM
Subject: Re: Help setting up RUNRMTCMD...
Sent by: midrange-l-bounces@xxxxxxxxxxxx
Sorry, I wasn't clear in my original post. The DIR command was only
used
as an initial test and it was run (and did create a spoolfile) as
expected. But the directory/folder it listed was c:\Windows\System32.
The program that I'm try to run exists in another folder and requires
the
working directory to be that folder. I have created a batch file which
issues as CD to the correct working folder and then calls the program.
This also works successfully but my boss has asked me to eliminate the
batch file if possible.
So what I'm asking is if when the RUNRMTCMD runs if the working
directory
can be set so the batch file (which sets the working directory) can be
eliminated.
I hope this is clear and sorry for the earlier confusion.
Rob
On 2013-09-27 2:54 PM, Dan Kimmel wrote:
When you're using RUNRMTCMD, you generally don't want to pipe output
to a
local file as you have here, Rob. Instead let the dir command write to
stdout as usual. The REXEC service will stream the output back to the
RUNRMTCMD which will then put the output in a spool file on the IBMi.
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.