Conference rocks::dec_edi

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

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

    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

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

    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

    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

    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

    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