Frequently Asked Questions, Tips and Tricks

A system administrator is an author with special privileges. The differences come from the group name (s rather than a regular group). The SYSTEM MODE screen (as opposed to AUTHOR MODE screen) is a recent change to remind the administrator of the privileges. At CERL everyone got AUTHOR MODE whether in group s or not.

Start lesson aids and when it shows the INFO screen press NEXT and select option b for Author Resources. Another one is sysaids.

The leading 0 meant that it was a published lesson. On CDC systems, this involved accounting for usage and royalty payments to the lesson authors. That is why the names were different on CDC systems for such lessons.

It is a NOS permanent file used as a container for a CYBIS or PLATO file system. So instead of reading the disk directly as CERL PLATO would do, CYBIS has to read the NOS permanent file which adds some small overhead.

The use of ECS (directly via RE/WE instructions) is pervasive throughout CYBIS. It's not like NOS where ECS is handled as a solid state disk and accessed only through disk I/O primitives that could be tweaked. All the CYBIS CPU components have ECS field length assigned to them, and among other things use it as a medium for high bandwidth message passing both among CPU programs and PPU programs. This version is actually configured to use UEM.

The CONSOLE program is a primitive CYBIS terminal program that runs on the CYBER console. It is invoked via the DSD command X.CONSOLE.. A text only terminal is displayed on the left screen, and a help page showing the keyboard layout on the right. Right blank toggles shift state, left blank toggles between text and function keys. The right screen changes accordingly. Usually it prompts

“Lesson desired” - BACK (left blank then ‘b’) then drops you into “Author mode”. At this point you don't have a user name or group name, but you have “s” privileges.

The program has limitations, but it is necessary to do some of the CYBIS setup. For example, it is the only way to get onto a system without having a valid login with a known password, or it allows you to create group “s” if it doesn't exist yet.

If for some reason you want to use the console terminal (perhaps because others don't work yet) and you do want to appear as a signed in user, at the “Lesson desired” page, enter “plato”. That will give you the login display, and you can go through username, group name, and password as usual. To exit the CONSOLE program press the following keys in order: left blank, right blank and ‘x’ (that means ‘[‘, ‘]’, and ‘x’ on Desktop CYBER).

CYBIS runs as a set of subsystems under NOS but bypasses NOS in many places. Not quite so much in the CDC / VCampus version as in the CERL edition. NOS just does startup, scheduling, provides disk containers in form of direct access permanent files (master files) and terminal communications (via NAM).

CYBIS uses a small subsystem called PNI written in CYBIL to provide the terminal interface. PNI interfaces via NAM/PIP to the NPU emulation of Desktop CYBER. The network settings are configured via an NDL file (NDL18) under NOS user netadmn with password netadmn. Desktop CYBER’s network configuration is defined in cyber.ini under the section specified in npuConnections which points to npu.cybis. The current configuration allows for 32 normal terminal connections on TCP port 6610, 30 Pterm connections on TCP port 8005 and 2 special RS232 terminal server connections for real terminals like the CDC IST II. Loading of the IST II or III firmware from CYBIS/PNI is not yet reliable.

CSTC is the assembler needed to assemble CYBIS or PLATO code. PLATO uses a modified Compass, with an additional directive CST, which is like SST but it saves more stuff, specifically common symbols as required by the PLATO sources. You can actually use it everywhere - CERL did exactly that. But CDC practice was to call it CSTC and use it only for PLATO. Paul Koning has what appear to be the actual mods that turn COMPASS into CSTC. The mods were done by Don Lee of CERL. No attempt has been made to build CSTC using these mods.

The PROC MFNX on the deadstart tape attaches all the master files spread over multiple disk packs accessed via the NOS PACKNAM directive. There is no directory of master files, instead at start-up, CYBIS asks MASTOR what all the master files are, and loads their directory. All master files that are of type “general” or “master” then have their directories essentially merged into a single namespace which is the namespace of files/lessons you can see as an author or student. MASTOR simply expects every local file that's a direct access file to be a master file.

The starting point is PROC CYBIS on the deadstart tape. That loads the “prime time” CYBIS, i.e., the one that lives on the deadstart tape. On development systems, there's also a notion of a “non-prime time” or “development” CYBIS, which is found in a set of direct access files and loaded by PROC CYBDEV which is unsupported and not working on this system. My standard procedure is simply to make a new deadstart tape when I want to test stuff. Our current tapes are fast enough for this.

CYBIS is invoked by X.CYBIS. from the console (DSD). It calls MFNX, gets the CONFIG file, and starts MASTOR. The CONFIG file is record TEXT/CONFIG on the deadstart tape.

When MASTOR starts, it looks for a permanent file “CYBIS” under user SYS. The file contains calls to load the CYBIS subsystems to NOS control points (PLATX, CONDX, FRAMX and PNIX).

All CYBIS sources are under user plato. Back at CERL, the official sources were in PLATO files (“code” type lessons). I believe CDC made the OPL since that's the form they are comfortable with. And in fact, the CYBIS system has those code files, but it's clear they are produced from the OPL, not the other way around. CYBIS files of type “e” indicate they contain NOS program sources

CYBIS wants a binary pack to put lesson binaries into when they are “condensed”. Ideally you want enough space to hold all the binaries that are in use, but if you don't have enough old entries are discarded.

The “backup” type masterfiles are typically used for doing file transfers: you put things on a backup type masterfile, then ship the masterfile, then load that on the destination system. The point is that PLATO's file name search only looks at “master” and “general” packs by default. To access a file on a backup or binary master files, you have to select it explicitly, by master files name.

To change a backup type master file to general type:

• shutdown CYBIS
• attach the backup type mastefile (xyz in the example below)
• then: “mfalter(mf=xyz,pt=general)”
• restart CYBIS

CYBIS uses 7 bits with parity. Pterm conforms to the CYBIS/PLATO custom encoding. The protocol is documented in CYBIS document type file s0ascers.

There are lot of “n” versions of files – standard system lessons with “n” prefixed to the name. This is a CYBIS system convention that development is done in those, for example “nedit” or “nplato”, then once it looks good it is copied into the primary lesson (and the old primary one goes to the “o” prefixed lesson). The “n” lessons are restricted to system staff. And when in an “n” lesson, by convention a ‘*’ is plotted in the upper right corner so you're aware that you're not in the official version. Also by convention, “n” files go into account s0nver, and “o” files into s0over.

The “n” versions aren't hard-coded, but they are a development convention supported by a couple of tools. They are defined as system lessons just like their non-n counterparts (apart from not being set up to trap shift-stop). That's about all that is needed for things to work.

As an additional convention, when you're in the “n” version of one of those lessons, the jumps to related lessons also use the “n” version. The idea is to make the set of components look like a single larger system. For example, if you just run “nedit” which tells me I am in the n version by showing a * in the top right corner. As you wander around the various bits of a lesson, you may be in nedit1, or nedit2, etc., but you stay in the “n” series.

Various bits of code that jump around different lessons know rules like “if I'm 'edit' then jumpout to editmicro, else jumpout to neditmicro”, so the “n” lessons act as a set. Note that this is just a coding convention.

As for copying over, there's a specific option in lesson operator for that, option g for “copyover file contents”, then “n” to copy <file> to o<file>, n<file> to <file>. So before you do that, make sure there exists an o<file> – for example oplato. These are content copies, not file creators. For that operation to work, all three files have to exist, and be the same size. There's a bit of magic: the codewords are not copied over so whatever the edit protection was on the original main lesson remains in effect. If after doing this you discover a problem, you can reverse it (“o” to copy current to new, old to current). Of course this is only one level of “Undo”.

Typically, this copyover file contents also deletes the binary so the lesson will recondense when next requested. In a few cases that doesn't happen; I think “plato” is one of those. You can edit or inspect the lesson and hit shift-stop to force a condense. That may tell you it is “in use” although it isn't always - sometimes the reference count is forced to 1 to keep a lesson resident even when it's not actively in use. You can then enter SHIFT-HELP to condense it anyway. It used to be that it was a bad idea to do this for lesson “syslib”. I don't believe that is true anymore. In any case, reloading PLATO will also do the job.

At the Author mode (or System mode) page, if you enter a lesson name and NEXT, that is a request to edit the lesson. For that, you need write access to it. System lessons by convention have their “change code” set to “no access permitted”, i.e., you can't write them. Well, not except from the console running X.CONSOLE. and then entering BACK to go into Author mode.

As mentioned earlier, the editing rule for system lessons is that you edit and test the “n” prefixed version, whose change code is set to “group s” meaning that anyone logged in into that group has write access. Then once debugging is done, you use the “copyover” operation (lesson “operator”, option g) to for example copy lesson ipedit to oipedit, nipedit to ipedit (or whatever the lesson name is).

If you want to execute a lesson, enter the lesson name and DATA (Control-D in Pterm). Also, if you want to inspect rather than edit, enter the name and LAB (Control-L in Pterm). Inspecting requires a match either on the change or inspect code. For system lessons such as ipedit, the inspect code by convention is “account system”, i.e., anyone logged into any group that is part of account name system (such as groups s, p, or pso) is allowed in.

File acclog1 is a “data file”, not to be confused with a “data set”. A data file is basically a log file. You can create it; make it an 18 part data file.

While manipulating files through the lesson accounts machinery is the normal practice, there is another way that doesn't depend on the account machinery to be fully operational - lesson “operator”. Option “f” lets you do file operations, such as creating, deleting, or renaming them. It lets you specify what account to operate on.

To shut down: lesson sysopts, option 3. If you aren't dealing with other users you can do an immediate backout. That leaves the terminal you're using still logged in. Log it out and then go to the NOS K display for MAS1. “K.STOP” tells it to exit, killing all the CYBIS subsystem. “K.RELOAD” tells it to reload the CYBIS subsystems.

Lesson ipedit, option g, has the list of “required master files”. Those are the ones expected to be there. A mismatch isn't fatal, but a bunch of things complain if they don't match. You can either correct a mismatch by changing what masterfiles are attached, or by editing the list through that ipedit option, or some of each. Then a restart should show the corrections.

Control-] toggles trace mode on and off; the status bar at the bottom shows “Trace” if it's on. The trace file is ptermxxxx.trc in the install directory, where xxxx is the process ID number. Pterm keeps adding to that file during the entire run, so you can toggle trace on and off repeatedly and still get just the one file.

“Development mode” is a flag that controls a variety of things. This system is in development mode. It's a match of the system ID (SID in the config file) against a table in deck msubs (at ndevsys). If you want to pick a new system ID you may want to add the chosen name there. The currently used “CYBDEV” is already in the table and is a perfectly fine generic “CYBIS development” name.

This is not needed in this working system, but provides some useful background information. In X.CONSOLE. at “Lesson desired” enter BACK. That gives you the Author mode page. Enter “s” to edit the group. Option 2, c, 3, to add the user. NEXT, edit the new user (DATA from the add page, or from the c menu in the group editor). Option 4 to set allowable options. Press DATA to set all. That creates a valid Group s user you can then sign on with in Pterm. Exit CONSOLE by pressing the following keys in order ‘[‘, ‘]’ and ‘x’. Further users can be added via Pterm after logging in using that first username.

In lesson operator, option c shows the actually used master files. Lesson ipedit is where you see the required list - they are expected to be the same. More precisely, the set of “master” and “general” packs is expected to match. But if they don't, you can still do things, and in particular file operations. The reason for the warning is that you might find yourself recreating a file which is actually on a missing pack, so if you fix the missing pack issue you now have two files.

The difference is that “general” type master files are available for file allocation through accounts. The master type master files are not - you can only put files there through “operator” by explicitly asking for a specific master file to be used. Both types contribute to the default file namespace (while binary and backup packs do not).

This is not needed in this working system, but provides some useful background information.

If you can't get ipedit to run, another option would be to manually edit the parameters common in file “sysfile”.

From X.CONSOLE in author mode, enter sysfile then NEXT. Keep entering + until you see the block name iparams. Enter the letter to the left of that name, then NEXT to edit and then 1 to change/inspect common. For example to change the list of master files required, press + until you see master file names show up. I see those starting at word 45. Enter a to set data entry mode to alphanumeric; o for octal. Once you see an entry to change, enter e for edit mode; it asks you for the word number and the new data, then advances to the next line so you can keep adding values. I'm not sure if the entries have to be together (no blank lines in the middle). If you see a master file name you don't want, just blank it out (octal entry mode, new value 0). If you need to add a name, alpha mode is easiest (add it to the end or into an empty slot in the middle of the list). To find a block by name type x.

“Site” refers to either “physical site” or “logical site” - usually the latter. A physical site is simply the 32 stations sharing a common site number (all but the lower 5 bits of the station number). That term comes from “site controller”, a device used in the old (pre-ASCII) PLATO communication system to drive 32 terminals from the TDM signal broadcast from the central system over a TV signal.

A “logical site” is a collection of terminals belonging to a given organization. It has a name, and an ECS allotment. Originally, that's about all there was to it. The “E” option from Author Mode shows ECS usage by the currently logged on terminals in the site. Lesson “site” is the site manager tool, it allows you to see more things, and also perform operations like send a message to a terminal on the site, or force a user off (this is called “backout”).

Logical sites are defined by a system option. In lesson site, SHIFT-DATA gets you there. Option “a” lets you see the logical site assignments for the terminals in a given physical site (i.e., 32 terminals at a time). Option “c” gives the logical site numbers (which is how option a shows assignments), site names, and current ECS allocation.

The “logical site access controller” (LSAC) feature was developed in response to the need of site managers to police the site users better. In particular, at CERL there tended to be a lot of game players, and their usage might interfere with the intended use (educational programs etc.). The LSAC is a program that can be used to verify that someone is allowed to log on right now, or later on, once they are logged on it can be used to check that they aren't doing stuff they aren't allowed to do right now.

CYBIS as received originally was configured to automatically drop the user into a default lesson or more correctly into a “logical site access controller”. The following describes how I disabled this: Start lesson “site”, SHIFT-DATA for system options, option “e” for “logical site lesson table”, enter your site name, then clear out the entries shown there.

Group “s” is one of the privileged groups. Others are “p”, “pso”, “o” and “m”. Groups “s” and “p” are intended for development system staff, “o” is for system operators, “pso” is for the user support team (the ones who answer questions from regular users). Group “m” was used only at CERL, I believe, by hardware people.

The specific privileges vary. Users of group s you can think of as superusers, and group p has close to the same privileges. Group o enables only privileges related to system operations – things like startup and shutdown. Group pso enables privileges needed for user support. On this CYBIS system, only groups s and author exist, but that should be sufficient.

In PLATO, “account” is a file space management concept. PLATO files (lessons and other files such as groups or datasets) are created explicitly and then their content is manipulated. You don't create or delete files as part of normal program operations, unlike most other systems. When you create a file, you chose its size, expressed in “parts”. A “part” is 7 320-word blocks (35 NOS disk sectors). Files can have 1 to 18 parts, except datasets and namesets which can be up to 63 parts. (A “dataset” is basically a binary data file made up of fixed length data blocks - the record size is selected at creation time. A “nameset” is an indexed file - records are arranged in record chains identified by a key, the “name”.)

An “account” is used to delegate space management. The account owner is given some number of parts (by the system staff), which are allocated to some named account which lists that owner. The owner, or others who have been given access to the account, can then create or otherwise manage files within the space limits given to the account.

Lesson “operator” is a system tool which lets system staff manipulate files for any account.

An account is a file space management and file ownership concept. It isn't a namespace. (That was considered as a further evolution but was not implemented) So groups, like any other file, are system-wide in the sense that all you need is the name to access it. (This applies to general and master packs, not backup packs.) But every file, groups included, belongs to some account, and its file space (number of parts) is charged against the limit of that account, the file can be controlled (access changed, renamed, or deleted) by the account manager of that account, and so on.

Lessons accounts, SHIFT-DATA for System options, option ‘b’ for account summaries/logs/file information, ‘1’ for List of accounts.

A “system backout” means forcibly logging off all terminals. That process is done roughly by pretending shift-stop is being pressed on all the logged-on terminals. This allows the currently running lessons to do their clean-up, including stuff like writing ECS to disk.

Normal system backout starts with a notification message to all logged-in terminals, giving them 60, 30, 10 second warning. Immediate backout skips the warning phase. The correct shutdown procedure is to run system backout (immediate is fine if you don't have others logged in), then on the console under DSD K,MAS1. followed by K.STOP.

In lesson notes, shift-data for system options (this isn't mentioned on that display), then option ‘h’. How do I print anything?

“R” at author mode (or directly lesson “prints”). For regular users, that gives you the printout request page. For system users, it shows the pending requests. SHIFT-BACK goes to the printout request page, but there's an extra option “shift-data to print a single file”. Option “f” is “print log maintenance”. There is also various setup stuff, “c” for the printer table, and “e” for the available print types and the corresponding submit decks.

Printing a file submits a batch job that runs the appropriate printing program, for example “tprint” to print a lesson. The submit decks are in file “prtsub”, so you can look there and find the source blocks containing the decks that will be submitted for the given print type.

There are some system settings on user records in the group editor which relate to NOS job submission. Check “special options”, batch jobs should be “enabled” and a NOS user name set. Mine is set to “plato”.

With X.CONSOLE. there is a distinct author/normal mode. You get from normal to author via BACK. The distinction author/normal doesn’t exist in Pterm sessions.

The “lesson desired” page is specific to the console. It is generated in the CONSOLE COMPASS code. It doesn't exist for other terminals.

On the author (system) mode page, shift-stop logs you off, that's true for CONSOLE as well as any other terminal. That produces “press NEXT to begin”. On the console (but no other terminal), BACK from that page gets you to “lesson desired”.

SHIFT-DATA from author mode shows all of them. For example ‘A’ is Aids (“INFO”), ‘Z’ is alarm, ‘E’ is ECS allocation. And ‘F’ is the lesson catalog.

No, a “data set” and a “data file” are entirely different. A data file is a log; a data set is a binary block data container. Each has its own editor, which allows you to view it in a manner meaningful to that kind of file.

For example I start the Avatar game with 2avat, but I have to prefix it with a space otherwise it executes the 2 shortcut. Why not just call it avatar?

The convention is that lessons starting with 0 are “published lessons”, and then some got names starting with 1, 2, or 3 for special purposes. I'm not sure why the Avatar ones start with 2, but we got them that way. The “2” shortcut only applies to system staff, so normal users don't notice this annoyance.

The reasoning is that non-system staff is subject to naming rules when creating files (“accounts” enforces these). One is a length limit (no 10 character names, I think). The other is 2 characters minimum, or maybe 3, and the first two must be letters. So file names that have a digit in the first or second position are essentially reserved names. Originally a whole bunch of system files were created with ordinary names, blocking those from general use. At some point the s0 convention was put into place to allow new system files to be created that could not conflict with user-owned file names.

Having to type DATA (Ctrl-D) to invoke a lesson is counter-intuitive. NEXT drops you into the editor. It would make more sense the other way around. Yes but remember that DATA on the PLATO keyset is a dedicated key, just like NEXT. So it's no harder to type one or the other.

Use lesson operator option c (master files on disk and space left).

When no master files is specified at creation they are allocated to the master file of type General with the most free space.

How to edit a lesson which starts when I enter NEXT after the lesson name? Edit or inspect it by typing “edit”, then the lesson name and NEXT to edit or LAB to inspect.

Lesson aids (info) is the documentation to use to learn Tutor. There's also Bruce Sherwood's text book, you might find that useful. Once you get past the basics, when reading system lessons like accounts or plato, you'll encounter commands not documented there. Those are system commands (commands accepted only in lessons listed in the “system lesson” table). The documentation for system commands lives in lesson “sysaids”.

It is similar to the #include in C. It is used to include lesson components from other files.

Normally a use command names blocks, and the lesson referenced is one of the “associated files”. In system lessons, a different form of use is allowed that explicitly names the file, rather than relying on the associated file name. That case applies if the use “lesson name” is set to “multi-lesson”.

In system lessons the “use” command refers to another lesson and a source block (by name) in that lesson file. It includes that text into the referring lesson at that point, like #include. The use command can have one argument (a block name) or two (lesson, block). For the single argument form, the lesson name is the one given on the “associated files” page of the directory information

Unlike C practice, use often brings in executable code (think of it as library code) because Tutor doesn't have object libraries the way Unix does.

Various Tutor operations (common, use, jumpout and attach) that refer to another file require that the two files have matching codewords for the code related to the operation.

To inspect or change the codewords edit the lesson, open block a and the select option c for Codewords.

A bit of notation: a word in hyphens (like -use-) means the Tutor command of that name.

You can see them if you edit the account (e.g. “system”) and press DATA twice. But to set those flags, you run lesson accounts, SHIFT-DATA for System Options, a for Edit/Inspect, 1 for Edit, now enter the account name (e.g. system), LAB for Lesson Access and 1-50 NEXT to enable all. Press BACK repeatedly to exit.

The normal rule is that SHIFT-STOP while editing a lesson forces it to be recondensed. If someone is using (running) the lesson, you will be told and have to elect to kick them out, or cancel the condense. By special rule, SHIFT-STOP while INSPECTING recondenses the lesson also only if you're signed in using a system staff group (s and probably a few others). That's useful because a lot of system lessons are set up to prohibit editing, and this way you can force a recondense even without edit access. That applies also to other non-editable lessons; the published lessons are typically set up that way also.

The way the condensor works, even if there are errors, it produces a binary. That may be good enough, or not. There is a “reserved word” - essentially a predefined constant - named “zcondok” that is true (-1) if the condensor was happy, false (0) if not. Incidentally, most reserved words have names starting with “z” as a way to avoid name clashes, though some (older) ones don't.

Often you can hit SHIFT-STOP to exit into author mode and then NEXT (by itself) to edit the lesson you were just in. Alternatively, you can use another terminal and lesson “site” to see what lesson your terminal is in.

A micro table is related to text entry. A micro table is a table of strings, which are mapped to “micro” keystrokes: control/m then another key. Think of it as somewhat like alt or control codes, except that “micro” is a prefix. Micro tables may for example be used to supply a Hebrew keyboard, or for convenient editing shortcuts. Typically, they are used when running a lesson (via the “micro” command). But you can also set up a micro table to be loaded whenever you edit a lesson. That is configured via one of the lesson information pages, accessed by DATA from the block directory display. (“Associated files”).

A “font” is another thing that can be loaded - those are the terminal programmable characters. You might see that used as an associated file in lessons that use other character sets, for example Hebrew or Russian language lessons. In either case, if the load fails, you get an error message. It doesn't interfere with editing, and has no effect on running the lesson. It just means that whatever convenience the author intended with that associated file isn't available.

It performs a similar role to Unix CRON. For details see the Plato Operator Guide.

TUTOR defines three sets of “variables” - CM resident data the lesson can manipulate. One set is “student variables”, 150 words. Another is “common”, 1500 words. The third is “router variables”, 50 words. They have builtin names n1-n150, nc1-nc1500, and nr1-nr50 respectively if you want to interpret them as integers, or v1-v150, vc1-vc1500, and vr1-vr50 to interpret them as float. “Router variables” are only available in “router lessons”. Student and router variables are preserved from session to session in the student record on disk (in the group) if the user type is “student”, but not otherwise.

In general, lessons use symbolic names for variables, which is done with the “define” command. You can see those at the start of a lesson, or in blocks referenced by use commands near the start. There are also “segment” variables - those are arrays defined as bitfields (think of them as somewhat like a VFD statement). There's is a lot of detail in Tutor command define - study AIDS for more information.

A common is a chunk of disk (the blocks of the given name in a lesson). When in use, it's copied into ECS. Changes are “checkpointed” (written back) to the disk copy at times. And when a lesson wants to manipulate common data, it normally brings it into CM (into nc variables with -comload-). There are some exceptions: the -transfr- command allows writing directly to the ECS copy of common or storage, which is useful for some special purposes. One example is moving large blocks of data, larger than can conveniently be manipulated as nc variables.

A similar idea to common is “storage”. That's also a chunk of ECS, swapped in/out using -stoload-(just like -comload-). The difference is that “storage” is private, not shared, and anonymous (not from disk). It's used when you need a lot of data, more than fits in the 150 student variables. It can also be used for I/O buffers, especially in system lessons. Remember that CYBIS disk I/O is to/from ECS, so storage acts as the ECS buffer for disk I/O.

Text type blocks (source, text, listing) are treated as individual blocks of 320 words. All other block types are referenced by name, when created you are asked for the desired length (if applicable) and the system then creates that many consecutive blocks with the given name. So, for example, a 900 word common takes 3 blocks. Editing any of the 3 has the same effect - it simply means that you're editing that common. Which block you named when you started the common edit makes no difference. The same applies to other block types that can be multi-block constructs, such as charsets.

Use the “pf” program. It is documented in lesson “nosaids”.

In lesson notes press the undocumented SHIFT-DATA key to get to Notes System Options and then select h for Edit the Notes Index. Make any changes as required (Help is available) and then use LAB to install the new version.

Lesson plato is the CYBIS login screen. To make changes you MUST use the new lesson mechanism. So if it doesn't already exist, copy “plato” to “nplato” using lesson operator (option f for File options and then 5 for Make a copy of a file). Try nplato to see that it works.

You just execute it as a lesson, and run through the normal sequence. There's one difference: in standard PLATO (though not, I think, in the CYBIS version) during login you have to press SHIFT-STOP after the group name. This foils fake login programs, because they end up being aborted by that keystroke before they can prompt for the password. This works because lesson plato is one of a small set of system lessons that are configured to treat shift-stop as a normal keystroke that they can act on.

However, nplato is not such a lesson. So the convention is that, while testing, you press SHIFT-LAB instead. When you run nplato, you'll note a * in the upper right corner. In general system lessons are set up to do this when you run the n version.

So you log in normally to your group s signon, then run nplato to test your changes. If it succeeds, you'll be logged in but it will drop you into the author mode page of “nedit” (the new version of “edit”). SHIFT-STOP at that point will sign you off. If while running nplato something goes wrong, you can hit SHIFT-STOP and it will abort. Depending on where you were, this may drop you back to the author mode page, or it may leave you signed out (if so, sign back in). See below under How to debug lessons for more information.

For debugging, you might find “term-step” helpful. It's a bit clunky but still valuable. AIDS has some info, and it has (of course) help built in. The way it works: at any prompt, you can press the TERM key and enter “step”. Alternatively, at any point in the code where you want to start step mode, use the command -step on-. This will erase the bottom two lines of the screen and give you the current unit, command, and source line. Pressing NEXT will step one command. You can also examine variables. BACK (or SHIFT-BACK?) exits step mode, as does the command -step off-. This doesn't have nice stuff like breakpoints, or the ability to step over subroutines (-do- commands) but it's better than nothing.

To create it, edit account system, file options, create a file, option d (“Personal notes file”), then enter the group name, masterfile (NEXT to have the system pick one), then it asks for space parameters. Those can be changed if needed, so for now some placeholders would be 20 users, 1000 notes total.

There are two key maps. The original one is used initially; the other one is enabled if the terminal supports XON/XOFF flow control and answers to that effect when the host sends an “enable flow control” echo code (echo 0x52). The host knows this was done because the reply is 0x53 rather than the default 0x52. The two key maps are largely the same; the differences are in the codes for Access (the “square” key), SHIFT-SUB, TAB, SHIFT-HELP, SHIFT-STOP, SUPER, and apostrophe. So if the wrong key table is being used, or if the two sides are not in agreement, SHIFT-STOP would indeed be affected but stop would work. XON/XOFF must be disabled in your terminal server program. Note that you also need two stop bits otherwise the IST II or III firmware download fails (or is unreliable).

PLATO always had an “echo” output command, which tells the terminal to send back an “echo key” with the specified low order bits in it. As a way to get status or ask for stuff in an upward compatible way, various specific echo data values were given specific meanings, and the various interesting reply values are all encoded as echo key responses with a value different from the request value. The result is that a terminal which doesn't understand the request simply treats it as a plain echo and replies with the data that was sent.

So, for example, enable flow control is echo code 0x52. Reply 0x52 means not supported (the terminal simply echoed the value). Reply code 0x53 means “flow control supported and I just enabled it”. Similarly, there are terminal type queries (0x70) - reply 0x70 means the terminal doesn't know that query, which makes it a PLATO IV (original Magnavox) terminal, while other values refer to one of the many different microprocessor based terminals.

At CERL, the system was both a production system and a development system. The way this was handled is through “prime time” and “non-prime time”. During prime time the system ran the tested “good for production” version, and was supposed to be up at all times without interruptions. Non-prime time was for running new test versions; ideally that would be pretty stable as well but there weren't guarantees. Normally the current non-prime version would migrate to prime status weekly.

The prime time version of PLATO was on the deadstart tape. The non-prime time version was loaded from permanent files, so developers could reassemble just one component (say, FRAMAT), run a backout, and reload the non-prime version. For reasons I never learned, the non-prime time version was called “GOGO”. Given that deadstart is so fast on DtCYBER, getting the GOGO version to work was not even attempted. At CERL, with slow tape drives, it certainly was.

CYBIS has a list of “system lessons”. Each entry has a set of flags associated with it to say what specifically that named lesson can do beyond the normal things.

The system lesson table is manipulated by lesson “s0syslst”. Option 1 gives the list of system lessons by name (the standard list), while option 4 lets you see the local (installation specific) additional system lessons. The “n” lessons are not explicitly listed as their own entry; instead they inherit the attributes of the regular entry, if that is enabled. Consider the settings for “edit”:

The main one is “sys” which says the system commands are enabled. The other flags add some additional capabilities that are not given to every system lesson. For example “s1p” means the - stop1- command is allowed, which lets the lesson treat SHIFT-STOP as a normal key it handles rather than as the “abort” key. The “wrt” flag enables -writecm- and -writecs- commands. “mas” enables - masreq- commands. For example, “edit” and “plato” have “s1p” set but not “mas”; lesson “console” has “mas” set so it can ask for console display information, but not “s1p” because it doesn't want to handle shift-stop keys.

Also, the “sysnv” flag means: if you're on a “development system” (which cybdev is because its name appears in the development systems table in the source code) then “nedit” is also a system lesson; otherwise it isn't (for some reason we don’t have the sysnv flag).

You can create your own system lesson for experimentation. Typically you'd set “sys” but not most of the others; you can add the more magical flags if needed. When you make changes to the local system lesson table, you have to use SHIFT-HELP from the main menu to put those changes into effect (by reading them into ECS where the condensor finds them); if you don't, you won't see the changes until the next restart.

Note that you can't change the flags for the standard entries like “edit”, only the local ones. The standard table is in the sources, in deck “sysless” but it's probably not a good idea to mess with it. For testing changes to edit, the normal practice is to modify nedit. If you want to make a private copy so you aren't touching nedit - perhaps worthwhile if you're doing drastic stuff - make a local system lesson entry for that copy, with the same flags as the original with the possible exception of s1p. (The reason for not setting s1p is that errors in such lessons may leave you with no reasonable way to abort, while having s1p off means shift-stop works normally.)

The text entry features are invoked by the CYBIS function keys EDIT (control-E), “square” (control-Q) and COPY (control-C).

In general, when you're entering text (at an “arrow” prompt, the character that looks like a hollow greater than sign) EDIT and square are available. COPY often is but not always. They work like described below.

If a “copy buffer” has been set, COPY fetches and displays the next word from it, SHIFT-COPY the entire remaining copy buffer, and Square the next character. Typical usage of the copy buffer is for the previous content of the line when you're doing a replace command, the contents of the previously inserted line when you're inserting multiple lines, etc. The specifics vary, but in many cases, if there's an obvious interpretation of COPY for that particular context, it will be there and have that meaning. For example, when renaming files in accounts or operator, COPY would give you the old name. When creating files, if you're doing several in a row, COPY will be the name of the previously created file. And so on.

EDIT is standard (except when explicitly disabled, which is rare). It's a mode toggle. Initially, if you've entered some text and press EDIT, the text is copied to the edit buffer (internal to PLATO) and erased. Subsequent presses of EDIT then retrieve the next word, SHIFT-EDIT the rest of the edit buffer, and Square the next character. So this is the tool if you're entering a line of text and notice a typo earlier in the line. It's not quite the same as cursor editing of the partial line the way modern systems do, but it's a pretty effective substitute. This is fully documented in the lesson editor help.

An important type of user is “author”. That looks just like administrators except that you don't get the system options. When you log in you get the “AUTHOR MODE” page (same as “SYSTEM MODE” except for the label). And just like admins, authors can execute lessons (name then DATA) as well as inspect (name LAB) or edit (name NEXT). For the latter, they need access privilege to the lesson in question. System admins have access to a lot of stuff; regular authors are more limited. Some standard files are open inspect, lesson “library” is an example because its purpose is to show sample code.

Some authors may have additional privileges. An admin might create an account, and make a given author the account owner. That author is thereby delegated the ability to create files of various types, including groups, lessons, and other stuff. Other authors who want a lesson to work on would request space from an account owner; typically one of the system admins. (At CERL it would be the account owner for the account related to your academic department.)

Regular authors are author type records in groups whose names are not among the special ones. The special names are s, p, o, pso, coserv – you can see the list in the documentation for the -check-command in sysaids. Other groups are normal. So to create a normal user record, start by creating a normal group (say “users”), then create an author record in that group.

Record types other than author are probably not that interesting. They are created in a similar way, though, in non-system groups. (System groups don't have non-author records in them as normal practice, except for special cases that I can't remember.) A student is either locked into a given lesson whose name is set in the student record, or in a “router” which is a lesson variant whose task it is to “route” the student through a sequence of lessons. The student record stores lesson state; when a student signs out and back in, at least part of the last activity is preserved and you continue where you left off (more or less, subject to what the lesson wants to do).

There is a standard router provided by the system that is driven by “instructor files” as a way to set a lesson curriculum. Those files are normally edited by people with instructor records. For details check lesson AIDS (INFO).

Finally, a “multiple” is like a student record, except that unlike all other record types, it can be concurrently in use at multiple terminals. Because of that, a multiple doesn't preserve the execution state as a student record does; it always starts at the predefined lesson set in the record. Multiples are often used for demos of various kinds. An example is user “diag” in group “m”. After signon this user directly goes to lesson “diag” which is a set of terminal tests including various test displays (note that user diag and group m are not implemented on this version of CYBIS but the diag lesson exists and is functional).

Account names are limited to 7 chars max, groups to 8 chars max. All file names must be alphanumeric, starting with a letter or digits 0-4. (But digits are used for specific purposes. I would avoid them entirely for groups and accounts).