| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 3830.1 | | ADA9X::BRETT | | Wed Dec 18 1996 13:16 | 9 |
| 3830.2 | | KMOOSE::CMCCUTCHEON | Charlie McCutcheon | Wed Dec 18 1996 13:56 | 8 |
| 3830.3 | | TAV02::MILCHIN | | Thu Dec 19 1996 12:11 | 23 |
| 3830.4 | Next steps... | ADA9X::BRETT | | Thu Jan 02 1997 13:58 | 52 |
| 3830.5 | Problem being worked on | KMOOSE::CMCCUTCHEON | Charlie McCutcheon | Fri Jan 31 1997 13:30 | 6 |
| FYI, we're working with the customer offline on this issue.
Results are slow due to their inability to release any code to us.
Charlie
DEC Ada
|
| 3830.6 | Problem Id'ed | ADA9X::BRETT | | Fri Feb 07 1997 11:45 | 46 |
| OKAY! I know what the problem is! I had given the customer a debuggable
compiler, and have been sending them debug scripts and getting back the
results. The last result (appended to this reply) clearly shows the problem.
CLIO creates a burst of ISAM records for a compilation unit. Because the info
for a compilation unit can be quite long, it uses a secondary (tertiary?) key
to spread the info across this burst, just numbering them.
When it replaces a unit, it first deletes all the records for the old unit,
and then writes the records for the new unit.
Under some (as yet unknown) circumstances it does not delete all the old
records.
When it goes to write the new records, it gets RMS$_DUP. This particular
error path DOES NOT EMIT ANY ERROR MESSAGES! So the compilation unit is
silently only partially added to the library.
I am working on a fix to CLIO, and pondering what the (as yet unknown)
circumstances might be.
/Bevin
From: US2RMC::"agmon@ppantr.iso.dec.com" "Ronen Agmon" 7-FEB-1997 08:35:00.29
To: ada9x::brett
CC:
Subj: Re: Next step
set lang bliss
set modu clputlib,clioalb
set bre clio_upd_dir
Go
!break at routine CLIOALB\CLIO_UPD_DIR
set bre CLIO__UPD_ALB do (eval .OLD_CONT_REC_COUNT)
Go
!break at routine CLIOALB\CLIO_UPD_ALB
!00000000
set bre clio__put_alb_cont_rec do (s/ret; eval/cond .r0)
set bre %line 1629 do (eval/cond .s)
Go
!break at routine CLIOALB\CLIO_PUT_ALB_CONT_REC
!stepped on return from routine CLIOALB\CLIO_PUT_ALB_CONT_REC to
CLIOALB\CLIO_PUT_ALB_CONT_REC%LINE 1549+3
!%RMS-F-DUP, duplicate key detected (DUP not set)
Go
|
| 3830.7 | | ADA9X::BRETT | | Fri Feb 07 1997 14:08 | 10 |
| > it uses a secondary (tertiary?) key to spread the info across this burst,
> just numbering them.
Not quite - it actually breaks the primary key into three pieces
the truncated name
the uniqifier
the continuation index
Combined, the first two pieces identify the unit.
|
| 3830.8 | Probable fix in future release | KMOOSE::CMCCUTCHEON | Charlie McCutcheon | Mon Feb 24 1997 18:29 | 8 |
| We have a likely fix for this problem, which would show up in a future
release of DEC Ada.
(Potentially the Alpha VMS V3.3 ECO kit I'm working on, and VAX VMS V3.4.
I've mailed .0 to ask for confirmation on the fix, since the user could
not submit a reproducer...)
Charlie
|
| 3830.9 | Fixed in V3.4 for VAX | KMOOSE::CMCCUTCHEON | Charlie McCutcheon | Fri Mar 14 1997 16:56 | 9 |
| This is a quick update to let you know that this problem is fixed
in DEC Ada V3.4 for OpenVMS VAX, field test 1. We expect it to be included
in the final SSB release.
Please have the customer contact FT_QUESTIONS@LEGO.ENET.DEC.COM if they'd
like to become a DEC Ada field test site. (And hurry, field test is
expected to be quite short!).
Charlie
|
| 3830.10 | | KMOOSE::CMCCUTCHEON | Charlie McCutcheon | Mon Mar 24 1997 15:50 | 3 |
| >Potentially the Alpha VMS V3.3 ECO kit...
Kit name is ADAAE23033, and is being processed for submission.
|