Conference iosg::all-in-1_v30

    Hi,
    
    The release notes off ALL-IN-1 3.0A state these conversion
    problems have been solved. Its not clear how. Perhaps
    someone from IOSG can shed some light on this dark issue.
    
    Regards,
    
    Jan
    
    
        2-6 Problems Solved By This Patch Kit
    
        2.1.25 Improved TeamLinks/IOS interoperation

              When messages containing PC document types, for example
              MicroSoft[TM] WORD[TM], are sent to ALL-IN-1 users by
              TeamLinks or MAILworks users, the ALL-IN-1 users cannot
              easily read or print the message content. They first
              have to extract or copy the message and may also have
              to perform conversions.

Some changes has been made in the MUP by making use of the Handling attribute.
I've included extracts from the ICOs which introduced this change.

If the current message/attachment being disassembled has a "FOREIGN"
document type then the current RMS semantic tag check is performed. If the
message file has a valid semantic tag the current message/attachment filename
is redefined with the new message file extension being set from the semantic
tag.

In addition, if the message file is found not to have a semantic tag or the
semantic tag validation (via OAET table lookup) fails, then a check is
made to see if the message/attachment has a handling value supplied. If
present, the handling value is validated in the FORMAT master file to
determine if a message filename redefinition needs to take place, with the new
message file extension being set from the default file type field value
specified in the FORMAT master file entry.

ALL-IN-1 V3.0 supports the use of CDA converters to display the contents of
documents and messages when a file cabinet entry meets the following
conditions:

    1.  The data-type (DSAB) is FOREIGN

    2.  The file has an RMS Semantic tag, or

    3.  If no RMS tag, the file type of the file specification (e.g. .RTF)
        is defined in the OAET CDATYPES table.


In V3.0 this mechanism only worked when processing file cabinet documents AND
the dataset was selected from the file cabinet information, i.e., the data type
was FOREIGN.  It was not used when the dataset was selected from the file
type.  

In the MUP, when the search key is file type (or extension) and an entry is not
found then the CDATYPES table is searched so see if this is a CDA supported
type.  If so, the dataset is set to FOREIGN.  When the FOREIGN dataset is used
it will then call the CDA text formatter to read the document.
 

    Hi,
    
    Its been a while since I looked at this but if I recall correctly there
    is no Word for Windows converter but you can send the message as RTF
    version 2.
    
    Save the document in the file cab as RTF2 and also copy the ALL-IN-1
    RTF format to RTF2.
    
    You should now be able to send the document.  Unfortunately I wouldn't
    say the conversion is brilliant, so I wouldn't go too heavy on the
    formatting in the document.
    
    When transfering mail in the other direction you may need to make some
    changes in the DEC MAILworks server and ensure that WPS-PLUS is NOT a
    valid format for the client so that conversion is forced.  I'm sorry
    but I'm even hazier on how to do that part.
    
    Regards,
    ajb

    Hello Eileen,
    
>present, the handling value is validated in the FORMAT master file to
>determine if a message filename redefinition needs to take place, with the new
>message file extension being set from the default file type field value
>specified in the FORMAT master file entry.
    
    Can get this to work. Could you post the FORMAT record for RTF2 ?
    
    Thanks,
    
    Jan