The first time I heard of UNIX as part of the greater (then AS/400) picture was at a TUG meeting which took place at the Hockey Hall of Fame, on May 17, 1994. The speaker for that memorable occasion was Eugene Carthra, of IBM. At that time, it sounded more like fictional techno-spin than anything very concrete.

AS/400 has since evolved into iSeries and we all know, a lot has changed in this landscape.

As for many AS/400 professionals with long years invested nearly exclusively in the OS/400 operating system, I have grown curious about UNIX.

Recently, on top of my iSeries duties, I got a chance to work on a UNIX/Oracle client-server project. The primary aim of this article is to share my UNIX discovery experience, from the viewpoint of a long time iSeries programmer. This will be done in three parts:

In Part 1, factual, will describe how the UNIX operating system works, and compare each of its major components with its equivalent in the iSeries.

In Part 2, somewhat subjective, will relate my top-10 impressions when first starting to work on UNIX, all along giving some precise examples to convey my points.

Finally, Part 3 provides a list of basic commands that can help one navigate in UNIX.

In March of 1999, nearly 3 years ago, I became a self-employed contractor, working on Y2K upgrades. Now on my own, I realized or perceived that I was suddenly more exposed to lack of knowledge in other platforms than the AS/400.

Recognizing that UNIX is probably closer to OS/400 than NT, I started a single UNIX course at the Southern Alberta Institute of Technology (SAIT), not knowing quite yet where it would lead me. To my surprise, this course was not taught on UNIX, as I had expected it to be. Rather, it was taught using Linux. Within a few weeks, I was hooked, and eventually took the full set of courses for the UNIX certificate.

In the late 1960's, Ken Thompson at Bell Labs had developed a game, "Space Travel", on an old GE computer that was later ported to run on a spare PDP-7. This project gave Ken Thompson, Dennis Ritchie, and Rudd Canaday the experience needed to develop a new operating system for the PDP-7 based on a new file system they had designed. This new operating system was capable of supporting two simultaneous users and was nicknamed (UNICS) for UNiplexed Information and Computing System. Bell Labs granted financial support to this project, and with time the name UNICS evolved into UNIX.

By Version 7, UNIX had developed and matured into a relatively stable operating system, which could run on several types of computers. At that time, a Department of Justice injunction forbade AT&T to sell software. AT&T made Unix available to universities as an academic tool for a low cost. It became very popular in university computer science departments. A major developer of the UNIX OS was one of these universities. In 1977 the first Berkeley Software Distribution (BSD) version of UNIX was released. Berkeley added virtual memory support, TCP/IP networking, vi, csh (C Shell), and more.

When deregulation hit and AT&T was split into different companies in 1982, the old regulatory restrictions were lifted and selling UNIX for a profit was allowed. The user community, universities especially, did not welcome this change. University of Berkeley's BSD then became a prominent UNIX player through its affiliation with Sun Microsystems, the leading proponent of the Berkeley UNIX. As a result of commercial pressure AT&T changed their licensing agreement which enabled many OEM's (e.g. Hewlett Packard's HP-UX) to write UNIX versions of their own without necessarily following all the standards or being obliged to share their innovations. Thus, the fragmentation of UNIX started.

In 1988, the standard for UNIX operating systems was formalized by the IEEE (Institute of Electrical and Electronics Engineers) under the name of "Portable Operating System Interface" (POSIX). POSIX, in particular, describes how to program operating systems so that they can be ported with greater ease to different hardware. The effect is that one can write the source code for an operating system in C and then compile on different compilers designed to work on each hardware model. All major UNIX systems, including Linux, adhere today to the POSIX standard. The United States government is the largest single organization procuring computer equipment in the world. It was an early adopter of the POSIX standard, giving it a lot of credibility.

In 1993, AT&T sold its UNIX business to Novell, who sold it to the Santa Cruz Operation two years later. In the meantime, the UNIX trademark had been passed to the X/Open consortium, which eventually merged to form The Open Group, who now owns the UNIX trademark.

This UNIX history perspective would not be complete without a word on Linux. In the early 1990's, Linus Torvalds, a Finnish undergraduate student, looked at a small UNIX hybrid called Minix and decided he could do better. In the fall of 1991, he released the source code for a freeware kernel called "Linux". While it is POSIX compatible, it is not technically a "UNIX" operating system, as its kernel was developed independently. Linux does not belong to The Open Group.

The evolution of the Linux OS is nothing short of surprising. In a mere ten years the Linux freeware project, with the contribution of thousands of programmers, has grown from undergraduate project to fully configured, professional grade operating system.

Any doubts about Linux's ability to handle a heavy load? At time of writing, Google.com, the number one search engine on the World Wide Web, uses web's largest index of web pages (over 2 billion), powered by the world's largest commercial Linux cluster - more than 10,000 servers. With this, it handles over 150 million searches per day.

What I found out when crossing to the UNIX world is that in the end, a computer is a computer, and that in many ways, even if the methods are different, the goals are mostly the same.

On the surface, and also from acquired reputation, one could be tricked into thinking the OS/400 and the UNIX operating systems are at opposite ends of a very large spectrum. Upon closer examination, it appears the overall methods used by UNIX and OS/400 to achieve computing goals are surprisingly similar. In the architecture diagram below, you can clearly see how both operating systems use similar layering methods to segregate the hardware from the software.

UNIX Architecture, compared to the iSeries

Beyond the basic architecture similarities and differences of these two operating systems, three more differentiators stand out:

• UNIX operating system builders were early adopters of the TCP/IP networking protocol. Right from the start, TCP/IP was to UNIX what SNA was to IBM 15 years ago. Initially, TCP/IP was considered less secure than SNA (this is still the case!). With the overwhelming popularity of the (TCP/IP based) Internet, TCP/IP has completely replaced SNA as the language of choice for communicating between systems.

• While UNIX sounds like one operating system, it is actually closer to an operating system type. There are several versions of UNIX and they are not 100% compatible with each other. The fastest evolving version of UNIX now is Linux, which has strong backing from all major computer hardware manufacturers. Even our trusty iSeries is now dipping its ladle in the UNIX sauce with its QSHELL, more on this later in the article.

• There are many facilities in the various UNIX shells to read and manipulate flat files, relational database systems however, have to be purchased separately. This, along the fact that UNIX can run on many types of hardware, is the biggest difference between these operating systems.

In any situation where you try a new car, visit a new house, you get a few "first impressions" that will likely remain in your mind for a while. In the next few paragraphs, I will describe my first UNIX impressions. My aim is to convey what I saw, as a typical iSeries programmer, when first crossing the line. Here are 10 items that struck me in my first UNIX experience:

1) Upon first glance, my number one impression was that UNIX could be probably well described as "MS DOS on steroids". The command line behaves the same way and it seems to be just as friendly. UNIX can accommodate multiple layers of directories (directories within directories) but it has no convenient way to represent or print the directory structure (not even a DOS "tree" equivalent). I subsequently found a shell script that could do that on the Internet, which means it can be done. It's just not there for you to start with. One other common point with DOS, the Shell Script language (Korn Shell, Bourne Shell etc..) is interpreted, like a .bat type of DOS file.

2) UNIX commands have evolved from many sources and many authors. They do NOT follow any type of naming convention. This, for the OS/400 programmer, is something to get used to. It's hard to compare commands like "CRTCLPGM" - named after "CReaTe Control Language ProGraM" with "awk" named after "Aho, Weinberg, and Kernighan" - the three authors of the command. "awk", by the way, is a text manipulation command.

3) If you do become acquainted with UNIX or Linux, or any of the flavors in between, you will need to get used to refer to "man" pages. The man command (short for "manual"), coupled with the command you are curious about, delivers manual pages (often referred to as man pages) describing the use of the command. Most times, man pages are cryptic and seldom have more than minimum examples. There is no prompting with F4 key or any equivalent to OS/400 command prompting in UNIX. In a strange twist of fate, QSHELL, the UNIX style shell implemented on OS/400 has no F4 prompt key support and no "man" command either. Again, there will be more on this topic later in the article.

With this order, using that profile, UNIX will proceed to wipe out your entire system, including the operating system without even as much as a burp or a thank you. For this reason, to protect yourself against dangerous experiments, it is best to use the root user profile sparingly.

This of course, is one man's opinion on command prompting. There are developers who find the iSeries operating system too talkative for its own good, and that less verbose is better.

5) vi is the most well known editors on UNIX. If you know vi, you can be sure you know at least one editor on just about any Unix machine you will ever get to work on, save your trusty iSeries, who has chosen not to implement it in QSHELL. Pronounced "vee-eye", vi is short for visual interface.

Working with three modes of operation: "command", "insert" and "line editor", vi has over 100 commands. Entire books have been written about vi. My experience is that it is rather confusing until you figure out which mode you are in. This is the type of editor you have to use regularly to get proficient. UNIX pros swear by it. They often say it is the most powerful text-based editor available. If you think there is power in simplicity, you may be tempted to argue differently. My number one vi tip: stay away from the arrow keys on the right side of the keyboard - they wont move your cursor!

6) Object authority or "file permission" in UNIX lingo, is something to both be aware of and get used to. I will go into some detail here because this is a key concept. Understanding how permissions work in UNIX is a necessity for every-day operations and it also gives a good indication of the style in which UNIX works.

A file, in UNIX can be anything from a flat file to a UNIX script. A UNIX script with an "x" in the "execute" permission flag position is deemed executable, even if not compiled (shell script is interpreted). Each file has 3 types of permissions (read, write or execute), for each of the three categories of users (individual users, groups of users or all users).

The 0 to 7 values are actually used as a shortcut to say their binary value. For example, the binary value of Octal 5 is "101". This translates in a permission value of "r-x" or "read, no write, execute". Octal 6 translates to binary "110" and thus the permission value of "rw-" or "read, write, no execute". The table below tells the whole story:

If a file for example has permission setting 777, it really has permission setting where the owner has rwx (read/write/execute), the group has rwx (read/write/execute) and the public has rwx (read/write/execute) permission. The permission flags look like rwxrwxrwx, listed at the right side of the file in a directory listing.

If a file has permission setting 764, the individual has rwx (read/write/execute), the group has rw- (read/write/no execute), and the public has r-- (read/no write/no execute). The permission flags look like rwxrw-r--, listed at the right side of the file in a directory listing.

There is more to read on UNIX permissions, but this is the base functionality. Coming from the iSeries environment, this method of determining authority or permissions, looks like a step backwards. It is however widely used and accepted by UNIX lovers the world over. There is no equivalent in UNIX to the notion of "object" in OS/400 sense. This may help understand this somewhat simple permission system.

7) One of the things you may have heard already about UNIX is that there is more than one standard for this operating system. You heard the truth. The main UNIX flavors of UNIX currently in the market place are Berkeley UNIX, AT&T Systems V Release 4 , SunOS/Solaris, XENIX, SCO and Linux.

The closest thing to a governing body that says, "This is UNIX" is the POSIX standard. It is now an accepted fact that to be commercially viable, a UNIX system, of any flavor, has to be POSIX compliant. That said, as long as this minimum is met, any company is free to invent or come up with a newer, better and stronger version. This is good and bad at the same time, for obvious reasons. It is good because there is freedom to innovate and change, it is bad because there is no strict standard, and thus incompatibilities do creep in. Perhaps the closest thing to a standard in UNIX available right now is the Linux kernel, which is standard across all distributions (Red Hat, SuSe etc.). It is also evolving faster than all other UNIX flavors and provide a lot more user friendly utilities than the traditional UNIX vendors.

There are several UNIX shells. The main shells are Korn shell, C-shell and Bourne shell. Why so many? The shell, in UNIX, is more or less equivalent to the iSeries CL language. Just as there are many UNIX operating system manufacturers, the UNIX Shell has also evolved over time. S.R. Bourne wrote the original UNIX shell around 1975. His version, one of the most commonly available, is the "Bourne shell". Bill Joy, from the University of California in Berkeley, created the "C shell". David Korn, at AT&T, created the "Korn shell". Linux has something called the "Bourne Again shell", also known as "bash". Consistently, each new shell creator (or creators) have tried to build upon established bases to create a better shell. Note that the Linux bash (Bourne Again shell) is free, as opposed to the other shells.

9) Despite differences between UNIX releases, some things are similar. Upon delivery, most UNIX systems have a number of standard directories, which contain well-known utilities or contain operating system programs that will perform certain functions or services.

The diagram below gives a quick idea of what these are. Note that the "/" is the symbol for the root directory. If you do a "cd /", you are doing a "change directory to root". This directory, in UNIX, is the OS/400 equivalent to QSYS, where all libraries ultimately belong. Note also that the example below is a typical map, but not necessarily an exact one for all UNIX flavors.

On the iSeries, up until recently, we had only one level of library or directory: There was QSYS, and all the libraries within it. This has now changed with the addition of the IFS, the Integrated File System, which allows multiple levels of directories.

10) In the same league as knowing what is going on with the authorities or permissions, there is a function in UNIX called the cron. The crontab file is equivalent to what we would call the "job scheduler" utility in OS/400.

The crontab, you guessed it, is UNIX's version of a task scheduler. At first glance, it is very cryptic, but it can be interpreted with relative ease if you know what it is talking about. Be prepared, in UNIX, "Relatively cryptic but can be interpreted" is practically a way of life. This is how the entire operating system is built. Many UNIX programmers will tell you that this is where the power is. Like beer, this may be an acquired taste, popular but acquired.

Back to the topic. A crontab file can have any number of commands. It can only process one command per line. One more thing to remember, after the last command, you must have a blank line or the CRONTAB will not run.

What does a crontab line look like?

The way the schedule looks is very cryptic but it's really very simple. There are five fields to the schedule. They are noted in bold below:

MINUTE(0-59) HOUR(0-23) DAY-OF-MONTH(1-31) MONTH-OF-YEAR(1-12) DAY-OF-WEEK(0-6)

Note 0 = Sunday

Also note that the ASTERISK (*) stands for a WILDCARD meaning it will match any value.

Example 1:

Means literally "execute the script located at /etc/dothis.abc" whenever the clock is equal to 0 minutes on ANYDAY, ANY HOUR, ANY DAY-OF-MONTH, ANY DAY-OF-WEEK. So the script is set to run ONCE PER HOUR EXACTLY ON THE HOUR regardless of what day it is or what hour.

Example 2:

is a little more picky. This crontab runs again whenever the internal clock hits ZERO (0) Minutes, but instead of running once per minute it will only run once per day. WHY? Because we also set the HOUR to zero so BOTH the MINUTE and HOUR must be equal to zero before crontab will execute /etc/dothat.now. So this example runs once per DAY at MIDNIGHT server time.

Example 3:

This example sets a crontab entry to run only on Tuesday at 2:21 PM. Note that this is written in military style time, i.e. 14:21.

Shell scripting in UNIX is the equivalent of CL programming on iSeries. It is part of the basic skill set necessary to effectively use a UNIX based system. The following examples are designed to give the reader a basic idea of three concepts that are key to the UNIX shell way of programming:

1. UNIX, unlike OS/400 or even NT is case-sensitive.
2. The UNIX shell scripting language uses a lot of pipes and directional operators to pass the output of one command to the input of the next. Think of it as having the *OUTFILE of your iSeries command piped directly into the command that follows without transiting via a physical file. (see Example 1)
3. In UNIX, even the simplest commands can have many optional flags that alter the command's default behavior. When unsure about which flags to use, you can get UNIX's equivalent of OS/400's F4 by typing the man command ("man" stands for "manual") followed by the command name. "man" pages are typically cryptic and provide minimal explanation. Many times, I find myself looking for other sources of information, either on manuals or on the Internet, which has a lot to offer for budding UNIX shell programmers.

"ps" is the UNIX equivalent to WRKACTJOB. This script command produces a list of active jobs using "ps -ef",(-ef represents two directives for "ps". The "e" tells "ps" to display information on every process and the "f" to display full information about the process). The output of "ps -ef" is piped into the "grep costing" command which will filter every line outputted by "ps -ef" except lines which contain the word "cost".

In this example, the meaning of the options attached to the command is:

The "ls" command in UNIX is similar to the "dir" command in DOS. It is both the simplest (nothing much to printing the contents of a directory) and most complicated (there are a total of 23 options for that command!) command in UNIX. When used all by itself, it only yields very basic information on the content of a directory. What I mean is that by just typing "ls", you will not know from the results, which entries are directories and which entries are files. You will also not know which are executable and which are the ones you have access to.

I have tried it myself, and have found it works fine. My experience is that QSHELL works in a standard UNIX fashion for most (but not all) commands. While there is no help or access to man pages in QSHELL, if you have access to the Internet, there is no shortage of documentation for UNIX commands (look for "UNIX man pages" in any search engine). Two other UNIX commands that are noted for their absence in QSHELL: "more" and "vi". There are thus no convenient file viewers (except "cat" which is not practical for larger files) or editors on the initial version of QSHELL. On its FAQ, IBM says:

• The Source Entry Utility (SEU) allows you to edit file members in the QSYS.LIB file system.
• The Edit Files (EDTF) CL command allows you to natively edit both stream files and QSYS.LIB file members.
• A mapped network drive to AS/400 allows you to edit files using your favorite PC editor.

For my initial shell scripts, I have typed my text file on a PC and FTPed it over to the iSeries to run.

Although QSHELL is not completely new, I have to admit it is new to me. It seems that quietly, UNIX has slipped-in through the back door of OS/400. If you are curious about UNIX, if you have no access to a "pure" UNIX machine, if you are reluctant to partition your PC to install a copy of Linux at home, this may be a good spot to get familiar with UNIX commands and the UNIX type of environment.

At some point, while writing this article, I had the following idea for a conclusion.

In the field of Biology, the first person to express a systematic presentation of evolution was Jean Baptiste de Lamarck (1774-1829) in 1809. Lamarck described his vision of evolution as "the inheritance of acquired characteristics." No kidding! It nearly sounds like "Object Oriented Programming"! In 1859, Charles Darwin (1809-1882) published "The Origin of Species" in which he coined the term "natural selection" to describe the process by which organisms with favorable variations survive.

If one could think of operating systems as actual living and evolving organisms, who would use innovation, research and marketing as food to grow, one could actually apply Lamarck's and Darwin's theories to the UNIX's and the OS/400's of the world.

If you think about it, you could say that Digital's CPM or Microsoft's Xenix for example have not evolved, or not evolved fast enough. From lack of support and/or lack of market, they eventually died.

By contrast, like the dog-like creature that in a few million years ago evolved into today's horse, DOS, fueled by Microsoft, mutated into Windows. The horse, user friendly, rather pretty and widely used, is also fragile. If it breaks a single leg, you have to put it down and start training a brand new horse.

The S/34 OS, fueled by IBM, became S/38 OS and then OS/400. I would compare it to the mammoth, which evolved into the elephant. Famous for its quiet stability, did evolve with time, but while doing so, it kept its general shape. The elephant is famous for its long memory of past events - a feature which compares well with OS/400's advanced system logging features.

UNIX, fueled by the rich intellectual grounds of AT&T's Bell Labs and Berkeley hit the market running right from the start. A living fossil, I would compare it to the crocodile. Long time survivor, it has kept a lot of its old proven concepts. Not pretty, not friendly, but it has stood the test of time. It will be there for a while yet. One more thing about the crocodile, like UNIX, it comes in several brands that look similar but have subtle differences, like the alligator and the caiman.

Looking back May 17, 1994, I now suspect Mr. Carthra was referring to PASE (Portable Application Solutions Environment) - an integrated solution to allow UNIX applications to run on AS/400. As far as I have seen, PASE was a good idea but it did not change anybody's life. Close but no cigar! Will the iSeries's ability to run Linux on a logical partition be different?

This all begs the question, which one of these operating systems will be the next survivor? Which one will be the next one to go extinct in the process of evolution?

Eventually, I decided that all this Darwin stuff would be a bit too deep for such a light-hearted piece. Here is my real conclusion to this article.

UNIX is not particularly hard to learn. It does however require a good road map if one needs to understand and/or investigate anything in this operating system. There is a large perceived cultural gap between it and OS/400. But perhaps it is caused more by what we do not know than by what we do know. Case in point: OS/400 and QSHELL now coexist quite comfortably on the same box.

The primary aim of this article was to share with fellow RPG/CL colleagues some of my own experiences as a new UNIX user. QSHELL is now part of the iSeries Operating System. iSeries now also supports Linux support also now offered on this computer, it might be a matter of time before you are exposed to some form of UNIX influence, without having to even leave the iSeries world.

Through my descriptions and examples in this article, I hope to have given you, iSeries programmers, a feel for what UNIX is like. Overall, it has a different look but in practical terms, it does many of the same things as OS/400. Of course, reading someone's impressions is a start, but it is no substitute for trying it your self. I encourage every iSeries programmer who read these words to fire up QSHELL, see what you can do with it, explore your system and see the possibilities. If you are interested in a more in-depth look at UNIX, buy a copy of Linux, install it on a spare PC, with this you can have your own risk-free UNIX training ground.

In this section, you will find the basic commands that will get you going in UNIX. If there was an 80/20 rule here, you could say that 80% of the time, you will use these few commands. At any rate, they are a good start and you can always learn more from there on.

Files & Directory Commands

Moving & Copying Files

Redirection (useful to string commands in Shell script)

Wildcard & Help (applicable to most commands)

File System Security

Special credits to

http://www.ee.surrey.ac.uk/Teaching/Unix/ for material used in this article.

http://www.superscripts.com/tutorial/crontab.html for crontab examples

http://www.SearchSolaris.com

http://www.ee.ic.ac.uk/

Recommended Reading:

• UNIX System V Release 4 An Introduction by Keneth H. Rosen, Richard R. Rosinski, James M. Farber and Douglas A. Host
• UNIX Shell Programming by Lowell Jay Arthur and Ted Burns
• TCP/IP Network Administration by Craig Hung
• UNIX in Plain English Third Edition by Kevin Reichard and Eric Foster-Johnson

Credits: Proofreaders around the world, who prefer to remain anonymous and have made this article more interesting, more fun to read.