MTM R10-01 SCRs are:
21775.0 - RVOLUME and ALLOCATE commands produce inconsistent results
21790.0 - A MTM sysgenned without accounting support pulls an alignment fault
21812.0 - SVC2,7 flwd close by SVC3,0 w/n output msg w/IOP MTM terminal.
================================================================================
================================================================================
217750
Software Problem:
----------------
The RVOLUME and ALLOCATE commands produce inconsistent results based
on the MTM signon account and the current user account (which might
be changed using the SET PRIVATE command). The following tables
demonstrate the problem:
Command: RVOL CMXX,U
-------------------------------
Account 5 = RO (Read Only) | Signon to 5 | 6 | 7 |
Account 6 = RW (Read/Write) |------------ | | |
Account 7 = NONE (No Access) | SET PRI x | | | |
| |------------------
| 5 | RO | RW | NO |
| 6 | RO | RW | NO |
| 7 | RO | RW | NO |
-------------------------------
Command: ALLOCATE ACTSyXz,IN,80
-------------------------------
y = Signon account | Signon to 5 | 6 | 7 |
z = Set Private account |------------ | | |
| SET PRI x | | | |
| |------------------
| 5 | No | No | No |
| 6 | Yes | Yes | Yes |
| 7 | No | No | No |
-------------------------------
The RVOLUME commands works as expected if TUB.SACC (MTM signon account)
is used. The ALLOCATE command works as expected if TCB.UACT is used.
This is inconsistent.
Software Response:
-----------------
The RVOLUME command displayed ones correct access privileges for the
restricted volume for ones signon account. For a user with SET PRIVATE
(x000001000) privileges in the AUF and used the SET PRIVATE command to
change their private account to an account other then their signon
account, the RVOLUME command did not display the users current access
privileges for the restricted volume. This was indeed incorrect, the
RVOLUME command should display ones access privileges for the restricted
volume based on ones current private account.
To better understand what a restricted volume is, a explanation is in
order. To create a restricted volume one would mark a disk on using
the RESTRICTED keyword specifying the account number of the owner. For
example:
MA DLST:,ON,RES=6,CD=ALL
Here account 6 is the owner of this restricted disk and read/write
access is limited to the user which signs on to account 6. The owner of
a restricted disk can use the RVOLUME command to allow other accounts
access to this restricted disk. To prevent a user with SET PRIVATE
privileges from using the RVOLUME command to chang which accounts have
access to a restricted disk, ones signon account must be the same as the
owner account of a restricted disk. In this example the user which
signed on to account 6 would be the owner of this restricted disk.
The owner of the restricted disk can grant access to other accounts by
using the RVOLUME command. For example disk device DLST: contains
the volume LIST:
RVOL LIST,ADD,5/RO,922/RW
After this RVOLUME command is executed account 5 has read only access,
account 6 as the owner has read/write access, and account 922 has
read/write access. All other accounts will be denied access to this
restricted disk. If one signs to account 6 or 922 (and does not do
a SET PRIVATE to some other account) they can allocate, delete, assign,
and the like to files within their current account. Also if one has
SET PRIVATE privileges and does a SET PRIVATE to account 6 or 922,
they also have the same access to files within their now current
account. If the owner of the restricted disk did not grant account 7
access, then if the owner does a SET PRIVATE to account 7 they will
not be able to allocate, delete, or assign to any files within that
account.
In order for the SPOOLER to print files on a restricted disk or for
one to do a BACKUP of a restricted disk, the owner of the restricted
disk must give account 0 read/write access to the restricted disk.
As a result of this, the following is common way in which a restricted
disk is set up:
a) Mark the disk on as restricted in ones startup CSS.
MA DLST:,ON,RES=6/1024,CD=ALL
b) Just after MTM is loaded and started in ones startup CSS, submit a
batch job to MTM which establishes the account access to the
restricted disk.
.MTM SUBMIT RVOLLIST.JOB/255
This batch job would look like the following:
SIGNON LIST,6,password,ENV=NULL:
RVOL LIST,ADD,0/RW,5/RO,922/RW
ME .OP SPOOLER given printing privileges to volume LIST
SIGNOF
To maintain security of the password to this account this batch job
file should not be placed in account 0. It is recommended that it
be placed in account 255 or within the account of the owner of the
restricted disk.
The owner of a restricted disk is allowed to change the access of their
signon account to the restricted disk, even to deny access to their own
signon account. A common practice is to grant read only access to all
account and read/write access to a few selected account plus account 0
(for SPOOLER and BACKUP).
If ones intent is to grant full read/write access to all account on a
given volume to a few selected users, then one should be using the
SET DEVICE command. For example, if the volume ADM exists on the disk
device DADM: one would mark it on in the normal way:
MA DADM:,ON,,CD=ALL
Within the SYSINIT.CSS in account 255 one would add the following:
SET DEVICE -DADM: ;* deny access to all
$DEF L1,,CURR(PRIVATE) ;* user signon account
$REL L,2 ;* make sure L2 is null
$IF DEC @*L1 EQ 162; $DEF L2,,ST(1); $ENDC ;* flag 162 as allowed
$IF DEC @*L1 EQ 163; $DEF L2,,ST(1); $ENDC ;* flag 163 as allowed
$IFNNULL @*L2; SET DEVICE +DADM:; $ENDC ;* grant access to allowed
$REL L,2 ;* done with L2
This would allow signon accounts 162 and 163 full access to volume ADM.
If these account have the SET PRIVATE privilege they could change their
current account and have full access privileges to files within their
new current account. On the other hand all other accounts would have
no access to the volume, even if they could do a SET PRIVATE to one of
those accounts. To all other accounts the device DADM: and volume ADM
would not even exist because it would not show up in a DISPLAY DEVICE
command and the DISPLAY FILE command would not be able to access this
volume.
The reason one would place the SET DEVICE command within the SYSINIT
CSS is because this command requires SUPERUSER privilege to execute.
This privilege exists during the execution of the SYSINIT CSS when one
is signing on to MTM.
On the systems used by the OS/32 Development group some disks are
marked on as SYSTEM, PROTECTED, and RESTRICTED. As part of the system
startup procedures a batch job is submitted to MTM for each restricted
volume to grant appropriate account access to the volume. Within the
SYSINIT.CSS in account 255, SET DEVICE commands similar to the above
example are used to allow access by particular signon accounts to
certain disks.
In addition to fixing the RVOLUME display command, a problem was found
in the SET DEVICE command when the device name started with the letter
A, for example A222:.
return to index
================================================================================
217900
Software Problem:
----------------
MTM R10-01 sysgenned without accounting support pulls an alignment
fault and and pauses after an MTM user loads a task.
Software Resolution:
-------------------
If MTM R10-01 is genned without accounting (i.e., SGN.ACT EQU 0), the
following MTM user commands will cause an alignment fault in MTM:
SET PRIVATE, SET GROUP, SET CSS, SET DEVICE, SET TIMEOUT
The entry points in ACCNTGN module of MTM were defined at wrong points
and the NOP'ing of some BAL instructions was done incorrectly.
Due to the nature of the resolution, not all components can be supplied
as a object patch. However, a program is supplied with this resolution
that can be compiled and used along with R10-01 MTMMAIN.LIB to resolve
the above stated problem. Ease of Use (EOU) procedures for compilation
and OBJECT/32 procedures for including the compiled object with
MTMMAIN.LIB are described.
return to index
================================================================================
218120
Software Problem:
----------------
If an MTM subtask executes an SVC 2 code 7 (log message) followed by an
SVC 3,0 (end of task), the message is not displayed on the screen if the
terminal is connected to an IOP but is OK if the terminal is connected
to the CPU. The IOP must be under very heavy load for the log message
not to be written to the terminal.
Software Resolution:
-------------------
MTM must issue a halt I/O to halt the current command read. When the
IOP is under heavy load this could take a few milliseconds. Because a
SVC 2 code 7 (log message) is a implicit proceed I/O request, the user
task is allowed to execute while the log message occurs. This allows
the user task to issue the SVC 3 and go to end of task. Within the
end of task handling code in MTM the task I/O flag was reset. This
resulted in the current I/O request and any pending I/O requests for
the task to be cancelled. To resolve this problem the code to reset
the task I/O flag was deleted.
When testing this correction using the multiple tasks per user feature
of MTM (enabled via ENABLE MULTITASK and defined during sysgen by
SGN.MTSK and NTASKS) it was found the task structure did not allocate
space for the console buffer. This could cause a write from one task
structure to overwrite another task structure which could result in
MTM faulting. To resolve this the console buffer size was added to
the task structure.
In investigating this problem it was observed that terminal drivers do
not return a valid length of transfer all the time, especially for I/Os
which were halted. This can result in a carriage return being stored
in someone else's command buffer or over the header information of ones
own command buffer. As a result strange problems and faults can occur
in MTM. This was resolved by forcing a zero length of transfer when
a negative length of transfer was returned by the terminal driver.
return to index
================================================================================