Enter your search terms Submit search form
	Web pdp-10.trailing-edge.com

                            ALU

The following describes  the  use  of  ALU  in  the  monitor
development  group.   Other applications may take this as an
example.

ALU is now formally installed as the interlock mechanism for
monitor  sources.  It serves to prevent simultaneous editing
of files by two or more people.  In  addition,  it  provides
information  on  who  has  reserved a file at any particular
time, and keeps a log of new versions.

ALU does not limit access to the source directories  in  any
way.  Any user is allowed to reserve files.

To use ALU, the first thing you must do  is  to  'take'  the
file  MYSTR:<MURPHY.ALU>ALUDEF.CMD  or  incorporate  it into
your LOGIN.CMD file.   It  defines  logical  names  for  the
active  monitor,  exec,  and utilities directories.  Yes, we
all  have  to  use  the  same  logical   names   for   these
directories.

The basic cycle is:

        1.  Reserve (interlock) the file, getting a  private
        copy.

        2.  Edit  the  private  copy;   ensure  that  it  is
        reasonably correct.

        3.  Release  the  file  (automatically  copying  the
        edited   private   copy   back   onto   the  regular
        directory).

1.  To reserve the file, run ALU:ALU and use the GET or QGET
command.  E.g.,
        ALU>GET (file) LIB1:TTYSRV

ALU then asks you
        (Till when?)

Your answer to this is strictly information for anyone  else
who  may  try  to  get  the  file  while  you have it.  Your
reservation does not automatically expire at  the  time  you
say or at any other time.  If you use the QGET command, this
question is not asked and the answer is defaulted to "SOON".
By  default,  GET  and QGET do not copy the source into your
connected directory.  If you want a  copy  immediately,  use
the  /COPY  switch  after the filename.  Otherwise, you will
get the file from the library directory when you edit it the
first  time.   Note  that  you  cannot  be  connected to the
library directory - ALU will detect this and complain.

                                                      Page 2


2.  You then  edit  your  private  copy.   As  with  current
practice,  you should add a comment at the very beginning of
the file to say what you did.  You need not add an edit line
however;   ALU  will do that when it puts the file back into
the library directory.

3.  When you are ready to have your file put back  into  the
library, run ALU and use the REPLACE command.  E.g.,
        ALU>REPLACE (file) LIB1:TTYSRV

If you did NOT put a comment at the beginning of  the  file,
ALU will ask:
        (Why?) <comment>

In either case, the comment will go into the  ALU  log  file
along  with  other  information  about the transaction.  ALU
will then run REDIT, comparing your source with  the  source
on  the library.  The changes files goes into a subdirectory
of the library called <LIBRARY.ALU>.   ALU  will  copy  your
private  version  back  into the library directory and put a
new edit/update line at the beginning of the file.   Nothing
is  removed  or  replaced from the file.  The private source
will then be deleted from your connected directory.

A log file of new sources put on the  library  directory  is
maintained as <LIBRARY.ALU>FILUPD.HST.

There are other commands in ALU which you can discover  with
"?",  including  one  to  CANCEL  your  reservation (without
putting anything back on the library) if you decide to  give
up.   Of  course, a GET will tell you if someone already has
reserved the file, and a REPLACE will not put  a  file  back
unless  you  had the reservation.  There are also STATUS and
INFORMATION commands which will  tell  you  what  files  are
currently reserved.

ALU uses various little bookkeeping files;  they are kept in
a    subdirectory    of    the   library   directory   (e.g.
<LIBRARY.ALU>) so as to be out of the way.

MISCELLANEOUS

ALU has project-specific information built into it, so  each
project has its own version.  Therefore, the ALU.EXE on SYS:
simply runs ALU:ALU.EXE,  assuming  that  ALU:   is  defined
appropriately for each project.

ALU looks for a rescan line, so you can  say  to  the  EXEC,
e.g.,

@ALU QGET LIB1:TTYSRV

or

@ALU REPLACE LIB1:TTYSRV

                                                      Page 3


          MAINTAINING MULTIPLE SOURCE DIRECTORIES

Here is a "cookbook" approach to making  edits  in  multiple
sources,  in  particular  to make edits in library 1 sources
(LIB1:) and duplicate them in library 2 (LIB2:).

The basic steps are:

     1.  Make edits in LIB1 sources in  the  usual  fashion,
         i.e.  "ALU GET" the ones you need, and work on them
         until they are correct.

     2.  When you "ALU REPLACE"  them,  note  the  files  to
         which the changes are written.

     3.  Do "ALU GET" of the same set of source  files  from
         LIB2 sources.

     4.  Run REDIT, merging the change  files  from  step  2
         with the sources from LIB2:.

     5.  Do "ALU REPLACE" to put the files back into  LIB2:.
         New change files will be written, but won't be used
         for anything further at this time.


(It would be nice to have a PCL or ALU command to  do  steps
3-5 at once, but until there is, you do 'em by hand.)

Here is an example.   I  have  been  working  on  SCHED  and
PROLOG, and am now ready to put them back into LIB1:.

    @ALU
    ALU>REP LIB1:PROLOG
    [ALU: Calling REDIT]
    [Compare:       MYSTR:<MURPHY.MON>PROLOG.MAC.4
     With:          MYSTR:<LIBRARY1>PROLOG.MAC.50
     Changes to:    MYSTR:<LIBRARY1.ALU>PROLOG-7.RED]
    There were 3 changes found.
    ALU>REP LIB1:SCHED
    [ALU: Calling REDIT]
    [Compare:       MYSTR:<MURPHY.MON>SCHED.MAC.3
     With:          MYSTR:<LIBRARY1>SCHED.MAC.44
     Changes to:    MYSTR:<LIBRARY1.ALU>SCHED-8.RED]
    There were 7 changes found.

The change files are always written  in  the  ALU  directory
associated  with  the  library.  The logical name LIB1A:  is
used for that directory below.  Now, I need to get the  same
two files from LIB2:.

    ALU>QGET LIB2:PROLOG
    ALU>QGET LIB2:SCHED
    ALU>EX

                                                      Page 4


Now, I will merge the change files created above.  This step
takes  the source from LIB2:, merges the changes, and leaves
the result in my connected directory.

    @REDIT
    REDIT>MER LIB1A:PROLOG-7.RED.1 (WITH SOURCE) LIB2:PROLOG.MAC.9 (TO) PROLOG.MAC
    .1 !New file! 
    REDIT>MER LIB1A:SCHED-8.RED.1 (WITH SOURCE) LIB2:SCHED.MAC.9 (TO) SCHED.MAC.1 
    !New file! 
    REDIT>EX

If there were conflicting edits in LIB2, I would have  heard
about it in those merges.

Now just put the LIB2:  files back.

    @ALU
    ALU>REP LIB2:PROLOG
    [ALU: Calling REDIT]
    [Compare:       MYSTR:<MURPHY.MON>PROLOG.MAC.1
     With:          MYSTR:<LIBRARY2>PROLOG.MAC.9
     Changes to:    MYSTR:<LIBRARY2.ALU>PROLOG-1.RED]
    There were 3 changes found.
    ALU>REP LIB2:SCHED
    [ALU: Calling REDIT]
    [Compare:       MYSTR:<MURPHY.MON>SCHED.MAC.1
     With:          MYSTR:<LIBRARY2>SCHED.MAC.9
     Changes to:    MYSTR:<LIBRARY2.ALU>SCHED-2.RED]
    There were 7 changes found.
    ALU>EX

That's all there is to it.

By the way, the number following the dash in the change file
name  is  the  ALU ID number.  You will also see that in the
update line  at  the  beginning  of  the  file  and  in  the
FILUPD.HST.   Hence,  one  can go looking for the particular
change that is noted at the beginning of a file.  The change
files  are  ordinary  text  and  can  be read like SRCCOM or
FILCOM DIF files.