Datenverwaltung, Ein-/Ausgabe. Prof. Dr.-Ing. Wilhelm G. Spruth. el0001 doc copyright W. G. Spruth, wgs 07-05

Transkript

1 Datenverwaltung, Ein-/Ausgabe Prof. Dr.-Ing. Wilhelm G. Spruth el0001 doc copyright W. G. Spruth, wgs 07-05

2 Datenverwaltung, Ein-/Ausgabe it-akademie Bayern z/os und OS/390 Lehrgang 2008 Prof. Dr.-Ing. Wilhelm G. Spruth Teil 1 File-Systeme EA 0601 ww6 copyright W. G. Spruth, wgs 10-02

3 Datenverwaltung Übersicht 1. File-Systeme 2. Datenorganisation 3. Data Sets 4. Dateiverwaltung 5. VTOC, Katalog Management 6. System Managed Storage 7. Ein/Ausgabe Parameter 8. Ein-/Ausgabe Verarbeitung 9. Adressierung desein-/ausgabe Subsystems

4 EA 0409 ww 2000 wgs 11-02

5

6 File Subsystem File System Platten- Speicher Device Driver Festplatten Plattenspeicher versus File System Das File Subsystem ist eine Komponente des Überwachers und arbeitet mit der logischen Sicht eines File Systems. Der Plattenspeicher Device Driver bildet ein oder mehrere File Systeme auf einem oder mehreren Plattenspeichern ab.

7 File System - Dateiverwaltung Das File System ist eine Sammlung von Daten für den Benutzer. Es besteht aus einer Menge von Files (Dateien). Eine File kann als eine Folge von Bytes angesehen werden. Alternativ konnen Files aus Datensatzen ( Records ) bestehen. Files werden über einen Filenamen identifiziert. Das File System wird von einer Komponente des Überwachers, dem File Subsystem, verwaltet. Das File System ist ein logisches Konstrukt. Das File Subsystem manipuliert die logische Sicht des File Systems. Das File System wird auf einer (oder mehreren) physikalischen Festplatten abgebildet. Die Festplatte enthalt neben den Files zusätzliche Daten über die Art der Abbildung (z.b. File Allocation Table, (inodes, Vnodes, Bitmaps, VTOC, DSCB). Es ist die Aufgabe des Plattenspeicher Device Drivers, das File System auf physikalischen Plattenspeichern abzubilden. Der Plattenspeicher Device Driver fiihrt die physikalischen Plattenspeicherzugriffe durch.

8

9 Unix File System A single level directory system contains 4 files owned by 3 different people, A, B, and C Letters indicate owners of the directories and files

10 A hierarchical directory system

11 File system containing a shared file

12 UNIX directory tree

13

14

15

16 Boot Block Block Block Block Block Group1 Group 2 Group 3 Group n Super FS Inode Datenblöcke Block Descriptor Liste Linux ext2fs File System Format Das Linux ext2fs File System besteht aus einer Folge von Datenblöcken, z.b. je 1 KByte groß. Der Boot Block (Boot Sector) beginnt auf Oberfläche 0, Spur 0, Sektor 1, gefolgt von einer Liste von Block Groups. Jede Block Group enthält einen Zeiger auf einen Superblock. Der Superblock enthält Angaben über Anzahl der Inodes Anfangsadresse der i-list ( Inode Liste) Literatur: M. Bach. The Design of the UNIX Operating System. Prentice Hall, 1986

17 Struktur des Superblocks Die Liste leerer Datenblöcke enthält Zeiger für einen Teil der verfügbaren Datenblöcke. Sie wird bei Bedarf aufgefüllt. Ebenso enthält die Liste leerer Inodes Zeiger für einen Teil der verfügbaren Inodes. Sie wird bei Bedarf ebenfalls aufgefüllt. Beide Listen üben eine Art Cache-Funktion aus, um bei einem Dateizugriff die Anzahl der physikalischen Plattenspeicherzugriffe zu minimisieren.

18 owner spruth group os type regular file perms rwxr-xr-x accessed Oct :45 P.M. modified Oct :30 A.M. inode Oct :30 P.M. size 6030 bytes disk addresses i-node

19 Linux ext2fs File System (1) Second Extended File System The Linux ext2fs file system can access data as large as 4TB. In contrast to other UNIXs, the ext2fs uses a variable length directory and can have files names that are as long as 255 characters. When creating the file system, the ext2fs enables you to choose what size block you want. Using larger blocks will speed up the data transfer because the head disk does not need to look (seek) as much. However, if you have a lot of small files, a larger block size means you waste more space. The directories entries in the ext2fs are in a singly linked list, as compared to an array with fixed entry lengths on some systems. Within the directory entry, you will find the name of the file as well as the inode number. This is the only place where the name of the file appears. In addition, there's a field that has the total length of the record in bytes (which is always a multiple of 4) that is then used to calculate the start of the next block. Therefore, there are no pointers as in other linked lists. EA 0414 ww 60 wgs 11-02

20 15 Zeiger in der inode 12 direkte Datenblöcke Je 1 einfach, zweifach, dreifach indirekter Block Struktur eines Linux file Systems EA 0416 ww 60 wgs 11-02

21 Linux ext2fs File System (2) Second Extended File System Among other things that the inode keeps track of are file types and permissions, number of links, owner and group, size of the file, and when it was last modified. In the inode, you will find 15 pointers to the actual data on the hard disk. Note that these are pointers to the data and not the data itself. Each one of the 15 pointers to the data is a block address on the hard disk. Assume each of these blocks is 1,024 bytes. Therefore, the maximum file size on a Linux system is 15KByte. Wait a minute! That doesn't sound right, does it? It isn't. If (and that's a big if) all of these pointers pointed to data blocks, then you could only have a file up to 15KByte. However, dozens of files in the /bin directory alone are larger than 15KByte. Hows that? The answer is that only 12 of these blocks actually point to data, so there is really only 12KByte that you can access directly. These are referred to as data blocks. The thirteenth pointer points to a block on the hard disk that actually contains the real pointers to the data. These are the indirect data blocks and contain 4-byte values, so there are 128 of them in each block. In the figure above, the thirteenth entry is a pointer to block 567. Block 567 contains 128 pointers to indirect data blocks. One of these pointers points to block 33453, which contains the actual data. Block is an indirect data block. Because the data blocks that the 128 pointers pointed to in block 567 each contain 512 bytes of data, there is an additional 65K of data. So, with 12K for the direct data blocks and 65K for the indirect data blocks, we now have a maximum file size of 77KByte. Hmmm. Still not good. There are files on your system larger than 77K. So that brings us to triplet 12. This points not to data blocks, not to a block of pointers to data blocks, but to blocks that point to blocks that point to data blocks. These are the data blocks.

22 In the figure, the fourteenth pointer contains a pointer to block Block 5601 contains pointers to other blocks, one of which is block However, block 5151 does not contain data, but more pointers. One of these pointers points to block 56732, and it is block that finally contains the data. We have a block of 128 entries that each point to a block that each contains 128 pointers to 512 byte data blocks. This gives us 8Mb, just for the double-indirect data blocks. At this point, the additional size gained by the single-indirect and direct data blocks is negligible. Therefore, lets just say we can access more than 8Mb. Now, that's much better. You would be hard-pressed to find a system with files larger than 8Mb (unless we are talking about large database applications). However, were not through yet. We have one pointer left. So, not to bore too many of you, lets do the math quickly. The last pointer points to a block containing 128 pointers to other blocks, each of which points to 128 other blocks. At this point, we already have 16,384 blocks. Each of these 16,384 blocks contain 128 pointers to the actual data blocks. Here we have 2,097,152 pointers to data blocks, which gives us a grand total of 1,073,741,824, or 1Gb, of data (plus the insignificant 8MB we get from the double-indirect data blocks). As you might have guessed, these are the triple-indirect data blocks.in Figure 0-7 pointer 13 contains a pointer to block 43. Block 42 contains 256 pointers, one of which points to block Block 1979 also contains 256 pointers, one of which points to block 988. Block 988 also contains 256 pointers, though pointers point to the actual data. For example, block 911. If we increase the block size to 4k (4096 bytes), we end up with more pointers in each of the indirect blocks so they can point to more blocks. In the end, we have files the size of 4Tb. However, because the size field in the inode is a 32-bit value, we max out at 4Gb. In addition to the "standard linux" file system, Linux supports FAT, VFAT, ISO9660 (CD-ROM), NFS, plus file systems mounted from Windows machines using Samba (via the SMB protocol). EA 0415 ww 60 wgs 11-02

23 ext2 Das ext2 oder auch second extended filesystem war viele Jahre lang das Standarddateisystem des Linux- Betriebssystems und ist immer noch weit verbreitet. Es wurde ursprünglich 1993 von Rémy Card auf Basis des Extended Filesystem v1 entwickelt, die heutige Implementation im Linux-Kernel stammt sowohl von ihm als auch Theodore Ts'o und Stephen Tweedie. Des Weiteren existieren Implementationen für NetBSD, FreeBSD, OpenBSD, GNU Hurd, Microsoft Windows, OS/2, RISC OS, AmigaOS und MorphOS. Hauptnachteil von ext2 ist, dass es kein Journaling-Dateisystem ist. Es verliert daher zunehmend Benutzer an seinen abwärtskompatiblen Nachfolger ext3 und andere, neuere Dateisysteme Spezifikation ext2 teilt viele seiner Eigenschaften mit traditionellen Unix-Filesystemen, z. B. das Konzept der Blöcke, Inodes und Verzeichnisse. Wenn gewünscht, ist es um Eigenschaften wie Zugriffskontrolllisten, Fragmente, Wiederherstellung gelöschter Daten und Kompression erweiterbar. Die meisten der genannten Funktionen sind nicht serienmäßig implementiert, sondern existieren nur als Patches. Weiterhin gibt es einen Versionsmechanismus, der es erlaubt, neue Funktionen abwärtskompatibel hinzuzufügen (wie dies bei der Journaling-Erweiterung ext3 geschehen ist). Alle Informationen werden auf einem ext2-system im Little Endian -Format abgelegt. Blöcke Der Platz auf einem mit ext2 formatierten Gerät oder einer Datei (man kann ext2-systeme in Dateien ablegen, die wiederum auf anderen Dateisystemen liegen) wird in Blöcke aufgeteilt. Diese haben eine feste Größe von 1 kb, 2 kb oder 4 kb (8 kb auf Alpha-Prozessoren). Die Größe der Blöcke wird bei der Erstellung des Dateisystems festgelegt. Kleinere Blöcke führen zu weniger verschwendetem Platz pro Datei, benötigen aber etwas mehr Zusatzaufwand bei der Verwaltung, und begrenzen indirekt auch die maximale Größe der Dateien und des ganzen Dateisystems. Blockgruppen Um eine übermäßige Fragmentierung zu vermeiden, die den Zugriff auf große Mengen aufeinander folgender Blöcke bremsen würde, werden Blöcke in Blockgruppen zusammengefasst. Die Informationen über jede Blockgruppe werden in einer Deskriptortabelle abgelegt, die direkt hinter dem Superblock liegt. Zwei Blöcke in der Nähe des Anfangs der Blockgruppe sind für zwei Bitmaps reserviert, welche die Blockund Inode-Belegung in der Gruppe anzeigen. Da jedes Bitmap nur einen Block belegen kann, ist die maximale Größe jeder Blockgruppe (in Blöcken) auf achtmal die Größe eines Blockes (in Bytes) begrenzt. Die auf die Bitmaps folgenden Blöcke enthalten die Inode-Tabelle für die Blockgruppe, und die übrigen sind als Datenblöcke nutzbar. Der Superblock Der Superblock enthält alle Informationen über die Konfiguration des Dateisystems. Der primäre Superblock liegt 1024 Byte hinter dem Anfang des Gerätes und ist wichtig, um das Dateisystem einbinden (mounten) zu können. Die Informationen im Superblock enthalten Felder, die z. B. die Anzahl der Blöcke und Inodes im Dateisystem angeben, wie viele davon frei sind, wie viele Inodes und Blöcke in jeder Blockgruppe vorhanden sind, wann das Dateisystem eingebunden wurde, ob es beim letzten Mal auch wieder sauber ausgehängt wurde, wann es geändert wurde, welche Version vorliegt, und welches Betriebssystem es angelegt hat. Da bei einer Beschädigung des Superblocks das gesamte Dateisystem unbrauchbar wäre, werden vom Superblock mehrere Kopien, verteilt in mehreren Blockgruppen, gespeichert. Diese Superblock-Kopien erlauben im Fehlerfall eine Reparatur des Original-Superblocks. Im Superblock gibt es weitere Felder, die den Namen des Datenträgers, eine eindeutige Identifikationsnummer und die Inode-Größe angeben, sowie Platz für die Konfigurationsinformationen optionaler Dateisystemfunktionen bieten.

24 Inodes Der Inode (Indexknoten) ist ein fundamentales Konzept im ext2-dateisystem. Jedes Objekt im Dateisystem wird durch einen Inode repräsentiert. Die Inode-Struktur enthält Zeiger (Verweise) auf die Blöcke, in denen die Daten des Objekts abgelegt sind, und außerdem alle Metadaten über ein Objekt mit Ausnahme seines Namens. Zu den Metadaten gehören Zugriffsrechte, Besitzer, Gruppe, Flags, Größe, die Anzahl der benutzten Blöcke, Zugriffszeitpunkt, Änderungszeitpunkt, Löschzeitpunkt, Anzahl der Links, Fragmente, Version (wird von NFS benötigt), erweiterte Attribute und eventuelle Zugriffskontrolllisten. Es gibt einige ungenutzte Felder und überladene Felder in der Inode-Struktur. Ein Feld ist für die Verzeichnis-Zugriffskontrollliste reserviert, wenn der Inode ein Verzeichnis ist, alternativ hält dieses Feld die oberen 32 Bit der Dateigröße, wenn der Inode eine reguläre Datei ist (dies erlaubt Dateigrößen über 2 GByte). Die meisten der übrigen Felder werden von Linux als vergrößerte Besitzer- und Gruppenfelder genutzt. Es gibt im Inode Zeiger auf die ersten 12 Blöcke, welche die Daten der Datei enthalten. Außerdem gibt es einen Zeiger auf einen indirekten Block (der wiederum Zeiger auf den nächsten Satz von Blöcken der Datei enthält), einen Zeiger auf einen doppelt indirekten Block (der Zeiger auf weitere indirekte Blöcke enthält), und einen Zeiger auf einen dreifach indirekten Block (der Zeiger auf doppelt indirekte Blöcke enthält). Das Flags-Feld enthält einige ext2-spezifische Flags, die nicht durch chmod etc. beeinflusst werden können. Diese Flags können mit dem Programm lsattr gelistet werden und mit chattr geändert werden. Diese Flags erlauben einer Datei besonderes Verhalten, welches über die POSIX-Dateiflags nicht darstellbar ist: Es gibt Flags für sicheres Löschen, Unlöschbarkeit, Kompression, synchrone Updates, Schreibschutz, indizierte Verzeichnisse, Journaling und einiges mehr. Nicht alle Flags werden derzeit jedoch vom ext2-treiber im Kernel umgesetzt. Verzeichnisse und (Hard-)Links Ein Verzeichnis ist ein Dateisystemobjekt und hat wie eine normale Datei einen Inode. Prinzipiell ist es eine spezielle Datei, die jeden Dateinamen im Verzeichnis mit einer Inode-Nummer verknüpft. Neuere Versionen des Dateisystems legen auch den Typ des Objektes (Datei, Verzeichnis, Symlink, Gerät, FIFO, Socket) mit ab, um zu vermeiden, dass der Inode selbst auf diese Information geprüft werden muss (um dies nutzen zu können, ist eine neuere Version der glibc erforderlich). Einen im Verzeichnis eingetragenen Dateinamen bezeichnet man auch als Link oder als Hard-Link, wenn die Abgrenzung gegenüber einem Symlink betont werden soll. Dahinter steckt eine N zu 1 -Beziehung zwischen Links und Dateien. Die Datei, die aus den Nutzdaten und dem Inode besteht, wird erst über einen Dateipfad, also einen Verzeichniseintrag nutzbar. Da zu einer Datei beliebig viele Verzeichniseinträge angelegt werden können, ist es sinnvoll, diese nicht mit der Datei zu identifizieren, sondern als Verweise auf die Datei zu begreifen. Mehrere Links zu einer Datei können im selben Verzeichnis stehen. Im Inode der Datei wird über die Anzahl der Links Buch geführt. Nach dem Löschen des letzten Links einer Datei, wird die Datei selbst, d.h. der Inode und die Nutzdatenblöcke freigegeben. Eine Besonderheit sind die Links von Verzeichnisdateien. Bei Erzeugen einer neuen Verzeichnisdatei werden gleich zwei Links dazu eingerichtet: Einer im übergeordneten Verzeichnis mit dem gewählten Verzeichnisnamen, einer mit dem Namen. im neuen Verzeichnis selbst. Unterverzeichnisse haben jeweils noch einen Link namens.. auf die übergeordnete Verzeichnisdatei. Für das Wurzelverzeichnis eines Dateisystems sind die beiden Links. und.. identisch.

25 Dateisystem Ein Dateisystem verbirgt die Eigenschaften der physikalischen Datenträger (Plattenspeicher, CD, evt. Bandlaufwerke) weitestgehend vor dem Amwendungsprogrammierer. Unix, NT Dateien sind strukturlose Zeichenketten, welche über Namen identifiziert werden. Hierfür dienen Dateiverzeichnisse, die selbst wie Dateien aussehen und behandelt werden können. Dateien werden sequentiell gelesen. Ein Direktzugriff wird mit Hilfe von Funktionen programmiert, die gezielt auf ein bestimmtes Zeichen in der Datei vor- oder zurücksetzen. z/os und OS/390 z/os verwendet gleichzeitig mehrere Dateisysteme. Das Dateisystem (Filesystem) wird durch die Formattierung eines physikalischen Datenträgers definiert. Bei der Formattierung der Festplatte wird die Struktur der Datei festgelegt. Es gibt unterschiedliche Formattierungen für Dateien mit direktem Zugriff (DAM), sequentiellen Zugriff (SAM) oder indexsequentiellen Zugriff (VSAM). Dateizugriffe benutzen an Stelle eines Dateiverzeichnisse Kontrollblöcke, welche die Datenbasis für unterschiedliche Betriebssystemfunktionen bilden. es 0116 ww6 wgs 04-99

26 Data sets and files in z/os and OS/390 Dateien werden in UNIX und z/os unterschiedlich dargestellt. In UNIX heissen Dateien Files, in z/os Data Sets. Jede File und jeder Data Set hat einen eindeutigen Namen. Während in UNIX Dateinamen bis zu 1024 Zeichen lang sein können, sind zseries Dateinamen maximal 44 Zeichen lang. z/os and OS/390 verwenden: Traditional MVS Data sets und Unix files. Data Sets Access Methods z/os data sets Record-oriented (F(B), V(B), U) Several general methods VSAM (ESDS,KSDS,RRDS,LDS) Non-VSAM (SAM, PDS-E) Data set name (max. 44 chars.) UPPER CASE names Location/attr. stored in catalog Files UNIX System Services HFS files Byte-oriented Hierarchical file structure directory/subdir/filename Path info max char. File name max. 256 char. Mixed case, case sensitive names Stored in z/os container data sets

27 Personalrecord Personalrecord Personalrecord Heinz Bauer Fritz Meier Franz Schulze Beispiel einer Personaldatendatei

28 Dateianfang ////////////////////////////////////// xxxxxxxxxxxxxxxxx Offset Länge Unix Datei Zugriff Dateien sind in UNIX Dateien strukturlose Zeichenketten (Byte Streams). Deshalb muss ein Unix Anwendungsprogramm den Offset zu den Daten und die Länge definieren, auf die zugegriffen werden soll. Da im UNIX Dateien Byte Streams sind, muss eine Anwendung den Offset zu den Daten und die Länge definieren, auf die zugegriffen werden soll. Bei dem Recordorientierten Zugriff unter S/390 definiert die Anwendung die Nummer des Records, auf den zugegriffen werden soll. Standard-Zugriffsmethoden für die Ein- und Ausgabe sind in das UNIX-System eingebaut und werden von der UNIX- Programmiersprache C/C++ unterstützt. Einige Anwendungen verwenden außerdem noch direkte (raw) Zugriffe auf Dateien. Dies wird in erster Linie von Datenbankanwendungen verwendet.

29 z/os Datei Zugriff Unter z/os und OS/390 existieren spezielle Programme (Access Methods), die den Zugriff auf Data Sets ermöglichen. Weiterhin kann die Kommandosprache der Kanäle direkt aus der Anwendung heraus benutzt werden. Dieser Low-Level- Zugriff wird als Execute Channel Programm (EXCP) bezeichnet. Dies ist das dem Unix direkt (raw) Zugriff entsprechende Verfahren, wird heute aber nur noch von wenigen Anwendungen direkt ausgenutzt. Zugriffsmethoden unter Z/OS erlauben direkten, sequentiellen und indizierten Zugriff auf Data Sets.

30

31

32

33

34 Hierarchical File System unter z/os Unix System Services Mit der Einführung von Unix System Services unter Z/OS wurde das Hierarchical File System (HFS) als UNIX File System eingeführt. Hierarchical File Systems werden in HFS Data Sets untergebracht. Jeder HFS Data Set kann genau ein File System enthalten, wobei ein Data Set über mehrere Platten gehen kann. Intern ist der Data Set in 4KB-große Blöcke organisiert, die genau der Grösse einer Seite im z/os entsprechen. Diese Blöcke enthalten entweder Directory- oder Daten- Informationen. Der Speicherbereich in einem HFS Data Set wird formatiert, wenn er benötigt wird. Freier Speicher kann jederzeit wieder verwendet werden. Die referenzierten Seiten eines HFS Data Set werden im Speicher zwischengepuffert. Geänderte Seiten werden zu bestimmten Zeitpunkten, den Synchronisationsintervallen (Sync Points), auf die Platte zurückgeschrieben.

35 z/os UNIX file systems Think of a UNIX file system as a container that holds part of the entire UNIX directory tree. Unlike a traditional z/os library, a UNIX file system is hierarchical and byte-oriented. To find a file in a UNIX file system, you search one or more directories (see Figure 5-5). There is no concept of a z/os catalog that points directly to a file. z/os UNIX System Services (z/os UNIX) allows z/os users to create UNIX file systems and file system directory trees on z/os, and to access UNIX files on z/os and other systems. In z/os, a UNIX file system is mounted over an empty directory by the system programmer (or a user with mount authority). You can use the following file system types with z/os UNIX: zseries File System (zfs), which is a file system that stores files in VSAM linear data sets. Hierarchical file system (HFS), a mountable file system, which is being phased out by zfs. z/os Network File System (z/os NFS), which allows a z/os system to access a remote UNIX (z/os or non-z/os) file system over TCP/IP, as if it were part of the local z/os directory tree. Temporary file system (TFS), which is a temporary, inmemory physical file system that supports in-storage mountable file systems. As with other UNIX file systems, a path name identifies a file and consists of directory names and a file name. A fully qualified file name, which consists of the name of each directory in the path to a file plus the file name itself, can be up to 1023 bytes long.

36 The path name is constructed of individual directory names and a file name separated by the forward-slash character, for example: /dir1/dir2/dir3/myfile Like UNIX, z/os UNIX is case-sensitive for file and directory names. For example, in the same directory, the file MYFILE is a different file than MyFile. The files in a hierarchical file system are sequential files, and are accessed as byte streams. A record concept does not exist with these files other than the structure defined by an application. The zfs data set that contains the UNIX file system is a z/os data set type (a VSAM linear data set). zfs data sets and z/os data sets can reside on the same DASD volume. z/os provides commands for managing zfs space utilization. The integration of the zfs file system with existing z/os file system management services provides automated file system management capabilities that might not be available on other UNIX platforms. This integration allows file owners to spend less time on tasks such as backup and restore of entire file systems.

37 z/os data sets versus file system files Many elements of UNIX have analogs in the z/os operating system. Consider, for example, that the organization of a user catalog is analogous to a user directory (/u/ibmuser) in the file system. In z/os, the user prefix assigned to z/os data sets points to a user catalog. Typically, one user owns all the data sets whose names begin with his user prefix. For example, the data sets belonging to the TSO/E user ID IBMUSER all begin with the high-level qualifier (prefix) IBMUSER. There could be different data sets named IBMUSER.C, IBMUSER.C.OTHER and IBMUSER.TEST. In the UNIX file system, ibmuser would have a user directory named /u/ibmuser. Under that directory there could be a subdirectory named /u/ibmuser/c, and /u/ibmuser/c/pgma would point to the file pgma Of the various types of z/os data sets, a partitioned data set (PDS) is most like a user directory in the file system. In a partitioned data set such as IBMUSER.C, you could have members (files) PGMA, PGMB, and so on. For example, you might have IBMUSER.C(PGMA) and IBMUSER.C(PGMB). Along the same lines, a subdirectory such as /u/ibmuser/c can hold many files, such as pgma, pgmb, and so on.

38