From: Michael Faurot <firstname.lastname@example.org>
Subject: inline SQL with isql (again) :-)
A friend recently brought to my attention that the mail
I sent to
you previously about how to do in-line SQL with Informix's
was published in the latest release of _SysAdmin_ (Vol.
2, No. 2).
Well, looks like the typesetting has a few bugs to be
worked out over
there. :-) In the article on pg. 110 it shows the following
isql phone - < EOF 2&1 | more
Actually it should read:
isql phone - << EOF 2>&1 | more
Could you ensure that something gets sent out in the
next issue showing the line as it should read?
Leor responds: Thanks for writing. Ventura sometimes
this to us.
Date: Fri, 28 May 93 11:05:36 EDT
Hi, I just picked up a copy of Sys Admin yesterday,
and have some
comments (mostly nits to pick) Larry Reznick's article.
First, a nit to pick... in the sidebar on '[' vs 'test',
it kind of odd that the article stated that the two
were linked. While
it's true that older versions of the Bourne Shell had
test as a separate
program, _all_ modern implementations have it as a built-in,
would have been better just to say that they are synonyms.
The other nits I have have to do with the 'which' script.
The first and most obvious problem with this script
to me is that
it bothers to convert the ':'s to ' 's, when the IFS
do the job even better. Not only that, but it is _possible_
of the directory names could contain a ' ', making the
The other one is that I'm appalled each time I see something
if [ "x$1" = "x" ]
This is _much_ easier to understand as either
if [ -z "$1" ]
if [ "$1" = "" ]
Well, at least the script didn't use
if [ x$1 = x ]
which I've seen all to often.
In this case, there's also the problem of the script
if one of the arguments is blank.
For instance, in the case of
which '' id
id will never be gotton to because the program does
to find the last argument by noting that it's ''. Using
$# is clearly
the right way to go.
Finally, the program merely checks that the files it's
are executable, but doesn't check that they might be
My revised version is below.
# based on which by Lawrence S Reznick (Copyright 1990) as printed in
# SysAdmin magazine.
# revised by Christopher J. Calabrese (email@example.com)
if [ $# = 0 ]
then echo "usage:\t$0 program [program] ..."
dirs=`echo $PATH | sed '
while [ $# != 0 ]
do unset found
for dir in $dirs
do if [ -x "$dir/$1" -a ! -d "$dir/$1" ]
then echo "$dir/$1"
if [ -z "$found" ]
then notfound="$notfound $1"
if [ -n "$notfound" ]
then echo "No $notfound in " `echo $dirs | sed 's/:/ /g'`
Larry Reznick responds: Thanks for writing. I like your
version of the code.
There are versions of test internal to sh, csh, &
with essentially the same test features, but with differing
I have also seen [ as a hard link to the external test
give you an idea of how varied this can be just on two
SCO SVR3.2v4, there are two unlinked files for [ and
test. Each is
a Bourne shell script that manually starts the internal
named for the script. On Esix SVR4 there is no [, and
test is a Bourne
shell script invoking the internal test program. But,
it invokes it
by using `basename $0`, so if a [ hard link was there,
it would use
the internal test or [ synonyms according to the name
used to execute
it. I imagine that the external test program still hangs
support old scripts that want it that way. I've seen
too many different ways. The sidebar mentions one way
I've seen it
that takes up the least space yet still has the external
Your IFS solution is more elegant for the loop, but
that you still need to convert the colons to spaces
for the error
message. While you have deferred the conversion until
it can't be
avoided, which is commendable for efficiency, you still
have to launch
sed to do it. I decided to just launch sed and get everything
with at once. (I noticed you have a semicolon typo in
the third sed
expression. It should be a period.) As for directory
a space, that sin is not easy to commit by the average
user. If I
ever saw that actually happen, I'd track down the owner,
why and what depends on it, and rename the offending
soon as I can. By the way, you don't need to store the
the IFS change won't affect scripts that aren't children
to the which
program. Notice that you don't restore from oIFS.
Your other comments are correct. The test techniques
holdovers from a very old version of this script when
I knew less
and was probably in an unreasonable hurry. I neglected
to update them
when I rewrote this for SCO. Not checking for directories
executable bit set was an important oversight pointed
out by another
reader. I plead only that the dirs in my path haven't
directories with the same name as the program I was
looking for, so
I never caught the problem. Thanks for your version
of the code. --lsr
Sys Admin staff,
I recently bought 2 Wyse 150 terminals in order to use
facility. I am presently using "Symulprint"
from Arnet Corp.
The problem is that it is not multi-tasking. When you
a job on one screen and try to switch over to the other
one, the processing
stops. I called Wyse Technologies and they said that
this was Arnet's
problem. I called Arnet and they do not offer a solution.
that since the programs write to the screen they must
have the screen
in order to process. Well, this just makes it impossible
to have multi-tasking.
Maybe someone has written an article to write to file
and delete the
"processed file" at the end od the day.
I would appreciate your help as I have two brand new
cannot use them for multitasking.
Pronto Cargo Corp
Contributor Larry Reznick responds: SCO provides multiscreen
for the console, and mscreen for serial lines. Esix
terminals only on the console. SVR4 doesn't support
at all. Therefore, I don't believe the problem has anything
with Wyse. It must be related to the particular implementation
I'm not familiar with the Arnet software. The virtual
I've set up require respawn entries in the /etc/inittab
for the virtual
terminals. The entries put a getty on each virtual terminal
entry I want to enable. Furthermore, the kernel may
need to be remade
to support them. A total-used count is given to the
drivers. Once the virtual terminals are set up, I've
never had a problem
with switching between screens. Tasks left in other
to run, including output on the switched-out screen.
Switch back to
that screen and it looks exactly as if you'd never switched
If Arnet's implementation requires the output screen
to be active,
they've effectively eliminated the usefulness of multiscreens.
If you can't get Arnet's multiscreens working properly,
you could have a script run the program that creates
the output file,
then enqueues an "at" job that will kill the
file at some
later time. --Larry
From: David Drexler
Date: Wed, 5 May 93 2:52:46 CDT
I recently received my first issue, and it looks to
be worth its weight
in 486 chips. The Publisher's Forum note say that this
is an anniversary
issue. That means there are 6 issues of it I haven't
seen yet. Where
can I get them, and what will they cost me?
Back issues are available for 1.3 (Sept/Oct '92), 1.4
'92), and 2.2 (March/April '93). They can be ordered
from R&D at a
cost of $11.00 per issue (US).
From: Chris Hare <firstname.lastname@example.org>
Subject: SCO UNIX Version Numbering
I just happened to be home sick today when my copy of
Sys Admin arrived. After I read your column, I felt
the Technical Services Manager for one of SCO's largest
Product Centers, I needed to explain the version numbering
The current release of SCO UNIX is release 3.2 Version
4, not 4.2.
Yes, you are correct that it is still based upon version
is the first USL release which was meant to incorporate
between Intel UNIX versions.
The Version 4 is SCO's attempt to show the lifeline
of the product.
It initially started as 3.2, and then 3.2 Version 2,
and now Version
The reasoning behind this is simple. When you look at
line right now, they have integrated UNIX, Security,
Extensions, X windows and the Desktop, and Networking.
In fact, SCO
has been doing Multiprocessor UNIX on Intel platforms
anyone else, and their latest MPX software provides
for true symmetrical
At the time Release 4.0 was announced from USL, there
was a separate
source code tree for each of these which would have
to have been re-integrated
by SCO. Their thought at the time, rightly or wrongly,
was to stay
with the 3.2 release until USL had integrated all of
You are quite correct that the version numbering has
confused a lot
of people, but then it is all marketing. Take a look
at how many people
will be buying Windows NT when it hits the streets,
and no one has
seen it yet! This is true for Release 4.0. So much effort
into the marketing, that people were persuaded to get
it even before
it was a product.
We all have to remember that USL desgins technology,
Those are for the vendors like SCO to assemble from
USL based technology.
In addition, Veritas does have volume management software
UNIX, and we have put some of it into some customer
sites, most notably
at Bell Cellular, which is one of the Cellular telephone
here in Canada. They are using SCO UNIX and Veritas
storage, call-record storage, communications with the
the costing routines are run, and the actual cell switches.
I would be happy to send you a copy of the information
which I have
Finally, congratulations on your anniversary. I feel
proud to be associated
with your organization, both as a subscriber, and an
up the good work!
Choreo Systems Inc.
SCO Advanced Product Center
Robert Ward responds: Thanks for the clarification --
and for your good work as an author!
Editor's note: Although Bjorn Satdeva has included information
about SAGE (The System Administrators Guild) in his
column, we thought
Ready Holt's letter would be useful to many of you.
From: Randy Holt <email@example.com>
Subject: Info That May Help the Administrator
First of all I want to say thanks for addressing the
area most needed
in computing, System Administration. Without competent
most work being done today would grind to a halt!
I have discovered a group of mail lists that can benefit
the proud, the System Administrator! I believe publishing
in Sys Admin magazine will help widen the distribution.
do not look at this as competition, but as a partnership.
The aliases I am referring to are the SAGE (System Administrators
Guild) group of USENIX aliases. Here is a listing followed
by a short
description of a select few. I hope you decide to publish
Network and System Administration
Here are instructions for the Administrator to subscribe
to an alias:
**** Help for Majordomo@USENIX.ORG:
This is Brent Chapman's "Majordomo" mailing
list manager, Revision
It understands the following commands:
subscribe [address] -- Subscribe yourself (or address
if specified) to the named .
unsubscribe [address] -- Unsubscribe yourself (or
address if specified) from the named .
which [address] -- Find out which lists you (or address
if specified) are on.
who -- Find out who is on the named .
info -- Retrieve the general introductory information
for the named .
lists -- Show the lists served by this Majordomo server.
help -- Retrieve this message.
end -- Stop processing commands (useful if your mailer
Commands should be sent in the body of an email message
Commands in the "Subject:" line NOT processed.
If you have any questions or problems, please contact
A Few Descriptions
Welcome to the SAGE certification working group.
The purpose of the certification working group is to
develop a model
for the certification of system administrators. The
model will address
the issues surrounding certification and discuss the
that might be taken. The working group will present
the model along
with their recommendations to the board of directors.
Welcome to the Sage-Conferences discussion list. This
is for the SAGE members (or potential members) who are
in conferences and workshops to be run by or in association
The Education working group's initial goal is to outline
for institutional and continuing education of the community
the development of model curricula, the identification
of useful tutorial programs, and the construction of
guides for self-study.
This group is charged with determining SAGE's role in
set of guidelines or codes of ethics for the system
We see these guidelines or codes as having at least
namely, guiding one's self in the performance of system
tasks, and informing one's employer and co-workers of
the proper bounds
of system administration.
Welcome to the SAGE Job Descriptions Working group!
The job description group will evaluate SAGE's role
in assisting system
administrators with defining job descriptions. If it
that this is an area that SAGE should pursue, the focus
of the group
will be to create multiple system administration job
that can be used as templates for those who are writing
for hiring purposes at their own site.
Welcome to sage-locals.
Users can be friend of the system administrator, but
will never be
able to be a peer. Therefore many system administrators
without contact to their peers. SAGE local groups is
intended to give
system administrators to meet on a regular basis.
The purpose sage-local small working group is to define
between local groups and SAGE. As SAGE is a USENIX STG,
include relationship to USENIX.
The group will also have the task of explore how creation
of new local
groups can be made easier, and how SAGE can support
groups, like Bay-LISA and BackBayLisa.
Welcome to the sage-managers mailing list!
While the complete new-subscribers information is currently
construction -this brief is available.
Sage-managers mail list was put together to provide
a forum for those
people wishing to address the issues of systems administration
managin or being managed thereto.
This includes, but is not limited to (in true management
how to provide the right kind of supporting information
how to explain systems administration so as to get what
you need and
not bore your boss; can someone talk to my manager and
him whatinhell is going on . . . and others.
All the details of what this means or what we-all have
have not been hammered out. I will have a one-liner
charter in place after Turkey day. Then we can free
The electronic information distribution working group
existing information sources that would be of use to
new types of information that should be gathered/produced,
proposals for the effective distribution of this information.
sources should include reprints of papers/articles and
news archives. New information sources might include
technical/positional papers and custom databases such
as vendor neutral
list of bugs. Distribution methods will include WAIS
or other information
servers, anonymous ftp/uucp, and CDrom.
This mailing list is for discussions pertaining to the
working group. This group will make a proposal to the
SAGE board on
how SAGE can address the needs of system administrators
who deal with
heterogeneous environments, which include systems running
OS's. Additional items may include how SAGE can best
people, who may not be plugged into the traditional
The Part Time working group is concerned that the proposed
did not mention the large number of people who do system
less than 100% of the time. (e.g. There are chemists
who fulfill system
administration roles some portion of each working day.
Yet, view themselves
as chemists, not system administrators. Hence, part
time system administration.)
We will consider how SAGE could address the needs of
and propose changes to the proposed SAGE charter which
The publications group is chartered to put together
a series of proposals
related to the various publications that SAGE wants
the immediate future the pubs group will be asked to
assist in the
publication of the first issues of newsletter segments
Long term goals include proposals concerning an independent
a technical journal, software tool collections, and
any other ideas
the committee can collect.
This is the USENIX SAGE Standards Working Group mail
The purpose of sage-stds is to provide a forum for discussion
system management standards in the following areas:
Communication: Provide a central point of contact for
regarding system management standardization efforts.
Education: Educate system administrators about the standards
in general. What can active administrators do to progress
Participation: Provide a conduit for the solicitation
of input from
active system administrators. Most standards participants
OEMs. More input from active system administrators is
will be posted to the mailing list of the IEEE POSIX
ManSig activities, UI SMWG activities, as well as X/Open
and NM Forum
activities as they are publicized. If you would like
to sign-up as
the "official" reporter for a standards working
post to firstname.lastname@example.org, and we'll sign you up.
Welcome to SAGE vendors working group! The purpose of
this list is
to discuss ways in which we, the members of the system
community, can encourage vendors to recognize the importance
administration and the need to develop tools to facilitate
times a single vendors' "solution" to system
has no application in the real world, where many of
us employ the
hardware and software of several different companies.
It is hoped
that SAGE can provide sufficient leverage to get vendors
real world solutions that we would actually want and
Initially the purpose of the list will be to discuss
of this course of action, and make a recommendation
to the SAGE board.
The board will then decide whether or not to pursue
any sort of interaction
with hardware and software vendors. However, the list
is not limited
to the purposes stated above, or to my personal view
of what the vendor
group should focus upon. You, as a member of the group,
have a great
deal of say in the matter. If the members of the list
feel the group
should take a different direction, that's what the group
provided it remains within the scope of our charter.