[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

3798.0. "Copy error when user attempts to print FOREIGN document" by SEDOAS::DAVIES_G (GLYN DAVIES @ESO) Mon Jan 24 1994 09:46

    I am having problems around storing FOREIGN documents in the file
    cabinet.
    
    I have a customer with ALL-IN-1 IOS and TeamLinks and they are now
    getting to the situation where they will be mailing PC files around and
    storing PC files in the IOS file cabinet.
    
    I have done some tests and found a problem when a user tries to print a
    FOREIGN document that has been stored in the IOS file cabinet.
    
    In this particular case the FOREIGN document is a PowerPoint file with
    a handling of POWERPOINT2.
    
    When a user selects this document and tries to print it the following
    message is diaplayed:
    
    	Problem with copy function - file OA$SHARE;[email protected]
    	RMS-W-RTB 989978 byte record too large for users buffer
    
    Looking at this in more detail it seems to be the following line in
    FILEFORMAT.SCP that is the culprit:
    	
    	COPY #FILEFMT_SRC_FILE #FILEFMT_DEST_FILE TXT$COPY_PRINT
    
    What is going wrong?
    
    I would have thought that the processing in WPPRINT or FILEFORMAT would
    have stopped this operation taking place on a FOREIGN document and
    generated some sort of FOREIGN documents cannot be printed message.
    
    Any help would be appreciated.
    
    Regards,
    
    Glyn
T.RTitleUserPersonal
Name
DateLines
3798.1FORMAT master entry?IOSG::NEWLANDRichard Newland, IOSG, REO2-G/L2Mon Jan 24 1994 10:4015
>    I would have thought that the processing in WPPRINT or FILEFORMAT would
>    have stopped this operation taking place on a FOREIGN document and
>    generated some sort of FOREIGN documents cannot be printed message.

WPPRINT and FILEFORMAT uses information in the FORMAT master to find out
how a document should be formatted.  'FOREIGN' means that the format is not
fully supported by the Text dataset mechanism, but it does not necessarily
mean that a document cannot be formatted by another mechanism, e.g. CDA.

Is there a POWERPOINT2 FORMAT master entry.  Such an entry tells ALL-IN-1
how to format the document for printing?  If there is not an entry ALL-IN-1
will default to ASCII formatting, which appears to be what is happening. 


Richard
3798.2It works OK when I read documentSEDOAS::DAVIES_GGLYN DAVIES @ESOMon Jan 24 1994 11:3528
    Richard,
    
    No I havnt got an entry in the FORMAT master for POWERPOINT2 as I havnt
    written any special formatting script for this format.
    
    Basically I want the same thing to happen when the document is printed
    as when it is read. ie a FOREIGN document type cannot be displayed
    message.
    
    I dont particularly want to have to create a FORMAT master entry for
    every possible format that a user might receive attached as a mail
    message.
    
    I think that the problem may be around the file extension that the
    document receives when it is inserted into the file cabinet.
    
    If I do a DT RCV on the file a copy of it with a .FGN extension is
    created and I get the FOREIGN document cannot be displayed message.
    
    If the document is detached from a mail message sent from a TeamLinks
    user it is created with a .PPT file extension and I get the COPY error
    when trying to print.
    
    Something appears to be going wrong here.
    
    regards,
    
    Glyn
3798.3More information on problemSEDOAS::DAVIES_GGLYN DAVIES @ESOMon Jan 24 1994 14:0045
    Richard,
    
    The problem does seem to be with the .FGN file extension. I have done
    the following tests on an ALL-IN-1 IOS system that will be supporting
    both interactive VT users together with TeamLinks users.
    
    1. From a TeamLinks session I sent a mail message with a PowerPoint
    attachment to an interactive ALL-IN-1 IOS user.
    
    - The interactive ALL-IN-1 user reads the message and gets the
    following message:
    
    	Document with ".PPT" file type cannot be displayed
    
    - The interactive ALL-IN-1 user files the attachment. The attachment
    is stored with a FOREIGN DSAB and given a file extension of .PPT.
    
    If the ALL-IN-1 user now tries to print the filed attachment I get the
    error message relating to the COPY function as outlined in .0
    
    2.. From a TeamLinks session I sent a mail message with the same PowerPoint
    attachment to  the same interactive ALL-IN-1 IOS user. However this
    time I force the message through Message Router.
    
    - The interactive ALL-IN-1 user reads the message and gets the
    following message:
    
    	FOREIGN document type cannot be displayed
    
    - The interactive ALL-IN-1 user files the attachment. The attachment
    is stored with a FOREIGN DSAB and given a file extension of .FGN.
    
    If the ALL-IN-1 user now tries to print the filed attachment I get the
    FOREIGN document type cannot be displayed message as I would expect.
    
    This would seem as if it is going to be a major problem with customers
    who are using the same IOS server for interactive and TeamLinks users.
    
    Any ideas on what can be done to address this.
    
    Regards,
    
    Glyn
    
    
3798.4Add FORMAT master entryIOSG::NEWLANDRichard Newland, IOSG, REO2-G/L2Tue Jan 25 1994 14:5619
You did not say what version of ALL-IN-1 you are using but if it is V3.0A 
then the only way of getting a better error message displayed is to add a 
FORMAT master entry.  The Print Function in the FORMAT master entry should
call a script which returns displays a suitable message and returns an
error status. 


Since ALL-IN-1 V2.2 (and perhaps earlier but that's before I worked on
ALL-IN-1) formatting for printing has always defaulted to ASCII formatting
if no other method is defined.  This may no longer be the best thing to do
but any changes we make also have to consider sites which rely on the
current behaviour. 

The issue is noted and improvements will be considered for inclusion in a 
PFR.


Richard