Conference iosg::all-in-1_v30

    Julie,
    
    ALL-IN-1 only accesses PERM_DB, CACHE_DB, PERM_AIF, CACHE_AIF
    and INQUE, OUTQUE, NETQUE, NIF and LOG and all of these via calls
    to the DDS callable-interface - no DDS files are accessed directly
    by ALL-IN-1.
    
    the documentation on the DDS callable Interface doesn't list any calls
    to IDSEC so it must be something internally in MR (DDS$TIDY??) that
    does this.
    
    Maybe our Message Router wizard GASH knows more???
    
    Regards,
    
    Andrew.D.Wicks

    Hi,
    
    Thanks for the reply,
    
    This file must be accessed from somewhere within ALL-IN-1, as quite a
    few customers have seen this intermittent problem. 
    
    Does anyone else have any ideas?
    
    	Thanks,
    		Julie	

    SWAG:
    
    Don't we turn off DDS temporarily whilst using the subprocess? Does
    spellchecking use the subprocess? Could the DDS stop be causing the
    problem?
    
    I can't see how else spell checking could involve DDS!!
    
    Graham

    No.
    
    We turn DDS off when we do a SPAWN or an ATTACH (due to VMS' wierd
    handling of AST delivery - if we didn't do this, DDS would be blocked
    in some circumstances by any ALL-IN-1 process which was sitting in a
    SPAWN or an ATTACH).
    
    Dave.

    After scanning the sources and pondering things a little bit, I come up
    with one possibility. I have some questions:
    
    1) Were the DDS server processes running, or had DDS been stopped and 
       started while ALL-IN-1 users were active?
    
    2) Does this only occur whilst spell-checking, or does it occur in
       other ALL-IN-1 subsystems (.0 isn't clear on this)?
    
    3) (to IOSG) If only whilst spell-checking, does IOS play with current
       privileges prior to entering this subsystem?
    
    There are a number of AST driven subsystems/threads in DDS. Most of
    these DDS subsystems can be "owned" by any active DDS process. Normally
    these subsystems end up being the responsibility of a DDS server process, 
    since they get started up first. However, in certain unusual cases, a
    given subsystem _could_ be owned/serviced by a DDS client. (Note that
    if the current "owner" of the subsystem exits, another DDS process
    simply takes over responsibility for servicing requests for it). All
    active DDS clients require that a certain minimum set of privs always
    be enabled, since this AST driven processing can occur at any time.
    
    The particular error indicated in .0 is reported from a routine that
    performs a refresh operation of the IDSEC file, and is due to an
    inability to $OPEN (or $CREATE) the file. The questions above will
    hopefully shed light on how/why the ALL-IN-1 user process became
    responsible for this, and why it was unable to access the file.
    
    	Dave

    Yes, I believe 3) is why we run with SYSLCK turned on all the time
    (note to Dave L - ALL-IN-1 turns off all its installed privs as soon as
    it starts up - except any held by the invoking process and SYSLCK. It
    only turns them on briefly when it's sure it needs them. This is to
    avoid it being fooled into using its privs to allow a hacker to access
    files they shouldn't).
    
    Dave.

    
    
    Is there any further information on this, is it know yet how to stop
    this error messge form being generated.
    
    
    Mike Nayler

    .5 seems to me, to be asking for some further information. Do you have
    any?
    
    Graham

    
    Just to bring this notes thread back to life:
    
    I've just had a call from a customer who gets exactly the same problem.
    His users have seen this problem when spell checking, when attempting
    to send a mail message, and also when pressing {RETURN} after filling
    in a correct address on a mail header. 
    
    In the latter case, they repeatedly got the error, until they logged
    out of ALL-IN-1, and re-entered.
    
    DDS has not been restarted while the ALL-IN-1 sessions were active, and
    I've just spoken to the customer, and apart from the three occurances
    of this in one day they haven't seen the problem since.
    
    Any more ideas or suggestions?
    
    Thanx
    
    Steve

    Thanks for the additional info - I keep checking here periodically
    hoping for some more... I'm pretty sure I know where the error is
    occurring and why (unfortunatly the fix will _not_ be simple), but 
    I still can't figure out how a "user" process could have become 
    responsible for that DDS AST thread in the first place.
    
    You indicate that "DDS has not been restarted while the ALL-IN-1
    sessions were active" - does this mean it _was_ restarted?? Also,
    is this a single node, a cluster, etc??
    
    Thanks,
    	Dave

    
    
    I hate to do this but is there an SPR for this problem?
    Or has it never been `officially' raised
    
    
    (Sorry Dave but me customer wants something formal)
    
    
    Mike Nayler
    UK CSC

    No reason to hide...
    
    No we've received no official problem reports on this via SPR, CLD,
    FORTY2::MAILBUS, etc... The only hint I had that this was occurring
    was this note (though someone just posted something in the MAILBUS
    conference wrt Teamlinks that may or may not be related).
    
    Dave