[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

1185.0. "EM attachments selected from non-MAIN drawer" by GIDDAY::LEH () Wed Aug 05 1992 09:36

	IOS 3.0 on VMS 5.5-1 system

There seems to be a bug with printing a READ document that has an attachment 
selected from a non-MAIL drawer. One typical problem being the control block 
is not processed, rather it's treated like ordinary text. Try this:

o create a document say XXX in TEST drawer. It contains;
	----------START CONTROL---------
	printer format landscape 
	----------END   CONTROL---------

o create an EM and attach XXX, send it

o read new mail the print it. 

The output has a normal mail header and on a second page, the text 

	printer format landscape

is printed and the rest of document XXX ignored.

It seems to work OK with attachments taken from MAIL drawer. Detaching 
attachments to separate documents and doing the printing from IA (index 
attachment) also worked fine.

This problem seems to happen on both private and shareable non-MAIL drawers.
Has anyone come across it ?

Hong
T.RTitleUserPersonal
Name		DateLines
1185.1When your software can't say no ...IOSG::MAURICECeci n'est pas une noteWed Aug 05 1992 10:2618
    Hi Hong,
    
    The underlying problem is a bug in the CAB$ATTACH data set. The
    difference between attach from the MAIN drawer and an attach from the
    other is that the first gives the attachment an attribute DFORMAT with
    a value of blank, the second does not have an attribute DFORMAT.
    Unfortunately CAB$ATTACH, if asked to provide a value for an attribute
    that does not exist, cannot bear to disappoint the caller and so makes
    up a random 1-character value to return. This has the effect of fooling
    the printing logic when determining how to format the attachment.
    
    I wasn't aware of the problem you report, but it has emerged recently
    in another guise where restoring documents with attachments leads to
    the same printing problem. 
    
    Cheers
    
    Stuart
1185.2how to obtain this attribute ?GIDDAY::LEHWed Aug 05 1992 11:1316
    Stuart
    
    Thanks for the interesting insight
    
    Just curiosity, why do I keep getting null value for the symbol that
    equates to:
    
    CAB$ATTACH_ATTRIBUTES.VALUE["DFORMAT"]
    
    for ANY message with attachments ?
    
    For this problem, is there a simple workaround via script changes ?
    
    Thanks
    
    Hong
1185.3Possible workroundIOSG::MAURICECeci n'est pas une noteWed Aug 05 1992 15:0626
    Hi Hong,
    
    If the document being attached has a blank Handling field (the FORMAT
    field) then the resultant attachment will have a blank DFORMAT field.
    
    For an example of getting a non-blank DFORMAT you could use the U
    (update) option on a document and change the handling field. Then
    attach the document. After the attach do 
    
    <for cab$attach do get CAB$ATTACH_ATTRIBUTES.VALUE["DFORMAT"]
    
    This will return a non-blank value.
    
    As to a work-round a possibility would be to find the place in
    WPPRINT.SCP that fetches the value of the DFORMAT
    attribute and check that the length of fetched value is 1 and if so
    blank it, i.e.
    
    .if fn$length(#PRINT_FORMAT) eq 1 then get #PRINT_FORMAT = ""
    
    All the usual caveats apply (use SCM, don't blame me!), and I'm sure
    there must be a more elegant work-round. 
    
    Cheers
    
    Stuart
1185.5SRF ref as THR-16679GIDDAY::LEHWed Aug 12 1992 06:131