Dan Hollis <[log in to unmask]> wrote:
>Oops. It's SR5003248492. And it's still not available ;)
>
>-Dan
Here's that SR: Is this the one you are interested in? (Since I did
not ask for permission, I've deleted people's names -- contact me if
you need more info).
SR # 5003248492 TURBOSTORE/XL II OLB 36388A 50.11 Sev: S Pri: 3
Classification: Enhancement (Maybe) Status: Being considered
Number of Duplicates: 1
ER modify TStore to short-map omnidex db files (type -410 or 411)
Company : SAINT BRUNO DE MONTARVILLE
Submitter: Submitted : 02/07/95
User # : Entered : 02/07/95
Verifier : COMSYS: 5003 SR updated : 06/28/95
SO ref # : Text updated: 06/28/95
Proj mgr : Reclassified: 06/28/95
Mkt engr : Purge date : / /
Lab engr : To lab : 02/14/95
QA engr : From lab : 02/21/95
Func area: STORE XL AR date : / /
Prod line: HPE To QA : / /
Sub line : HPE From QA : / /
Sys model: New v.u.f : . .
Release : Fix number :
Prod type: REL Prob cause :
Ack flag : Y Field class : ER
Response : Y Mkt action : N
SSB issue: Lab action : N
SSB suppr: N QA action : N
SUBMITTER TEXT:
TURBOSTORE/XL II OLB (36388A)
TRUBOSTORE OLB does not allow users to open a database with SHORT MAPPED
access if that database is currently being stored. TURBOSTORE opens
the database in LONG MAPPED access as default.
Users opening the database receive an error 3950.
This Enhancement Request is to ask HP to change TURBOSTORE/XL II OLB to
open databases (filecode of -410 or -411) with SHORT mapped access.
Here s the situation with TurboStore and Omnidex with
error 3950 (or just 950 if TPI is not enabled):
Omnidex opens its index files for Short Mapped access.
TurboStore opens first for Long Mapped access then, if that
fails, opens for Short Mapped access. This works well for
TurboStore, but can cause Omnidex to fail if TurboStore has
opened the file first (i.e. for Long Mapped access).
Since it is unlikely that Omnidex will redesign its
internals to use Long Mapped access, a simple enhancement to
TurboStore could solve both problems. If TurboStore can
check the filecode before opening the file, and use Short
Mapped access if the filecode is either -410 or -411 (File
codes defined for Omnidex by the TPI specifications).
VERIFIER TEXT:
RCE- , MVRC
RCAA- , ATLRC
Submitting this request on behalf of the the customer, BOMBARDIER INC &
3rd Party Software vendor, Omnidex
MARKETING TEXT:
02/14/95 On the surface this appears to be a reasonable request but
I suspect that there is something ominous lurking in any attempt to
implement this (like enough people already mucking around in short point
er space already). Passing on for enlightenment.
02/21/95 MPE/iX Expert Center
After talking to the turbostore lab, we will ask OMIDEX to take another
look at making the enhancement request to their code instead. The basic
problem is that if Turbostore opens these files as short mapped, there
will increase the possibility of running out of short pointer space.
Turbostore keeps up to 30 files per son open and sometimes these files
are opened for long periods of time, depending on what type of files
are being opened. Since short pointer space is a limited system wide
resource, it is not a good idea to be yet another subsystem using it
up. Should this space be exhausted, other subsystems such as TurboImage
would be affected to the point of causing it to be unable to function.
A better solution would be for OMIDEX to use long pointers in the case
where turbostore already has the file open. I have contacted the account
team about this and they will persue it with OMIDEX.
6/21/95 MPE/iX Expert Center
While working on EC call W3292511, I received a copy of a FAX from
DISC (makers of OMNIDEX) recommending a workaround; so I'm documenting
it here:
"Here is a fully tested workaround: If you exclude the 0A file when
you store the database, this will still store the indexes. And
you'll just need a copy of the 0A file. The dbname0A file is
effectively our indexes "rootfile". Currently you may be backing
up @[log in to unmask]@. Our solution would be to add [log in to unmask]@ to exclude our 0A
file(s). Since the 0A, OMNIDEX rootfile, doesn't change, you could
take a copy of it from your most recent full backup and still be
safe."
------------------------------------------------------------------
Responce Center 6/28/95
SR 5003271023 came in today as a dupe of this. I did not want to
dupe it to a closed SR so I am moving this SR from ER-NO to ER-MAYBE.
I also sent the verifier a copy of the workaround documented
above just to be sure they tried it. This SR should stay open until
the issue is resolved - probably by a fix from OMNIDEX.
LAB TEXT:
Lab Engineer, 2/21/95:
I'm closing this as ER-NO, since we are going to try and get
Omnidex to fix the problem, due to the issues mentioned above by
Expert Center. If we cannot get Omnidex to fix it on their side, we can
reopen this SR.
-----------------------------------------------------------------
Responce Center 6/28/95
I've moved this SR from ER-NO to ER-Maybe because a new SR came
in. It's not clear whether the WA was not acceptable or they
didn't want to use it, but until the problem is fixed we should
keep an SR open for tracking purposes. Please note that it
is still expected that the fix for this problem is to come from
OMNIDEX.
************************************************************************
|
