This page includes a collection of sections on administering Multics. For now, they are in no particular order and will be organized once there is a critical mass of such articles.
Follow the following example to add a new user to your Multics system. Make sure you are logged into a user on the SysAdmin project. For a brand new system, the only accessible SysAdmin account will be Repair.SysAdmin.
cwd >udd>sa>a
r 11:05 0.017 0
ec master register
Enter full user name (Last, First I.)
Full name Swenson, Eric J.
Enter mailing address
Address Room 13
Enter programmer number
Prog. number
Enter notes
Notes
Enter default project
Project ID SysAdmin
Password:
Password again:
Network Password:
User ID assigned is "Swenson".
Is this OK? y
More users to add? no
r 11:06 0.390 55
Note: You must provide some value for the Full name and Address fields. The newly created user will not be able to login until you add this user to some project. See the next section for help on how to add a user to a project.
Before you can add a user to a project, you must have created the user. See the FAQ entry on how to do that.
Follow the following example to add a user to a project. Make sure you are logged in as a user on the SysAdmin project. For a brand new system, the only accessible SysAdmin account will be Repair.SysAdmin.
cwd >udd>sa>a
r 11:16 0.016 0
ec master upmf SysAdmin Swenson
r 11:17 0.250 47
The first parameter to the upmf function (in master.ec) is the ProjectId. The second parameter is the Personid.
Note: the above command will extract the project PMF from pmf.archive, update it, convert the PMF to a PDT, and install the PDT. Then, it will re-archive the PMF in pmf.archive.
Note: new users should be notified that they should create their own mailboxes (by invoking the "accept_messages" ("am") command. This will, as a side effect, create a mailbox if one doesn't already exist. It will also enable users to send interactive messages for that single login session. Telling them how to create a minimal start_up.ec (or pointing them to the one on this Wiki) will enable them to have a better initial experience, and if you use the suggested start_up.ec, will also enable interactive messages for all subsequent login sessions. See Is there a .bashrc or equivalent for a sample start_up.ec you can point your users at.
To create a new project, and set the initial member(s) of the project, you must login to a project with sufficient privileges (e.g. *.SysAdmin). You can follow the example below, substituting appropriate values for the project name, various fields, and members. You can hit <enter> or <return> at each prompt to accept the default value. Note that in a clean system, the Other (load control group), which will be selected as the default group, is incorrectly set up, so if you use the default group (Other), you will have to fix the group. See below for details. Alternately, you can specify the System group, although that is not really a good idea, unless your new project is considered a System project.
You can also create another load control group first, and specify it here. More on this later.
cwd >udd>sa>a
r 13:34 0.899 354
ec master new_proj Multics
Creating new project "Multics".
Title: Multics
Investigator:
Inv. Address:
Supervisor:
Phone:
Account:
Requisition:
Amount: open
Cutoff date: 12/02/16 0000.0 pdt Fri
Billing name:
Billing Address:
Project Alias: type "." to delete current alias from SAT.
Alias:
Project administrators. Type "." to delete.
Administrator:
Absentee foreground cpu limit: 0
Authorization: system_low
Audit flags: fsobj=N/N,fsattr=N/N,rcp=N/N,admin=N/N,special=N/N,other=N/N,^admin_op,^priv_op,^fault,^small_cc,^moderate_cc
Segment quota: 100
Directory quota: 10
Rate structure: default
Default group: Other
System
Authorized groups. Type "." to delete.
Group:
Attributes: anonymous, bumping, brief, vinitproc, vhomedir, nostartup;
Grace: 2880
Minimum login ring: 4
Maximum login ring: 5
Maximum pdir quota: 0
Maximum foreground processes: 0
Maximum background processes: 0
new_proj: Do you wish to review the project? no
Project directory logical volume:
Enter initial list of users. Type "." to exit
Person: Swenson
Person:
Input for "Multics" complete.
daily_summary: cut 0, warned 0, total $0.00
archive: >udd>sa>a>Multics.pmf appended to >udd>sa>a>pmf.archive
r 13:35 1.390 93
Now, your new project is created, and you've added a single user to that project. To fix the Other load control group issue, do the following:
cwd >udd>sa>a
r 13:42 0.232 7
ed_mgt MGT.mgt
type c
code abs_max
abs_max 3276.0
code .
type w
type q
r 13:42 0.232 7
What you've done, above, is to fix a bug in ed_mgt when it is used to create a brand new MGT.mgt. This is done during the cold boot of Multics (and since the QuickStart is simply a freshly cold-booted system, it has the issue). The bug is that the value of abs_max defaults to 0. This is the absolute maximum number of load control units that can be consumed by the Other group. This clearly means that no one can login to that group. The above fix simply changes the value of abs_max to 3276.0. This is simply a "very large" magic number that effectively means "infinite".
Now that doesn't mean that an infinite number of users can log into that load control group. It means that "up to 3276 users can log in, but limited by other factors".
The Other load control group is "special" in that it is a catchall group. It will allow logins up to the maximum number of available load units. This is why the Other load control group has a constant of -1. If you run ed_mgt after you make the above change, and look at the Other load control group, you will see something like this:
ed_mgt MGT.mgt
type p
EOP
Other -1 (abs max 3276.0 + 0/0)
int wc: 1 1 1 1 1 1 1 1
abs wc: 1 1 1 1 1 1 1 1
absentee: max min pct
1000 0 100%
absentee allowed
type
That "-1" is what lets it consume all available load control units.
While any project can support anonymous logins, a typical convention is to use the Guest project for this purpose. The Guest project does not exist on a new (cold booted or QuickStart) Multics system. In order to create the Guest project, you proceed just like you were creating any other project. However, usually, you want to place some limits on the number of Guest logins. The Multics way of controlling the number of logins (interactive or absentee) of an account is through "Load Control Groups". Before creating the Guest project, it is recommended that you add a load control group, called "Guest", for the Guest project.
First, login as a user in the SysAdmin project. Then, execute the following commands:
cwd >udd>sa>a
r 16:59 0.096 7
ed_mgt
The ed_mgt command uses a prompt of "type " to let you know it is ready for a command. For example:
ed_mgt
type
Issue the a command to add a new load control group. Name the group "Guest" and specify, for example, "4.0" load control units for this group.
a Guest 4.0
You will once again receive a type prompt, do which you should reply with the w and q commands (which write the changes and quit the ed_mgt program):
Your session should look like this:
ed_mgt
type a Guest 4.0
type w
type q
r 17:29 0.111 15
Next, install the new MGT (Master Group Table) with this command:
install MGT.mgt
r 17:30 0.106 1
This safely copies the MGT (MGT.mgt) to the >system_control_1 directory, ensuring no collisions with other administrators.
Next, create the Guest project.
ec master new_proj Guest
You will be given a series of prompts, all of which you can just accept the default (by typing <return> or <enter>) UNTIL you see the prompt for "Default group:". For that prompt, enter "Guest". Then, continue typing <return> or <enter> until you see the question: "Do you wish to review the project?":
The prompts will look like this:
Creating new project "Guest".
Title:
Investigator:
Inv. Address:
Supervisor:
Phone:
Account:
Requisition:
Amount: open
Cutoff date: 03/22/17 0000.0 pst Wed
Billing name:
Billing Address:
Project Alias: type "." to delete current alias from SAT.
Alias:
Project administrators. Type "." to delete.
Administrator:
Absentee foreground cpu limit: 0
Authorization: system_low
Audit flags: fsobj=N/N,fsattr=N/N,rcp=N/N,admin=N/N,special=N/N,other=N/N,^admin_op,^priv_op,^fault,^small_cc,^moderate_cc
Segment quota: 100
Directory quota: 10
Rate structure: default
Default group: Other
Guest
Authorized groups. Type "." to delete.
Group:
Attributes: anonymous, bumping, brief, vinitproc, vhomedir, nostartup;
Grace: 2880
Minimum login ring: 4
Maximum login ring: 5
Maximum pdir quota: 0
Maximum foreground processes: 0
Maximum background processes: 0
new_proj: Do you wish to review the project?
At the "Do you wish to review the project?" prompt, answer "no".
You will be prompted with:
Project directory logical volume:
to which you can reply with <return> or <enter>.
Next, you will be asked for a list of initial users. Here, in order to allow anonymous logins, enter a Personid of "*". At the next "Person:" prompt, type "." followed by <return> or <enter> to end the list.
Enter initial list of users. Type "." to exit
Person: *
Person: .
Input for "Guest" complete.
WARNING 14, SEVERITY 1 IN LINE 7
Anonymous user had no "homedir" statement; assuming project directory.
WARNING 15, SEVERITY 1 IN LINE 7
Anonymous user has no password specified.
WARNING 16, SEVERITY 1 IN LINE 7
Anonymous user has no initial procedure specified.
daily_summary: cut 0, warned 0, total $0.00
archive: >udd>sa>a>Guest.pmf appended to >udd>sa>a>pmf.archive
r 17:06 2.771 73
Do not worry about the warning messages. They are expected.
Now, you will have a Guest account that supports anonymous logins.
Login as a user in the SysAdmin project. Then execute the following commands:
cwd >udd>sa>admin
ec master chpass <username>
Password
<enter password>
Password again:
<enter password>
By default, Multics enforces an hour inactivity timeout. If a user does not interact with Multics for more than 1 hour, he/she will be automatically logged out. There is a warning message displayed to the user 5 minutes before this automatic logout.
If you wish to increase the inactivity timeout period (you can't disable it), you can follow these procedures:
ed_installation_parms >sc1>installation_parms
The program will respond with the prompt:
type
You can see the current inactivity timeout by typing:
p inactive_time
And you will get a response similar to this one:
inactive_time: 3600 sec.
type
You can change this value by typing something like:
c inactive_time
And you will prompted with:
inactive_time (seconds):
Enter a value in seconds, such as:
7200
Then save your changes and quit with:
type w
type q
Note that Multics doesn't support per-user or per-project inactivity timeouts. This is a system-wide parameter.
If you wish to force-logout a user, which is called, in Multics, "bumping" a user, you can use the operator "bump" command.
On the operator console, you can type: bump <personid>.<projectid> <time> <message> for example, bump Swenson.Multics 5 "logging you out in 5 minutes".
As an administrator, you can use the command send_admin_command sc_command bump <personid>.<projectid> <time> <message>. The short name for send_admin_command is sac.
Using send_admin_command sc_command <command> is a way for an admin to execute arbitrary operator commands.
When you cold boot a new Multics system, its name will be "Installation and location". Clearly, this is not what you want. You may also not like the choice you (or someone else) originally made for the so-called installation_id. The installation id shows up in many places, but the most prominent is when you connect to Multics:
Multics MR12.6d: Installation and location (Channel d.h000)
Load = 5.0 out of 90.0 units: users = 5, 12/01/15 1121.4 pdt Tue
To change the installation id, make sure you are logged in with sufficient privileges (such as an account in the SysAdmin project). Then use the ed_installation_parms prorgram like this:
ed_installation_parms >sc1>installation_parms
The system will respond with:
Hit QUIT and use "program_interrupt" to return this request loop.
type
Here, you can use the p all command to see all the parameters. Or the p installation_id to see the current setting of this installation parameter. You can change the value with the c installation_id command:
type c installation_id
Installation id Gold Hill Multics
type
To check the value, do this:
type p installation_id
Installation id Gold Hill Multics
type w
type q
r 22:01 0.067 2
Now, when you logout and log back in, you will be greeted with your new installation id:
logout
Swenson.SysAdmin logged out 12/01/15 1301.7 pdt Tue
CPU usage 3 sec, memory usage 7.7 units, cost $1.76.
hangup
Multics has disconnected you
Multics is now listening to this line
Multics MR12.6: Gold Hill Multics (Channel d.h000)
Load = 5.0 out of 90.0 units: users = 5, 12/01/15 1301.7 pdt Tue
While historically, Multics Personids were either a user's last name, or more frequently, a combination of initials and last name, it was also possible to have an alias. An alias might be user's initials or something easier to type and all lower-case. With an alias, you can login with the shorter alias, rather than your possibly difficult-to-type Personid. Although not specifically tied to aliases, a common practice was to also get the alias as an added name on your home directory.
To add an alias for a Personid, make sure you are logged into a privileged project, such as SysAdmin, and use the following example as a guide:
cwd >udd>sa>a
r 13:34 0.740 97
ec master chalias Swenson ejs
Alias:
r 13:34 0.402 33
The first parameter to the chalias function (in master.ec) is the Personid. The second is the desired alias. The command displays the old alias.
If you'd like to add the alias to the home directory, use the add_name (an) command, as follows:
an >udd>SysAdmin>Swenson ejs
By default, projects are setup to only allow one login session at a time. You can easily change this by giving the project the "multip" attribute.
Without this attribute, a second login attempt might result in a login message such as the following:
Multics MR12.6: Gold Hill Multics (Channel d.h002)
Load = 6.0 out of 90.0 units: users = 6, 12/02/15 1342.3 pdt Wed
l ejs Multics
Password:
Attempt to log in Swenson.Multics from ASCII terminal "none".
Swenson.Multics already logged in from ASCII terminal "none".
Please try to login again or type "help" for instructions.
You can, of course, login to a different project, but you will be warned that this is what you are doing when you login:
Multics MR12.6: Gold Hill Multics (Channel d.h002)
Load = 6.0 out of 90.0 units: users = 6, 12/02/15 1342.3 pdt Wed
l ejs sa
Password:
Another Swenson (Swenson.SysAdmin) is now logging in from ASCII terminal "none".
This is your 2nd interactive login instance.
You are protected from preemption.
Swenson.SysAdmin logged in 12/02/15 1344.8 pdt Wed from ASCII terminal "none".
Last login 12/02/15 1333.9 pdt Wed from ASCII terminal "none".
r 13:44 0.792 24
In order to give a project or a specific user on a project the multip attribute, you have to update the project in the SAT as well as the project's PDT. It is not enough to do one or the other.
To update the Project in the SAT, follow similar steps to these:
cwd >udd>sa>a
r 14:56 0.044 5
edit_proj Multics attributes
Attributes: anonymous, bumping, brief, vinitproc, vhomedir, nostartup;
multip
r 14:57 0.078 2
install smf.cur.sat -a
r 14:57 0.029 2
Note that we didn't use the master.ec this time, but the new_proj command directly. We gave edit_proj the project name (Multics) and the field we wanted to update (attributes). edit_proj displayed the existing allowed attributes for the project and then prompted for changes. Typing multip added that attribute to the list (it didn't change any of the other attributes). Because we didn't use master.ec, we have to manually install the updated candidate SAT (smf.cur.sat).
You can verify that this change was made by doing the following:
print_sat >sc1>sat Multics
projectid: Multics;
/* state: 1; */
projectdir: >user_dir_dir>Multics;
/* pdt_ptr: 554|0; */
maxprim: 32767;
/* n_users: 1; */
attributes: anonymous, multip, bumping, brief, vinitproc, vhomedir, nostartup;
authorization: "system_low";
/* days_to_cutoff: 366; */
/* pct_balance: 100%; */
/* dollars_to_cutoff: $0.00; */
ring: 4,5;
group: System;
grace: 2880;
pdir_quota: 0;
max_foreground: 0;
max_background: 0;
abs_foreground_cpu_limit: 0;
r 15:00 0.069 2
Note the multip attribute is now allowed for this project. Next, you have to update the PDT for the project. You can do that by editing the PMF with your favorite editor (emacs, qedx, ted, etc.). Change the Attrributes line (fields with initial capital letters are per-project and those with initial lowecase letters are per-user) to include the multip attribute.
PMFs for undelegated projects are stored in the archive >udd\>sa\>a\>pmf.archive. You should extract the PMF from the archive using a command similar to this (assuming you're still in the >udd\>sa\>a directory):
ac x pmf Multics.pmf
r 15:04 0.319 1
Then, edit the PMF to add the multip attribute. Here is an example PMF edited already:
pr Multics.pmf
Multics.pmf 12/02/15 1501.7 pdt Wed
Projectid: Multics;
Initproc: process_overseer_;
Grace: 0;
Attributes: vinitproc, vhomedir, nostartup, multip;
personid: Swenson;
end;
r 15:01 0.054 7
Once you have edited the PMF, convert it to a PDT, install the PDT, and put the PMF back in pmf.archive:
cv_pmf Multics
r 15:06 0.059 2
install Multics.pdt
r 15:06 0.018 1
ac rd pmf Multics.pmf
r 15:06 0.028 1
Now, you will be able to login to the project more than once, concurrently:
Multics MR12.6: Gold Hill Multics (Channel d.h002)
Load = 6.0 out of 90.0 units: users = 6, 12/02/15 1507.5 pdt Wed
l ejs Multics
Password:
Another Swenson (Swenson.Multics) is now logging in from ASCII terminal "none".
This is your 2nd interactive login instance.
You are protected from preemption until 15:07.
Swenson.Multics logged in 12/02/15 1507.6 pdt Wed from ASCII terminal "none".
Last login 12/02/15 1506.2 pdt Wed from ASCII terminal "none".
r 15:07 0.246 19
Multics supports per-directory quotas. A directory may have a specific quota, or it may get its quota from its parent directory. Each directory off of the root must have a quota. If you run out of quota, you need to "move" quota to an appropriate parent directory (or a directory with a quota) from a parent directory.
Note: Multics supports both segment quota and directory quota. We're only talking about segment quota here.
For example: Let's say that you get a record_quota_overflow error while attempting to write something in your home directory. You can check to see if your home directory has quota via a command like this:
gq >udd>SysAdmin>Swenson
quota = 0; used = 2975
r 15:54 0.013 0
The above example shows that there is no explicit quota on >udd\>SysAdmin\>Swenson, but this directory is currently using 2975 records. It presumably is getting these from its parent directory. Let's check:
gq >udd>SysAdmin
quota = 3000; used = 3000
r 15:55 0.013 0
Aha! We see that Swenson's home directory is getting its quota from >udd\>SysAdmin, which is at its maximum quota of 3000 records.
We need to give more quota to >udd\>SysAdmin. Let's make sure that the parent directory (>udd) has enough quota.
gq >udd
quota = 3790; used = 0
r 15:56 0.010 0
We can see that it has 3790 records. So without giving more quota to >udd, we can only move a maximum of 3790 records of quota from >udd to >udd\>SysAdmin. Let's do that:
mq >udd>SysAdmin 3790
move_quota: Record quota overflow. >udd>SysAdmin
r 15:58 0.020 0
Well, that didn't work. We can't allocate the maximum. Let's try 3000 records:
mq >udd>SysAdmin 3000
r 15:58 0.009 0
That worked. Let's check:
gq >udd>SysAdmin
quota = 6000; used = 3000
r 15:59 0.011 0
That should give all users of the SysAdmin project 3000 more records of quota. Since the original directory we tried to add segemnts to (>udd\>SysAdmin\>Swenson) didn't have any quota set, we don't need to move quota to it. It will just borrow from the parent. We should be all set now (until we run out of the 3000 records!)
The "crank" is composed of the daily, weekly, and disk report absentee jobs run by the system administrators. These are necessary to keep the system healthy and also provide reports for administrators.
To set up the crank, decide on the SysAdmin user who is doing to run the crank and related exec_coms. It can be anyone on the SysAdmin project.
Then, login as that SysAdmin user.
Before you can schedule the absentee jobs, you have to set up a few variables in the "value segment" (think of this as a config file that can be queried via exec_coms).
The pathname of the value segment used by the crank is >udd\>sa\>a\>sys_admin.value.
To see the current values in this segment, use these command:
cwd >udd>sa>a
r 13:24 0.051 8
value_list -pn sys_admin
abort_crank "false"
accounting_start_up_time "2015-12-22__17:36:46.203305_pst_Tue"
admin_online "SA1.SysAdmin"
crank_time "0300."
default_addr "ADMINISTRATOR"
default_dest "SYSTEM"
disk_time "0230."
log_number "0"
r 13:24 0.051 8
To set the required variables to allow the crank to run, do the following (still in the >udd\>sa\>a directory):
value_set -pn sys_admin last_diskreport "2015-12-17__22:57:20.526510_pst_Thu"
r 13:24 0.051 8
value_set -pn sys_admin last_log_time "2015-12-17__22:57:20.526510_pst_Thu"
r 13:24 0.051 8
value_set -pn sys_admin weekly_time "0400._6days"
r 13:24 0.051 8
The first two settings for last_diskreport and last_log_time configure when the crank was last run. You will get errors if these are not set, so set these to dates in the past (the above values should work).
The third setting tells the system what time to run the weekly job. In the example above, we run the weekly job at 04:00 (4AM). Note that the disk report is run at 02:30 and the crank at 03:00. Those values were already set in the sys_admin.value segment.
The crank requires the Terminals, Operator, and HFED projects to exist. If these exist already, you can skip this next step. It won't hurt to execute it in any case. But before you do, make sure that the Terminals.pmf, Operator.pmf, and HFED.pmf segments are in the >udd\>sa\>a directory. If they are not, they are likely archived in >udd\>sa\>a\>pmf.archive. Extract them from the archive, as shown below -- but only if they don't already exist -- in other words, skip the ac x pmf (Terminals Operator HFED).pmf step if they already exist in >udd\>sa\>a. Depending on what has happened on your machine before you attempt to setup the crank, the PMF files may, or may not be in >udd\>sa\>a.
ac x pmf (Terminals Operator HFED).pmf
r 13:35 0.148 34
cv_pmf (Terminals Operator HFED)
r 13:35 0.148 34
install (Terminals Operator HFED).pdt -a
r 13:35 0.148 34
ac ad pmf [segs *.pmf]
r 14:02 0.110 15
Now it is time to run the crank for the first time. This will actually not complete successfully, but will schedule the crank run for 0300 the next day. It should run successfully then.
ec master crank
ID: 10455982; 0 already requested.
>udd>sa>a>crank.absin in queue 1
sumry at end of file.
cutrpt at end of file.
daily_summary: cut 0, warned 0, total $0.00
sumry device detached.
cutrpt device detached.
system_total: range err: dayx = 0, not 1-190. set to 190
system_total: range err: qhi = 2804154368, not 1-96. set to 96
summarize_sys_log: 5 streams, 37 selectors
summarize_sys_log: Log >system_control_dir>as_logs>log from 2015-12-22 17:37:07.968223 to 2016-01-11 13:37:26.593098
summarize_sys_log: 175 messages read.
summarize_sys_log: 3 streams, 15 selectors
summarize_sys_log: Log >system_library_1>syserr_log from 2015-12-22 17:23:47.496112 to 2016-01-11 13:17:41.657665
summarize_sys_log: 561 messages read.
summarize_sys_log: 1 streams, 1 selectors
summarize_sys_log: Log >system_control_dir>as_logs>admin_log from 2015-12-22 17:25:03.502298 to 2016-01-11 13:16:43.186541
summarize_sys_log: 1942 messages read.
summarize_sys_log: 1 streams, 1 selectors
summarize_sys_log: The requested log message cannot be located. Cannot find message before 2016-01-11 13:37:27.594181
move_log_segments: At least two log segments must be present in >sc1>syserr_log>syserr_log in order to migrate one.
move_log_segments: Use of star convention resulted in no match. Listing >sc1>as_logs>log.????????.??????
move_log_segments: Use of star convention resulted in no match. Listing >sc1>as_logs>admin_log.????????.??????
move_log_segments: Use of star convention resulted in no match. Listing >sc1>as_logs>iolog.????????.??????
105 messages copied into:
>system_control_1>heals_dir>heals_log
371 messages processed,
syserr seq_num 1000179 through
syserr seq_num 1000550.
No records were deleted from:
>system_control_1>heals_dir>heals_log.
remove_registry: Use of star convention resulted in no match. >udd>sa>a>safe_registries>**.rcpr
delete_registry: Use of star convention resulted in no match. >udd>sa>a>safe_registries>**.old
copy_registry: Use of star convention resulted in no match. >sc1>rcp>**.rcpr
truncate: Entry not found. meter_data.print
truncate: Entry not found. bwchart.print
Error: out_of_bounds at b_and_w$|2253
(>system_library_tools>bound_admin_rtnes_)
referencing >udd>sa>a>today.use_totals|776206
Attempt to access beyond end of segment.
r 13:37 7.572 578 level 2
You can release that command level with:
rl
r 13:37 7.572 578
If you then list your absentee requests, you'll see that the crank is scheduled:
lar
Absentee queue 1: 1 request. 1 total request.
213725.5 crank.absin (deferred by user to 01/12/16 03:00)
r 13:39 0.097 1
Invoke this command to get the disk report doing:
ec master disk_auto
$ Following figure is total quota / current use.
557883/76140
dir: 267340/924
seg: 290543/75216
charge_disk: No logical volumes specified. Storage on all logical volumes will
cbe charged for.
charge_disk: charged 7 dirs out of 20 to 6 projects
ID: 12557720; 1 already requested.
>udd>sa>a>dodrp.absin in queue 1
r 13:40 1.425 71
Invoke this command to get the weekly job running:
ec master weekly
ID: 13024732; 2 already requested.
>udd>sa>a>weekly.absin in queue 1
save_dir_info: Incorrect access on entry. Cannot get quota of PNT.safe.pnt
save_dir_info: Incorrect access on entry. Cannot list inacl of PNT.safe.pnt
save_dir_info: Incorrect access on entry. >udd>SysAdmin>admin>PNT.safe.pnt
comp_dir_info: Entry not found. Accessing dir_info segment
(>udd>SysAdmin>admin>old.admin.dir_info).
delete: Entry not found. >udd>SysAdmin>admin>old.admin.dir_info
comp_dir_info: Entry not found. Accessing dir_info segment
(>udd>SysAdmin>admin>old.lib.dir_info).
delete: Entry not found. >udd>SysAdmin>admin>old.lib.dir_info
save_dir_info: Incorrect access on entry. Cannot get quota of PNT.pnt
save_dir_info: Incorrect access on entry. Cannot list inacl of PNT.pnt
save_dir_info: Incorrect access on entry. >system_control_1>PNT.pnt
save_dir_info: Incorrect access on entry. Cannot get quota of user_messages
save_dir_info: Incorrect access on entry. Cannot list inacl of user_messages
save_dir_info: Incorrect access on entry. >system_control_1>user_messages
comp_dir_info: Entry not found. Accessing dir_info segment
(>udd>SysAdmin>admin>old.system_control_1.dir_info).
delete: Entry not found. >udd>SysAdmin>admin>old.system_control_1.dir_info
comp_dir_info: Entry not found. Accessing dir_info segment
(>udd>SysAdmin>admin>old.pdt.dir_info).
delete: Entry not found. >udd>SysAdmin>admin>old.pdt.dir_info
r 13:41 3.194 63
The errors are ok at this point.
Now you should have the daily and weekly absentee jobs setup.
You should run this command:
cwd >udd>sa>a
ec master day
For a slightly more convenient command set, I do this:
pushd >udd>sa>a
ec master day
popd
This remembers my current directory, changes the working directory to >udd\>sa\>a, runs ec master day, and then restores the previous working directory. I have this set as an abbrev on my system to make it easier to invoke:
.l daily
b daily push_wdir >udd>sa>a ; ec master day ; pop_wdir
This prints out the crank.absout segment after filtering out unimportant lines. It offers to delete the absout segment afterwards. You should answer "yes" to the question about deleting the .absout -- otherwise it will grow without bound.
You can check the other .absout segments manually and delete them if you wish. These are weekly.absout and dodrp.absout.
To run the build each month, you issue a few commands. For example:
ec master bill prepare
ec master bill run MM DD YYYY
ec master bill accept YYYYMMDD
The first command, obviously, "prepares" the bills for running. The second runs the bills. You should do this every month. Specify the MM DD YYYY of the day you run the bills. It is not critical that it is exactly a month since the previous time, but bills were customarily run on the last business day of the month back in the day.
This should all be documented in the SysAdmin manual -- AK50-03B. See "Part X" (i.e. section 10) of that manual, which is entitled "Managing the Accounting System".
In the >udd\>sa\>a directory, there is a link to a "value segment" with the name sys_admin.value. Check out the value_list (vls) command to see details, but you can do vls -pn >udd\>sa\>a\>sys_admin.value to see the "value pairs" stored there.
On GHM, my value segment looks like this:
vls -pn sys_admin.value
abort_crank "false"
accounting_start_up_time "2015-12-01__02:04:04.039801_pdt_Tue"
admin_online "Swenson.SysAdmin"
crank_absout_read "2023-09-18__08:02:53.476691_pdt_Mon"
crank_time "0300."
default_dest "SYSTEM"
disk_time "0230."
last_crank "2023-09-18__03:00:02.023651_pdt_Mon"
last_diskreport "2023-09-18__02:30:17.298687_pdt_Mon"
last_log_time "2023-09-18__03:00:08.640314_pdt_Mon"
log_number "0"
weekly_time "0400._6days"
GHM 08:04 0.096 0 Swenson
On your system, this will likely look different.
The master.ec, also found in the >udd\>sa\>a directory, contains the accounting commands. For example, the ec master setdisk command, schedules the dodrp absentee process for a time specified by the disk_time value in this value segment.
As you can see, in my case, dodrp runs at 02:30.
The crank (>udd\>sa\>a\>crank.absin) and the weekly absentee, (>udd\>sa\>a\>weekly.absin) also use various values in the sys_admin.value value segment.
The >udd\>sa\>a\>util.ec exec_com, used by a lot of the accounting routines (exec_coms), has an entry point -- dp that is used for printing reports. It uses the xxx_addr values in the value segment (as you can see I have none defined, but you probably do), to decide whether to actually print out something.
For example, in the crank, there are lots of lines that look like this:
&- dprint the reports
&- exec_com util dp system.report director0
exec_com util dp system.report director1
&- exec_com util dp (system.report meter_data.print) director2
exec_com util dp system.report director3
&- exec_com util dp system.report director4
exec_com util dp system.report director5
exec_com util dp (system.report bwchart.print) director6
&- exec_com util dp daily_log_2 assurance0 2
exec_com util dp (daily_log_2 bwchart.print) assurance1 2
exec_com util dp (sumry cutrpt daily_log_0 crank.absout) accts0 2
exec_com util dp (daily_log_1 bwchart.print) admin0 2
exec_com util dp daily_log_2 sysprg2
exec_com util dp (daily_log_0 bwchart.print sumry crank.absout) admin1 2
exec_com util dp (daily_log_0 daily_log_1 daily_log_2 system.report bwchart.print sumry cutrpt meter_data.print crank.absout) defa
cult 1
exec_com util dp (system_logprint io_logprint) admin0
&- exec_com util dp (system_logprint io_logprint) default 1
exec_com util dp (system_logprint) default 1
The second argument to the dp entrypoint, e.g. director0, assurance1, admin1, admin0, default, denote the intended recipients of a given report/output. If there exists a corresponding xxx_addr entry in the value segment, e.g. admin0_addr, then the report destined to admin0 will be printed (and that address included in the printer output banner). So, take a look at the value segment's contents (using value_list), and note any entries that have the form xxx_addr. For each of those, look in >udd>sa\>a>master.ec, >udd>sa\>a>util.ec, and the other exec_coms in >udd>sa>a and see what "output" is sent to that "address". If you want it, leave things as they are. If you don't, either do one of two things: 1) remove the xxx_addr entry from the value segment, or 2) comment out the exec_com util dp entry in the appropriate exec_coms.
You can remove entries in the sys_admin.value segment using the value_delete (vdl) command. You can change values in a value segment with the value_set (vs) command.
This should all be documented in the SysAdmin manual -- AK50-03B. See "Part X"(i.e. section 10) of that manual, which is entitled "Managing the Accounting System".
All the the stuff about the contents of the value segment (sys_admin.value) should be documented there as well.
If you see messages such as:
0310.1 Utility.SysDaemon.z: monitor_quota: Storage in >user_dir_dir>SysAdmin>a is 100% full.
you should increase the quota on the >udd>sa>a directory. You can do this by moving quota from the >udd>sa directory using the move_quota (mq) command. If you have insufficient quota in >udd>sa to do this, move quota from >udd to >udd>sa first, and then move quota to >udd>sa>a. If you have insufficient quota in >udd, you will need to ask the Initializer process to increase its quota. Do this with the sac mq >udd +nnnn command.
After you do this, you should see that the messages from Utility.SysDaemon regarding quota no longer say that it is 100% full, but a new value. To make monitor_quota stop bothering you with these messages, you can tell Utility.SysDaemon to stop monitoring quota, and then tell it to start monitoring again. To turn it off, issue this command from the operator console:
r ut monitor_quota -off
Don't forget to turn it back on, because it is important you know if any system directories are running low on quota:
r ut ec monitor>monitor
You can see what Utility is monitoring by looking in >udd>sd>Utility>monitor.ec.
There is an "inconvenience" with monitor_quota. Once it detects that the quota is low on a directory, even if you give it more quota, it will continue to report whatever percentage it is at, periodically, even if the new percentage is below the 80% and 90% thresholds it starts warning about. So by turning it off and on again, it will start warning when >udd>sa>a gets to 80% of its quota.
First, enable auditing at the system level (the example below only enables unsuccessful access attempts, see the documentation on set_system_audit_flags for more options):
set_system_audit_flags -unsuccessful_access system_low
Next, establish the default auditing for new projects:
cwd >udd>sa>admin
admin_util set audit fsobj=N/R,fsattr=N/R,rcp=N/R,admin=N/R,special=N/R,other=N/R,admin_op,priv_op,fault
The above command will set the default value for the audit flags for any new projects you create. However, audit flags for all existing projects will remain at the previous default value defined by admin_util. To see what those default are, you can issue this command:
admin_util print
Now, you have to set the audit flags for any projects for which you want to have auditing enabled. This example, sets audit flags for the SysAdmin project.
cwd >udd>sa>a
edit_proj SysAdmin audit fsobj=N/R,fsattr=N/R,rcp=N/R,admin=N/R,special=N/R,other=N/R,admin_op,priv_op,fault
install smf.cur.sat -a
You can verify your new audit settings with the print_sat command:
print_sat >sc1>sat SysAdmin
To set audit flags for existing users, use the following command:
new_user$cga Swenson audit fsobj=N/R,fsattr=N/R,rcp=N/R,admin=N/R,special=N/R,other=N/R,admin_op,priv_op,fault
To verify the audit flags for an existing user, use this command:
print_pnt Swenson
The command ring_zero_dump (rzd) can be used to display the contents of both ring-0 segments and outer-ring segments. By default, it dumps out segments as a sequence of words in octal. However, it is capable of displaying structured data it knows about.
For example, you can use the command:
rzd [pd]>kst -as kst
Will dump out the KST in your process directory in a format like the following:
kst @ 373|0
lowseg = 152, highseg = 1023, highest_used_segno = 336, lvs = 0, time_of_bootload = 0, garbage_collections = 0,
entries_collected = 0, free_list = "000000"b3, uid_hash_bucket (0) = "001600"b3, uid_hash_bucket (1) = "002460"b3,
uid_hash_bucket (2) = "000650"b3, uid_hash_bucket (3) = "001420"b3, uid_hash_bucket (4) = "002030"b3,
uid_hash_bucket (5) = "001730"b3, uid_hash_bucket (6) = "002510"b3, uid_hash_bucket (7) = "000000"b3,
...
See the documentation on rzd (help rzd) for details. The help file >doc>ss>azm>structure_names.info documents all the structures known to rzd. For those structures it doesn't know about, you can create your own definitions for rzd.
You create your own structure declaration in an object segment compiled with the -table option. Just create an PL/1 program that declares the structure you want, compile it with the -table control argument, and specify the name of the object segment with the -in control argument of rzd.
As an example, assuming you have created a PL/1 program named gdStructures.pl1 from the declaration of the pds structure in pds.cds, invoke rzd on a pds this way:
rzd [pd]>pds -as pds.stacks -in gdStructures
You will get output like the following:
000000
stacks (0) = 230|0 (Invalid segment number), stacks (1) = 231|0 [pd]>stack_1, stacks (2) = 232|0 [pd]>stack_2,
stacks (3) = null, stacks (4) = 234|0 [pd]>stack_4, stacks (5) through stacks (7) = null
...
Note: You will need access to the phcs_ gate in order to dump ring-0 segments.
Note 2: Thanks to Gary Dixon for this information. You can find a sample (gdStructures.pl1) here: [http://swenson.org/multics_wiki/downloads/doc/gdStructures.pl1]
Terminal types are defined in the system TTT (Terminal Type Table). This binary segment is located in >sc1>ttt. You never modify this segment directly, however. The source for this segment is found in >udd>sa>a>TTF.ttf. It is compiled using the cv_ttf command, which produces the file TTF.ttt. This is installed using the command install TTF.ttt, which safely updates the system version in >sc1>ttt.
In order to add a new terminal type definition, you perform the following steps:
cwd >udd>sa>a
<edit the TTF.ttf segment to add the new definition(s).
cv_ttf TTF
install TTF.ttt
If your Multics system appears hung, first determine whether or not the Initializer process can respond to commands from the operator console. Do this by going to the terminal shell in which you started the simulator and pressing the Esc key. If you get the response:
M->
Then your system is probably not hung. Issue a command, such as who to the operator console and look for the output of that command. If you see the output, then your system is not really hung. If you can talk to the Initializer process, but your system is really not working (you can't login, those logged in are hung, etc.), you can try to shut your system down by using these commands:
logout * * *
shut
You may wish to shut down all the way to your OS shell, and restart everything.
However, if your system does not respond to operator input, and appears otherwise hung, you may need to crash the system and restart. You may wish to "take a dump of the system" and you will certainly want to perform an "emergency shutdown". These are described next:
To interrupt a hung (or running) system, you perform what is called (in Multics parlance) an \execute fault" (EXF). In the days of hardware-based Multics systems, this involved pressing some buttons on hardware panels. Chances are, today, that you are using the DPS8M simulator. In order to "execute fault" on the simulator, you have two choices:
USR1 signalexf command.If you are using a Linux or macOS host, you can send the USR1 signal to the process by first determining the process id (PID) for the process (use ps aux | grep dps8 or ps -elf | grep dps8) and then using the kill command to send the USR1 signal to that PID (kill -USR1 NNN, where NNN is the PID of the dps8 process.
I have no idea how to do this on Windows, but you can use the second option (typing Control-E) to the simulator and using the exf command.
Both options should cause an "execute fault". Below is an example of commands executed on macOS to "find" the dps8 PID:
$ ps aux | grep dps8
eswenson 65997 1.4 0.8 2587720 135564 s007 S+ 11:46AM 0:24.93 /Users/eswenson/Personal/Multics/src/dps8m-code/src/dps8/dps8 MR12.6f_boot.ini
eswenson 66017 0.0 0.0 2432804 800 s005 S+ 11:47AM 0:00.00 grep dps8
You can see that the PID is 65997.
Now, here is an example of the command on Linux and macOS to send the USR1 signal to that process:
$ kill -USR1 65997
$
Expect to see something like the following on the operator console:
USR1 signal caught; pressing the EXF button
DBG(2399749397065)> ERR ERR: Need status register data format
DBG(2399749397113)> ERR ERR: doPayloadChan expected IDCW 10 (12)
CONSOLE: ALERT
sys_trouble: Execute fault by operator.
bce (crash) 1049.1:
The Bootload Command Environment (BCE) is now waiting for you to enter a command.
The best practice here is to make a dump of the system and then perform an emergency shutdown:
bce (crash) 1049.1: M-> dump -long
Dumping Multics image.
Dump #1
Filling sst_names_
proc 1, dbr = 171714500004007775100023
proc 2, dbr = 000524000004000775100000
proc 3, dbr = 170740140004003775100000
proc 4, dbr = 170754740004003775100023
proc 5, dbr = 170764540004001775100023
proc 6, dbr = 170765740004001775100023
proc 7, dbr = 170766740004001775100023
proc 10, dbr = 170770140004001775100023
proc 11, dbr = 170771740004001775100023
bce (crash) 1051.2: M-> esd
1051.3 begin emergency shutdown part 1.
1051.3 emergency shutdown part 1 complete.
1051.3 shutdown complete
DBG(2400991064787)> ERR ERR: Need status register data format
DBG(2400991064835)> ERR ERR: doPayloadChan expected IDCW 10 (12)
bce (boot) 1051.3:
Now, you can reboot your system:
bce (boot) 1051.3: M-> boot star
Multics MR12.6f - 04/03/17 1052.2 pst Mon
1052.2 Loading FNP d, >system_library_unbundled>site_mcs 7.6c
Received BOOTLOAD command...
1052.2 FNP d loaded successfully
...
When the system is up, you may wish to analyze the dump (once Utility.SysDaemon has copied it from the dump partition to the >dumps directory). You do this with analyze_multics (azm). See the documentation for details.
Say you attempt to login to a project and see this:
Multics MR12.6g2: Gold Hill Multics (Channel d.h001)
Load = 8.0 out of 90.0 units: users = 8, 03/02/19 0844.2 pst Sat
e Guest
Your project's account is past its termination date.
Please try to login again or type "help" for instructions.
You need to do this:
cwd >udd>sa>a
r 08:46 0.101 0
edit_proj Guest cutoff
Cutoff date: 12/31/2018 0000.0 pst Mon
12/31/2019
r 08:46 0.119 10
install smf.cur.sat -a
r 08:47 0.060 2
And then you can login:
Multics MR12.6g2: Gold Hill Multics (Channel d.h001)
Load = 8.0 out of 90.0 units: users = 8, 03/02/19 0844.2 pst Sat
e Guest
Your project's account has less than -60 days until its termination date.
You are protected from preemption until 08:47.
Anonymous user Guest.Guest logged in 03/02/19 0847.6 pst Sat from ASCII terminal "none".
New messages in message_of_the_day:
Welcome to Gold Hill Multics.
This is a shared Multics system, so please be respectful of others.
print_motd: Created >process_dir_dir>!BMLBKBxBBBBBBB>home>Guest.value.
r 08:47 0.422 22
After you've done this, you should be able to login to the project whose cutoff (termination) date you extended. However, you may still see a message like:
Your project's account has less than -60 days until its termination date.
when you login. This is because the days_to_cutoff value in the project's SAT entry has not been updated. edit_proj doesn't do this -- daily_summary, run as part of the crank every night, does. If you don't want to wait until the crank runs to get rid of this message, you can run daily_summary manually. You can do this thus:
cwd >udd>sa>a
iocall attach sumry file_ sumry w
iocall attach cutrpt file_ cutrpt w
daily_summary
iocall detach sumry
iocall detach cutrpt
install smf.cur.sat -a
The daily_summary command updates the local copy of the SAT (smf.cur.sat), so you must install it (as above) after daily_summary runs. Note that daily_summary cannot be run without first attaching two (old style) i/o switches: sumry and cutrpt. In the above commands, these switches are attached to files of the same name as the switches. Feel free to inspect these files after daily_summary runs. The sumry file will contain a billing summary for all projects registered on the system. The cutrpt file will show you which projects are cutoff and a code to indicate why.
When you notice that you are low in disk space, or anticipate needing more disk space, you have two main options:
A QuickStart Multics system, or a cold boot of Multics using the standard cold boot simulator INI file will create a system with a single logical volume (LV), named "root". This is all that is required for Multics to boot. The root LV, also called the Root Logical Volume (RLV) consists of three 3381 sub-volumes (again, this is if you use a QuickStart or cold boot INI). This is illustrated via the use of the list_vols Initializer command:
M-> list_vols
Avg PV
Drive Records Left % VTOCEs Left % Size Name PB/PD LV Name
dska_00a 30166 11206 37 15082 12734 84 8 rpv pb root
dska_00b 68111 45627 67 13622 10754 79 7 root2 pb root
dska_00c 68111 42561 62 13622 10776 79 8 root3 pb root
A few things to note from the above:
dska_00a, dska_00b, and dska_00c. The a, b, and c following the base name of dska_00 indicates that these are each sub-volumes of a 3 sub-volume disk whose name is dska_00. While it is not obvious from the above output that these comprise a single 3381 disk, the following config deck PRPH card shows this:pcd prph
prph dska a 13 1 3381. 16
...
r 14:27 0.061 3
That card indicates that a disk device called dska is connected to IOM A channel 13 (octal) and uses 1 logical channel. There are 16 3381 devices accessible on this channel.
The first physical volume (PV), dska_00a, is the RPV (and named rpv). It is "special" in that it has some partitions defined on it that other PVs in the root LV do not have. Therefore, the number of records available to segments (and directories) is less (30166) than that for the other two PVs (root2, on dska_00b; and root3 on dska_00c). Altogether the root LV has (30166 + 68111 + 68111) records available, for a total of 166388 records.
Given that there are 166388 records of storage available on the only LV (root) on a QuickStart (or system cold-booted using the standard INI), that is the total amount of disk space that those systems have available. Of course, the system directories and system libraries take up some portion of that leaving less storage space for your segments and directories.
In the next two sections, we'll discuss how to add a new logical volume and how to expand a existing logical volume (by adding more PVs to it). We'll differentiate two distinct cases of this last one -- when the LV to be expanded is the RLV and when it is not the RLV.
While you certainly can expand the root LV (RLV), there is a downside to doing this. The RLV must be mounted at all times (cannot be unmounted) and must have integrity in order to boot Multics. In addition, the procedures for expanding the RLV are a bit more involved and there are some limitations. These will be discussed in the next section.
In this section, we'll simply create a new logical volume (LV) and create some PVs to add to it.
Before we get started, however, you have to make a decision as to which type of disk to add in your new LV. Following are your choices for disk models along with the number of records each supports:
| Model | Number of Records | Supported in dps8 Simulator |
|---|---|---|
| 500 | 38258 | no |
| 451 | 38258 | yes |
| 400 | 19270 | no |
| 190 | 14760 | no |
| 181 | 4444 | no |
| 501 | 67200 | yes |
| 3380 | 112395 | no |
| 3381 | 224790 | yes |
Of these, as you can see, only the 451s, 501s, and 3381s are supported in the default configuration of the dps8 simulator. You can also see that the 3381s are the largest. For this reason, unless you are trying to test out something specific that requires the other disk types, we recommend that you use 3381s. This example will, therefore, use 3381s for the new LV.
A 3381 disk volume is actually subdivided into 3 subvolumes, each with 68111 records available for segments and directories (68111 * 3 is 204333, but there is additional disk overhead of 20457 records, which reduces the 224790 total size to 204333 records available for record storage.
The first step in creating a new logical volume is to come up with a name for it. For the purposes of this example, we'll use the name public. You also need to decide how many PVs you will have comprising this new LV. Since we are using 3381s, and since there is a single host system file (e.g. public.dsk) that will contain all three sub-volumes of a 3381 disk, it is very logical to start with 3 new 3381 subvolumes -- each will be a PV in our new LV.
The next step is to come up with names for your new PVs. Since our LV is named public, we'll use pub01, pub02, and pub03 for the PVs in this LV.
Now, in order to register our LV and PVs, we need to use the add_volume_registration (avr) command. This is a regular Multics command and should get executed in a SysAdmin process, so that the process has the necessary access in the >lv directory to create segments. You can also do this from the Initializer admin mode, but you really shouldn't use admin mode unless you really need to. The normal way SysAdmin personnel administered Multics "back in the day" was to use their own SysAdmin accounts for administration.
The following avr command registers a new PV and tells Multics which LV it is part of. It also specifies the disk model. The first reference to a new LV causes Multics to prompt whether you want to create a new LV.
avr -pv pub01 -lv public -model 3381
add_volume_registration: LV "public" does not exist. Do you wish to create it?
Answer "yes" to the above query and you will get a response such as this:
add_volume_registration: Registered PV "pub01" (pvid 136533050034) on new LV "public" lvid 136533050021).
r 15:01 0.327 13
You have now registered the pub01 PV and created the public LV. Do the same for the other two disk sub-volumes:
avr -pv pub02 -lv public -model 3381
add_volume_registration: Registered PV "pub02" (pvid 136673705137) on LV "public".
r 15:02 0.037 3
avr -pv pub03 -lv public -model 3381
add_volume_registration: Registered PV "pub03" (pvid 136717010021) on LV "public".
r 15:02 0.096 4
These registrations are persistent in the >lv directory. If you list that directory, you will now see, among other segments:
ls >lv>**
Segments = 6, Lengths = 1.
0 public.mdcs
0 lv.public
lvid.!HwPQNBLbBBBBBB
pv.pub01
pvid.!HwPQNBXBBBBBBB
pv.pub02
pvid.!HwkZcMZbBBBBBB
pv.pub03
pvid.!HwmqDBLbBBBBBB
In short, the above shows that you have three PVs (pub01, pub02, and pub03) associated with a new LV (public). The public.mdcs segment is where the master directory information for directories on this new LV is stored. More on that later.
At this point, there are no so-called quota accounts for this new LV -- in other words, no one can create any directories on this LV because there is no quota. Also, no one can administer this logical volume other than the account that created it because there is no Acess Control Segment (ACS) segment controlling access to the LV. Let's first create the ACS:
cr >lv>public.acs
r 15:11 0.052 8
sml >lv>public.acs 0
r 15:11 0.022 0
sa >lv>public.acs rew *.SysAdmin
r 15:11 0.039 0
da >lv>public.acs
r 15:11 0.039 0
A few things to note about the above commands:
create (cr) command.set_acl (sa) command is used to allow anyone on the SysAdmin project to administer the LV.delete_acl (da) command is used to remove the default ACL that would have given rw access to the creator of the segment. You need the e access in order to administer the LV.Now, we need to tell the logical volume manager about this ACS segment. We use the change_volume_registration (cvr) command for this purpose.
cvr -lv public -acs >lv>public.acs
change_volume_registration: Changed attributes of LV "public".
r 15:14 0.072 3
Note that we could have specified this ACS on the first avr command, we executed earlier to create the LV, but I prefer to do this as a separate step to make the avr commands parallel in form.
Now that we have set up our LV and PVs as far as Multics volume management is concerned, it is time to actually initialize and add the disks.
Before we do that, we need to tell the simulator what host disk file to use as the backing storage for the new 3 sub-volume 3381 disk. If you look at your existing dps8 INI file, you'll see a dps8 command such as this already present:
attach disk0 root.dsk
What that is saying to the simulator is this: "Please associated the host file root.dsk with disk0." So what should you use as the diskN for your new disk? To really answer that, you need to understand a bit more about the cabling and the config deck. And you need to know which disks are already in use on your system. Without going into a lot of detail, a current dps8 simulator defines 26 disks named disk0 through disk25. Of these, however, you need to know what kind of disk each is so you can properly select a simulator disk for your new disk.
The first 4 disks -- disk0 through disk3 -- are 3381s. The next four -- disk4 through disk7 -- are 501s. The next four -- disk8 through disk11 -- are 451s. The next two -- disk12 and disk13 -- are 500s. And the next 12 -- disk14 through disk25 are 3381s. The reason why all the 3381s are not grouped together is historical.
Now, while the simulator uses disk names like diskN, Multics uses a completely different naming convention. disk0 is dska_00, disk1 is dska_01, disk2 is dska_02, and disk3 is dska_04. However, that pattern doesn't continue, so be careful. disk4 is dskb_01, disk5 is dskb_02, ... disk13 is dskb_10. And then, we have the remaining 3381s, disk14 is dska_04, disk15 is dska_05, ... disk25 is dska_15. Use the following chart to more easily map the 3381 disks in the default configuration to disks:
| Simulator Disk Name | Multics Disk Name |
|---|---|
| disk0 | dska_00 |
| disk1 | dska_01 |
| disk2 | dska_02 |
| disk3 | dska_03 |
| disk14 | dska_04 |
| disk15 | dska_05 |
| disk16 | dska_06 |
| disk17 | dska_07 |
| disk18 | dska_08 |
| disk19 | dska_09 |
| disk20 | dska_10 |
| disk21 | dska_11 |
| disk22 | dska_12 |
| disk23 | dska_13 |
| disk24 | dska_14 |
| disk25 | dska_15 |
In a QuickStart system, disk0 is used for the 3 subvolume RLV. So as far as additional 3381s, you can use disk1 - disk3 and disk14 - disk25.
If you have no other logical volumes besides the RLV (root), I recommend you use the next available disk -- disk1. Note that the Multics name for this disk is dska_01. And this means that your three subvolumes will be dska_01a, dska_01b, and dska_01c.
The first step is to tell the simulator about the new association with the disk (disk1) and the host file, which we'll call public.dsk. You have two choices for this:
attach disk1 public.dsk command, and restart the systemSince shutting down, updating, and rebooting takes time, we'll take the second approach.
Use the <control-s> key binding on the operator console to enter a DPS8M command:
<control-s> attach disk1 public.dsk
That will look like this on the operator console:
^S
DPS8M> attach disk1 public.dsk
DISK: creating new file
Remember to update your INI file before your next boot of the system with the same command (no <control-s>, of course).
Now, we need to initialize each of our three PVs (pub01, pub02. and pub03). You use the Initializer init_vol command for this. So an Initializer terminal (or operator console if you have no other Initializer terminals), do the following:
M-> init_vol pub01 dska_01a
volume pub01 68111 records
Ready
M-> init_vol pub02 dska_01b
volume pub02 68111 records
Ready
M-> init_vol pub03 dska_01c
volume pub03 68111 records
Ready
M->
Note that each of these PVs has 68111 free records of storage available to segments and directories, as described above.
Now that you have initialized your three new PVs, you have to "mount" them. To do this, issue the following commands on an Initializer terminal (or operator console):
M-> av pub01 dska_01a
Ready
M-> av pub02 dska_01b
Ready
M-> av pub03 dska_01c
Ready
M->
You can confirm that your new PVs are mounted with the list_disks (ld) command:
M-> ld
dska_00a rpv root
dska_00b root2 root
dska_00c root3 root
dska_01a pub01 (public) ***
dska_01b pub02 (public) ***
dska_01c pub03 (public) ***
dska_02a
dska_02b
dska_02c
dska_03a
dska_03b
dska_03c
dska_04a
dska_04b
dska_04c
dska_05a
dska_05b
dska_05c
dska_06a
dska_06b
dska_06c
dska_07a
dska_07b
dska_07c
dska_08a
dska_08b
dska_08c
dska_09a
dska_09b
dska_09c
dska_10a
dska_10b
dska_10c
dska_11a
dska_11b
dska_11c
dska_12a
dska_12b
dska_12c
dska_13a
dska_13b
dska_13c
Ready
M->
Note the \*\*\* next to the PVs. This indicates that the corresponding LV (public) is not yet added. Let's add that now:
M-> alv public
lv public mounted
Ready
M->
Now, if you rerun the ld command you'll see:
M-> ld
dska_00a rpv root
dska_00b root2 root
dska_00c root3 root
dska_01a pub01 public
dska_01b pub02 public
dska_01c pub03 public
dska_02a
dska_02b
dska_02c
dska_03a
dska_03b
dska_03c
dska_04a
dska_04b
dska_04c
dska_05a
dska_05b
dska_05c
dska_06a
dska_06b
dska_06c
dska_07a
dska_07b
dska_07c
dska_08a
dska_08b
dska_08c
dska_09a
dska_09b
dska_09c
dska_10a
dska_10b
dska_10c
dska_11a
dska_11b
dska_11c
dska_12a
dska_12b
dska_12c
dska_13a
dska_13b
dska_13c
Ready
M->
This shows you that the public LV is now mounted, with its three PVs.
So how do you actually "put stuff" on this new LV? The high level answer to that question is that you must create a "master directory" and specify its LV to be your new public LV. The normal create_dir (cd) command supports an -lv control argument that lets you specify the LV on which the directory should be created. When you create a master directory, you must also specify some quota. You do that with the -quota control argument to the create_dir command.
However, before you can do that, you must have a "quota account" on the LV. To see all the quota accounts on an LV, you can use the list_mdir (lmd) command with the -all control argument (assuming you have access to the LV's ACS segment). This is a normal Multics command, so do this in your SysAdmin process:
lmd public -a
No quota accounts on volume public.
r 16:07 0.076 13
Note that at present, there are no quota accounts. Let's try to create a new master directory anyway, so that you can see what happens and how Multics tells you about the issue.
In any directory to which you have sma access (say, your home directory), attempt to create a new directory "on" the public LV:
create_dir dir_on_public -lv public
create_dir: Expected argument missing. -quota needed to create master directory.
r 16:09 0.024 0
Remember I said you needed to specify quota? Let's try that:
create_dir dir_on_public -lv public -quota 1000
create_dir: No quota account for the logical volume. >user_dir_dir>SysAdmin>Repair>dir_on_public
r 16:10 0.036 0
This request is rejected because you (in this case, me as Repair.SysAdmin) has no quota account on the public LV. Let's add one:
svq public 1000 *.SysAdmin
r 16:11 0.038 0
Here, we've allocated 1000 records of quota to anyone on the SysAdmin project.
Let's verify that:
lmd public -a
ACCOUNT QUOTA PATHNAME
ACCOUNT ASSIGNED AVAILABLE
*.SysAdmin 0 1000
r 16:11 0.035 1
Let's use up all that quota when we try to create that directory again:
create_dir dir_on_public -lv public -quota 1000
r 16:12 0.093 1
Note that this succeeded this time. Let's check the quota accounts on the public LV again:
lmd public -a
ACCOUNT QUOTA PATHNAME
*.SysAdmin 1000 >user_dir_dir>SysAdmin>Repair>dir_on_public
ACCOUNT ASSIGNED AVAILABLE
*.SysAdmin 1000 1000
r 16:13 0.039 1
Note that we've now used up all 1000 records in our quota account (for *.SysAdmin) and that quota is now associated with the new master directory we created.
Now, any segments we create in this directory will be on our new public LV. Let's verify that:
pwd
>user_dir_dir>SysAdmin>Repair
r 16:14 0.033 0
cwd dir_on_public
r 16:14 0.030 0
cr foo
r 16:14 0.073 0
st foo -lv
public
r 16:14 0.037 11
st [wd] -lv
public
r 16:14 0.038 1
st < -lv
root
r 16:14 0.021 0
Note that the segment we created, foo, is on the public LV. And so is our master directory. But also note that the parent directory of the master directory is on the root LV.
So that is all there is to creating a new logical volume, populating it with PVs, create a quota account, and creating a master directory on the new LV.
In case it wasn't obvious, a "master directory" is a directory that is "on" a different LV than its parent directory. It also takes away quota from a quota account on the LV as opposed to from its parent directory.
You can, of course, add more quota to the LV and create multiple master directories on the new LV.
There are two cases, and each will be discussed separately. These are:
The first step is to create new volume registrations for the new volumes. The example here will use 3381 disks, which are 3-volume disks. The example also assumes that you are starting from a system with a single 3381 disk serving the RLV and that disk is dska_00 with its three volumes, dska_00a, dska_00b, and dska_00c.
The name of the RLV is root. You can check the existing registration for this LV by using the the lvr -lv root command. For example:
lvr -lv root
lvname: root
lvid: 132642546271 (!HhgNmdqbBBBBBB)
public: yes
owner: Initializer.SysDaemon
min_access_class: 0:000000 ()
max_access_class: 7:777777 (l7,c1,c2,c3,c4,c5,c6,c7,c8,c9,c10,c11,c12,c13,c14,c15,c16,c17,c18)
acs_path: >lv>root.acs
npv: 3
pvname: rpv
pvid: 132642546257 (!HhgNmdkbBBBBBB)
serial: 0-1
model: 3381
location: online
date registered: 08/05/23 1023.4 pst Sat
pvname: root2
pvid: 455432324007 (!dpFMhBFbBBBBBB)
serial: registered at cold boot
model: 3381
location: dska_00b
date registered: 08/05/23 1023.4 pst Sat
pvname: root3
pvid: 455472415704 (!dpKNFZDBBBBBBB)
serial: registered at cold boot
model: 3381
location: dska_00c
date registered: 08/05/23 1023.7 pst Sat
This shows that you have three Physical Volumes (PVs) named rpv, root2, and root3, and that these comprise the entirety of the root LV.
It is recommended that you expand the root LV (RLV) by adding a second 3381 disk, dska_01 (if not already used). We will add that disk shortly, but first, add three new volumes to the root LV.
avr -pv root4 -lv root -model 3381
add_volume_registration: Registered PV "root4" (pvid 366153467157) on LV "root".
r 09:57 0.133 4
avr -pv root5 -lv root -model 3381
add_volume_registration: Registered PV "root5" (pvid 366175441514) on LV "root".
r 09:57 0.022 3
avr -pv root6 -lv root -model 3381
add_volume_registration: Registered PV "root6" (pvid 366212147070) on LV "root".
r 09:57 0.037 3
Now, if you use the lvr -lv root command again, you should see all 6 disks.
lvr -lv root
lvname: root
lvid: 132642546271 (!HhgNmdqbBBBBBB)
public: yes
owner: Initializer.SysDaemon
min_access_class: 0:000000 ()
max_access_class: 7:777777 (l7,c1,c2,c3,c4,c5,c6,c7,c8,c9,c10,c11,c12,c13,c14
c,c15,c16,c17,c18)
acs_path: >lv>root.acs
npv: 6
pvname: rpv
pvid: 132642546257 (!HhgNmdkbBBBBBB)
serial: 0-1
model: 3381
location: online
date registered: 08/05/23 1023.4 pst Sat
pvname: root2
pvid: 455432324007 (!dpFMhBFbBBBBBB)
serial: registered at cold boot
model: 3381
location: dska_00b
date registered: 08/05/23 1023.4 pst Sat
pvname: root3
pvid: 455472415704 (!dpKNFZDBBBBBBB)
serial: registered at cold boot
model: 3381
location: dska_00c
date registered: 08/05/23 1023.7 pst Sat
pvname: root4
pvid: 366153467157 (!ZQWXWmkbBBBBBB)
serial: unspecified
model: 3381
location: uninitialized
date registered: 04/09/24 0957.1 pst Tue
pvname: root5
pvid: 366175441514 (!ZQZjLWJBBBBBBB)
serial: unspecified
model: 3381
location: uninitialized
date registered: 04/09/24 0957.3 pst Tue
pvname: root6
pvid: 366212147070 (!ZQcLmlqBBBBBBB)
serial: unspecified
model: 3381
location: uninitialized
date registered: 04/09/24 0957.4 pst Tue
r 10:01 0.103 1
Next, you must come up with a name for the .disk file on your host for your new 3-volume 3381 disk. It is suggested you use root2 since there is already a root for the original three volumes. This writeup assumes you've chosen root2.
Since the INI file you use to boot Multics doesn't already specify this disk file, you will need to attach it while your system is running. This writeup assumes you have only a single disk specified in your dps8m INI file, and that that disk is disk0 and the associated filename is root.dsk. Verify this before continuing.
If you have more than this single disk defined in your INI, make sure to pick ANOTHER disk number for the next step.
To attach the new disk file to the simulator, make sure you are on the operator console, and issue the simulator escape sequence, which is <control-s>, and then type:
attach disk1 root2.dsk
The console should show something like this:
^S
DPS8M> attach disk1 root2.dsk
DISK: creating new file (root2.dsk)
You will need to remember to update your INI file before your next boot of the system with the same command (no <control-s>, of course). Don't do this yet.
Now, we need to initialize each of our three PVs (root4, root5. and root6). You use the Initializer init_vol command for this. So on an Initializer terminal (or operator console if you have no other Initializer terminals), do the following:
M-> init_vol root4 dska_01a
volume root4 68111 records
Ready
M-> init_vol root5 dska_01b
volume root5 68111 records
Ready
M-> init_vol root6 dska_01c
volume root6 68111 records
Ready
M->
Note that each of these PVs has 68111 free records of storage available to segments and directories.
If you now issue the list_disks Initializer command, you should see this:
M-> list_disks
dska_00a rpv root
dska_00b root2 root
dska_00c root3 root
dska_01a root4 root *
dska_01b root5 root *
dska_01c root6 root *
dska_02a
dska_02b
dska_02c
dska_03a
dska_03b
dska_03c
dska_04a
dska_04b
dska_04c
dska_05a
dska_05b
dska_05c
dska_06a
dska_06b
dska_06c
dska_07a
dska_07b
dska_07c
dska_08a
dska_08b
dska_08c
dska_09a
dska_09b
dska_09c
dska_10a
dska_10b
dska_10c
dska_11a
dska_11b
dska_11c
dska_12a
dska_12b
dska_12c
dska_13a
dska_13b
dska_13c
Ready
M->
Note that your three new disk volumes are shown, and bound to the root LV. The * next to the entries show that they are not yet added to the root logical volume.
Now that you have initialized your three new PVs, you have to "mount" them. To do this, issue the following commands on an Initializer terminal (or operator console):
M-> av root4 dska_01a
Ready
M-> av root5 dska_01b
Ready
M-> av root6 dska_01c
lv root mounted
Ready
Note that now that we completed the root logical volume, Multics tells you that the LV is mounted with the "lv root mounted" message.
If you now invoke the list_vols root command, you should see something like this, and in particular, the new disk volumes:
M-> list_vols root
Avg PV
Drive Records Left % VTOCEs Left % Size Name PB/PD LV Name
dska_00a 30166 7746 26 15082 12473 83 8 rpv pb root
dska_00b 68111 33356 49 13622 10353 76 10 root2 pb root
dska_00c 68111 35220 52 13622 10158 75 9 root3 pb root
dska_01a 68111 68111 100 13622 13622 100 0 root4 pb root
dska_01b 68111 68111 100 13622 13622 100 0 root5 pb root
dska_01c 68111 68111 100 13622 13622 100 0 root6 pb root
Ready
You now have an expanded RLV. However, you must perform the following steps prior to your next boot. If you have the time now, you can shut down your Multics system and perform these steps. Otherwise,do not forget to do them once you have shut down and are ready to reboot. It is recommended that you shut down to BCE (not all the way), thus:
M-> logout * * *
Ready
M->
CONSOLE: RELEASED
1027 as LOGOUT IO.SysDaemon.z dmn cord 0: 0 $0.02 (looc)
1027 as LOGOUT Backup.SysDaemon.z dmn bk 0: 0 $0.03 (looc)
1027 as LOGOUT IO.SysDaemon.z dmn prta 0: 0 $0.02 (looc)
1027 as LOGOUT Utility.SysDaemon.z dmn ut 0: 3 $1.90 (looc)
1027 as LOGOUT Volume_Dumper.Daemon.z dmn vinc 0: 0 $0.05 (looc)
M-> shut
1027 as act_ctl_: shutdown, 6 0.03 0.03 0.00 0.44 0:0:16 $4.94
1028.1 shutdown complete
bce (boot) 1028.1: M->
Now that you are at BCE, edit your config deck to update the root config card to know about the three new drives:
M-> config
M-> /root -subsys/
root -subsys dska -drive 00a -subsys dska -drive 00b -subsys dska -drive 00c
M-> s/$/ -subsys dska -drive 01a -subsys dska -drive 01b -subsys dska -drive 01c/
M-> p
root -subsys dska -drive 00a -subsys dska -drive 00b -subsys dska -drive 00c -s
cubsys dska -drive 01a -subsys dska -drive 01b -subsys dska -drive 01c
M-> w
M-> q
bce (boot) 1034.2: M->
Now, shut down BCE and the simulator:
M-> die
Do you really wish bce to die? M-> y
BCE DIS causes CPU halt
+---------------------------------+
| CPU A Statistics |
+---------------------------------+
| cycles 3269684317 |
| instructions 1641096997 |
+---------------------------------+
| lockCnt 2355043120 |
| lockImmediate 2355043120 |
+---------------------------------+
| lockWait 0 |
| lockWaitMax 0 |
| lockYield 0 |
+---------------------------------+
| CPU A Micro-cache Statistics |
+---------------------------------+
| Instruction Fetch: |
| Hits 74632827 |
| Misses 5061351 |
| Skipped 641178815 |
| Effectiveness 10.35% |
+---------------------------------+
| Operand Read: |
| Hits 223349916 |
| Misses 52012878 |
| Skipped 0 |
| Effectiveness 81.11% |
+---------------------------------+
| Cache Bypasses: |
| RALR 82 |
| CALL6 6226672 |
| Segno 0 |
+---------------------------------+
Simulation stop, IC: 000000 (000000000000)
sim>
And exit the simulator:
sim> q
Goodbye
$
Now, edit your INI file to add the attachment of your new disk using your favorite host editor. The new line should be:
attach disk1 root2.dsk
You should place it after the line:
attach disk0 root.dsk
Now, to test everything out, reboot your system. It should reboot normally, with a lot more disk space in your RLV.