The merging of two platforms, especially two as disparate as MVS (now called OS/390) and UNIX, is bound to cause confusion in those who have to maintain, debug, and write applications for the merged system. Users generally have experience in either MVS or UNIX and neither side is quite sure what to make of the other. Terminology is different: an address space in MVS is a process in UNIX; a task is a thread, and a started task is a daemon. A daemon? Not only how we talk about the platforms but how we talk to them is different. One is upper case, one is lower case. One uses a shell, the other has TSO/E and ISPF. Applications are written in different languages and jobs are submitted for processing in different ways. And so forth...
The team who manages OS/390 workloads and installs e-business products must be equally comfortable in both environments. That team needs to understand that OS/390 is a certified UNIX platform, that there is a history behind UNIX, and that, though the differences may be confusing at first, tremendous value can be derived from the system if people understand the concepts and operational procedures of both and can translate between them.
The following pages address this need by explaining:
- What UNIX is
- Why IBM implemented UNIX on the S/390 platform and how we did it
- Some UNIX history and concepts
- What's different and what's the same between UNIX and MVS
The main audience for this discussion is the MVS system programmer for whom OS/390 UNIX System Services (OS/390 UNIX) is, at times, an unwelcome addition to the computing environment. The table at the end of the discussion is for everyone who runs OS/390. Don't miss it; it compares and contrasts tasks and concepts in MVS and UNIX in terms everyone will understand. The topics in the table come directly from discussions that took place on the MVS-OE listserv. This list is an excellent source of help for OS/390 UNIX. The participants are customers using UNIX System Services and some IBMers. Subscribers to the mailing list ask and answer each other's questions; They receive all questions, answers, and comments as e-mail. To subscribe (and perhaps participate) send a note to email@example.com. In the body of the note put:
sub mvs-oe your_first_name your_last_name
Once you are subscribed, you will receive further instructions on how to use the mailing list.
Table of ContentsWhat is a UNIX System?
IBM's Implementation of UNIX
Some UNIX Concepts
OS/390 UNIX Security
The Multiple Ways to Use OS/390 UNIX
Comparing MVS and UNIX Concepts and Terms
A UNIX person might respond that a UNIX system has directory and file structures that are similar to PC systems. It has TCP/IP to connect to other systems. It has a set of system calls that perform functions that are similar to the functions other UNIXes provide. It allows users to telnet or login to a shell (the UNIX command-line interface) to interact with the system. It has certain utilities that the UNIX user expects to find in the work environment. UNIX application developers expect C or C++ compilers and X-Windows, a graphical interface.
OS/390 UNIX is a UNIX system because it has all these things as well as UNIX-branding. IBM's first UNIX, called OpenEdition (a name you might remember), was one of the first UNIX offerings to meet the standards of POSIX (portable operating system interface for computer environments), an IEEE operating system standard.
History loves a paradox. Even the evolving histories of OS/390 and UNIX are no exception. Starting as a batch-oriented operating system running on the world's largest mainframes, MVS evolved into an interactive system that, as technology advanced, can now run on machines the size of a PC. And UNIX, starting as an interactive operating system running on workstations, converged with MVS in OS/390 to run on the world's largest mainframes.
Describing the background of OS/390 UNIX means first looking at the history of MVS. For more than 30 years, MVS programs have run on IBM and non-IBM mainframes, and have invoked services that use data in MVS data sets, such as sequential, partitioned, or VSAM data sets. The programs run only on the proprietary operating system; specifically, they run only on MVS. In the beginning, programs and input data were stored in 80-column punched cards. To process the data, jobs were submitted all at once as batch jobs. Scientific and business applications were developed that took advantage of the computer's phenomenal calculating speed. Some business-critical programs written in the 1960s are still running today.
The history of UNIX is very different. In the UNIX world, there are many varieties of UNIX, and each of them contains few lines of code from the first UNIX. To summarize, AT&T created the original UNIX in 1969 and, in 1973, began to make the source code available outside of AT&T. Others ported the code to their platforms and added their own extensions to make their UNIX unique from others. These extensions made each UNIX platform different from others and introduced challenges to those porting applications from one UNIX platform to another. Since then, standards have eased the process of porting.
UNIX is an interactive operating system. It provides application developers with many small, simple tools that they join together to do complex things. UNIX does not have all the checks and balances that MVS has; it provides the tools you need and assumes you know what you are doing.
In 1994, in MVS SP4.3, IBM introduced UNIX, calling it OpenEdition. Adding UNIX to MVS required IBM to make changes to MVS components, such as real storage manager (RSM) and contents supervisor, to make UNIX work. Although the first version of OpenEdition met some POSIX standards, it offered no entry to the network and did not include support for TCP/IP. In OS/390 R2, OpenEdition received full UNIX95 branding; OS/390 UNIX became a UNIX system according to the people who own the definition of UNIX, the Open Systems Foundation.
The UNIX that is in the current release supports all the C functions and command interfaces in the Open Systems Foundation's Single UNIX Specification. UNIX98 is the most recent standard and IBM is implementing the UNIX98 functions that make sense on OS/390.
IBM added UNIX to the MVS environment to compete for new work on S/390. In addition to the characteristics of UNIX described earlier, portability is important -- the openness of UNIX.
For programmers, portability of skills from one UNIX to another is important. If you work on a UNIX system, you can port most of your skills onto another UNIX platform. If you are familiar with AIX -- to you AIX is UNIX -- and you go to another UNIX system, there will be some differences, but, in general, you will feel right at home.
For applications, portability of source code from one UNIX platform to another is important. If applications consisted of only interfaces that meet the X/Open spec1170 specifications (also known as X/Open XPG4.2 or UNIX95 or Single UNIX Specification), a port would require no changes to the applications. But, in the real world, where applications contain some non-standard UNIX code, the applications will require some changes.
So, the two major reasons for UNIX on S/390 are portability of skills and portability of code. You can use the same skills on one platform and then another, and you can move function from one platform to another.
IBM did not port someone else's UNIX to OS/390. OS/390 UNIX is not an emulation, a subsystem, or an LPAR; it is not sitting on top of S/390 (as in a layering effect that suggests bad performance). IBM looked at the spec1170 specifications that say "these are what the UNIX interfaces are" and implemented those specifications directly into the OS/390 system as OpenEdition services, which now are the OS/390 UNIX services. The OpenEdition MVS Shell and Utilities, with many of the Korn shell features, were first to take advantage of the new UNIX system services in OS/390.
To manage OS/390 UNIX, IBM wanted to use MVS system programming and operational skills. They wanted those who understand and manage S/390 availability, reliability, and security to continue to manage this new system in ways familiar to them. Therefore, there are MVS ways to manage the hierarchical file system, and SMP/E management of product code and service updates. However, UNIX programmers who expect UNIX interfaces will find those interfaces, unaware that, under the covers, traditional MVS things happen. For example, OS/390 UNIX services operate in MVS virtual storage areas called address spaces. Both the MVS system programmer and the UNIX application developer can be comfortable in this new environment.
There are many services in the OS/390 system, such as MVS services and OS/390 UNIX services. All of these services run on MVS. Existing MVS applications continue to run, unaffected by the existence of UNIX services and applications that use the OS/390 UNIX services. All the applications can benefit from the reliability, availability, and security of the S/390 platform.
A common misconception is that application programmers have a choice of either running UNIX programs that use UNIX services and file systems or running MVS programs that use MVS services and MVS data sets. You do not have to choose between OS/390 UNIX and MVS. For example, if you are developing a UNIX application that needs to call DB2, you do not have to pass a request to an MVS program that then extracts data from DB2 and passes data back to the UNIX program. You can call DB2 directly from UNIX. And, if you telnet into the shell, you have a standard UNIX interactive command-line interface like the one you are familiar with. There is no wall between UNIX and MVS and there are no "sides"; you do not run "on the UNIX side" or "the MVS side". OS/390 is a powerful blend of UNIX System Services and MVS.
MVS-experienced system programmers now installing, maintaining, and debugging OS/390 UNIX are faced with new responsibilities that require learning new vocabulary and new concepts. Perhaps they now must interact with UNIX or TCP/IP computer personnel from whom they have been isolated before now. Differences between the familiar MVS world and the new UNIX world sometimes seem cultural and philosophical, as well as technical. This section tries to bridge the gap.
The UNIX operating system has two distinct pieces, the kernel and the shell:
- The kernel is part of the BCP element of OS/390; it sends instructions to the processor, schedules work, manages I/O, and tracks processes, open files, and shared memory, among other things. Other parts of the operating system or applications request the kernel's services using assembler callable services (called syscalls). No work gets done in OS/390 UNIX without involving the kernel.
- The shell, the interactive interface with the kernel, has a programming language of its own. The shell is a command interpreter. The shell's work consists of programs and shell commands and utilities run by shell users. You can think of the shell running with the kernel as TSO/E running with MVS (after all, TSO/E is the original shell of MVS.)
A shell script consists of shell commands packaged in one file; a shell script is similar to an MVS command list or a REXX exec.
There are several ways for you to access the shell. The most common are:
- The OMVS command, issued by a logged-on TSO/E user ID from a 3270 terminal or a workstation running a 3270 emulator, provides those familiar with TSO/E a familiar 3270-type interface.
- The telnet or rlogin commands, issued (without a login proc) from a workstation running TCP/IP.
When you use telnet or rlogin to access OS/390 UNIX, you have a standard UNIX interface, not a 3270-type interface. You work in character-at-a-time mode (each character processed as you type it). You can use the vi editor. One difference between telnet and login is:
- Communication through telnet can take place from OS/2, WIN95, VM, AIX, and many others. To login, type:
- Communication through rlogin takes place from another UNIX system. To login, type
- Communication through telnet can take place from OS/2, WIN95, VM, AIX, and many others. To login, type:
The shell has some extended functions that have no MVS equivalents; for example:
- Pipes (redirecting output of a program to the input of another)
- Redirection (directing a data flow)
A daemon is like an MVS started task -- it is a long-running task that runs in the background and is not associated with any particular user. It starts work (or performs the work itself) on behalf of a user request, such as an rlogin request on an IP port, or a user shell script run at a scheduled time each day. Daemons usually run authorized and can issue authorized functions, such as changing the identity of the user associated with a process. You can think of the VTAM started task as a daemon.
If you have used UNIX before, you are probably familiar with file systems that are hierarchical in nature. In OS/390, system programmers need to understand this file system; they have new terms to learn and new procedures to follow, including:
- Allocating and mounting HFS data sets
- Applying service to the programs and data in the HFS data sets.
In OS/390 UNIX, all data and programs are in a hierarchical file system (HFS). You can think of this file system as an upside down tree with a root at the top and many leaves, that is files, at the bottom. This file system is similar to the file structures in the OS/2 and DOS platforms. It is a collection of files and directories.
OS/390 programs and data are delivered to you in MVS data sets and in this new file structure. In fact, IBM ships over twenty elements (their programs and data) that store into the HFS. After the installation is complete, more directories and files will be created for use by application developers.
OS/390 has implemented the file systems in the following way. It uses MVS data sets of a type called "HFS", a type created for OS/390 UNIX. System programmers create and maintain the HFS data sets. These data sets can only be used through OS/390 UNIX. This use is no different from how an MVS program would use a VSAM data set.
As of Release 9, HFS datasets can reside on non-SMS managed volumes, but IBM does not generally recommended it Regardless of whether the volumes are SMS-managed or not, DFSMS/MVS must be active for all OS/390 UNIX function.
The way to make an HFS data set accessible is by mounting it. After you finish with a data set, you can can unmount it. The OS/390 UNIX mount is not the same as the traditional volume mount; internally, MVS allocates and opens a data set. For the unmount, MVS closes the data set and deallocates it.
In OS/390, MVS security extends to include OS/390 UNIX. To protect the system from programs and programs from other programs, every resource runs in an address space and every task in that address space runs under a security environment managed by RACF, or a comparable security program.
All access control decisions for OS/390 UNIX are made by RACF, unlike other UNIX systems. In OS/390 UNIX, RACF knows users by a numeric ID, called a UID. Additionally, groups the users belong to are known by group IDs (GIDs). For example, if everyone within a department needs to use a certain set of common files, directories, or devices, that department would be a group and have a GID. A user's UID and GID are stored in RACF's security data base.
When a user wants to access a file, RACF matches the requester's UID and GID against security information associated with each file, namely:
- The file's owner, represented by the owner's UID
- Group owner, represented by the owning group's GID
- Permission bits, which describe the read, write, and execute ability for owner, group, and "others" (all users). The permission bit is known by a three-digit number. For example, permission bit 755 is a common one - it looks like this, where r stands for read, w stands for write, and x stands for execute.
r w x r w x r w x 1 1 1 1 0 1 1 0 1 7 5 5 3 3 3 3 3 all users permission 3 group permission owner permission
By matching the user's UID and GID against this security information, RACF determines who should be allowed to read, write, and execute the file. In this case the permission bit 755 means that the owner can read the file, write to the file, and execute the file; members of the owning group can read and execute the file, as can all users. The owner can write to the file; no one else can.
Just like all UNIX systems, the installation defines certain system administrators as superusers, having UID(0), who can change the contents of any file, manage processes, and perform other administrative activities. When not doing activities that require superuser authority, system administrators can change to user authority, which permits access to his or her own files and other files, according to the permission bits.
Don't confuse superuser authority with MVS supervisor state. Being a superuser does not increase the ability to do things in MVS. Remember the point about "no wall between MVS and UNIX"? Well, where security is concerned, the wall is there.
IBM offers familiar ways to use OS/390 UNIX, whether your background has been with UNIX or with MVS. Workstation users can copy data from MVS data sets into the file system for use at the host or, through OS/390 Network File System, at the workstation. They can also upload ASCII-encoded files to the host, where they can be translated into EBCDIC encoding for the host. The same application program can access both traditional MVS data sets and the files in the HFS. The program can invoke callable services from Assembler applications and subroutines, in addition to the C/C++ language applications. And, here are more ways:
- Interactive users can choose between the familiar interface of the UNIX shell or command interface and the traditional TSO/E panel or command interface. To use the HFS, you can use TSO/E commands, shell commands, or the panel interface of ISPF.
- To edit HFS files, you can use the ISPF full-screen editor or a UNIX editor, such as vi or ed, available in the shell.
- You can write MVS job control language (JCL) that includes UNIX shell commands.
- Using OS/390 UNIX extensions to REXX, you can run REXX programs from TSO/E, batch, the shell, or a C/C++ program.
- You can run a non-interactive shell command or a shell script from the TSO/E READY prompt and display the output at your terminal; you can run an interactive shell command through the OMVS command.
- You can use the BPXBATCH interface (with familiar JCL statements) to run the shell and its utilities in the background.
Workstation users can be connected to TSO/E and the shell through 3270 emulation or through OS/390 SecureWay Communication Server - IP (also known as TCP/IP). An installation can customize logging-on so that a user who prefers to work with a UNIX-like interface is put directly into the familiar UNIX shell. From there, the user can choose to switch to the TSO/E environment (through ISPF panels or TSO/E commands). An interactive user can log on through the TSO/E interface and switch to the shell when desired.
Comparing MVS and UNIX Concepts and Terms
After collecting topics from the MVS-OE listserv, as mentioned earlier, I created a reference table that identifies a task or concept, in platform-independent terms and then describes it in MVS terms, in terms of AIX (the UNIX that runs on RS/6000), and in terms of OS/390 UNIX. You may find it a useful reference.