UNIX Unleashed, Internet Edition
by Cameron Laird
It's a variety of the UNIX operating system. The Santa Cruz Operation, Inc. at <URL: http://www.sco.com/> or 1-800-726-8649, owns the intellectual property--the trademark, the copyrighted software, and so on. Contact SCO for details.
SVR4, (pronounced "ess-vee-are-four"; also written at times as SysVr4 "sys-vee-are-four"; or occasionally, "sys-vee") is an acronym for UNIX System V Release 4. UNIX System Laboratories, or USL, which was an affiliate of AT&T at the time, first released SVR4 in 1988. Its aims were to incorporate features of BSD UNIX (the other leading lineage of UNIX in the 1980s) into the System V mainstream, as well as SunOS's Network File System (NFS), the new POSIX, ABI, and X/Open standards, and to provide a base for future work, particularly in multi-processing. USL completed the kernel for Release 4.2 in July 1992. "UNIX" itself is a trademark licensed exclusively by X/Open (URL: http://www.xopen.org/faqs/faq_brnd.htm), a unit of The Open Group (URL: http://www.opengroup.org/), an industry standards organization.
Yes and no. SVR4 is at the center of UNIX operations in the 1990s, but the center has become a quiet place. Most UNIX users today rely on licenses of SVR4, because it's the basis for such market-leading brands as Solaris, HP-UX, Irix, and Unixware. However, most UNIX users do not concern themselves with SVR4, because each of those same market leaders has differentiated itself from SVR4. Most Sun customers think of their operating system as Solaris; Hewlett-Packard customers identify with HP-UX; and so on. There are machines that run SVR4 in a narrow sense, but they are all niche products, with populations a couple orders of magnitude lower than those of the leaders.
What's the conclusion? Think of these three categories:
Unless it is declared explicitly, all mentions of SVR4 in the rest of this chapter have to do with "narrow-sense" SVR4, that is, a release other than the "branded" ones of Solaris, HP-UX, Irix, and so on.
In 1995, Pierre Lewis wrote the standard online summary history of recent UNIX
varieties for the comp.unix.questions FAQ; see URL: ftp://rtfm.mit.edu/pub/usenet-by-hierarchy/comp/unix/questions/Unix_-_Frequently_
Asked_Questions_%286_7%29_%5BFrequent_posting%5D both for his work, and also
for the references he supplies there. The best single hard-copy publication that
covers the same territory is Salus' A Quarter Century of UNIX, published by
Addison-Wesley.
Most vendors and customers of SVR4 are in special situations that make their concerns much different from those of the mass market.
These are the leading vendors of UNIXes promoted as SVR4:
These vendors supply specialized hardware that provides high availability, high performance, commodity pricing, or a combination of related benefits. One possible complement to highly differentiated hardware is a well-understood operating system with an industry reputation for reliability and stability. That's what SVR4 is. When these vendors promote their products, they're able to concentrate their presentations on hardware capabilities, because the operating system is already familiar to prospective customers. The industry is comfortable with SVR4.
It's a little more difficult getting a handle on the SVR4 customers than it is to enumerate the vendors. The numeric majority might still be those using Coherent and Dell UNIX and other low-end, mostly 80 x 86-based, releases of SVR4 from earlier in the decade. Few of these vendors remain in the business, and their customer populations are inexorably falling.
The other principal category of customer for SVR4 is the specialized corporate information technology employee who needs the special offerings of the vendors listed in the previous two sections. The dynamics of SVR4 use are quite a bit different from those of such "evangelical" UNIXes as Linux and FreeBSD. SVR4 users generally maintain a narrow focus on "getting the job done" and have little interest in pushing the limits of the operating system as an exercise for its own sake.
SVR4 differs little in appearance from most other UNIXes in 1997. With few exceptions, you can do the same things you do with other UNIXes.
SVR4 includes:
It feels like modern UNIX; that's the main point. SVR4 does not encompass the POSIX threads library, but, otherwise, programming SVR4 is like programming almost any other UNIX.
Simply because it is so standard, programming SVR4 needn't be confined to C codings. Csh and ksh are part of the distribution, and freely distributable languages such as Perl, Tcl, Python, Rexx, Sather, Scheme, and more are readily available. Although SVR4 is unlikely ever to support the explosive growth of specific and graphical utilities and products one sees in the Windows world, these "scripting" or "high-level" languages can bring as much productivity to certain sorts of application development in the SVR4 world as any environment enjoys.
Yes. There is one point about application development that is specific to SVR4. One of the technologies that SVR4 makes available is that of shared or loadable objects. Essentially all modern UNIXes rely on shared objects. There are a number of specific cases in which using shared objects is not recommended; most have to do with commercial realities of backward compatibility for HP-UX, Solaris, and Linux. I've had no problems with shared objects under SVR4, though, and can safely recommend it for generation of applications in both the development and deployment stages.
You're probably using shared libraries already; they are the default for many development environments. Here's the story: a traditional approach to generation of applications is to compile and link into a single file all the machine instructions that a particular application requires. If you need system routines to translate from display format to floating-point, or to resolve a symbolic name into a numeric address, or to calculate a logarithm, the linker sorts all those references, mixes together all the fragments of machine language that implement them, and writes them into a "monolithic" file image.
There are other possibilities, though. Imagine a linker that makes a much smaller executable image, one that includes both the machine language for your source code and references to other libraries. The operating system can load that smaller file, and then, when it needs to execute one of the system functions, load that in also, from a standard location. Even better, in a multi-tasking environment, the system function your application needs may already be available in memory, because another process has been using it. There's more: shared libraries can improve the efficiency of installation, provide a much more convenient solution to certain security issues, and simplify some aspects of upgrading operating systems.
Shared libraries also have the potential to be an effort-wasting nuisance, if done improperly. The good news is that SVR4 shared libraries are generally done reliably, and there's no reason to avoid them. Read 'man ld' and other references your vendor supplies for details.
Let's look at an example. Suppose you're programming at a low level in C, and need to copy a structure from one location in memory to another. There are a number of idioms for doing so, but the safest I know is
#include <memory.h>
Ö
struct some_struct *source, *destination;
Ö
(void) memmove(destination, source, sizeof(struct some_struct));
memmove() is part of the 159-1989 ANSI standard for C, and reliance on it is less hazardous than bcopy() or structure assignment. I'm making a distinction here between correctness--each of these might be correct, depending on the requirements of your application--and safety; the latter accounts for robustness, readability, and maintainability. Intelligent reliance on POSIX and ANSI standards can go a long way toward making your source code clear and effective.
Stock SVR4 doesn't have a GUIfied admintool, or smit, or sam, to structure system administration tasks in a point-and-click paradigm. It's important that a system administrator with SVR4 responsibility have a complete set of manuals from the vendor, and also such a reference as the UNIX System Administration Handbook, by Nemeth et al., or Essential System Administration, by Frisch. The Prentice-Hall UNIX System V Release 4: Network User's and Administrator's Guide is also a possibility, depending on the circumstances (it was published in 1990). It covers almost all the technologies available in any SVR4, apart from dynamic kernels, but has nothing to say about several of the topics--NNTPSERVER, NIS, firewalls, and others--that are likely to be important in 1997.
If you're using SVR4, you'll be talking with your vendor. I know of no independent developers of device drivers. There surely are some, but they do not have the prominence that third parties do for Sun or Linux or Windows products. When SVR4 first appeared, it was a leader in supporting SCSI and serial devices. The technology underlying that leadership remains strong, but now that SVR4's market position is within niches specific to vendors, using it reflects the concerns and priorities of those vendors.
One of the most interesting developments in SVR4 technology is Portage (URL: http://www.consensys.com/portage/pintro.htm), "a complete integration of UNIX SVR4 with Windows NT," as its vendor advertises it. For a modest incremental cost, 80 x 86-based WNT users can have a full UNIX development environment on their existing host, including a choice of command shells, accessible from the NT Command Prompt.
Getting help from your vendor can hardly be emphasized enough. The SVR4 vendors are the modern experts on their offerings, and most of them understand the importance of their customers' success. Ask your vendor for help.
Online discussion groups ("newsgroups," in the vernacular of Usenet) are the best single mode for continuing education on SVR4. There are many forms: bulletin boards for regional interest groups, BIX conferences, CompuServe forums, and others. I find Usenet most useful for System V. Please understand that there's a large element of personal taste in this; even in the soberest technical groups, Usenet has a density of noise that many readers can't effectively filter. It also has the deepest and most precise answers on difficult questions.
All newcomers to Usenet should begin with news.newusers.questions (What are newsgroups, and what do I do with them?), and then news.groups.questions (Which newsgroups talk about particular topics?).
There are many valuable newsgroups that discuss UNIX topics. The most prominent are:
For particular specialized domains, check the following:
Both comp.unix.sys5.r4 and comp.unix.sys5.misc are newsgroups designed to support SVR4 discussion. They are both very low in volume, though, and particular questions directed to them have only a modest likelihood of being answered. The comp.bugs.sys5 newsgroup is even less lively.
Much of the information that comes out about SVR4 appears in the following vendor-specific newsgroups:
I want to draw special attention to alt.folklore.computers; at least part of the large and active population for this newsgroup are old-timers who enjoy reminiscing accurately about how they performed heroic works on obscure machines. Many of them have detailed and useful knowledge about SVR4. There is much less traffic at comp.unix.wizards, but it frequently bears on topics germane to SVR4.
For system administration issues, start with Celeste Stokely's "UNIX Sysadm Resources" at URL: http://www.stokely.com/stokely/unix.sysadm.resources/index.html and Frank Fiamingo's "Introduction to UNIX System Administration" at URL: http://sunos-wks.acs.ohio-state.edu/sysadm_course/sysadm.html. Mr. Fiamingo has also done an equally thoughtful "Introduction to UNIX" located at URL: http://www-wks.acs.ohio-state.edu/unix_course/unix.html.
There are a few dozen books that specifically address System V development and use--far more than almost anyone would want to read. My advice throughout this chapter has been to program or use the generic facilities at the heart of SVR4, because they're also familiar to users of other UNIXes. Heed the counsel of your vendor, who probably knows how to make the best use of the implementation. If you need information beyond those boundaries, you're likely to find it in some combination of the following:
Building UNIX System V Software, Israel Silverberg; Prentice-Hall, 1994.
Device Driver Interface/Driver-Kernel Interface Reference Manual for Intel Processors: UNIX System V Release 4; Prentice-Hall, 1992.
The Magic Garden Explained Solutions Manual: The Internals of UNIX System V Release 4: An Open Systems Design, Berny Goodheart, James Cox; Prentice-Hall, 1995.
Product Overview and Master Index for Intel Processors UNIX System V Release 4 Includes Multiprocessing; Unix System Laboratories, 1992.
System Files and Devices Reference Manual for Intel Processors: UNIX System V Release 4; Prentice-Hall, 1992.
UNIX System V Release 4: An Introduction, Kenneth H. Rosen (Editor), Richard R. Rosinski, Farber James M.; Osborne McGraw-Hill, 1996.
Mitch Wright and Samuel Ko make available useful annotated lists of published hard-copy UNIX reference works at ftp://ftp.rahul.net/pub/mitch/YABL/yabl and URL: http://rclsgi.eng.ohio-state.edu/Unix-book-list.html, respectively. They include no editions published after 1993 and 1994, respectively, but this makes them, if anything, only more useful for working with SVR4, whose technology hasn't changed materially since that time.
©Copyright,
Macmillan Computer Publishing. All rights reserved.