004 - Build New PLATO

The PLATO build process relies on several procedures. The ones shipped with Release 1 are insufficient and will be replaced during this phase.

• Code File plmods
  This file contains the pre-configured modifications which will be applied to the PLATO system.
  • IGNORE: block 1-b bu
    (it doesn't really apply in present-day builds)
  • READ: block 1-c mod files
    
  • READ: block 1-d retro1.org
    This block contains a detailed itemization of each modification to be applied.

• Code File tpmods
  These are modsets used in all assemblies, but never applied permanently to platopl. In practicality, nothing is permanently applied to platopl any longer.

• Code File gogomods
  modsets used in all assemblies, except the code-sharing full assemblies, and not applied permanently to platopl. the modsets in this file are active during gogo only; they are partialed out before the codesharing assemblies are run. the programmers must reactivate their modsets each week after codesharing is finished.

• Code File maintp
  This file contains the Development Submit File which is used by s0maint
  • READ: Block 1-b ReadMe
  • REVIEW: Block 1-c maintp
    This block contains the job which replaces the build procedures in maintp/un=plato

• Code File maintsub
  This file contains the core of the utility routines needed for the development process.

  • System procedures
  • Submit Jobs
  • Key Configuration Files for “Original” and “New” NOS:
    • CMRDECK
    • EQPDECK
    • IPRDECK
    • CONFIG
    • MFNX
    • MFDX is disregarded in Release2

  • Blocks prefixed with o are the “Original” blocks which should be the same as the ones running at the start of this procedure if all prior steps were done correctly. Blocks without the o prefix are the ones which will replace their respective contents in the deadstart tape.

  • Utility submit blocks getall, getsingle and tgetselect update the contents of the o code blocks in this file with different conditions.

  • Submit block getall updates the o blocks with the contents of the currently running system.

  • Submit block getsingle selectively updates individual blocks from the currently running system contents.

  • Submit block tgetselect to retrieves selected blocks from a deadstart tape which is not currently running.
  • READ: Block 1-b ReadMe

• Lesson s0maint
  This is the workhorse upon which we will rely in the construction of the proper job submissions when building parts of the PLATO system.

• Code File maintdf
  This Code File is a listing repository for the output generated during builds.
  • LISTING BLOCK dayfile contains this output.

Using ''CDC.IO'', all other files that need to transfer from any other installation may be moved dynamically to the new installation.

Before PLATO can be built, the core maintenance procedures need to be updated.

1. Enter code file maintp.
2. Select c (code block maintp)
3. Shift-LAB to submit this block and wait for job output. You will be transferred to lesson jobstat to monitor its progress.

   Warning

   The dayfile from this procedure is written to listing block dayfile in file maintp so don't return to this code file from jobstat until the job is completed.

Once the job has successfully completed, update the backup (as in Plan B) procedures which may be used through the console to rebuild PLATO.

1. Enter code file maintsub
2. Select c (code block fix-builds)
3. Shift-LAB to submit this block and wait for job output. You will be transferred to lesson jobstat to monitor its progress.

   Warning

   The dayfile from this procedure is written to listing block dayfile in file maintsub so don't return to this code file from jobstat until the job is completed.

EXECUTE lesson s0maint (enter the name then press DATA)

Choose Option:

 a. Full Assemblies
 <Press NEXT>
 r. Full System Assembly
 <Press NEXT>
 

Shift-LAB to invoke personal defaults.

Shift-NEXT to build the batch job.

Shift-LAB to submit the job.

NEXT to view the job in lesson jobstat.

Take a BIO¹⁾ Break

Review the dayfile output in code file maintdf block dayfile.

Transferring new binaries AND the new configuration elements defined in maintsub to a new deadstart tape is the final stage in performing the upgrade.

Use the show_tape dtCyber command to see the status of the loaded tapes:

At the dtCyber console, attach a new blank tape to NOS Tape unit 51 (C31 E00 U01) using the emulator Operator> prompt. We assume that you have created a dedicated deadstart tape directory called deadstart relative to the location of the cyber.ini file. It is also recommended that you use the naming convention shown below to maintain naming of the deadstart tapes in time sequence:

  load_tape 13,0,1,w,YYYYMMDDX.ds.tap

Where YYYYMMDD is the current date and X is the sequence letter A through Z.

1. Enter Code File maintsub.
2. Enter Block 1-f mkdstart.
3. Shift-LAB to submit this job.
4. The PLATO terminal will be directed to lesson jobstat but your attention should be on the NOS Virtual console.
   1. Locate the submitted job.
   2. When prompted for tape1, assign,<jsn>,050. (Where <jsn> is the Job Sequence Number of the requesting job.)

      ASSIGN,<jsn>,050.

   3. When prompted for tape2, assign.<jsn>,051. (Where <jsn> is the Job Sequence Number of the requesting job.)

      ASSIGN,<jsn>,051.

This job does very detailed reporting of what it is doing and its output will be generated to the system printer when complete.

You may now detach your new deadstart tape at the dtCyber operator prompt:

  unload_tape 13,0,1

At this point, the new deadstart tape should have been properly built and the currently running system may now be shut down and restarted.

Once the deadstart has completed, on the NOS console issue the E,C. command to check the status of the new disks:

Confirming that there are no errors, proceed to start CYBIS by issuing the NOS console command CYBIS..

Note that there will still be the ERROR - SYSTEM ID .NE. ROUTING ID. Ignore that for the moment and connect a PTerm session.

You will see a number of “success indicators”:

1. The color functionality is now correct.
2. The Welcome to CYBIS screen shows Maintenance and Development Time

You may proceed to log in as admin/s.

You will see an error message from s0init: system *ncc* not in network table. This is a good thing!

Now proceed to:

1. Backout all users
2. Log off
3. Shutdown CYBIS
   1. NOS> K,MAS1.
   2. NOS> K.STOP.
4. Once CYBIS is fully-terminated:
   1. NOS> X.DIS.
   2. NOS> USER(PLATOMF,PLATOMF)
   3. NOS> PURGE,CONFIGX.
   4. NOS> DROP.
   5. NOS> CYBIS.

Let CYBIS reinitialize and the following should appear:

You may now re-connect the PTerm session and login as admin/s:

1. Enter Code File maintsub.
2. Enter Block 1-g productupd.
3. Shift-LAB to submit this job.
4. The PLATO terminal will be directed to lesson jobstat.

When this job completes, the PLATO binaries will have been incorporated into the NOS file PRODUCT/UN=INSTALL on the chance that it may be needed for future enhancements. This file is used by the NCC distribution to maintain an image of the deadstart tape during product installation.

Deadstart again… Just to convince yourself that everything is working properly.

Next Step: Move on to version management and Create a Backup Repository

Next Step: NDL Modification

Next Step: NOS Configuration Summary