Conference orarep::nomahs::dbintegrator_public_public

    I have some more info: Both systems are on OSI. The last system changes
    were around mid april (VMS 6.2). After the reboot everything was
    working. After a generator check (they call it Diesel test) and the
    following reboot some 2 weeks ago, it stopped working.
    
    In that period on the DBI machine were installed Sql Services ECO2 and
    the ALP security patch, on the Rdb machine (vax) I couldn't find any
    .VMI_DATA.
    
    Also, they did some renames on proxies and node names, but the DTM part
    seems to be ok (log file names).
    
    Thanks,
    Regina
     

    
    Hi Regina,
    
    We have seen hangs when the DECdtm log file is full.  You may want to
    look on the node where the remote database exists and do an:
    
    mcr lmcp
    
    sho log/current
    
    If you see that there is a stall in progress that would mean the decdtm
    log file needs to be emptied.
    
    If not then post a note here and we'll put the high power thinking caps
    on.
    
    Dan

    Hello,
    
    no it is no full dtm logs problem, I have checked that. Customer can't
    transfer data since about 2 weeks, and called us after DEC said it must
    be DBI and/or Rdb. 
    
    Would a recreate of a new dtm log be worth a try? RDB$REMOTE access
    works fine, so I really suspect s.th. on the system side, but where?
    
    Should I force them to install the DTM ECO?
    
    Thanks for any hint,
    Regina
    PS: I have online access to the systems

    I would definitely insist that they install the latest DECdtm patches.

    
    I agree with Paul - they should install the latest ddtm patches.  The
    other thing I would suggest looking at is also DDTM related - since the
    node was renamed make sure the stuff that ddtm uses also got updated - I
    think they use either sys$node or scsnodename but you may want to check
    in the movies::decdtm notes conference to find out (I haven't used ddtm
    on an OSI system).  Also the DDTM log file would need the new node
    name.
    
    Hope this helps, let us know if there is still a problem after checking
    on those things.
    
    Dan

Unfortunately I can't look into Dec's Notes anymore. Though, as Dec still
accesses the now Oracle notes, it would be a nice idea if we could look at
Notes like DTM and VMS and while we are at it compilers and ACMS and OSI
and... 
Am I too demanding...? ;-)
Regina
      

    
    Hi Regina,
    
    Could you define some trace flags and mail us a pointer to the trace
    file (don't post it here - it will be quite verbose).  I contacted one
    of the DDTM folks via mail and we will probably have two or three
    rounds of stuff for you to do before we actually track this down.  I'm
    not sure what else to do.  We might be able to streamline things if we
    can get dial in access to your system.
    
    For now, can you:
    
    $define dbi_trace_flags "SDI,MDM_ATT"
    $define dbi_trace_output "FILE.EXT"
    
    then send us or post a pointer to the file.ext?
    
    Thanks,
    
    dan

    
    Hi Regina,
    
    We got the trace flags results - this confirmed that indeed the hang is
    happening on a start transaction.  I'm not sure it is DDTM related
    though.
    
    Can I ask a few more questions?
    
    1) Can the remote database be accessed from the remote node without
    dbi, i.e. can a user from the node dbi is installed on attach to the
    remote database and start/commit transactions without a problem?
    
    SQL> attach 'file node::bere$test';
    etc.
    
    2) if that works, can you check node grdba2 and make sure ddtm has a
       log file and that it has the right name (i.e.
       sys$journal:system$grdba2.lm$journal i believe would be the right
       name.
    
    3) Please confirm that the dbi catalog is not also the database that
       has the table you are trying to import (the catalog cannot also be a
       database that contains other data)
    
    4) if test 1) works, 2) is OK, and 3 is OK, then can you create a file in 
       the user's default directory called rdb$client_defaults.dat?  In
       that file include the line:
    dsp_debug_flags TRUE
    
    Some extra output should now go to the user's screen.  Can that screen
    be sent to us to we can see what call dispatch was making when things
    hung?
    
    Thanks,
    
    dan

Since they have patched the DECDTM with ALPDDTM02_070 on the 
DBI machine all is ok.

Thanks to all
Jean-Luc