This chapter describes the type of storage devices available on UNICOS and UNICOS/mk systems including tapes, solid-state storage device (SSD), disks, and main memory. The type of I/O device used affects the I/O transfer rate.
The information in this chapter is pertinent for UNICOS and UNICOS/mk systems only.
The UNICOS tape subsystem runs on all UNICOS systems and is designed for system users who have large-scale data handling needs. Users can read or write to a tape with formatted or unformatted sequential Fortran I/O statements, buffer I/O, and the READDC(3f), READP(3f), WRITEC(3f), and WRITEP(3f) I/O routines.
A Fortran program interfaces with the tape subsystem through the Fortran I/O statements and the I/O library. The Tape Subsystem User's Guide, describes the tape subsystem in detail.
There are two different types of tape I/O interfaces: the traditional read[a] and write[a] system calls and tapelist I/O, which is unique to magnetic tape processing on UNICOS and UNICOS/mk systems.
Tapelist I/O allows the user to make several I/O requests in one system exchange. It also allows processing of user tape marks, bad tape data, and end-of-volume (EOV) processing.
The system libraries provide the following four common ways to perform tape I/O:
Through the use of the system calls.
Through the stdio library, which is commonly used from C. This method provides no means to detect or regulate the positioning of tape block breaks on the tape.
Through Fortran I/O (not fully supported on UNICOS/mk systems). This provides bad data handling, foreign data conversion, EOV processing, and high-performance asynchronous buffering. Only a subset of these functions are currently supported through Fortran I/O for the ER90 tape device.
Through the Flexible File I/O (FFIO) system (not available on UNICOS/mk systems). FFIO is used by Fortran I/O and is also available to C users. It provides bad data handling, foreign data conversion, EOV processing, and asynchronous buffering. FFIO uses tapelist I/O. For more information about FFIO see the INTRO_FFIO(3f) man page. Only a subset of these functions are currently supported through Fortran I/O for the ER90 tape device.
The tape subsystem provides the following capabilities:
Label processing
Reading and writing of tape marks
Tape positioning
Automatic volume recognition (AVR)
Multivolume tape files
Multifile volume allocation
Foreign dataset conversion on UNICOS and UNICOS/mk systems
User end-of-volume (EOV) processing
Concatenated tape files
The tape subsystem supports the following user commands on UNICOS and UNICOS/mk systems:
| Command | Description | |
| rls(1) | Releases reserved tape resources | |
| rsv(1) | Reserves tape resources | |
| tpmnt(1) | Requests a tape mount for a tape file | |
| tprst(1) | Displays reserved tape status for the current session ID | |
| tpstat(1) | Displays current tape status |
See the Tape Subsystem User's Guide, for more details about the tape subsystem.
The SSD is a high-performance device that is used for temporary storage. It is configured as a linear array of 4096-byte blocks. The total number of available blocks depends on the physical size of the SSD.
The data is transferred between the mainframe's central memory and the SSD through special channels. The actual speed of these transfers depends on the SSD and the system configuration. The SSD Solid-state Storage Device Hardware Reference Manual, publication HR-0031, describes the SSD.
The SSD has a very fast transfer rate and a large storage capacity. It is ideal for large scratch files, out-of-core solutions, cache space for I/O transfers such as ldcache, and other high-volume, temporary uses.
You can configure the SSD for the following three different types of storage:
SSD file systems
Secondary data segments (SDS)
ldcache
All three implementations can be used within the same SSD. The system administrator allocates a fixed amount of space to each implementation, based on system requirements. The following sections describe these implementations.
In the UNICOS operating system, file storage space is divided into file systems. A file system is a logical device made up of slices from various physical devices. A slice is a set of consecutive cylinders or blocks. Each file system is mounted on a directory name so that users can access the file system through the directory name. Thus, if a file system is composed of SSD slices, any file or its descendants that are written into the associated directory will reside on SSD.
To use an SSD file system from a Fortran program, users must ensure that the path name of the file contains the appropriate directory. For example, if an SSD resident file system is mounted on the /tmp directory, use the assign(1) command to assign a file to that directory and the file will reside on the SSD.
Example:
assign -a /tmp/ssdfile u:10 |
Users can also use the OPEN statement in the program to open a file in the directory.
SSD file systems are useful for holding frequently referenced files such as system binary files and object libraries. Some sites use an SSD file system for system swapping space such as /drop or /swapdev. Finally, SSD file systems can be used as a fast temporary scratch space.
The secondary data segment (SDS) feature allows the I/O routines to treat part of the SSD like an extended or secondary memory. SDS allows I/O requests to move directly between memory and SSD; this provides sustained transfer rates that are faster than that of SSD file systems.
Users must explicitly request SDS space for a process but the space is released automatically when the program ends. Users can request that several files reside in SDS space but the total amount of SDS space requested for the files must be within the SDS allocation limit for the user.
To request SDS space for unit 11 from a Fortran program, use either of the following assign commands:
assign -F cos,sds u:11 |
assign -F cachea.sds u:11 |
The ssread(2) and sswrite(2) system calls can be called from a Fortran program to move data between a buffer and SDS directly. ssread, sswrite, and ssbreak should not be used in a Fortran program that accesses SDS through the assign command because the libraries use SDSALLOC(3f) to control SDS allocation. Using SSBREAK directly from Fortran conflicts with the SDS management provided by SDSALLOC. The UNICOS System Calls Reference Manual, describes ssbreak, ssread, and sswrite.
On UNICOS/mk systems, the library does not handle allocation of SDS space from more than one processing element (PE). For files opened from different PEs, do not use SDSALLOC, assign -F sds, or the sds option of assign -F cache or assign -F cachea.
A Fortran programmer can use the CDIR$ AUXILIARY compiler directive to assign SDS space to the arrays specified on the directive line. The name of an auxiliary array or variable must not appear in an I/O statement. See the Fortran Language Reference manuals for your compiler system for a description of this feature. The UNICOS File Formats and Special Files Reference Manual, describes SDS.
The system administrator can allocate a part of the SDS space as ldcache. ldcache is a buffer space for the most heavily-used disk file systems. It is assigned one file system at a time. Allocation of the units within each assigned space is done on a least recently used basis. When a given file system's portion of the ldcache is full, the least recently accessed units are flushed to disk. You do not need to change a Fortran program to make use of ldcache. The program or operating system issues physical I/O requests to disk.
Several permanent mass storage devices or disks are available with UNICOS and UNICOS/mk systems. A disk system for UNICOS and UNICOS/mk systems consists of I/O processors, disk controller units, and disk storage units.
A sector is the smallest unit of allocation for a file in the file system. It is also the smallest unit of allocation; all I/O is performed in sectors.
In each disk storage unit, the recording surface available to a read/write head group is called a disk track. Each track contains a number of sectors in which data can be recorded and read back. The data in one sector is called a data block; the size of the data block varies with the disk type. The number of sectors per track, the number of tracks per cylinder, and the number of cylinders per drive also vary according to the type of disk storage unit. For example, a DD-49 disk storage unit contains 886 cylinders with 8 tracks per cylinder and 42 sectors per track. See the dsk(4), disksipn(7), disksfcn(7), and disksmpn(7) man pages for complete details.
The following table lists sector size, track size, and tracks per cylinder for a variety of disks:
Disk type | Sector size (in words) | Track size (in sectors) | Tracks per cylinder |
|---|---|---|---|
DD-49 | 512 | 42 | 8 |
DD-40 | 512 | 48 | 19 |
DD-41 | 512 | 48 | 15 |
DD-42 | 512 | 48 | 19 |
DD-40r | 512 | 48 | 19 |
DD-60 | 2048 | 23 | 2 |
DA-60 | 8192 | 23 | 2 |
DD-61 | 512 | 11 | 19 |
DD-62 | 512 | 28 | 9 |
DA-62 | 2048 | 26 | 9 |
DD-301 | 512 | 25 | 7 |
DA-301 | 2048 | 25 | 7 |
DD-302 | 4096 | 28 | 7 |
DA-302 | 16384 | 28 | 7 |
This information is useful when you must determine an efficient buffer size.
Disk-based storage under the UNICOS operating system is divided into logical devices. A logical disk device is a collection of blocks on one or more physical disks or other logical disk devices. These blocks are collected into partitions to be used as file system entities. A block is a sector.
An optional striping capability exists for all disk drives. Striping allows a group of physical devices to be treated as one large device with a potential I/O rate of a single device multiplied by the number of devices in the striped group. Striped devices must consist of physical devices that are all of the same type. I/O requests using striping should be in multiples of n×ts bytes; n is the number of devices in the group and ts is the track size of the disk in bytes (not in words or sectors).
For most disks this figure will be n× 4096 bytes. For DD-60 disks, n must be rounded to the nearest multiple of 4 because its sector size is 16 Kbytes.
Disk striping on some systems can enhance effective transfer rates to and from disks.
The assign(1) command provides an option to declare certain files to be memory resident. This option causes these files to reside within the field length of the user's process; its use can result in very fast access times.
To be most effective, this option should be used only with files that will fit within the user's field length limit. A program with a fixed-length heap and memory resident files may deplete memory during execution. Sufficient space for memory resident files may exist but may not exist for other run-time library allocations.
See Chapter 6, “The assign Environment”, for details about using the assign command.