Conference iosg::all-in-1_v30

3753.0. "Transfered 500 users cannot print existing mail msgs" by GIDDAY::SETHI (Oh what a feeling .....) Wed Jan 12 1994 02:29

    Hi All,
    
    I have read note 3601 and was unable to reply to that note sometime
    last week so I sent an EM to the moderators as well as the engineers
    who had replied to the note.
    
    I have a problem at a customer site where they transfered 500 users
    from 1 system to another and now they are having problems with their
    mail messages.  Please find below a description of the problem the
    customer has sent to me.
    
    I had a reply via EM suggesting that WPPRINT.SCP needs to be changed. 
    Some how the nature of the problem does not point to WPPRINT.SCP, can
    someone help me out on this one.
    
    Regards,
    
    Sunil  
    
HISTORY
        2 of VAX Clusters were merged into one slightly larger
        VAX Cluster on w/end of 12-13 December 1993.

        ALL ALL-IN-1 users on the smaller cluser were transferred to the
        larger cluster in the 2 weeks prior to the merge, via the standard
        ALL-IN-1 Manager "Transfer User" options.

        We are running ALL-IN-1 V3.0 - no patches.
        Customisation is to the general user screen layouts mostly, with
        minimal to NIL customisation of system manager features.
        Customisations are identical on both systems.


OBSERVED PROBLEM SINCE TRANSFER

        OLD Mail messages, with Documents attached - when printed,
        a) produce massive quantities of printed giberish - as if the
           formatting did not correctly detect the document as a Wordperfect
           document.
        b) Sometimes the OA$FORMATTER queues become STALLED or STOPPED.
        c) Sometimes the OA$FORMATTER queue symbionts abort with an "ACCVIO"
           OPCOM message and a large .DMP file created in the sys$system dir.
        d) When a user tries to perform a GET DOCUMENT from within the editor
           (Wordperfect) sometimes the "Problem with Copy function" message
           is returned.

        All of these problems have been linked to
        1) users transferred,
        2) documents attached to mail messages,
        3) mail messages created & sent prior to the Transfer of users,
        4) probably a combination of all 3, however I have not tested further
           having determined attributes are the problem.
        5) NEW documents and mail messages created after the transfer print OK.


FINE ANALYSIS of Symptom Mail

        using A1 command    FOR CAB$ATTACH DO FOR CAB$ATTACH_ATTRIBUTES DO ...
        I was able to compare attributes on the attachments for problem and
        OK documents.

        I found that typically, mail message attached to a mail message have
        attributes duplicated - ie. JOB_NUMBER appears twice and are identical.

        I found that typically, a document attached to a mail message
        (regardless if it's the first or second or other attachement no.)
        have 2 attributes missing (DMAIL_STATUS value Null expected, and
        DFORMAT value of Null expected also),
        and have 6 extra attributes relative to mail messages
        which are normally not existing for DOCUMENT type attacments :
                DR, RR, PRIORITY, FORWARDABLE, SUBJECT, POSTED, and
                DAUTHOR appears twice.

        Trying to follow background printing process to determine why it mucks
        up the documents, I found an entry in WPPRINT.SCP, in both the version
        in OA$DO_SHARE and OA$SITE_DO, look for the line
                .label NEXT_ATTACHMENT

        the following lines refer to DATA_FILE functions to get attachment
        attributes - one of those is the field DFORMAT. A few lines further,
        an .IF function states if the Format is set then skip over some code.
        My programming experience tells me that if a field does not exist,
        the result of a GET will not set/change the destination symbol previous
        value.

        I wrote a quick and dirty procedure to list attachment attributes by
        using the DATA_FILE function to retrieve them shows the DFORMAT field
        on the attached document as "A" (using CAB$... shows it does not exist)
    
        I'll modify my test do-scripts that list the attributes and values to
        put the output into a file and post those to you soon.

        The SDAF corruption I referred to previously does not mean records are
        lost or unreadable, I meant the record content (attributes) are
        incorrect.

        Is there a tool or procedure I can write that will repair these
        attributes.  All attempts so far to set attachment attributes I have
        found a lack of information, telling me that a) it can't be done, or
        b) it's not documented for good reasons.

    Hi Sunil!
    
    	Talking to the engineers you mailed, the analysis was as follows:
    
    	- The transfer user functions don't copy DFORMAT if it is blank.
    	- CAB ATTACH doesn't expect the missing attribute and writes out a
    	  one character DFORMAT (the "A" you observed). Fixed in MUPA.
    	- WPPRINT.SCP doesn't expect the one character DFORMAT and causes the
    	  problems you are seeing.
    
    	You were sent an updated WPPRINT.SCP, doesn't it work around the
    	problem?
    
    	The duplicated attributes you have noticed are quite normal. To be
    	tidy they probably shouldn't be there, but they are not causing
    	your problem.
    
    	You should be able to fix the DFORMAT attribute with the CAB attribute
    	functions.
    
    Regards,
    Paul