| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 147.1 | I can not think of any cases | HOTRDB::LASTOVICA | Is it possible to be totally partial? | Mon Feb 17 1997 09:27 | 2 |
| Not that I'm aware of. We tend to test Rdb and let Digital test
OpenVMS.
|
| 147.2 | | HOTRDB::PMEAD | Paul, [email protected], 719-577-8032 | Mon Feb 17 1997 11:44 | 2 |
| Well, not intentionally, but we do sometimes test in clusters, which
implies that lock remastering is likely to occur.
|
| 147.3 | Those wonderful defaults... | NOMAHS::SECRIST | Rdb WWS; [email protected] | Mon Feb 17 1997 12:25 | 12 |
|
There is nothing on record that says we do or do not support
dynamic lock remastering though, is there ? It is hard to
believe that anyone would want to move huge lock trees around
in the middle of the day on a production system on purpose
(but that is the VMS default) -- let alone the ramifications
of that in terms of software complexity. In the back of my
mind I always hear Dr. McCoy ranting about the transporter ;-)
Regards,
rcs
|
| 147.4 | | HOTRDB::PMEAD | Paul, [email protected], 719-577-8032 | Mon Feb 17 1997 13:26 | 4 |
| Why should we document whether we do or don't support a particular VMS
internal mechanism? If the mechanism doesn't work then VMS engineering
should fix it. It isn't up to us to second-guess the usability of our
platform operating system services.
|
| 147.5 | delete me | NOMAHS::SECRIST | Rdb WWS; [email protected] | Tue Feb 18 1997 11:22 | 3 |
|
If we produce a repeatable case which demonstrates a problem in
VMS functionality that adversely affects Rdb
|