1 11/19/85 Card Input
2
3 Since this info segment is long, you may want to print a hard copy of
4 it. See also card_access_control.gi.info.
5
6 There are two modes of Multics punched card input--bulk data input and
7 remote job entry RJE. Bulk data input is used to copy data from
8 punched cards into the Multics storage system. RJE allows a
9 registered user to submit an absentee job from a card deck.
10
11
12 Card input formats: Facilities are provided to read punched card decks
13 into Multics files. There are several conventions for interpreting
14 the punched codes used in your card deck. The central site reader is
15 capable of reading any punch codes, including binary data. Remote
16 terminal card readers normally cannot read binary code. There are
17 four types of card formats that you can input to Multics: Multics card
18 codes mcc, remote Multics card code rmcc, 7punch, and raw.
19 mcc
20 defined in "Punched Card Codes" in Appendix C of the Multics
21 Programmer's Reference Manual AG91. It consists of a superset of
22 the EBCDIC card punch codes and can be produced by 029 key punches.
23 Each column is interpreted as one character. The 12-bit card codes
24 are converted to 9-bit ASCII codes.
25
26
27 rmcc
28 does not concern itself with punch codes, but rather with the
29 characters that are transmitted. Selection of punch code is
30 determined on the basis of hardware configuration. Conversion and
31 translation is specified by the -terminal_type control argument to
32 the remote_input_ I/O module see the Subroutines manual. Unlike
33 mcc format, punch codes are not specified because various remote
34 terminals use different codes for the same characters, and it is
35 the character, not the punch code, that is transmitted.
36 7punch
37 are binary representations of existing files with checksums and
38 sequence numbers added, and the data portions of the cards are read
39 in exactly as they were punched out. The format of a 7punch deck
40 is described in Appendix C of AG91.
41
42
43 raw
44 are read into Multics files without any conversion and without
45 regard to format; that is, the 960 bits on each card are read into
46 the file in column order and without padding. You can then perform
47 any desired conversion.
48
49 The flip cards prepared when a deck is punched and other sorts of
50 labeling cards from other systems are not read correctly and should be
51 removed from decks.
52
53
54 Control cards: Control cards are used to tell the card input process
55 how to read your data and what to do with it. Each control card
56 consists of a key e.g. ++FORMAT and possibly some data fields. The
57 control card key must start in column 1 and cannot contain any spaces.
58 Data fields are separated from the key and from each other by one or
59 more spaces.
60
61 All letters punched on the control cards are mapped to lowercase
62 except those immediately following an escape character backslash or
63 cent sign. For example, \SMITH.\SYS\MAINT is mapped into
64 Smith.SysMaint.
65
66
67 At the central site, you submit card decks to operations personnel for
68 processing. At remote sites that have a card reader terminal, you may
69 have to physically place the card deck in the reader, in which case
70 be sure to include some additional control cards that must be
71 placed before and after your card deck. For more information on
72 these additional control cards ++EOF and ++UID for example see
73 ...
74
75
76 Bulk data input: Bulk data input is the mode of card input used to
77 read a punched card deck and write its contents into a card image
78 segment in the Multics storage system. You are able to read the card
79 image segment from your normal Multics process interactive or
80 absentee. For security reasons, card image segments are created in
81 system pool storage rather than in your directory. Once the data has
82 been read, you can copy the card image segment into your directory
83 using the copy_cards command see the Commands manual. You must make
84 the copy within a reasonable time, as these segments are periodically
85 deleted from the system pool.
86
87 The user identified on the ++DATA card is notified by mail when his
88 card deck has been successfully read.
89
90
91 Here is a complete card deck for bulk data input.
92 ++DATA DECK_NAME PERSON_ID PROJECT_ID
93 ++PASSWORD PASSWORD
94 ++CONTROL OVERWRITE
95 ++AIM ACCESS CLASS OF DATA CARDS
96 ++FORMAT PUNCH_FORMAT MODES
97 ++INPUT
98 .
99 .
100 user data cards
101
102 The only control cards required are the first, which is an identifier
103 card; the second, which is a password card; and the last, which is the
104 end of control input. For an explanation of all the control cards,
105 see "Bulk data control cards" below.
106
107
108 You should submit a complete card deck to operations. The deck must
109 follow the format specified in "Card input formats" above.
110
111 Normally you can omit the ++AIM cards when the access_class is
112 system_low, but not when it is greater than system_low.
113
114
115 Bulk data control cards: In the following discussion of control cards,
116 parameters you must enter are shown as all uppercase characters. You
117 can keypunch either uppercase or lowercase characters when preparing
118 card decks; internal conversion of uppercase to lowercase is forced by
119 the system. You can use the escape convention if you wish to input
120 uppercase characters. The control card format is:
121 1. it begins with ++ in columns 1 and 2
122 2. a keyword begins in column 3
123 3. balance of the card after the keyword is free form
124 4. continuation cards are not permitted; each control card must be
125 contained within 80 columns
126 5. cards are read with lowercase, nocontin, noaddnl modes see "Card
127 input conversion modes" below.
128
129
130 ++DATA Required
131 tells the card input process that the deck is to be read as bulk data
132 input. It must be the first control card of the deck. Specify all
133 three fields of this control card in the order shown.
134 Usage
135 ++DATA <DECK_NAME> <PERSON_ID> <PROJECT_ID>
136 where:
137 1. DECK_NAME
138 is the name used to separate each deck and to identify the card
139 image segment in system pool storage. It should be unique
140 among the user's decks recently submitted. In case of name
141 duplications, the card-reading process appends a numeric
142 component to the end of the name supplied and creates a
143 duplicate card image segment for DECK_NAME unless you give the
144 OVERWRITE control option on the ++CONTROL card.
145
146
147 2. PERSON_ID
148 is the registered name of the submitter. Only this person is
149 able to read the card image segment from the pool.
150 3. PROJECT_ID
151 is the registered project of the submitter.
152 Notes: Multics person and project names normally begin with
153 uppercase. Such names must have an escape character punched
154 before each uppercase as described under "Control cards" above.
155
156
157 ++PASSWORD Required
158 used to specify your card input password. It must immediately follow
159 the ++DATA card.
160 Usage
161 ++PASSWORD <xxxxxxxx> -control_arg
162 where:
163 1. xxxxxxxx
164 is the card input password registered for you. This password is
165 normally different from your login password. It is maintained by
166 the system administrator. The printing mechanism on the keypunch
167 should be usually turned off when creating this card. Users who
168 have r access to >sc1>rcp>card_input_password.acs don't need to
169 be registered for card input or type a card input password to
170 have input accepted. In this case, xxxxxxxx should be blanks.
171
172
173 2. -control_arg
174 is -change_password STR -cpw STR to change the password, where
175 STR is a new password of up to eight characters.
176
177 ++CONTROL Optional
178 used to control the way the card reading software operates. If you
179 specify the control string OVERWRITE, then if the DECK_NAME specified
180 on the ++DATA card already exists in the system card pool, the segment
181 is truncated before input is started. This feature is useful when
182 communication line error or operator error requires multiple inputs of
183 the same card deck. See also ++CONTROL card for remote job entry.
184 Usage
185 ++CONTROL OVERWRITE
186
187
188 ++AIM Optional
189 used to specify the AIM access class of the data on the cards in your
190 deck. If you don't specify it, the access class system_low is assumed.
191 Usage
192 ++AIM <ACCESS CLASS>
193 where ACCESS CLASS is the access class of the data. The access class
194 field can contain embedded spaces and commas. If the complete access
195 class does not fit onto a single card, you can use additional ++AIM
196 cards. The access class fields of all the ++AIM cards must define a
197 valid access class when concatenated in deck order. Trailing blanks
198 are stripped off before concatenation is done. Concatenation to form
199 a valid access class is performed on successive access class strings,
200 separated by a blank.
201
202
203 The access authorization of the process that runs the remote device
204 must be the same as the access class given in ++AIM for the deck to be
205 accepted by the system.
206
207 ++FORMAT Optional
208 used to define the punch code conversion used to interpret the data in
209 your card deck not control cards. If you omit it, the MCC punch
210 code conversion is assumed for local card readers and RMCC mode for
211 remote card readers.
212
213
214 Usage
215 +FORMAT <PUNCH_FORMAT> <MODES>
216 where:
217 1. PUNCH_FORMAT Required
218 is the punch code conversion to use in reading the card deck.
219 It must be either MCC, RMCC, VIIPUNCH, or RAW. Not all card
220 readers support each of these conversion modes.
221 Note: Most remote card readers are able to read in the RMCC
222 conversion mode only.
223
224
225 2. MODES Optional
226 it can be any of the following. It is meaningful only for MCC
227 and RMCC formats. See "Card input conversion modes" below.
228 TRIM default
229 NOTRIM
230 LOWERCASE
231 NOCONVERT default
232 ADDNL default
233 NOADDNL
234 CONTIN
235 NOCONTIN default
236
237
238 ++INPUT Required
239 marks the end of the control cards. The next card is the first card
240 of your data to be placed in the card image segment.
241 Usage
242 ++INPUT
243
244
245 User data cards: All user data cards following the ++INPUT card are
246 copied into the card image segment. The data can consist of any card
247 punch combinations acceptable for the specified punch code conversion
248 mode, except for an end-of-file marker, which is defined as a card with
249 "++EOF" in columns 1 through 5 and blanks in columns 6 through 80.
250 This marker defines the end of your data. The ++EOF card is supplied
251 by the operator. If you give it, the card deck is not read in
252 successfully and the card deck aborts.
253
254
255 Remote job entry: RJE on Multics is a mechanism that allows a
256 registered user to submit an absentee job via a card deck. The card
257 deck must contain standard Multics commands exactly as an interactive
258 user would put into an absentee input absin segment. Your card deck
259 is copied into an absentee input segment created in the normal system
260 pool storage used for bulk data input. When your deck has been
261 successfully read, an absentee request is submitted on your behalf.
262
263
264 A special header is added to the absentee input segment so that a
265 dprint request of the absentee output segment is automatically
266 generated using the request type associated with the remote terminal
267 or the request type of the local printer, depending on the input
268 device. The header consists of the following lines:
269 &command_line off
270 rje_args$set prt_rqt X
271 rje_args$set pun_rqt Y
272 rje_args$set station Z
273 set_epilogue_command "eor -dl -rqt rje_args prt_rqt user absout"
274 where:
275 X is the printer request type of the submitting station.
276 Y is the punch request type of the submitting station.
277 Z is the station ID of the submitting station.
278
279
280 If the remote terminal does not have a printer request type, the
281 dprint of the absentee output segment is issued for the central site
282 printer.
283
284 The absentee process is created as Person_id.Project_id.p at the AIM
285 authorization specified on any ++AIM control cards. The absout file
286 is put in your home directory unless otherwise specified on the
287 ++RJECONTROL.
288
289 The user identified on the ++RJE card is notified by mail when his
290 absentee input card deck has been read and his RJE job has been
291 successfully queued.
292
293
294 Here is a complete card deck for RJE--
295 ++RJE DECK_NAME PERSON_ID PROJECT_ID
296 ++PASSWORD PASSWORD
297 ++AIM ACCESS CLASS OF ABSENTEE PROCESS
298 ++RJECONTROL CONTROL ARGS TO THE EAR COMMAND
299 ++RJEARGS ARGUMENTS FOR THE ABSENTEE PROCESS
300 ++EPILOGUE COMMAND
301 ++FORMAT PUNCH_FORMAT MODES
302 ++INPUT
303 .
304 .
305 user absentee file
306
307
308 The only control cards required are the first, which is an identifier
309 card; the second, which is a password card; and the last, which is the
310 end of control input. For an explanation of all the control cards,
311 see "RJE control cards" below.
312
313 You should submit a complete card deck to operations. The deck must
314 follow the format specified in "Card input formats" above.
315
316 Normally you can omit the ++AIM cards when the access_class is
317 system_low, but not when it is greater than system_low.
318
319
320 Remote job entry control cards: The following is a list of RJE control
321 cards. The format is the same as for bulk data cards discussed in
322 "Bulk data control cards" above.
323
324 ++RJE Required
325 tells the card input process that the deck is to be read as a set of
326 RJE absentee commands and submitted as an absentee job for
327 Person_id.Project_id. It must be the first card of the deck. Specify
328 all three fields of this control card in the order shown.
329
330
331 Usage
332 ++RJE <DECK_NAME> <PERSON_ID> <PROJECT_ID>
333 where:
334 1. DECK_NAME
335 is the name of your absentee input segment. If it does not end
336 in .absin, the suffix is supplied. The name should be unique
337 among all RJE decks you have recently submitted. In case of name
338 duplications, the card reading process adds a numeric component
339 just preceding .absin and creates a duplicate absentee input
340 segment for DECK_NAME.
341 2. PERSON_ID
342 is the registered name of the submitter. This is the person name
343 under which the absentee job is run.
344
345
346 3. PROJECT_ID
347 is the registered project of the submitter. This is the project
348 name under which the absentee job is run.
349 Notes: Multics person and project names normally begin with
350 uppercase letters; therefore these names must have an escape
351 character punched before each uppercase letter as described in
352 "Control cards" above.
353
354
355 ++PASSWORD Required
356 used to specify your card input password. It must immediately follow
357 the ++DATA card.
358 Usage
359 ++PASSWORD <xxxxxxxx> -control_arg
360 where:
361 1. xxxxxxxx
362 is the card input password registered for you. This
363 password is normally different from your login password.
364 It is maintained by the system administrator. The printing
365 mechanism on the keypunch should be usually turned off when
366 creating this card. A blank password is not allowed.
367 2. -control_arg
368 is -change_password STR -cpw STR to change the password, where
369 STR is a new password of up to eight characters.
370
371
372 ++AIM Optional
373 same as for bulk data input described above.
374
375 ++RJECONTROL Optional
376 used to specify control arguments that you can give to the
377 enter_abs_request command. You can use multiple ++RJECONTROL cards if
378 all the control arguments do not fit on a single card.
379 Usage
380 ++RJECONTROL <ARG1> <ARG2>...<ARGn>
381 where ARGi is any control argument acceptable to enter_abs_request,
382 except for -argument -ag. If you used multiple ++RJECONTROL cards,
383 the order of the control arguments is the concatenation of each ARGi
384 string separated by a space in deck order. Don't split a control
385 argument across cards; put leading hyphens where appropriate.
386
387
388 ++RJEARGS Optional
389 used to pass arguments to the absentee process, as would normally be
390 done by using -argument with enter_abs_request. If there are more
391 arguments than can fit on a single card, you can use additional
392 ++RJEARGS cards. Don't split an argument across cards.
393 Usage
394 ++RJEARGS <ARG1> <ARG2>...<ARGn>
395 where ARGi is the ith argument to be passed to the absentee process
396 used in substitutions of the form &i. If you use multiple ++RJEARGS
397 control cards, the order of the arguments is the concatenation of each
398 ARGi string separated by a space in deck order.
399
400
401 ++EPILOGUE Optional
402 overrides the default command string
403 eor -dl -rqt rje_args prt_rqt user absout
404 which is executed at logout time with the one supplied. This allows
405 you to control what action is taken just prior to logout of your
406 absentee process.
407 Usage
408 ++EPILOGUE <COMMAND_LINE>
409 where COMMAND_LINE is any command acceptable in an absentee process.
410 If you use multiple ++EPILOGUE cards, a single command line is
411 generated by concatenating the values contained on the ++EPILOGUE
412 cards separated by spaces.
413
414
415 ++ABSIN Optional
416 allows you to use an already-online absentee input segment instead of
417 including one in your deck. If any user-supplied cards follow the
418 ++INPUT card, the input is aborted.
419 Usage
420 ++ABSIN <PATHNAME> SYSTEM
421 where PATHNAME is the absolute pathname of the absentee input segment.
422 If you supply SYSTEM, then pathname is assumed to be the entryname of
423 the absentee input segment in >system_library_tools.
424
425
426 ++CONTROL Optional
427 used to control the way the card-reading software operates. If you
428 supply the control string CANCEL, then if the DECK_NAME specified on
429 the ++RJE card was submitted as an absentee job, the old job will be
430 canceled. See also ++CONTROL card for bulk data input.
431 Usage
432 ++CONTROL CANCEL
433
434 ++FORMAT Optional
435 same as for bulk data input described above.
436
437 ++INPUT Required
438 same as for bulk data input described above.
439
440
441 User absentee cards: All cards following the ++INPUT card for remote
442 job entry are copied into the absentee input segment as commands. The
443 command lines are translated according to the modes specified on the
444 ++FORMAT card, if present, or by the default modes, which are TRIM,
445 LOWERCASE, and ADDNL see "Card input conversion modes" below. You
446 can give any command lines except for an end-of-file marker, which is
447 defined as a card with "++EOF" in columns 1 through 5 and spaces in
448 columns 6 through 80. The end-of-file marker defines the end of your
449 data. See "Card input formats" above.
450
451
452 Card input conversion modes: Card input is reformatted according to
453 the conversion modes specified on the ++FORMAT control card. In all
454 discussions it is assumed that prior to translation a card consists
455 of 80 characters with trailing blanks as required. The action of each
456 translation mode is as follows:
457 TRIM strips off trailing blanks. Default
458 LOWERCASE converts all uppercase characters to their lowercase
459 equivalent unless preceded by the escape character \.
460 ADDNL appends a newline character after the last character of a
461 card. This operation takes place after trimming if you
462 requested trimming. Default
463 CONTIN if the last character on the card is \, then if you give
464 the ADDNL mode, a newline character is not added. This
465 operation takes place after trimming if you requested it.
466
467
468 These modes cause the above actions not to occur--
469 NOTRIM the trailing blanks of the card image are not removed.
470 NOCONVERT no uppercase-to-lowercase conversion is performed.
471 NOADDNL a newline character is not appended after the last
472 character.
473 NOCONTIN no action is taken if the last character on the card is
474 \.
475
476 If you are reading a deck, using edit-directed I/O, into a PL/I
477 program that expects card images to be fixed-length records, you
478 should use the latter modes.
479
480
481 Deck size: Decks being read in mcc or rmcc format may exceed the
482 maximum length of a Multics segment; if they do, the input will
483 automatically be stored in a multisegment file MSF.
484
485
486 Errors: The operator returns a note with the deck if any errors take
487 place during the read. In general, the error should be corrected and
488 the deck resubmitted.