Scott,
Perhaps you or Dennis could clarify something I hit about 10 years ago...and
not used since...
When doing program calls that are SUBMITTED TASKS...the job initiation
process in AIX/unix ignores the path statement in the .profile file for the
profile that the task is running under. Last I recall, we had to qualify
everything or change the path inside the script so that it pointed where we
wanted it to...
DR2
--------
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Thursday, November 11, 2010 1:04 AM
To: Midrange Systems Technical Discussion
Subject: Re: qshell documentation, tutorial, rtm, rtfm and that genre
Okay, you have part of it right...
It's true that you can run a native *PGM object by fully-qualifying it.
As you stated, you can in fact run a program like this:
/QSYS.LIB/SOMELIB.LIB/SOMEPGM.PGM
That's a fully qualified call... and it's more or less equivalent to
doing the following in the native environment:
CALL PGM(SOMELIB/SOMEPGM)
However, it's not the full story. As you know, in the native
environment, if I don't qualify the program name (i.e. I specify CALL
PGM(SOMEPGM) without the library qualifier) the system will use the
library list to find the program.
QShell (or, really, any Unix shell) has something similar. Of course,
it uses IFS path names rather than libraries, but... it has something
similar, it's called the PATH. The main difference between PATH and
*LIBL is that PATH is only used when calling programs. It's not used
for files or other object types like *LIBL is.
So when you type just "ls" at the QShell prompt, it actually searches
the PATH to find it. You can view your current path by typing:
echo $PATH
Echo is a QShell program that prints it's parameters on the screen.
You're passing one parameter, which is $PATH. $ is a special character
in Unix shells, it means 'insert a variable value here.' So I've told
it to insert the value of the PATH variable... thus echo will print the
contents of that variable.
By default, IBM ships QShell's PATH set to only one directory, /usr/bin.
So when you type 'ls' (without qualifying it with a directory name) it
will look for a program named 'ls' in the /usr/bin directory of the IFS.
To see the ls object in the /usr/bin directory, you could type the
following (in QShell):
ls -l /usr/bin/ls
The output would look something like this:
lrwxrwxrwx 1 QSYS 0 27 Mar 27 2001 /usr/bin/ls ->
/QSYS.LIB/QSHELL.LIB/LS.PGM
The -> means that it's a symbolic link. So /usr/bin/ls is actually a
symbolic link to /QSYS.LIB/QSHELL.LIB/LS.PGM. Therefore, if you type
'ls' by itself, it results in CALL PGM(QSHELL/LS). But perhaps it was
for a different reason than you originally thought. It doesn't just
"automatically go to the QSHELL library", but rather it follows the
PATH, resulting in the symbolic link that ultimately leads to the QSHELL
library.
This behavior is really useful if you want to create your own QShell
utilities. For example, you might do this (from QShell):
$
mkdir -p /usr/local/bin
$
ln -s /qsys.lib/somelib.lib/somepgm.pgm /usr/local/bin/somepgm
$
export PATH=$PATH:/usr/local/bin
$
At this point, you've created a /usr/local/bin directory ("local" is for
stuff that's not included with the OS -- so it makes sense to put the
stuff you create into the /usr/local/bin directory -- or at least,
that's the norm on Unix systems.)
In the /usr/local/bin directory, I've added a new symbolic link that
makes /usr/local/bin/somepgm point to SOMELIB/SOMEPGM.
And finally, I've added (for this QShell session only) the
/usr/local/bin to the end of my PATH.
Now that I've done that, I can run the 'somepgm' program simply by typing:
$
somepgm
$
And QShell will run the somepgm that's located in the SOMELIB library.
I no longer have to fully qualify the directory name that the program is
in.
Furthermore, QShell is _also_ capable of running PASE programs (Assumimg
that PASE has been installed.) When you run a PASE program (either by
fully qualifying it, or by putting a directory containing PASE software
into your PATH) QShell will see that the object is an AIX program, and
will automatically invoke PASE for you -- thus letting you run AIX
software from QShell.
QShell also takes care of converting any parameters or stdin data from
EBCDIC to ASCII before it calls the PASE program, and it converts it
back to EBCDIC when it's done.
So QShell isn't just an easy way to run native programs, it's also an
easy way to run AIX/PASE programs.
On 11/10/2010 10:38 PM, Ryan Watkins wrote:
Just to clarify....I
Issuing the LS (or ls) command from QSHELL actually calls the LS
program (*PGM) object in library QSHELL behind the scenes.
And like Scott said, you can run any native IBM i programs directly from
QSHELL like this for example:
/qsys.lib/somelib.lib/somepgm.pgm
Ryan Watkins
midrange.com
