| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 74.1 | V3.2 Rdb version and logical disk | SNOFS1::CHEUNGW | Wilson Cheung from down under DTN: 730-5106 | Tue Mar 21 1995 00:47 | 24 |
| Hi Lois,
I have V3.2 installed onto our development cluster. There are a few
minor issues which we can get around but would like to comment on.
1. We have multiversion RDB installed on the machine (V4.2, V5.1 and
V6.0.) KITINSTAL checks SQL$.EXE for version verification. As
multiversion RDB does not have SQL$.EXE (it has SQL$42.EXE, SQL$51.EXE
and SQL$60.EXE instead), the installation process failed. I get around
it by putting a dummy SQL$.EXE in.
2. The installation kit does not accept logical device address for
TPAS$ROOT. I move the whole TPAS directory after set up and change
TPAS_LOGICALS.COM to avoid hard coding physical device address. Do you
foresee any problem?
We are testing it in the next few days. Further assistance may be
required.
Regards,
Wilson
SPT Finance Development
|
| 74.2 | | AWARD::MAGNI | Lois, 237-5548 | Wed Apr 12 1995 12:37 | 13 |
| Wilson,
Thanks for noting the problem with the install on TPAS with multiversions.
Your solution looks like it works fine. The only reason the TPAS Install
checks for the version of SQL is to load the correct TPAS*PRIV*.SQL filed
as there are different RDB Priviledges needed for V3 to V4/V5 RDB.
As for the change you did to TPAS_LOGICALS.COM, I foresee no problems.
I will have a look at it for the next release to see if I can change the
VMSInstal.com
Lois
|
| 74.3 | TPAS directories, rights and ACLs | AYRMIS::LSS055::Charles | If you can't knit bring a book! | Fri May 05 1995 09:06 | 18 |
| Lois,
We installed TPAS 3.2 on a different (development) machine, ie no other
versions of TPAS II had been installed before.
The directory structure was owned by TPAS$SUPPORT but this rights ident was
not set up as a resouce identifier. This causes problems with file
ownership and quotas.
Also the directory ACLs only had one entry for TPAS$SUPPORT as an
Option=default. This only allows the acl to flow down to the sub
directories. You also need an ordinary ACL entry of TPAS$SUPPORT (and the
other rights idents.) to allow access to the directories themselves.
Regards
Charley
|
| 74.4 | The ongoing bane of ACLs | AWARD::MAGNI | Lois, 237-5548 | Fri May 05 1995 17:31 | 16 |
| Charley,
Right you are on the resource. I create the rights identifier with the VMS
Callback:
$ VMI$CALLBACK ADD_IDENTIFIER TPAS$SUPPORT
I would have to change this to:
$ VMI$CALLBACK ADD_IDENTIFIER TPAS$SUPPORT "/attributes=(resource)"
As for the /default - I had no problems when I tested TPAS Install on a
TPAS free machine. I will look into this more, it may have been I had other
rights ids / process privs that let me in.
regards,
Lois
|
| 74.5 | More fun with TPAS 3.2 | AYRMIS::LSS055::Charles | If you can't knit bring a book! | Mon May 08 1995 12:51 | 24 |
| Hi,
Couple more points:
FYI: If you use a disk with quotas for TPAS you need to give SYSTEM a quota
(V4.2 rdb+). When you do a write transaction there are some work files
created on the disk owned by SYSTEM. If you dont have system privilidges
you get a diskquote exceeded error when loading the database.
----------
ACLs again: The solution to RMU privs problem described in note 67 works on
VMS 6 and RDB 6. However it does not work on VMS 5.5 and RDB 4.2 (our dev
machine). Reason is when you create an rdb VMS/RMS creates an ACL entry
for your account with read+control access only (On my VMS 6 machine you get
r+w+e+d+c). So you can't even change the ACL (no write access). The only
fix is to get system privs (SYSPRV, BYPASS) put on the account. If I
recall correctly standards state you should not have to set up privilidged
accounts for an application. This should be fixed.
Regards
Charley
|