|
1 Introduction 2 Ground Rules Building a File System 3 File Systems 4 File Content Data Structure 5 Allocation Cluster Manager 6 Exceptions and Emancipation 7 Base Classes, Testing, and More 8 File Meta Data 9 Native File Class 10 Our File System 11 Allocation Table 12 File System Support Code 13 Initializing the File System 14 Contiguous Files 15 Rebuilding the File System 16 Native File System Support Methods 17 Lookups, Wildcards, and Unicode, Oh My 18 Finishing the File System Class The Init Program 19 Hardware Abstraction and UOS Architecture 20 Init Command Mode 21 Using Our File System 22 Hardware and Device Lists 23 Fun with Stores: Partitions 24 Fun with Stores: RAID 25 Fun with Stores: RAM Disks 26 Init wrap-up The Executive 27 Overview of The Executive 28 Starting the Kernel 29 The Kernel 30 Making a Store Bootable 31 The MMC 32 The HMC 33 Loading the components 34 Using the File Processor 35 Symbols and the SSC 36 The File Processor and Device Management 37 The File Processor and File System Management 38 Finishing Executive Startup Users and Security 39 Introduction to Users and Security 40 More Fun With Stores: File Heaps 41 File Heaps, part 2 42 SysUAF 43 TUser 44 SysUAF API Terminal I/O 45 Shells and UCL 46 UOS API, the Application Side 47 UOS API, the Executive Side 48 I/O Devices 49 Streams 50 Terminal Output Filters 51 The TTerminal Class 52 Handles 53 Putting it All Together 54 Getting Terminal Input 55 QIO 56 Cooking Terminal Input 57 Putting it all together, part 2 58 Quotas and I/O UCL 59 UCL Basics 60 Symbol Substitution 61 Command execution 62 Command execution, part 2 63 Command Abbreviation 64 ASTs 65 Expressions, Part 1 66 Expressions, Part 2: Support code 67 Expressions, part 3: Parsing 68 SYS_GETJPIW and SYS_TRNLNM 69 Expressions, part 4: Evaluation UCL Lexical Functions 70 PROCESS_SCAN 71 PROCESS_SCAN, Part 2 72 TProcess updates 73 Unicode revisted 74 Lexical functions: F$CONTEXT 75 Lexical functions: F$PID 76 Lexical Functions: F$CUNITS 77 Lexical Functions: F$CVSI and F$CVUI 78 UOS Date and Time Formatting 79 Lexical Functions: F$CVTIME 80 LIB_CVTIME 81 Date/Time Contexts 82 SYS_GETTIM, LIB_Get_Timestamp, SYS_ASCTIM, and LIB_SYS_ASCTIM 83 Lexical Functions: F$DELTA_TIME 84 Lexical functions: F$DEVICE 85 SYS_DEVICE_SCAN 86 Lexical functions: F$DIRECTORY 87 Lexical functions: F$EDIT and F$ELEMENT 88 Lexical functions: F$ENVIRONMENT 89 SYS_GETUAI 90 Lexical functions: F$EXTRACT and F$IDENTIFIER 91 LIB_FAO and LIB_FAOL 92 LIB_FAO and LIB_FAOL, part 2 93 Lexical functions: F$FAO 94 File Processing Structures 95 Lexical functions: F$FILE_ATTRIBUTES 96 SYS_DISPLAY 97 Lexical functions: F$GETDVI 98 Parse_GetDVI 99 GetDVI 100 GetDVI, part 2 101 GetDVI, part 3 102 Lexical functions: F$GETJPI 103 GETJPI 104 Lexical functions: F$GETSYI 105 GETSYI 106 Lexical functions: F$INTEGER, F$LENGTH, F$LOCATE, and F$MATCH_WILD 107 Lexical function: F$PARSE 108 FILESCAN 109 SYS_PARSE 110 Lexical Functions: F$MODE, F$PRIVILEGE, and F$PROCESS 111 File Lookup Service 112 Lexical Functions: F$SEARCH 113 SYS_SEARCH 114 F$SETPRV and SYS_SETPRV 115 Lexical Functions: F$STRING, F$TIME, and F$TYPE 116 More on symbols 117 Lexical Functions: F$TRNLNM 118 SYS_TRNLNM, Part 2 119 Lexical functions: F$UNIQUE, F$USER, and F$VERIFY 120 Lexical functions: F$MESSAGE 121 TUOS_File_Wrapper 122 OPEN, CLOSE, and READ system services UCL Commands 123 WRITE 124 Symbol assignment 125 The @ command 126 @ and EXIT 127 CRELNT system service 128 DELLNT system service 129 IF...THEN...ELSE 130 Comments, labels, and GOTO 131 GOSUB and RETURN 132 CALL, SUBROUTINE, and ENDSUBROUTINE 133 ON, SET {NO}ON, and error handling 134 INQUIRE 135 SYS_WRITE Service 136 OPEN 137 CLOSE 138 DELLNM system service 139 READ 140 Command Recall 141 RECALL 142 RUN 143 LIB_RUN 144 The Data Stream Interface 145 Preparing for execution 146 EOJ and LOGOUT 147 SYS_DELPROC and LIB_GET_FOREIGN CUSPs and utilities 148 The I/O Queue 149 Timers 150 Logging in, part one 151 Logging in, part 2 152 System configuration 153 SET NODE utility 154 UUI 155 SETTERM utility 156 SETTERM utility, part 2 157 SETTERM utility, part 3 158 AUTHORIZE utility 159 AUTHORIZE utility, UI 160 AUTHORIZE utility, Access Restrictions 161 AUTHORIZE utility, Part 4 162 AUTHORIZE utility, Reporting 163 AUTHORIZE utility, Part 6 164 Authentication 165 Hashlib 166 Authenticate, Part 7 167 Logging in, part 3 168 DAY_OF_WEEK, CVT_FROM_INTERNAL_TIME, and SPAWN 169 DAY_OF_WEEK and CVT_FROM_INTERNAL_TIME 170 LIB_SPAWN 171 CREPRC 172 CREPRC, Part 2 173 COPY 174 COPY, part 2 175 COPY, part 3 176 COPY, part 4 177 LIB_Get_Default_File_Protection and LIB_Substitute_Wildcards 178 CREATESTREAM, STREAMNAME, and Set_Contiguous 179 Help Files 180 LBR Services 181 LBR Services, Part 2 182 LIBRARY utility 183 LIBRARY utility, Part 2 184 FS Services 185 FS Services, Part 2 186 Implementing Help 187 HELP 188 HELP, Part 2 189 DMG_Get_Key and LIB_Put_Formatted_Output 190 LIBRARY utility, Part 3 191 Shutting Down UOS 192 SHUTDOWN 193 WAIT 194 SETIMR 195 WAITFR and Scheduling 196 REPLY, OPCOM, and Mailboxes 197 REPLY utility 198 Mailboxes 199 BRKTHRU 200 OPCOM 201 Mailbox Services 202 Mailboxes, Part 2 203 DEFINE 204 CRELNM 205 DISABLE 206 STOP 207 OPCCRASH and SHUTDOWN 208 APPEND Glossary/Index Downloads |
REPLY, OPCOM, and Mailboxes The next utility used in the shutdown script is REPLY. But before we can discuss it, we have to cover the concept of operators. A system operator is a person who does things that must be done manually, such as loading paper or toner into a printer when it runs out, or loading/unloading removable media (such as magnetic tapes or DVD-R discs). In high-security facilities, the computers and some of their peripherals (such as printers and tape drives) are in a room that has restricted access - only system administrators and operators can enter. When a user needs to, say, write data to a tape, he has to request that an operator place a new tape on one of the tape drives. Once this is done, the operator has to reply to the user to inform them that the tape is now mounted, and on which drive it was physically mounted. As things became more automated, requests for mounting tapes came from certain programs (such as periodic file backups) rather than actual people. But the operator still had to let the program know when the tape was mounted. Even on a personal computer, a file backup program has to request that the user load a new DVD into the drive so it can write to it. Thus, the user acts as a system operator. Things are simpler, of course, since usually only one backup program is run at a time and the program can just wait until the system detects that the media has been loaded into the drive. It also helps that there is usually only one of these drives rather than a bank of tape drives with hundreds of potential users wanting to use them at the same time. But, in any case, something manual has to be done at the (ultimate) request of a user. Operators also manage queues, which is a discussion for the future. The REPLY utility is a multi-purpose program that allows operators to respond to media requests and perform other tasks related to system shutdown. For now, we will only address those REPLY operations that apply to the shutdown script. We will cover the rest of the features in the future. The OPER privilege is required to perform the activities of a system operator. Certain terminals can be marked as having "operator status". Such terminals receive the aforementioned media requests. The REPLY utility is also used to manage operator terminals. First the documentation:
REPLY
Format REPLY {message}
Parameter message
Description Users with OPER privilege can use REPLY to perform the following:
Qualifiers /ALL
Required Privileges OPER is required if messages are sent to a different terminal.
Examples
OPCOM REPLY allows interactive control of OPCOM, but logicals can be used to define startup settings. The logicals are:
OPC$OPER1 through OPC$OPER12 can be defined as one or more attributes each, which can then be used as "abbreviations" for those attributes. For instance, defining OPC$OPER1 to "NETWORK,TAPES" would allow you to use the command REPLY/ENABLE=OPER1 which would be the same as using: REPLY/ENABLE=NETWORK,TAPES Thus, you can use those logicals to define system operators with different areas of responsibility. OPCOM creates a new log file each time it starts (unless the logfile has been disabled). The previous file is renamed to an older version. Note that OPCOM may buffer up messages, so that the log file may not contain the last messages received. Also, if the system crashes or the OPCOM process is killed, some messages may be lost. Additionally, if the device on which the log file is located runs out of space, messages are obviously not written to the log. When a terminal is defined as an operator, the logical OPAn is defined to point to that terminal, where n is 0 through 12, inclusive. The default (main) operator terminal is associated with OPA0:. By default, the system console is associated with OPA0:. Note: apparently OPA1: through OPA12: are used in inconsistent ways in VMS depending upon the hardware platform.
Mailboxes OPCOM creates a permanent mailbox which REPLY sends messages to. OPCOM reads those messages and processes them as appropriate. A mailbox is analogous to a pipe in other operating systems. It is a virtual stream device. Data written to the mailbox is written in discrete packets (one per I/O write). The mailbox can then be read, one message at a time. In implementation, messages for a mailbox are stored in a queue. A write appends the message to the end of the queue. A read removes the message from the head of the queue. Mailboxes can be temporary or permanent. A temporary mailbox is charged against the quotas of the creating process, while a permanent mailbox is not charged since it is used by many processes. However, to avoid abuse of system resources, the TMPMBX privilege is required to create a temporary mailbox and the PRMMBX privilege is required to create a permanent mailbox. By default, all accounts are given the TMPMBX privilege. Temporary mailboxes are automatically deleted when the last I/O channel assigned to them is closed. Permanent mailboxes exist until they are specifically deleted or the system shuts down. Each mailbox has a limit as to how many total bytes can exist in the messages in its queues. Attempting to write to a full mailbox (meaning that the size of the write operation would cause the mailbox queue to exceed its limit) causes the writing process to block until enough space frees up in the mailbox. Reading an empty mailbox results in the reading process blocking until a new message is added to the mailbox. To avoid blocking on reads, a process can query a mailbox to see if there are any messages in it. Processes can also block on message writes until that message has been read, thus allowing some form of synchronization (they can opt to asynchronously write a message and continue). Once a message is read, it is deleted from the queue and the available space in the mailbox increases by the size of that message. Finally, mailboxes have owners and protections, which allows access to them to be restricted just like files and other devices. The device name for a permanent mailbox is "MAILA" plus a unit number that is assigned by UOS when the mailbox is created. For example: "MAILA1:". For temporary mailboxes, it is "MAILB". Unit numbers may be reused during a given timeshare session. It should also be noted that although mailboxes are virtual devices rather than physical, and reside entirely within memory, they use paged memory and their messages may or may not be in resident memory pages at the time they are read. Thus, reading them is not guaranteed to be instantaneous. However, it should also be noted that on systems without memory paging, the mailboxes do reside in permanent memory (that is, non-swappable, non-paged) and so the use, and size, of mailboxes must be carefully controlled so as not to run out of that memory space on those systems. Since mailboxes are used for interprocess communication, they cannot be swapped out along with a process or else another process cannot access them. In the next article, we will examine the code for the REPLY utility. |