[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference rocks::dec_edi

Title:DEC/EDI
Notice:DEC/EDI V2.1 - see note 2002
Moderator:METSYS::BABER
Created:Wed Jun 06 1990
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:3150
Total number of notes:13466

3024.0. "Shared lookup caching, V3.1" by CSC32::R_GOLLEHON () Fri Feb 21 1997 19:50

    Hello,
    
    I'm having some confusion around shared lookups under V3.1 and I'm
    hoping someone will be able to tell me what exactly I'm doing wrong.
    
    I've ComCen v3.1, MSWin v3.1, OBB V2.6, Intersolv Datadirect
    DEC/EDI server v3.1, Digital Unix 3.2C, Informix Online v7.12, OBB V2.6
    
    I've created a mapping table and want to add a shared lookup table.  I
    go into the Mapping menu and select Lookups... This gives me an empty
    Lookup Tables box...I then go to the Lookups menu and select Load...
    This displays my server node with no lookup tables, as none are defined
    yet.  I create a couple tables under the server node and select
    Store...  I'm asked if I would like to recache the the shared lookups
    on my server and I say yes.  Now the fun begins.
    
    I get a message box telling me:
    ======================================================================
    DEC/EDI GUI Server error:
    The DEC/EDI GUI Server failed to execute the command you requested.
    Please refer to the Error Log for details.
    ======================================================================
    
    "Hmmmm," says I.  I look in the error log on the server...nothing
    there.  It does look like a GUI OBB server is being started when I try
    to cache the tables.  I tried running the decedi_recache_lookups on the
    server, and that runs cleanly.  However, if I view the lookups there is
    nothing there.  If I get back into the mapper and load lookups from the
    server, the lookups are loaded.  If I do the recache again, I get the
    same error.
    
    Is there another error log somewhere that I'm missing?  Am I missing a
    step here?
    
    Any help would be appreciated!
    
    Thanks,
    
    -Robert
T.RTitleUserPersonal
Name
DateLines
3024.1SYSTEM::newdial_10.reo.dec.com::JOHNSONRichard Johnson , http://samedi.reo.dec.comThu Feb 27 1997 17:0815
Robert

Which account is ObbjectBroker proxied into (obbshpxy) ?

It is possible with V3.1 that if the cache was created by root
then a process operating via decedi will not have permission to
modify it.

Restarting decedi will remove the cache.
Amend the obb proxies to go via the root (0) account.

The error should have been logged into the error_log.
All the above has been fixed in V3.1A

Richard
3024.2I'll try thatCSC32::R_GOLLEHONMon Mar 03 1997 18:4629
Richard,
    
    Thanks for the response.
    
    
    
>Which account is ObbjectBroker proxied into (obbshpxy) ?

    decedi
    
>It is possible with V3.1 that if the cache was created by root
>then a process operating via decedi will not have permission to
>modify it.

>Restarting decedi will remove the cache.
>Amend the obb proxies to go via the root (0) account.
    
    Is this what is normally advised for 3.1?  I'll give this a shot...

>The error should have been logged into the error_log.
>All the above has been fixed in V3.1A
    
    Nope...no error that I could see.  Rechecked several times.
    
    I'll let you know how it goes.
    
    Thanks,
    
    -Robert
3024.3it worked...thanks!CSC32::R_GOLLEHONMon Mar 03 1997 18:531
    
3024.4Maybe not quite fixedCSC32::R_GOLLEHONThu Mar 06 1997 21:0722
    Strike that...it acted like it worked...for a while.
    
    Now I'm getting the following error in the error log when I try to
    recache my shared lookups:
    
    Mon Mar  6 10:46:07 1995 PID =  5177 NAME = DECEDI Set Recache Lookups Fla
    DECEDI__FAILMSLREAD (w), failed msl keyfile read
    /var/adm/decedi/data/DECEDI_MSL_KEYFILE.KEY
    
    The file does exist, but it's empty.  The proxies are now set to the
    root account and edi and obb have been shutdown and restarted many
    times.  The file mentioned is owned by decedi.
    
    I also don't always get this error when caching...sometimes I get no
    error at all.  However, if I execute decedi_view_lookups it tells me
    that the shared lookup cache has not been created.
    
    Any thoughts?
           
    Thanks,
    
    -Robert
3024.5SYSTEM::newdial_2.reo.dec.com::JOHNSONRichard Johnson , http://samedi.reo.dec.comFri Mar 07 1997 12:4215
Robert

When you get an error recaching the lookups please type

# ipcs

and

# ls -la  /var/adm/decedi/data/DECEDI_MSL_KEYFILE.KEY

when logged into a privilaged accout such as root
and post the results here.

Thanks
Richard
3024.6resultsCSC32::R_GOLLEHONMon Mar 10 1997 17:4234
    Hello Richard,
    
    Here are the results:
    
    Message Queues:
    T      ID     KEY      MODE        OWNER    GROUP
    q       0 1090534153 --rw-------      root   system
    
    Shared Memory:
    T      ID     KEY      MODE        OWNER    GROUP
    m       0 1381386241 --rw-rw----      root informix
    m       1 1381386242 --rw-rw----      root informix
    m       2 1381386243 --rw-rw----      root informix
    m       3 1381386244 --rw-rw-rw-      root informix
    
    Semaphores:
    T      ID     KEY      MODE        OWNER    GROUP
    s       0 1090534153 --ra-------      root   system
    s       1        0 --ra-------      root informix
    s       2        0 --ra-ra-ra-      root informix
    s       3        0 --ra-ra-ra-      root informix
    s       4        0 --ra-ra-ra-      root informix
    s       5        0 --ra-------      root informix
    s       6        0 --ra-------      root informix
    s       7        0 --ra-------      root informix
    s       8        0 --ra-------      root informix
    
    # ls -la  /var/adm/decedi/data/DECEDI_MSL_KEYFILE.KEY
    -rw-r-----   1 decedi   users          0 Mar  7 12:58 
         /var/adm/decedi/data/DECEY
    
    Thanks,
    
    -Robert
3024.7SYSTEM::newdial_4.reo.dec.com::JOHNSONRichard Johnson , http://samedi.reo.dec.comMon Mar 10 1997 18:1021
    Robert

    >I also don't always get this error when caching...sometimes I get no
    >error at all.  However, if I execute decedi_view_lookups it tells me
    >that the shared lookup cache has not been created.

    If and only if the shared lookups cache exists will recache set the
    'recache' flag. If the shared lookups cache does not exist then
    recache should simply exit doing nothing.

    The error that recache is reporting should be ignored because
    there are is no lookups cache to reache.

    The shared lookups cache is created when and only when the mapping
    server needs to access a $LOOKUP_SHARED(expr,expr) translation.

    If the recache problem persists even when the shared lookups cache
    exists then please reply here.

    Thanks
    Richard
3024.8been there, done thatCSC32::R_GOLLEHONMon Mar 10 1997 18:5349
    Hello Richard,
    
    Well, I had assumed that the nonexistance of the cache was the problem,
    since when my table gets to the $LOOKUP_SHARED translation I get an
    internal error.
    
    Here's the error from the debug file:
    
    =================================================================
     Mapping Assignments:
     FOB_01 = $LOOKUP_SHARED("SHIPMENT",FOB);
          VALUE SET TO: "PR"
    
    -------------------------
    
     Mapping Assignments:
     FOB_01 = $LOOKUP_SHARED("SHIPMENT",FOB);
    
    DECEDI__STACK_ERROR (e), FileBridge internal error - stack not empty
    after expression
      FILE=1, DOC=1
    SOFT ERROR: document aborted, continuing with the next document
    =================================================================
    
    Please note that a value was assigned...the following is the somewhat
    different error from the same run that was listed in the output file:
    
    =================================================================
    Copyright Digital Equipment Corporation 1990,1995. All rights reserved.
    FileBridge Tracking Run ID: 000042
    Shared Lookup Table name not specified
     Mapping Assignments:
     FOB_01 = $LOOKUP_SHARED("SHIPMENT",FOB);
    
    DECEDI__STACK_ERROR (e), FileBridge internal error - stack not empty
    after expression
      FILE=1, DOC=1
    SOFT ERROR: document aborted, continuing with the next document
    
    normal completion - no documents generated - SEND
    =================================================================
    
    This is why I thought it might be a problem with the lookup table cache
    creation.  I've tried executing the post from both my account and from
    root, same result.
    
    Thanks,
    
    -Robert
3024.9still trying to shareCSC32::R_GOLLEHONThu Mar 27 1997 17:587
    Any thoughts on this (-.1)?  I am still at a loss to get the shared lookups
    working and have a customer who is having other annoying problems which
    because of this I am unable to reproduce the problem.
    
    Thanks,
    
    -Robert