| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 381.1 | Just another UIC | CAFEIN::PFAU | You can't get there from here | Tue Jan 13 1987 19:47 | 0 |
| 381.2 | Except for [0,0] and [377,377] | DEBET::CANTOR | Dave C. | Wed Jan 14 1987 00:25 | 9 |
| Except [000,000] and [377,377].
[0,0] is illegal, isn't it? I'm not sure.
I think I remember that [377,377] is what all UICs with either
group>377 or member>377 get mapped into under some circumstances.
(When accessing a FILES-11 format version 1 disk?)
Dave C.
|
| 381.3 | | ERIS::CALLAS | So many ratholes, so little time | Wed Jan 14 1987 10:59 | 6 |
| Nope, [0,0] is perfectly legal.
There's also nothing special about [377,377], either. Since V4,
UICs are 32 bits, too.
Jon
|
| 381.4 | [0,0] used by DISKQUOTA | USHS01::BLANDO | | Wed Jan 14 1987 21:08 | 8 |
| repl .-1
[0,0] is legal; however, using it can cause confusion. DISKQUOTA
uses that UIC to store its DEFAULT values like AUTHORIZE uses the
DEFAULT account. As far as I know that is the only restriction,
but can be a big one sometimes.
FJBlando
|
| 381.5 | Beware [0,0] my son... | SHEILA::PUCKETT | Open the pod bay doors please HAL | Wed Jan 14 1987 23:45 | 4 |
| If you have files on the disk owned by [0,0] then Diskquota falls over when
doing a rebuild with Duplicate disk quota entry...
= Giles =
|
| 381.6 | ODS-1 disks must be an exception | DELNI::CANTOR | Dave C. | Thu Jan 15 1987 00:54 | 9 |
| Re .3
(Rathole alert)
How can a disk with ODS-1 format have files owned by a UIC
whose group and member parts are not both less than or equal
to 377(8)?
Dave C.
|
| 381.7 | Nope, no dice. | MOTHRA::DUTKO | Nestor Dutko, VMS/VAXclusters CSSE | Thu Jan 15 1987 13:47 | 13 |
| RE: .6
It can't. I just took a floppy and initialized it and mounted it
as follows:
$ INITIALIZE /STRUCTURE=1 MOTHRA$DUA1: TEST_UIC
$ MOUNT MOTHRA$DUA1: TEST_UIC TEST_UIC
$ CREATE /DIR /LOG /OWNER=[1,400] MOTHRA$DUA1:[DUTKO]
No error was issued, yet when I did a DIRECTORY /SECURITY, I found
that the file was actually owned by [377,377].
Does that help?
|
| 381.8 | So [377,377] is special. | DEBET::CANTOR | Dave C. | Mon Jan 19 1987 13:06 | 10 |
| re .7 (re .6 (re .3 (re .2)))
Thanks. That's just my point. [377,377] is special.
I recall a long-winded discussion about which UIC to choose
for the purpose of a catchall for all large-format UICs on
ODS-1 disks in some old note file, about four years ago. They
decided on [377,377].
Dave C.
|
| 381.9 | VMS_V4.n .neq. ODS1 | BASHER::TRAVELL | John Travell, UK-RDC, 833-3333. | Mon Jan 19 1987 20:15 | 11 |
| re .various....
Please excuse my innocence, I thought this note was aking about UIC's
under VMS, specifically V4.n, and nowhere in the discussion I have read
anything to say that VMS V4.n considers [377,377] special in any way.
--------
I fully accept that systems using ODS1 regard [377,377] as special,
but VMS uses ODS2.... (I said USES, not `can make use of when required to')
John Travell.
|
| 381.10 | VAX RSX, add nauseum... | LEROUF::PALO | qu'est-ce que c'est? | Tue Jan 20 1987 10:11 | 5 |
| [Un]fortunately, one can $INITIALIZE/STRUCT=1 and subsequently $MOUNT
the volume. In this case VMS is accessing the volume with ODS-1
format and, voil�, you really *do* need to worry about the UIC.
\rikki
|
| 381.11 | | BASHER::TRAVELL | John Travell, UK-RDC, 833-3333. | Tue Jan 20 1987 19:57 | 15 |
| re .10,
Granted, this is very true, BUT, this is still not native VMS V4, so
unless someone can specify otherwise, there does not appear to be anything
special about [377,377] to native VMS V4 running on its default ODS2 disk
structure.
I would consider `/struct=1' or other accomodation to non-default disk
structures to be special cases, and so exceptions to the normal rules for VMS.
Does any reader know of any reason why VMS V4.n on an ODS2 disk, with
no reference to other disk formats, should see anything at all special about
any UIC (other than the previously stated significance of [0,0])
John Travell.
|
| 381.12 | Its worth noting... | 9399::ILES | Mike Iles | Wed Jan 21 1987 13:23 | 14 |
|
John,
A user could quite easily be using an ODS1 disk transparent to the fact
that he is. An RSX development environment would certainly have
ODS-1 disks mounted. A user might well create directories on this
disk and VMS if he choses a UIC above the ODS-1 spec it will become
[377,377]. It's still certainly VMS he's using and its worth knowing,
particularly when looking for files that might get put there. If
you have an owner UIC outside the range then you would surely be
interested in knowing what files you can and can't get to.
-Mike-
|
| 381.13 | I `noted' the pun... intentional ?? | 42023::TRAVELL | John Travell, UK-RDC, 833-3333. | Wed Jan 21 1987 20:05 | 19 |
| Hello Mike,
I accept your comment about an RSX development environment,
but I don't see this as a particularly high volume situation, at least in
comparison to the number of `vanilla,- all ODS2' VMS systems around.
Hi all,
In summary, it appears that if you have all ODS2 format disks then
[377,377] is not `special'.
If you have ODS1 disks mounted, [377,377] represents a catch-all for
files copied to them, without a specified destination UIC legal for ODS1, from
UIC's greater than [377,377].
Is this a fair summary??, if not, will someone please give us
something more accurate.
John Travell.
|
| 381.14 | | CAFEIN::PFAU | You can't get there from here | Fri Jan 23 1987 20:15 | 8 |
| The owner of a disk volume may perform logical (and physical?) I/O to
that volume. The default owner of a disk initialized /SYSTEM is [1,1].
If the disk wasn't initialized /SYSTEM, it will use the UIC of the
person who performed the initialization.
Any UIC with a group number <= MAXSYSGROUP has implicit SYSPRV.
tom_p
|