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: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?) 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 . 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 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. ) 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:PROLOG.MAC.4 With: MYSTR:PROLOG.MAC.50 Changes to: MYSTR:PROLOG-7.RED] There were 3 changes found. ALU>REP LIB1:SCHED [ALU: Calling REDIT] [Compare: MYSTR:SCHED.MAC.3 With: MYSTR:SCHED.MAC.44 Changes to: MYSTR: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:PROLOG.MAC.1 With: MYSTR:PROLOG.MAC.9 Changes to: MYSTR:PROLOG-1.RED] There were 3 changes found. ALU>REP LIB2:SCHED [ALU: Calling REDIT] [Compare: MYSTR:SCHED.MAC.1 With: MYSTR:SCHED.MAC.9 Changes to: MYSTR: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.