USER/CANDE account maintenance

46 views
Skip to first unread message

Richard Hamilton

unread,
May 28, 2017, 6:44:48 PM5/28/17
to retro-B5500
Ok, I'm looking at the source for the program used to create accounts, e.g.
B5500-XIII-Release/SYMBOL2/SYMBOL/USER.  It seems that the following are true:

A "USER" can be up to seven characters, likewise a password (I had originally created my usual seven character account, but with an eight character password; there was no evident complaint, or if there was I never saw it; but it didn't work; remaking the user with a seven character password worked fine...although the 1st try password also had a digit in it, which the 2nd didn't...so I'm not yet 100% on the limits of what works).  A "NAME" will be truncated to 15 characters (mine was my first and last name, which is 16 characters, so I saw the last character left off).

There are potential commands $NEW (initializes file if necessary, I gather - if used, must be 1st card), $USER (parameter names and values, one to a card, follow), and the following that I haven't figured out yet:

$OPTIONS
$PRINT
$REMOVE
$LINK

I gather $REMOVE takes a user name on the same line, probably quoted, although I haven't tried.  Nor have I tried any of the others; I'd be careful with $OPTIONS and $LINK for now, $PRINT may be harmless.

It seems possible to control which CANDE verbs and which compilers are allowed for an account to use; I think that's the VERBS and LANGUAGE parameters; since each has multiple possible values, I suppose one repeats VERBS or LANGUAGE cards; either can be NONE (to clear the permitted values before setting a few of them?).  Not 100% sure of the usage there.  In addition to NO CHARGE, it seems possible to either set a fixed charge code for an account, or request one at login time.  One can also set PHONE and TIME.  Perhaps the latter is a limit on time logged in and/or CPU time used?  Not sure yet.

It doesn't help that I'm neither familiar with ALGOL (although the similarity to Pascal is enough to have a general idea what's happening), nor with the conventions of the system, nor have I looked at any of the code before.  Still, it's not too hard to figure out some things for which actual documentation may be lost, unavailable online, or at least very hard to find.

Oh, and the file is exclusive use, so CANDE can't be running when one does account maintenance (the batch job for maintenance will wait until the CANDE/TSHARER process is terminated).

Is there a proper way to shut down CANDE/TSHARER, or is the only thing to just DS it?  That works, but it feels like there might be a better way (I think newer OS versions have a proper way to shut down CANDE).

Paul Kimpel

unread,
May 29, 2017, 10:34:48 AM5/29/17
to retro-B5500
You might find the following document useful:


The discussion on USER/CANDE begins on page 1-37, but I'd recommend reading all of Section 1 if you are interested in setting up CANDE. There is also a page on the project wiki, originally written by Tim Sirianni, describing CANDE setup and operation:


Apparently the only way to terminate CANDE was to DS CANDE/SHARER (or halt/load and then not do a CE command). Note, though, that the whole purpose of the TSMCP was to run CANDE, and the memory "fence" and the timesharing (swapping) memory management scheme remained in effect whether CANDE was running or not.

Batch jobs could run above the fence with CANDE tasks by initiating them with an ?EXECUTE card (recommended), or below the fence with the MCP and CANDE/TSHARER using a ?RUN card (not recommended due to memory constraints), but the fence was still there and could be moved only across a halt/load. There was not a great deal of advantage to terminating CANDE in order to run batch work.

Like most early multi-programming/timesharing systems, the B5500 simply didn't have enough memory to realize its potential performance. I suspect that at least some sites ran TSMCP and CANDE during the day, then CM-ed to DCMCP to run batch work overnight to get the fence and swapping mechanism out of the way.

Richard Hamilton

unread,
May 29, 2017, 11:27:29 AM5/29/17
to Paul Kimpel, retro-B5500
Found the document, thanks; it's a bit easier than reading source code, esp; in a somewhat unfamiliar language. :-)

The reason I wondered about shutting down CANDE is that I have yet to find an explicit OS halt command, and if e.g. using the simh simulator, all I can do is break to its command level and exit.  I'd rather have everything quiet as much as possible before pulling the plug.

Not that I've forgotten that v7 Unix didn't have a halt command either; one just brought it down to single user, synced, and dropped into the firmware monitor.

--
You received this message because you are subscribed to the Google Groups "retro-B5500" group.
To unsubscribe from this group and stop receiving emails from it, send an email to retro-b5500+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/retro-b5500.
To view this discussion on the web visit https://groups.google.com/d/msgid/retro-b5500/2d341607-9257-418a-a2fd-144f72bf46bb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Paul Kimpel

unread,
May 29, 2017, 7:35:13 PM5/29/17
to Richard Hamilton, retro-B5500

The B5500 could not programatically halt under normal conditions. The way you shut down the MCP was to press the HALT button on the operator console. There was a Conditional Halt instruction (ZPI, octal 2411) that would stop the Processor clock, but that was a no-op unless a switch on the maintenance panel was set. It was a diagnostic instruction, not one that user programs or production versions of the MCP used.

Remember that this system (starting with the B5000) was explicitly designed to run under control of an operating system. There was no operational need for a halt as on more traditional, non-multiprogramming systems of the time. User programs did not finish by halting, they finished by informing the MCP (via a COM 5), which would then deallocate their resources and see if those resources could be used by other (possibly scheduled) programs.

The B5500 could not even idle -- the control processor (P1) simply ran continuously, spinning in the MCP's NOTHINGTODO loop, responding to interrupts and sensing device status changes, until something happened that gave it, well, something to do.

It's generally safe to just shut down the B5500 MCP. It was pretty good about not corrupting itself if that happened. I usually try to get to a null mix and then do an explicit halt just before shutting down the retro-b5500 emulator. If the simh emulator does not have a way to do a manual halt, then it needs one.

 
-------- Original Message --------
Subject: Re: [retro-B5500] Re: USER/CANDE account maintenance
From: Richard Hamilton <rlha...@gmail.com>
To: Paul Kimpel <paul....@digm.com>
Cc: retro-B5500 <retro...@googlegroups.com>
Date: 5/29/2017 8:27 AM
Found the document, thanks; it's a bit easier than reading source code, esp; in a somewhat unfamiliar language. :-)

The reason I wondered about shutting down CANDE is that I have yet to find an explicit OS halt command, and if e.g. using the simh simulator, all I can do is break to its command level and exit.  I'd rather have everything quiet as much as possible before pulling the plug.

Not that I've forgotten that v7 Unix didn't have a halt command either; one just brought it down to single user, synced, and dropped into the firmware monitor.

On Mon, May 29, 2017 at 10:34 AM, Paul Kimpel <paul....@digm.com> wrote:
<snip>
Reply all
Reply to author
Forward
0 new messages