11/19/85 Card Input Since this info segment is long, you may want to print a hard copy of it. (See also card_access_control.gi.info.) There are two modes of Multics punched card input--bulk data input and remote job entry (RJE). Bulk data input is used to copy data from punched cards into the Multics storage system. RJE allows a registered user to submit an absentee job from a card deck. Card input formats: Facilities are provided to read punched card decks into Multics files. There are several conventions for interpreting the punched codes used in your card deck. The central site reader is capable of reading any punch codes, including binary data. Remote terminal card readers normally cannot read binary code. There are four types of card formats that you can input to Multics: Multics card codes (mcc), remote Multics card code (rmcc), 7punch, and raw. mcc defined in "Punched Card Codes" in Appendix C of the Multics Programmer's Reference Manual (AG91). It consists of a superset of the EBCDIC card punch codes and can be produced by 029 key punches. Each column is interpreted as one character. The 12-bit card codes are converted to 9-bit ASCII codes. rmcc does not concern itself with punch codes, but rather with the characters that are transmitted. Selection of punch code is determined on the basis of hardware configuration. Conversion and translation is specified by the -terminal_type control argument to the remote_input_ I/O module (see the Subroutines manual). Unlike mcc format, punch codes are not specified because various remote terminals use different codes for the same characters, and it is the character, not the punch code, that is transmitted. 7punch are binary representations of existing files with checksums and sequence numbers added, and the data portions of the cards are read in exactly as they were punched out. The format of a 7punch deck is described in Appendix C of AG91. raw are read into Multics files without any conversion and without regard to format; that is, the 960 bits on each card are read into the file in column order and without padding. You can then perform any desired conversion. The flip cards prepared when a deck is punched and other sorts of labeling cards from other systems are not read correctly and should be removed from decks. Control cards: Control cards are used to tell the card input process how to read your data and what to do with it. Each control card consists of a key (e.g., ++FORMAT) and possibly some data fields. The control card key must start in column 1 and cannot contain any spaces. Data fields are separated from the key and from each other by one or more spaces. All letters punched on the control cards are mapped to lowercase except those immediately following an escape character (backslash or cent sign.) For example, \SMITH.\SYS\MAINT is mapped into Smith.SysMaint. At the central site, you submit card decks to operations personnel for processing. At remote sites that have a card reader terminal, you may have to physically place the card deck in the reader, in which case be sure to include some additional control cards that must be placed before and after your card deck. For more information on these additional control cards (++EOF and ++UID, for example) see ... Bulk data input: Bulk data input is the mode of card input used to read a punched card deck and write its contents into a card image segment in the Multics storage system. You are able to read the card image segment from your normal Multics process (interactive or absentee). For security reasons, card image segments are created in system pool storage rather than in your directory. Once the data has been read, you can copy the card image segment into your directory using the copy_cards command (see the Commands manual). You must make the copy within a reasonable time, as these segments are periodically deleted from the system pool. The user identified on the ++DATA card is notified by mail when his card deck has been successfully read. Here is a complete card deck for bulk data input. ++DATA DECK_NAME PERSON_ID PROJECT_ID ++PASSWORD PASSWORD ++CONTROL OVERWRITE ++AIM ACCESS CLASS OF DATA CARDS ++FORMAT PUNCH_FORMAT MODES ++INPUT . . (user data cards) The only control cards required are the first, which is an identifier card; the second, which is a password card; and the last, which is the end of control input. For an explanation of all the control cards, see "Bulk data control cards" below. You should submit a complete card deck to operations. The deck must follow the format specified in "Card input formats" above. Normally you can omit the ++AIM cards when the access_class is system_low, but not when it is greater than system_low. Bulk data control cards: In the following discussion of control cards, parameters you must enter are shown as all uppercase characters. You can keypunch either uppercase or lowercase characters when preparing card decks; internal conversion of uppercase to lowercase is forced by the system. You can use the escape convention if you wish to input uppercase characters. The control card format is: 1. it begins with ++ in columns 1 and 2 2. a keyword begins in column 3 3. balance of the card after the keyword is free form 4. continuation cards are not permitted; each control card must be contained within 80 columns 5. cards are read with lowercase, nocontin, noaddnl modes (see "Card input conversion modes" below). ++DATA (Required) tells the card input process that the deck is to be read as bulk data input. It must be the first control card of the deck. Specify all three fields of this control card in the order shown. Usage ++DATA where: 1. DECK_NAME is the name used to separate each deck and to identify the card image segment in system pool storage. It should be unique among the user's decks recently submitted. In case of name duplications, the card-reading process appends a numeric component to the end of the name supplied and creates a duplicate card image segment for DECK_NAME unless you give the OVERWRITE control option on the ++CONTROL card. 2. PERSON_ID is the registered name of the submitter. Only this person is able to read the card image segment from the pool. 3. PROJECT_ID is the registered project of the submitter. Notes: Multics person and project names normally begin with uppercase. Such names must have an escape character punched before each uppercase as described under "Control cards" above. ++PASSWORD (Required) used to specify your card input password. It must immediately follow the ++DATA card. Usage ++PASSWORD {-control_arg} where: 1. xxxxxxxx is the card input password registered for you. This password is normally different from your login password. It is maintained by the system administrator. The printing mechanism on the keypunch should be usually turned off when creating this card. Users who have r access to >sc1>rcp>card_input_password.acs don't need to be registered for card input or type a card input password to have input accepted. In this case, xxxxxxxx should be blanks. 2. -control_arg is -change_password STR (-cpw STR) to change the password, where STR is a new password of up to eight characters. ++CONTROL (Optional) used to control the way the card reading software operates. If you specify the control string OVERWRITE, then if the DECK_NAME specified on the ++DATA card already exists in the system card pool, the segment is truncated before input is started. This feature is useful when communication line error or operator error requires multiple inputs of the same card deck. (See also ++CONTROL card for remote job entry.) Usage ++CONTROL OVERWRITE ++AIM (Optional) used to specify the AIM access class of the data on the cards in your deck. If you don't specify it, the access class system_low is assumed. Usage ++AIM where ACCESS CLASS is the access class of the data. The access class field can contain embedded spaces and commas. If the complete access class does not fit onto a single card, you can use additional ++AIM cards. The access class fields of all the ++AIM cards must define a valid access class when concatenated in deck order. Trailing blanks are stripped off before concatenation is done. Concatenation to form a valid access class is performed on successive access class strings, separated by a blank. The access authorization of the process that runs the remote device must be the same as the access class given in ++AIM for the deck to be accepted by the system. ++FORMAT (Optional) used to define the punch code conversion used to interpret the data in your card deck (not control cards). If you omit it, the MCC punch code conversion is assumed for local card readers and RMCC mode for remote card readers. Usage +FORMAT where: 1. PUNCH_FORMAT (Required) is the punch code conversion to use in reading the card deck. It must be either MCC, RMCC, VIIPUNCH, or RAW. (Not all card readers support each of these conversion modes.) Note: Most remote card readers are able to read in the RMCC conversion mode only. 2. MODES (Optional) it can be any of the following. It is meaningful only for MCC and RMCC formats. (See "Card input conversion modes" below.) TRIM (default) NOTRIM LOWERCASE NOCONVERT (default) ADDNL (default) NOADDNL CONTIN NOCONTIN (default) ++INPUT (Required) marks the end of the control cards. The next card is the first card of your data to be placed in the card image segment. Usage ++INPUT User data cards: All user data cards following the ++INPUT card are copied into the card image segment. The data can consist of any card punch combinations acceptable for the specified punch code conversion mode, except for an end-of-file marker, which is defined as a card with "++EOF" in columns 1 through 5 and blanks in columns 6 through 80. This marker defines the end of your data. The ++EOF card is supplied by the operator. If you give it, the card deck is not read in successfully and the card deck aborts. Remote job entry: RJE on Multics is a mechanism that allows a registered user to submit an absentee job via a card deck. The card deck must contain standard Multics commands exactly as an interactive user would put into an absentee input (absin) segment. Your card deck is copied into an absentee input segment created in the normal system pool storage used for bulk data input. When your deck has been successfully read, an absentee request is submitted on your behalf. A special header is added to the absentee input segment so that a dprint request of the absentee output segment is automatically generated using the request type associated with the remote terminal or the request type of the local printer, depending on the input device. The header consists of the following lines: &command_line off rje_args$set prt_rqt X rje_args$set pun_rqt Y rje_args$set station Z set_epilogue_command "eor -dl -rqt [rje_args prt_rqt] [user absout]" where: X is the printer request type of the submitting station. Y is the punch request type of the submitting station. Z is the station ID of the submitting station. If the remote terminal does not have a printer request type, the dprint of the absentee output segment is issued for the central site printer. The absentee process is created as Person_id.Project_id.p at the AIM authorization specified on any ++AIM control cards. The absout file is put in your home directory unless otherwise specified on the ++RJECONTROL. The user identified on the ++RJE card is notified by mail when his absentee input card deck has been read and his RJE job has been successfully queued. Here is a complete card deck for RJE-- ++RJE DECK_NAME PERSON_ID PROJECT_ID ++PASSWORD PASSWORD ++AIM ACCESS CLASS OF ABSENTEE PROCESS ++RJECONTROL CONTROL ARGS TO THE EAR COMMAND ++RJEARGS ARGUMENTS FOR THE ABSENTEE PROCESS ++EPILOGUE COMMAND ++FORMAT PUNCH_FORMAT MODES ++INPUT . . (user absentee file) The only control cards required are the first, which is an identifier card; the second, which is a password card; and the last, which is the end of control input. For an explanation of all the control cards, see "RJE control cards" below. You should submit a complete card deck to operations. The deck must follow the format specified in "Card input formats" above. Normally you can omit the ++AIM cards when the access_class is system_low, but not when it is greater than system_low. Remote job entry control cards: The following is a list of RJE control cards. The format is the same as for bulk data cards discussed in "Bulk data control cards" above. ++RJE (Required) tells the card input process that the deck is to be read as a set of RJE absentee commands and submitted as an absentee job for Person_id.Project_id. It must be the first card of the deck. Specify all three fields of this control card in the order shown. Usage ++RJE where: 1. DECK_NAME is the name of your absentee input segment. If it does not end in .absin, the suffix is supplied. The name should be unique among all RJE decks you have recently submitted. In case of name duplications, the card reading process adds a numeric component just preceding .absin and creates a duplicate absentee input segment for DECK_NAME. 2. PERSON_ID is the registered name of the submitter. This is the person name under which the absentee job is run. 3. PROJECT_ID is the registered project of the submitter. This is the project name under which the absentee job is run. Notes: Multics person and project names normally begin with uppercase letters; therefore these names must have an escape character punched before each uppercase letter as described in "Control cards" above. ++PASSWORD (Required) used to specify your card input password. It must immediately follow the ++DATA card. Usage ++PASSWORD {-control_arg} where: 1. xxxxxxxx is the card input password registered for you. This password is normally different from your login password. It is maintained by the system administrator. The printing mechanism on the keypunch should be usually turned off when creating this card. A blank password is not allowed. 2. -control_arg is -change_password STR (-cpw STR) to change the password, where STR is a new password of up to eight characters. ++AIM (Optional) same as for bulk data input described above. ++RJECONTROL (Optional) used to specify control arguments that you can give to the enter_abs_request command. You can use multiple ++RJECONTROL cards if all the control arguments do not fit on a single card. Usage ++RJECONTROL ... where ARGi is any control argument acceptable to enter_abs_request, except for -argument (-ag). If you used multiple ++RJECONTROL cards, the order of the control arguments is the concatenation of each ARGi string (separated by a space) in deck order. Don't split a control argument across cards; put leading hyphens (where appropriate). ++RJEARGS (Optional) used to pass arguments to the absentee process, as would normally be done by using -argument with enter_abs_request. If there are more arguments than can fit on a single card, you can use additional ++RJEARGS cards. Don't split an argument across cards. Usage ++RJEARGS ... where ARGi is the ith argument to be passed to the absentee process (used in substitutions of the form &i). If you use multiple ++RJEARGS control cards, the order of the arguments is the concatenation of each ARGi string (separated by a space) in deck order. ++EPILOGUE (Optional) overrides the default command string eor -dl -rqt [rje_args prt_rqt] [user absout] (which is executed at logout time) with the one supplied. This allows you to control what action is taken just prior to logout of your absentee process. Usage ++EPILOGUE where COMMAND_LINE is any command acceptable in an absentee process. If you use multiple ++EPILOGUE cards, a single command line is generated by concatenating the values contained on the ++EPILOGUE cards separated by spaces. ++ABSIN (Optional) allows you to use an already-online absentee input segment instead of including one in your deck. If any user-supplied cards follow the ++INPUT card, the input is aborted. Usage ++ABSIN {SYSTEM} where PATHNAME is the absolute pathname of the absentee input segment. If you supply SYSTEM, then pathname is assumed to be the entryname of the absentee input segment in >system_library_tools. ++CONTROL (Optional) used to control the way the card-reading software operates. If you supply the control string CANCEL, then if the DECK_NAME specified on the ++RJE card was submitted as an absentee job, the old job will be canceled. (See also ++CONTROL card for bulk data input.) Usage ++CONTROL CANCEL ++FORMAT (Optional) same as for bulk data input described above. ++INPUT (Required) same as for bulk data input described above. User absentee cards: All cards following the ++INPUT card for remote job entry are copied into the absentee input segment as commands. The command lines are translated according to the modes specified on the ++FORMAT card, if present, or by the default modes, which are TRIM, LOWERCASE, and ADDNL (see "Card input conversion modes" below). You can give any command lines except for an end-of-file marker, which is defined as a card with "++EOF" in columns 1 through 5 and spaces in columns 6 through 80. The end-of-file marker defines the end of your data. (See "Card input formats" above.) Card input conversion modes: Card input is reformatted according to the conversion modes specified on the ++FORMAT control card. In all discussions it is assumed that prior to translation a card consists of 80 characters with trailing blanks as required. The action of each translation mode is as follows: TRIM strips off trailing blanks. (Default) LOWERCASE converts all uppercase characters to their lowercase equivalent unless preceded by the escape character (\). ADDNL appends a newline character after the last character of a card. This operation takes place after trimming if you requested trimming. (Default) CONTIN if the last character on the card is \, then if you give the ADDNL mode, a newline character is not added. This operation takes place after trimming if you requested it. These modes cause the above actions not to occur-- NOTRIM the trailing blanks of the card image are not removed. NOCONVERT no uppercase-to-lowercase conversion is performed. NOADDNL a newline character is not appended after the last character. NOCONTIN no action is taken if the last character on the card is \. If you are reading a deck, using edit-directed I/O, into a PL/I program that expects card images to be fixed-length records, you should use the latter modes. Deck size: Decks being read in mcc or rmcc format may exceed the maximum length of a Multics segment; if they do, the input will automatically be stored in a multisegment file (MSF). Errors: The operator returns a note with the deck if any errors take place during the read. In general, the error should be corrected and the deck resubmitted. ----------------------------------------------------------- Historical Background This edition of the Multics software materials and documentation is provided and donated to Massachusetts Institute of Technology by Group BULL including BULL HN Information Systems Inc. as a contribution to computer science knowledge. This donation is made also to give evidence of the common contributions of Massachusetts Institute of Technology, Bell Laboratories, General Electric, Honeywell Information Systems Inc., Honeywell BULL Inc., Groupe BULL and BULL HN Information Systems Inc. to the development of this operating system. Multics development was initiated by Massachusetts Institute of Technology Project MAC (1963-1970), renamed the MIT Laboratory for Computer Science and Artificial Intelligence in the mid 1970s, under the leadership of Professor Fernando Jose Corbato. Users consider that Multics provided the best software architecture for managing computer hardware properly and for executing programs. Many subsequent operating systems incorporated Multics principles. Multics was distributed in 1975 to 2000 by Group Bull in Europe , and in the U.S. by Bull HN Information Systems Inc., as successor in interest by change in name only to Honeywell Bull Inc. and Honeywell Information Systems Inc. . ----------------------------------------------------------- Permission to use, copy, modify, and distribute these programs and their documentation for any purpose and without fee is hereby granted,provided that the below copyright notice and historical background appear in all copies and that both the copyright notice and historical background and this permission notice appear in supporting documentation, and that the names of MIT, HIS, BULL or BULL HN not be used in advertising or publicity pertaining to distribution of the programs without specific prior written permission. Copyright 1972 by Massachusetts Institute of Technology and Honeywell Information Systems Inc. Copyright 2006 by BULL HN Information Systems Inc. Copyright 2006 by Bull SAS All Rights Reserved