OS / 400
The OS / 400 (OS = Operating System) is one of the companies IBM developed and 1988 under the name CPF for the IBM System / 38 introduced operating system for the minicomputer class IBM Power Systems, System i , iSeries and AS / 400. With the appearance of Version 5 Release 3 (V5R3M0), OS / 400 was renamed to i5 / OS. From version 6.1 the operating system is called IBM i (for Business).
General
To understand OS / 400 or i5 / OS, it is necessary to understand the basic principle of the System-i architecture: main memory and disk storage merge seamlessly . In PC terms, the main memory is a "page cache" and the disk memory is a huge swap file (see paging ). The data in memory - RAM or disk - are generally objects , not files . A file system was therefore initially superfluous. This principle was only broken with the connection option for external data storage devices and an integrated file system was added (more on this below).
Virtualization
However, OS / 400 does not work directly with the hardware - it runs as a virtual machine. The MI (Machine Interface) or TIMI (Technology-Independent Machine Interface) is responsible for providing software and hardware . Below the MI level, the SLIC (System Licensed Internal Code) , which represents the actual operating system, works together with the hardware (in the days of the CISC processor, this code was still called HMC / VMC - horizontal / vertical microcode ).
Similar to Java, an OS / 400 compiler, such as ILE / C, ILE / RPG or ILE / COBOL, generates intermediate code at the machine interface level that cannot run directly on the AS / 400 hardware. Only a native translator in the operating system converts the machine interface code into the executable target processor code (formerly CISC IMPI - Internal Microprogramming Interface Code, today POWER RISC Code). Both the intermediate code (also known as the object template ) and the executable target processor code are stored in the program object . If the processor architecture is changed, no program source files are necessary; H. the corresponding translator generates the target processor code anew, based on the intermediate code, at the latest with the first program call. This is how the switch from the CISC (48 bit) to the RISC architecture (64 bit) was accomplished. This concept is already designed for a 128-bit architecture that may be available later.
Object basedness
The OS / 400 is built on the principle of object-basedness , whereby basically everything in the operating system, regardless of whether it is a user profile or a program , is viewed as an object with properties and functions; However, this principle should not be confused with object orientation as it is to be understood in programming languages . By convention, all system objects begin with the letter Q (e.g. QSYS or QSECOFR).
This consistent object-based nature means that objects (programs, files, spools, subsystems, etc.) can only be addressed using a set of finally defined functions. For example, it is not possible to freely change the binary code of a program, since this type of interface is available for objects of the file type (* FILE), but not for objects of the program type (* PGM). This fundamentally distinguishes OS / 400 from most other operating systems, where the file system only manages files , the purpose of which is only determined by a file extension and possibly a user assignment.
Objects are managed in libraries. These libraries cannot contain sub-libraries, only objects. The QSYS library, which contains all the libraries, is an exception. Files themselves can be broken down into members called subfiles. Source codes, for example, can be stored in those of the PF-SRC file type; members are stored in PF-DTA as indexable data tables. In OS / 400, each member has a logical record length (LRECL). Originally, OS / 400 did not recognize structure-free files like Unix. This only became possible with the introduction of the integrated file system (IFS).
Integrated applications
OS / 400 offers a variety of turnkey solutions, such as a permanent database management system (DB2 / 400) that does not require any additional installation. Furthermore, i5 / OS supports the Java language .
Often, ready-made solutions such as SAP on System i or Lotus Notes Cluster on System i are sold that rely on the system-integrated capabilities and do not entail any further licenses.
Commands
The operating system provides a number of extensive menus for operation. Likewise, the operation can also by the commands of the control language ( ger .: Command Language happen CL briefly). These commands are divided into:
- Action (what should be done?)
- Object (what should it be done with?)
Examples:
DSPOBJD : The first part DSP stands for D i SP lay, ie displays . The second part OBJD stands for OBJ ect D escription, i.e. object description . Together with the two mandatory parameters OBJ and OBJTYPE , you can display an object description, for example DSPOBJD OBJ (QTEMP) OBJTYPE (* LIB).
WRKOUTQ : The content of an output queue can be displayed with WRKOUTQ + "Name of the queue".
The GO CMD… command offers the option of displaying all commands that are associated with a corresponding action. For example, GO CMDWRK lists all commands that are related to WRK (WRK = Work). Alternatively, it is also possible, for. B. with wrk * to display all commands beginning with WRK . The user can use the F4 key (BT4 on terminal keypads) to call up operator guidance for almost every command, which makes entering parameters easier.
| word | short form |
|---|---|
| show (display) | DSP |
| print (print) | PRT |
| change | CHG |
| edit (edit) | EDT |
| clear | CLR |
| create | CRT |
| delete | DLT |
| add | ADD |
| remove | RMV |
| start (start) | STR |
| terminate (end) | END |
Users can also create their own commands. Objects of the type * CMD are provided for this, which can be created with commands according to the patterns described here.
As a tip: All command names are composed of two to three parts. It is a 90% valid rule that part of the command name is obtained by removing all voices from the corresponding English word and merging the first three voices (words that start with a vowel, this is retained). Example WRK = WORK or DSP = DISPLAY or STR = START etc. ...
privacy
There are three levels of security:
- System level
- User level
- Object level
The security at the system level is set in the system value QSECURITY. There are five levels , ranging from no security to so-called C2 security , a level certified by the US government. The user level is necessary for logging on to the system, whereby various authorizations are already defined here. At the object level, authorizations can be assigned explicitly for each object.
System objects are also protected from manipulation by the domain attribute of the object. Above a certain value in QSECURITY, despite object authorization, program code running in the user domain cannot change an object in the system domain . With this tightening of security, however, it should be noted that certain third-party software is dependent on such access.
Predefined user profiles
It is important to change the passwords for the system user profiles QSRV and QSRVBAS in addition to the QSECOFR (Security Officer) when starting up the system for the first time. These profiles are intended for the system engineer from IBM, and their passwords are like the user names themselves after installation. Although these user profiles are officially restricted in their authorization, they can very easily disrupt the system and even undermine security. It is here possible to start the system service tools with the command 'strsst'. Here an attacker can edit all objects (including user profiles) in the system without an authorization check preventing this.
Jobs, subsystems (SBS) and their processing
Jobs can be classified into system jobs, such as B .:
- Start-control-program-function (SCPF) (name comes from the S / 38 operating system CPF)
- System arbiter (QSYSARB)
- Logical unit services (QLUS)
- Work control block table cleanup (QWCBTCLNUP)
- Performance adjustment (QPFRADJ)
- Database server (QDBSRV01..N)
- Decompress system object (QDCPOBJ1..N)
- Job schedule (QJOBSCD)
- System spool maintenance (QSPLMAINT)
- LU 6.2 resync (QLUR)
- File System (QFILESYS1 and QFILESYS2)
- Database cross-reference system job (QBDSRVXR)
and subsystem-based jobs. The subsystems and their characteristics define the runtime environment of jobs in the system (assigned main memory pools, job queues, routing entries, job priorities, CPU time slices, etc.). For example, the jobs are routed to the desired subsystems via job queues, job classes or job descriptions.
The most important predefined subsystems are:
- QCTL - Controlling SBS (starts all other SBSs, otherwise only for system console)
- QINTER - Interactive SBS ( 5250 data stream jobs)
- QBATCH - Batch SBS (batch jobs of all kinds)
- QHTTPSVR - Web Server (various Apache instance + CGI jobs)
- QSPL - Spooling SBS (print jobs of all kinds)
- QSERVER - (File) server SBS (e.g. SMB server and client requests)
- QSYSWRK / QUSRWRK - most services / daemon jobs (ODBC / SQL, FTP, SMTP, LDAP etc.) run here
The most important job types running in the system are:
- System jobs SYS (run without subsystem)
- SBS subsystem (a subsystem is itself a special form of a job)
- Interactive Jobs INT (starts when a user logs in to the 5250 workstation and ends when a user logs off)
- Batch jobs BCH (starts as soon as a request is placed in a job queue)
- Spool jobs SPL (provides input and output files - for example a print job )
- Prestarted jobs PJ (are pre-started with the respective subsystem, e.g. ODBC / JDBC requests)
All jobs in the system can be easily viewed and managed using the wrkactjob command .
Integrated file system (IFS)
The OS / 400 operating system has also had a hierarchical file system since operating system version 3, analogous to Linux / Unix or Windows. This is a completely virtual file system - in contrast to hardware / hard disk-based file systems such as FAT, NTFS. It supports various local file systems as well as predefined mount points for remote file systems. Each object (path or file) in local file systems is represented by a Vnode (virtual index node). The Vnode structure contains pointers (references) to the blocks in which the data and metadata about an object are stored. This means that the OS / 400-IFS is perhaps best comparable to an "ext2 / ext3" file system. The local file systems of the IFS can be journalized.
Most file systems are started with the IPL (initial program load) of the operating system and are mounted in the root /.
- local file systems
-
- Root file system (Windows-like, case-insensitive)
- QOpenSys (UNIX-like, case-sensitive)
- QOPT (mount point for physical or virtual optical drives, i.e. CD / DVD images)
- QDLS (Document Library Service, 8.3 naming convention, relic from OfficeVision / 400 times)
- QSYS.LIB (this is a different view of the OS / 400 libraries)
- udfs (user-defined file systems - mount point under / dev / QASPxx)
- Network file systems
-
- QFileSvr.400 (Remote IFS of another iSeries / I5)
- QNTC (Remote CIFS / SMB server, OS / 400 acts here as SMB client)
- QNetWare (Remote Netware Server)
- NFS
There are several methods to access the file systems:
The Root and QOpenSys file systems support hard links and symbolic links.
- Hard links
- Hard links cannot be created across file system boundaries and mean that there are multiple references to the same IFS object. Deleting the last hard link to an object deletes the object itself.
- Symbolic links
- Symbolic links can be created across file system boundaries. Deleting a symbolic link never deletes an object (directory or file).
From i5 / OS V5R3 the IFS contains integrated scan APIs for virus scanners.