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

Conference iosg::all-in-1_v30

Title:*OLD* ALL-IN-1 (tm) Support Conference
Notice:Closed - See Note 4331.l to move to IOSG::ALL-IN-1
Moderator:IOSG::PYE
Created:Thu Jan 30 1992
Last Modified:Tue Jan 23 1996
Last Successful Update:Fri Jun 06 1997
Number of topics:4343
Total number of notes:18308

2337.0. "Distributed sharing on foreign documents" by KERNEL::OTHENJ () Fri Feb 26 1993 14:54

Hello,

ALL-IN-1 v3.0

Can someone help me with a problem with the Distributed Sharing option 
within ALL-IN-1. If the customer reads a document of DSAB type FOREIGN 
within his folder, he gets the message

FOREIGN document type cannot be displayed

which he would expect. But if a remote user tries to access this document from 
another machine, on the Select form he gets the message

File does not exist

He is testing from the ALL-IN-1 managers account, and can read other wps 
documents successfully, so it cannot be a problem with the proxies.

I have tried testing a postscript and foreign type document on our system (one 
running v3.0, the other machine running v3.0-1) and find that I cannot 
recreate the problem. I have looked through the release notes for v3.0-1 
,and I cannot find anything to suggest that the patch would resolve the 
problem, but can anyone shed any light on this?

	Thanks,
		Julie
T.RTitleUserPersonal
Name		DateLines
2337.1Check FALIOSG::STANDAGEOink...Oink...MoooooooooooooooooooooooooooooooooFri Feb 26 1993 15:0425
    
    
    Julie,
    
    Certainly "FOREIGN document type cannot be displayed" should be
    returned from both a local and remote read on such a document, and my
    tests confirmed that. Is this problem restricted to only one remote
    user, or can it potentially happen to all the remote users on that
    particular node ?  
    
    Also, double check that this problem only occurs when the remote user
    attempts to read the FOREIGN file - and not for all document types.
    There is a problem with FAL where the FAL password in NCP does not
    match the password of FAL$SERVER in SYSUAF. This will cause a remote
    read to fail, but a remote edit to be successful. The reason is due to
    ALL-IN-1 using FAL for reading remote private documents, but when
    editing the same document the FCS is called.
    
    The easiest way for checking FAL and the proxy setups is to do a
    $DIR NODE:: from the remote user's account having the problems.
    
    
    Kevin.
2337.2Yes, there are inconsistencies.IOSG::CARLINDick Carlin IOSG, Reading, EnglandFri Feb 26 1993 16:2920
    Julie
    
    Without giving you the precise answer for this case, I can tell you
    that there are inconsistencies in some of the UI, in that a different
    (and misleading) error message is given if the document is remote.
    
    One example is if the document file is foreign. We do a
    get_rms_semantic_tag to try and find out more about the file. Any error
    return from this is reported as "File doesn't exist". Unfortunately we
    have no way yet of doing get_rms_semantic_tag on a remote file in the
    shared area (no access), so this will end up returning "File doesn't
    exist".
    
    At some time we hope to build more remote content operations into the
    File Cabinet Server, eg get rms attributes, but we can't promise
    anything yet.
    
    In the meantime we'll at least try and make the messages more accurate.
    
    Dick
2337.3KERNEL::OTHENJWed Mar 03 1993 17:3225
    Hello,
    
    Thanks for the replies.
    
    I am still a bit confused about this problem. From my ALL-IN-1 v3.0-1
    system, I sucessfully get the message
    
    FOREIGN document type cannot be displayed
    
    when reading a (personal) foreign document from another ALL-IN-1 v3.0
    system. But if I try (from the local system)
    
    <get_rms_semantic_tag #doc , #tag_sym     (where #doc = filename on
    					       local system)
    
    I received the error File not Found. Then I tried it a few more times,
    and suddenly it did not return an error anymore (Yes, I know this
    sounds like user error, but someone else was watching this to confirm
    it was not!!!!!)
    
    Is it just a case of 'it may work, it may not' , or is there any reason
    why I seem to get inconsistent results?
    
    		Thanks,
    			Julie