johnking@xxxxxxx wrote:
For example, ScottK recently published a clever QShell script (see link #1
below) to copy spool files to HTML. The instructions described placing the script
in /usr/bin which, if I understand correctly (see link #2) is akin to C:\WinNT or
QSYS.lib. Other utilities may create their own directories in /root or place a
.jar file somewhere in /Javautil. Or whatever.
Hmmm... well, that's an interesting question, and open to debate (so
this is probably a great place to post it, right?)
On a Unix system, you'd typically have the following directories:
/bin = binary (programs)
/lib = library (unix equiv of service programs)
/var = variable (data that changes frequently, like logs, e-mail, etc)
/usr = user (stuff thats used by users, not just admins)
/tmp = temporary (self explanatory)
/etc = et cetera (configuration files.)
/home = stuff that's specific to a given user.
Originally, configuration files were stored all over the place, and only
those that didn't fit anywhere else would go into /etc. But it evolved
into the "right" place for configuration, and many people now refer to
this directory using the backronym "editable text configuration" for etc.
Then, because there can be programs, libraries, and so forth that are
used by users, not just admins, you'd have
/usr/bin
/usr/lib
/usr/etc
And, certain users might have their own programs, not globally
available, so you'd have:
/home/myuserid/bin
/home/myuserid/lib
/home/myuserid/etc
Many unixes also separate stuff used for "system" purposes (i.e. stuff
used by admins only) from those that are available to everyone. For
example, FreeBSD has /bin and /sbin for normal programs and
system-related programs. (and /usr/bin and /usr/sbin)
Many systems also have a /usr/local directory for things that are
specific to the current installation. Like your DR example, stuff that
you'd want to save/restore to set up your system on another machine
would be in /usr/local (and /home) so you don't have to restore the
entire /usr directory.
As with the others, this is broken into subdirectories
/usr/local/bin
/usr/local/sbin
/usr/local/etc
/usr/local/lib
So that's the basic idea, on Unix machines, though every different Unix
environment (UNIX, AIX, HP-UX, Solaris, IRIX, Minix, Linux, BSD, etc)
has their own interpretation of these basic directory structures. For
example, in Linux distros, if you install software from their packages
(for example, RPMs) it goes into the subdirectories of /usr, since it's
not considered a per-site thing, lots of people have that software.
However, on FreeBSD, packages go into /usr/local since they're not
included with the OS. and therefore, some shops will have them and some
won't.
You'll note that IBM includes a directory called /QIBM in the IFS. They
put that there so that their stuff is set apart from everyone else's
stuff...
It might be wise to do the same thing with your own software. Create a
/JohnsCompany directory (not sure who you work for off the top of my
head) and put all of your stuff inside that, so that that's all you have
to back up.
Or perhaps use /usr/local for that purpose (though, a lot of packaged
software will go into /usr/local by default, such as Zend's stuff, so it
might be smarter to make your own.)
The other thing that seems to continually throw me for a loop is the
QOpenSys directory. Since Unix stuff is case-sensitive, IBM made a
different file system for case-sensitivity, and put everything Unix-like
in it. So we have /qopensys/usr, etc.
That's irritating, since most Unix software expects /usr, and here IBM
has put things in /qopensys/usr. So I typically have /usr be a symbolic
link to /qopensys/usr, and put everything in /qopensys/usr. But that's
not the default configuration.
I find it difficult to figure out how much to explain and not explain
about directory structures, etc, when writing articles about Unixy
things like QShell and PASE. If I'm in a hurry, and don't want to deal
with 10000 questions about how to set up your PATH, I just go ahead and
tell people to put stuff in /usr/bin -- it may not be the best course
going forward, but it's much easier.
The people who are comfortable enough with the IFS to ask the question
("is this the best place?") will usually figure out how to move it!
midrange.com
