RE: opendir() - THE ANSWER -- MIDRANGE-L

Chris;

Do link() and unLink() fit your circumstances? These are what my moveIfsFile procedure are built with.

Duane Christen

--

Duane Christen
Senior Software Engineer
(319) 790-7162
Duane.Christen@xxxxxxxxxx

Visit PAETEC.COM

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Chris Bipes
Sent: Thursday, November 12, 2009 2:20 PM
To: Midrange Systems Technical Discussion
Subject: RE: opendir() - THE ANSWER

Ok I am just going with using the system API and the MOV command. It works. I was just hoping to find the API / Program behind the command so I would not be adding that additional workload. Guess it just is not worth the effort as all the APIs I have found don't seem to move between servers.

Chris Bipes
Director of Information Services
CrossCheck, Inc.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Thursday, November 12, 2009 11:54 AM
To: Midrange Systems Technical Discussion
Subject: Re: opendir() - THE ANSWER

Vern,

This is a bad idea. The programs in the QSHELL library are meant to be used inside the QShell environment.

There are all sorts of things that are set up in that environment...
this includes the standard I/O streams being set up a particular way, certain environment variables being set up a particular way, certain descriptor set up, the services of a shell and all of the stuff that the

shell does for you, being spawned a separate child job, etc.

These programs are written with the expectation that they will have all of that stuff set up. If you call the programs directly, you are using them in a manner that they weren't intended to be used!

If they happen to work because they don't happen to require the QShell environment right now... well, okay, I guess they'll work then. But you

can't rely on that being the case going forward. Your app may work today, then you might do a release upgrade or install a PTF and it may stop working.

It's just not a good idea to use software in a manner that it wasn't intended for!

If you're really THAT hard-up for a MV utility, you'd be better off finding an open source one and taking the relevant pieces of code out of

it so you can use it on i.

But I really don't see the value in calling the QShell MV command here.
why not just use the CL MOV command? That'll be more efficient than the Qshell variety, and you'll be using it from the interface it was deisgned for.

Just write a simple little wrapper program like this:

PGM PARM(&FROM &TO)
DCL VAR(&FROM) TYPE(*CHAR) LEN(500)
DCL VAR(&TO) TYPE(*CHAR) LEN(500)
MOV OBJ(&FROM) TOOBJ(&TO)
ENDPGM

Compile that as a CL program (or if you prefer, as a CL module and bind it to your RPG) then you can call it willy-nilly.

Vern Hamberg wrote:

Every command in QShell is a symbolic link to a program - those

programs

handle parameters the way a C program does - in my experience. There

a MV command in QShell, and its program is QSHELL/MV. This is an

example

of using it that does just what you want -

call QSHELL/MV ('/home/vern/aab.txt' '/home/aab.txt')

Scott, here's a chance for another article!!

I figured this out about 6 years ago and had forgot it. If you want it

not to prompt when replacing, add a parameter with value '-f'.

Whoopee!!
Vern

Chris Bipes wrote:

Not so crazy.. But how to write records to a iSeries Database from
within that shell script? Then make it wake up an process the