Conference iosg::all-in-1_v30

595.0. "Packed Decwrite/eps files mailed over X400 ?" by COMICS::BARHAM (Norbert:) Wed Apr 29 1992 13:27

    ALL-IN-1 v2.4/v3.0 PBL122D British
    
    I have a customer running ALL-IN-1 2.4 who has a Decwrite DDIF document
    with a link to an EPS file. He asked me if it was possible to import
    this document into ALL-IN-1 and send it via x400 mail, retaining the
    original format and link to the EPS file so that they could work on the
    document at the receiving end. I think not.
    
    We can convert the whole lot to postscript and Gold Get that in and
    mail it, but that's not good enough because that's final format.
    If we get the DDIF file in, it strips out the EPS so that's no use
    either. 
    
    I see in v3.0 that doing a Document Transfer DT RVC asks you :-
    
    Are referenced files to be processed as well [Y/N] ?
    
    to which I answer Yes as I assume it's talking about the link to the
    eps file.
    
    It then asks :-
    
    Create a PACKED version of the document [Y/N] ?
    
    If I answer YES, it creates a DOTS file which I can attach to a mail.
    When I send it via ALL-IN-1 mail to myself and file the attachment it
    asks :-
    
    File an unpacked version of the attachment [Y=Unpack/N=Pack]
    
    I answer Yes and it says :-
    
    %OAFC-W-CARDIDNF, File Cabinet object does not exist, Attacment not filed
    
    The object does exist and the server is running.
    
    Running OAFC_LOCAL_PHASE_IV_NAMES.SCP as per note 166.17 gives 
    
    Logicals for partition names are not defined correctly, at which point
    I lost heart !
    
    Looking at the trace, in EM_FATT_DOC.SCP, it fails doing
    
    CABINET FILE_ATTACHMENT ,#CURATTACH,#FOLDER,#TITLE,#UNPACK_VALUE
    
    I note the lack of the initial doc-sym parameter but putting that in
    with a value of oa$curdoc gives the same result interactively. Putting
    "Y" in for #UNPACK_VALUE also gives the error but removing
    #UNPACK_VALUE parameter altogether does not give the error.
    Documentation says if the symbol is missing, ALL-IN-1 does not unpack
    the attachment.
    
    Anyway, I'm not too bothered about fixing my problem, rather answering
    the customers question :-
    
    If on a working system, we DT RVC a Decwrite document with a link to an
    eps file and create a Packed version (DOTS), can I then send this over X400
    and unpack it at the other end and SVC the constituent parts back to
    VMS where Decwrite can work on them at the receiving end ?
    
    Thanks
    
    Clive
                                      

    Also forgot to ask, if this functionality with packed CDA documents in
    v3.0 is what will fix my problem, is there an equivalent method in 2.4.
    
    (And why aren't the packing/unpacking questions documented under DT RVC
    and FA ?!)
    
    Thanks
    
    Clive
    

    If I understand what you're customer is asking, yes it is possible. (I'm
    assuming that sending through x400 doesn't `corrupt' the message.) Note
    that SVC will do the unpacking, there's no need for any explicit unpack
    stage. Remember, also, that packing breaks LiveLinks.

    However, in case I've misunderstood I'd like to know:
    - The versions of VMS, DECwindows, and DECwrite they are using.
    - The location type of the EPS link (w/ document, private/system/network
      library)

    As for your V3.0 problem, I'll leave it to a FC/FCS person to explain.
    When I tried (with SSB V3.0, VMS V5.5, DECwrite V2.0, DECwindows V2 + CDA
    patch supplied with ALL-IN-1 V3.0) it worked for me.
    
    Cheers,
        Paul