RE: QSH RM

Might be a bug, but it's an old one. On this V5R3 system, the error message
is as David states. See the following (edited) log. I note that on PASE
(and on the unix systems I tested) this does not occur.

find myData

myData

myData/test

myData/test/file1

myData/test/file2

rm myData/*

rm: 001-2139 The object myData/test is a directory. No such path or
directory.

Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
"That was Benes' fifth strikeout of the day. He came in with 94, so now he
has 104 strikeouts for the year."
-- sportscaster Ralph Kiner

There are two potential things that could be stopping your program.

1) the fact that QShell prints a message on the display will stop the
program until someone presses ENTER. This is so that you don't miss
the
message.

2) if your CL program is configured to treat non-zero exit status from
QShell as an *ESCAPE message (via the QIBM_QSH_CMD_ESCAPE_MSG
environment variable) then QShell will send an *ESCAPE message to your
program, which would stop your program if not caught with a MONMSG.

Based on your symptoms, I'm guessing the former message is the culprit.
Please try coding the following in your CL program:


ADDENVVAR ENVVAR(QIBM_QSH_CMD_OUTPUT) +
VALUE(NONE) +
REPLACE(*YES)

ADDENVVAR ENVVAR(QIBM_QSH_CMD_ESCAPE_MSG) +
VALUE(N) +
REPLACE(*YES)

QSH CMD('rm /myData/*')


The two environment variables (ADDENVVAR lines) change the way that
QShell behaves. The QIBM_QSH_CMD_OUTPUT one tells it not to print any
output on the screen -- therefore, it won't stop and ask you to press
enter. The QIBM_QSH_CMD_ESCAPE_MSG tells it not to send an *ESCAPE
message if the 'rm' command fails (when Unix commands fail, they set
their exit status to non-zero, but if this envvar is set to Y, Qshell
will convert that exit status to an *ESCAPE message sent to your CL)

Please understand that this also means that your program will not
detect
any errors. For example, if it fails to delete 'file1' because of
insufficient authority, your CL program will get no notification of
that
fact. (This is true of _any_ type of failure, authority is just an
example.)

If you'd rather keep a log of QShell output (rather than discard it)
you
could do this:

ADDENVVAR ENVVAR(QIBM_QSH_CMD_OUTPUT) +
VALUE('FILE=/tmp/mylog.txt') +
REPLACE(*YES)

If you do that, your program still won't stop, but, each time it runs,
mylog.txt will be cleared, and the messages from QShell will be written
to it.

If you'd rather it not be cleared (but rather have new messages
appended
to the end) you can do this instead:

ADDENVVAR ENVVAR(QIBM_QSH_CMD_OUTPUT) +
VALUE('FILEAPPEND=/tmp/mylog.txt') +
REPLACE(*YES)

Hopefully you get the idea.

Regarding your second question about the strange error message:

rm: 001-2139 The object /myData/test is a directory. No such path or
directory.

I can't explain this. I suspect it's a bug... When I try it myself,
(v5r4) I get this somewhat different message:

rm: 001-2139 The object /home/klemscot/mydata/test is a directory. The
specified descriptor does not reference a socket.


My best guess is that it's a bug. The "object is a directory" message
is correct, but it's adding on spurious information (extra stuff that
doesn't apply) to the end.


On 6/3/2010 5:53 AM, David FOXWELL wrote:

Hi I'm running this command in a CLP :

QSH CMD('RM /myData/*')

This empties /myData ok, but as the directory 'test' exists in myData,

the program stops with :

rm: 001-2139 The object /myData/test is a directory. No such path or

directory.

I hit enter and everything's ok because I want the files in myData

deleted without touching any subdirectories. How can I prevent the
program from stopping? What does it mean by<No such path or directory>?

Thanks.

--
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.