Conference pamsrc::objectbroker_development

2466.0. "DECEDI$CONFIGURE_ACAS ACCVIOs" by MUNICH::WWERNER (When in doubt, do as the INTs do) Mon Apr 14 1997 12:46

Hello !

A customer has a strange problem with DECEDI V2.1D and Objectbroker V2.7-10.
on OpenVMS Alpha V6.2

The command (this is the fourth 'reg impl')
$ appl/brok reg impl/replace decedi$tools:decedi$imr_reg.dat
from DECEDI$CONFIGURE_ACAS.COM fails with the following

%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=495F524D,
PC
=8048ECB8, PS=0000001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
  image    module    routine             line      rel PC           abs PC
                                            0 FFFFFFFF8048ECB8 FFFFFFFF8048ECB8
                                            0 FFFFFFFF805B61AC FFFFFFFF805B61AC
 OBB$SHR                                    0 00000000000DE65C 000000000033C65C
 OBB$SHR                                    0 00000000000D64CC 00000000003344CC
 OBB$SHR                                    0 00000000000E81CC 00000000003461CC
 OBB$CMDSHR                                 0 0000000000049100 000000000008B100
 OBB$CMDSHR                                 0 0000000000046C48 0000000000088C48
                                            0 000000007EF49C60 000000007EF49C60
                                            0 FFFFFFFF8002B3F4 FFFFFFFF8002B3F4
                                            0 FFFFFFFF8002B3F4 FFFFFFFF8002B3F4
 OBB$CMDSHR                                 0 000000000009B194 00000000000DD194
 OBB$CMDSHR                                 0 000000000000015C 000000000004215C
 OBB$CMD                                    0 000000000002040C 000000000003040C
 OBB$CMD                                    0 0000000000020058 0000000000030058
                                            0 FFFFFFFF8359E170 FFFFFFFF8359E170

The virtual address translates to 'MR_I'. This string could be found in 
DECEDI$IMR_REG.DAT. 

SDA> MAP 8048ECB8
Image Resident Section                  Base      End       
LIBOTS                                  8048E000  8049CC00  

After that the registry was corrupt. Fortunately, older versions of
OBB_SOFTWARE_REGISTRY.REG were still there.

Up to now not so strange...

BUT:

I could reproduce this under the following circumstances:

I did a deinstall of ObjectBroker (delete files in OBB$LIBRARY, SYS$SHARE,...)
then reinstalled it from CD. Then I executed a COM file containing the 6
REG IMPL commands (extracted from DECEDI$CONFIGURE_ACAS.COM). The ACCVIO 
occurs. 

Then I deleted the new versions OBB_SOFTWARE_REGISTRY.REG, retried. Same ACCVIO.

Again deletion of the OBB_SOFTWARE_REGISTRY.REG files, LOGGED OUT and IN AGAIN:

problem disappeared...


Any hints ?

Wolfgang

    Hi Wolfgang,
    
    there are some notes in the DECEDI notesfile about a crashing
    configure_acas.
    
    I'm not sure it's about exactly the same problem, as I use OBB V2.5 or
    V2.6.
    A workaround has been to use a 'set verify' before running the
    procedure.
    
    GJ

    Could you copy the command procedure, the initial software registry,
    and the .dat files to send:: and then write up how to reproduce the 
    problem. We can try it here with a debug version.
    

.1: unfortunately, SET VERI does not help. 
.2: file is SEND::NOTE2466.SAV

Btw.: on one node on customer site even LOGOUT/LOGIN does not solve the
problem. He had to manualy register DECEDI$IMR_REG.DAT before starting
DECEDI$CONFIGURE_ACAS.COM

Wolfgang

Hi,

Sven-Olof KLasson seems to have done a good analysis of this.

DEC/EDI V2.1D is built on ObjectBroker V2.6.

If DEC/EDI is installed on a system running OBB V2.6 then everything works
just fine. If  OBB V2.6 is upgraded to V2.7 - everything still works fine.

However if the procedure is run on a system that is a new V2.7 install then
there are the problems reported (and others). 

The good news here is that you don't need to install DEC/EDI to reproduce
this.


We were aware that Object References changed between V2.5 and V2.6,
have they changed again between V2.6 and V2.7?  We appear to benefit from
some migration you do in between V2.6 and V2.7 that is not present
in a clean V2.7 install.

Mark

  

Hi,

would it be possible for this to be looked at as soon as possible? I think .0
may IPMT it as well.

As near as I can tell there is no DEC/EDI code involved in this, we are
sinply registering things using scripts that are pretty old.

I've just come back from a user group where I was advising customers
to go to OBB V2.7. If that's bad advice I need to correct it quickly.

THanks
Mark