Multics Technical Bulletin                                MTB-626
The config deck editor for Bootload Multics

To:       Distribution

From:     Keith Loepere

Date:     06/07/83

Subject:  The config deck editor for Bootload Multics


        As  part  of  replacing  BOS  with  the  Bootload Multics
environment, a new config deck  editor is needed.  The new config
deck  editor  is a  subset of  qedx that  allows the  operator to
perform normal  text editing operations on  the config deck (such
as,  "s/off/on/" to  configure a box  on) in  an environment that
understands the format of config decks.  A certain level of error
checking is performed by the new config deck editor on the config
deck.  The  editor's functioning was made  different from that of
qedx where this is convenient for editing config decks.

Comments on this MTB should be sent to the author -

     via Multics mail to:


     via telephone to:



Multics  project  internal  working  documentation.   Not  to  be
reproduced or distributed outside the Multics project.

Multics Technical Bulletin                                MTB-626
The config deck editor for Bootload Multics


        The new config deck editor is  a subsystem for use in the
Bootload Multics  environment (although it also  works at Multics
command level).   It keeps the  config deck in an  ascii form and
allows,  through  a qedx-like  interface, relatively  normal text
editing operations  to be performed on  the deck.  However, since
the editor  knows the format  of config cards  (as it must  to be
able  to read  and write them  in their binary  form), the config
deck editor can allow input of  and searching for config cards in
more meaningful and convenient forms  than would be possible in a
regular text editor  or was possible in the  previous config deck
editor.  Also, some validation of the config cards is possible.

        The new  config deck editor  allows a more  symbolic form
for config  cards.  In this form,  the fields of the  card may be
labeled and therefore appear in  any order.  A typical card might

        iom -tag a -port 0 -model nsa -state on

Fields may  also be unlabeled;  in this case they  must appear in
the correct order for the particular card.  Labeled and unlabeled
fields may be mixed at will.  Depending on the circumstances, the
data  type of  a field  is determined from  the label,  if one is
present,  or  from the  appearance  of the  data value.   The old
convention  that fields  ending in a  period are  decimal and the
rest are octal (or strings) is kept.

        Config decks are normally read and written in their ascii
form.   Thus,  the user  visible  form of  the config  deck (with
fields  having symbolic  labels) is maintained.   When the config
deck is  written to the  real (binary) config  deck, however, the
labels  obviously disappear.   Any time  the config  deck is read
from the real config deck, and therefore converted from binary to
ascii form,  all of the  fields are given labels  for those cards
that are recognizable by the config deck editor.

1.  Structure

        The config deck editor (config_deck_edit_) is designed to
be called through the Bootload Multics simulated ssu_ environment
calling   sequence.    It  can   also   be  called   through  the
config_deck_edit Multics command.   The routine config_deck_edit_
itself is not ssu_ based because the syntax of requests and basic
operation  is  not  proper  for  ssu_.   The  routine  takes  one
argument, the deck to edit.  If no argument is supplied, the live
config deck  is read and  converted to fully  labeled ascii form;

Multics Technical Bulletin                                MTB-626
The config deck editor for Bootload Multics

otherwise,  a  file from  the Multics  hierarchy or  the Bootload
Multics file system is read, depending on the environment.

        The user is  then placed at request level  where he types
relatively normal looking qedx  requests.  The line addresses are
extracted from the request and  found, then the command character
dispatches to  the appropriate place  to perform the  action.  If
the request causes a line to  be printed from the config deck, it
is also validated  so the user knows what  to fix.  Requests that
modify  the  buffer post  a  modified flag  for it.   Writing the
entire buffer posts it as unmodified.

        The format  of config cards is  described through a bunch
of  tables;  no  information  on the  structure  of  any  card is
committed to  code.  Unknown card  formats are allowed;  you just
aren't  allowed to  label any  of the  fields (since  field names
would be  unknown).  Also, for  a card format which  is known but
for  which you  wish to supply  different ordering  of values and
types   (possibly  during   a  system  change),   placing  a  dot
immediately  before  the config  card  name causes  it not  to be
interpreted (and can then not have any labeled fields).

2.  Conversion from ascii to binary form

        The  conversion from  ascii to  binary forms  of a config
card  starts  by  separating  the unlabeled  and  labeled fields.
Labeled fields without a value generate an error.  Looking at the
fields,  the type  of config card  ("cpu", "prph  dsk", etc.)  is
determined.   A card  that is  unrecognizable or  whose card name
starts with a dot is considered  to be of type "user".  (The user
card type is described as  having no restrictions on its format.)
Given the card type, we can  tell from our tables what fields are
needed or allowed, and what they are called.

        We then take the labeled fields  and match them up to the
known names for  this card's fields.  This is done  in such a way
that the order of the labeled  fields on the user's card does not
matter but  where multiple occurrences of  the same labeled field
(such as more  than one "-chn" field) are kept  in the same order
that  the  user supplied.   Labeled  fields whose  label  are not
appropriate  for the  card (and there  are no labels  valid for a
user formatted card) are flagged as an error.

        As  a  result  of  the  labeled  field  match,  some  not
necessarily contiguous collection of fields have not been filled.
The  unlabeled fields  are put  into these  empty spaces,  in the
order supplied.

Multics Technical Bulletin                                MTB-626
The config deck editor for Bootload Multics

        The resultant card is then  checked to be sure that there
are no  holes left in  the card (a  field near the  end filled in
without  filling the  intermediate ones).  We  convert the user's
values  to binary  by first using  the type we  believe that they
should be, and,  if this fails, we convert  them according to the
type implied by the appearance of the user's value.

        The result of the above is that a user may say:

        iom a on -model nsa -port 0

and this will correctly turn into:

        iom a 0 nsa on

3.  Conversion of binary to ascii form

        Converting  a  config  card   from  binary  to  ascii  is
relatively simple  at the base level.   Each binary card contains
the  various fields,  in order, along  with a  tag specifying the
data type of  the field.  We determine the config  card type in a
manner similar to the method used for ascii to binary conversion.
Given  the  type, we  can determine  what labels  to give  to the
fields as we  convert them, given the data  type specified in the
card.   Cards of  an unrecognized  type are  given no  labels for
their fields.

        We  would  expect this  card  so formed  should  be good.
However, even  if the type  of this card was  recognizable to us,
its format may have changed without the change being reflected in
our tables.  A possibility we can't detect would be if two fields
of the  same data type were  rearranged so that we  have ended up
giving the wrong  names to the fields.  What we  expect to see in
cases  of  config  card  change, though,  is  for  the  data type
specified in the  binary card to produce an  ascii value which is
not what we  expected for the field.  (We did  not use our tables
to validate the  data types in the binary  to ascii conversion to
avoid duplicating code already in  the ascii to binary conversion
routines.)  To  validate the data  types, and to  cover any other
possible apparent misconformity, we take the ascii card generated
and parse it back to binary.   That is, we gave the fields labels
according to our tables but took the  card at its word as to what
data  types we  had.  We now  use our  tables to see  if the data
types are what we think they should be.  If we get any errors, we
assume the format has changed and  convert the card as if it were
a user  format card, putting a  dot in front of  the card name to
prevent errors from being flagged  later when the card is printed
or written back.

Multics Technical Bulletin                                MTB-626
The config deck editor for Bootload Multics

4.  Operation of the new config deck editor

        The  config deck  editor is  invoked either  from Multics
command  level with  the command  config_deck_edit (cde)  or from
Bootload  Multics  level  by   an  appropriate  name.   Also,  if
performing a  cold boot, the  config deck editor  is invoked with
the current  config deck as  an argument automatically  since you
must  type in  an initial  config deck.   The config  deck editor
takes either zero or one argument; if  one, it is the name of the
config  deck to  use (either a  Multics storage system  file or a
Bootload  Multics file,  depending on the  environment); if none,
the current (live) config deck is  used.  The config deck is read
into an internal  buffer; the binary config deck  is converted to
ascii as it is read.  The user is then put at request level.

        A current line pointer is  kept.  This points to the last
line  printed or  operated upon by  the config  deck editor.  The
first line in the buffer is numbered one.  Operations that add or
delete lines dynamically renumber the lines in the buffer.

        Any request that prints a  line also prints any errors in

        Requests  follow  the  usual  qedx  syntax:   one  or two
addresses  followed  by  the  command  character.   This  may  be
followed by other arguments to  the request.  Another request may
follow this one on the same line.

        When no line addresses are  supplied, the default for the
requests is the same as for  qedx.  We allow both one address and
two address forms; for two addresses, the separator may be either
a comma or a semi-colon with the same meaning as in qedx.

        Line addresses  may take several forms.   A number refers
to the line so numbered.  A line address of the form .  or .+n or
.-n refers  to the line n  lines away from the  current line.  An
address of the form $ or $-n refers to the line n lines away from
the last line in the buffer.   Finally, /str/ or |str| or /str/+n
or /str/-n or |str|+n or |str|-n causes a string search to occur.
The /str/ form  performs a normal string search.   The |str| form
takes the  string apart as if  it were a config  card.  A card is
searched  for that  has all  the labeled  fields from  the search
string,  in  any order,  and  all the  unlabeled fields  from the
string, in order, but not necessarily contiguous.  Thus,

        |cpu -state on|

Multics Technical Bulletin                                MTB-626
The config deck editor for Bootload Multics

will match all cpu cards that are specified to be on in this way.
Null strings  may be supplied  which implies the  previously used
string.  Also, the qedx perverted forms //n and .n are allowed.

        The request  set and their  actions are the  same as qedx
except as  noted below.  In particular,  we support the following

- print lines (p) request
- string searching (a search string specified for an address with
        either no request character or the p request specified)
- append (a), insert  (i) and change (c) lines  requests using f
        to denote end of insertion
- delete lines (d) request
- print line number (=) request
- buffer status (x) request (prints the number of config cards)
- read config deck (r) request
- write config deck (w) request
- substitute string (s) request
- quit (q) request
- global and exclude (gp, gd, g=, vp, vd and v=) requests

We differ from qedx in the following:

- All whitespace converts to a single blank between fields.
- We do not allow regular expressions in search strings.
- Although  the  value of  // and  || are  saved, the  values are
        different.  (Specifying || uses  the last value of |str|,
        not the last value of /str/.)
- We do not recognize ampersand substitution forms.
- The old string in the substitute request must be of the form //
        or /str/.   |str| forms are  not allowed.  Slash  must be
        the delimiter.
- We do not  support multiple  buffers or  anything suggestive of
- We do not support line escapes since their is no need for them.
- A read or write with no file name specified does not follow the
        qedx  default action.   Instead, we  use the  live config
        deck.   Note that  this is the  only way to  refer to the
        live config  deck.  (One cannot write  to the live config
        deck during Multics normal operation.)
- Escape to command level is not supported.
- Quitting with  a modified buffer  causes a query.   One may not
        quit during cold boot until the deck has been written.

5.  Cards currently recognized

Multics Technical Bulletin                                MTB-626
The config deck editor for Bootload Multics

        The card formats currently recognized follow.

chnl -subsys  <str> -iom  <tag1> -chn  <number1> -nchan <number2>
        {...  -iom <tag4> -chn <number7> -nchan <number8>}

clok -delta <number1> -zone <str> -boot_delta <number2>

cpu -tag <tag1> -port <number1> -state <str1> -type <str2> -model
        <number2> -exp_port <tag2>

fnp -tag <tag1> -iom <tag2> -chn <number>

iom -tag <tag> -port <number> -model <str1> -state <str2>

mem -port <tag> -size <number> -state <str>

mpc -ctlr  <str>  -model  <number1>  -iom  <tag1>  -chn <number2>
        -nchan <number3> {...  -iom  <tag4> -chn <number8> -nchan

parm <parms> (no restrictions are placed on names or order)

part -part <str1> -subsys <str2> -drive <number>

prph -device ccuN -iom <tag> -chn <number1> -model <number2>

prph -subsys  dskN  -iom  <tag> -chn  <number1>  -nchan <number2>
        -model   <number3>   -number   <number4>   {...    -model
        <number11> -number <number12>}

prph -device opc -iom <tag> -chn <number1> -model <number2>

prph -device  prtN  -iom  <tag> -chn  <number1>  -model <number2>
        -train <number3> {-ll <number4>}

prph -device punN -iom <tag> -chn <number1> -model <number2>

prph -device rdrN -iom <tag> -chn <number1> -model <number2>

prph -subsys  tapN  -iom  <tag> -chn  <number1>  -nchan <number2>
        -model   <number3>   -number   <number4>   {...    -model
        <number11> -number <number12>}

root -subsys <str1> -drive <number1>  {...  -subsys <str7> -drive

salv <parms> (no restrictions are put on salv card options)

schd -wsf <number1>  -tefirst <number2> -telast  <number3> -timax
        <number4>  {-mine  <number5>  {-maxe  <number6> {-maxmaxe

Multics Technical Bulletin                                MTB-626
The config deck editor for Bootload Multics

sst -4k <number1> -16k <number2> -64k <number3> -256k <number4>

tbls <parms> (no restrictions are put on tbls card fields)

tcd -apt <number1> -itt <number2>

udsk -subsys  <str>  -nchan  <number1>  -drive  <number2> -number
        <number3> {...  -drive <number12> -number <number13>}

<user defined> <fields>  (no restrictions are put  on user format

6.  Equivalences for old functions

        Currently, in  BOS, there are  two ways to  edit a config
deck,  with  the  BOS editor  and  with the  BOS  CONFIG command.
Although there is really no comparison between the old methods of
editing a config deck in BOS and the new way, we will list a way,
in the new  config deck editor, to perform  the same operation as
in the old methods.

- BOS EDIT N {n} becomes +{n}n (one  can leave off the final n to
        get the line to print)
- BOS EDIT - {n} becomes -{n}n
- BOS EDIT P {n+1} becomes .,+{n}p
- BOS EDIT I becomes i
- BOS EDIT T  becomes 1n (although T  really positions before the
        first line)
- BOS EDIT B {lines} {empty line} becomes $a {lines} f
- BOS EDIT D {n+1} becomes .,+{n}d
- BOS EDIT Q becomes q followed by  answering no to the query "Do
        you wish to quit with a modified buffer?"
- BOS EDIT W {name} becomes w{name} followed by q
- CONFIG  L  {cards}  QUIT  becomes  1,$da  {cards}  f (assuming
        throughout that you are in the config deck editor)
- CONFIG  L  {name} was  performed  as a  result of  entering the
        config deck editor
- CONFIG SAVE {name} becomes w{name}
- CONFIG A {cards} QUIT becomes $a {cards} f
- CONFIG  C  {cards}  QUIT or  CONFIG  R {cards}  QUIT  becomes a
        collection of  |{card}| searches with  c or s  requests -
        performing an s request is  probably what the user wanted
        to do with the CONFIG C command
- CONFIG P {card names} becomes a set of gp|{card name}|
- CONFIG  D  {card  names}  becomes  a  set  of  gd|{card  name}|
        (although the usual use of  this, to delete all mem cards
        before  retyping  the  new   order,  can  now  be  better