Conference iosg::all-in-1_v30

3601.0. "Transfer users to another system and Shared mail files" by BACHUS::BERVOETS (Luc Bervoets - CSC Brussels alive and kicking) Mon Nov 29 1993 23:57

Hallo,

When transferring  a user from node A, where we have 5 mail areas, and 1000
shared directories in OA$SHARE , to a node B (in this case BRUOA2) which has
1 mail area (OA$SHARE) with 75 directories, I get lot of problems notified by
the housekeeping procedures on BRUOA2, especially the FCVR

Beginning Phase 2 at 02:37 AM -- processing shared files
========================================================

Processing DISK_A1:[ALLIN1.SHARED_E]OA$DAF_E.DAT file at 02:37 AM
-----------------------------------------------

Error looking for shared area text file OA$SHARE201:ZUECP3V8L.TXT
error in device name or inappropriate device type for operation

Error looking for shared area text file OA$SHARE230:ZUGDMWGIS.WPL
error in device name or inappropriate device type for operation

...

Error looking for shared area text file OA$SHARE996:ZUVXFR13B.WPL
error in device name or inappropriate device type for operation

Number of records in OA$SHARE:   6584  - 02:38 AM

Processing OA$DATA:PENDING.DAT file at 02:38 AM
-----------------------------------------------

Number of records:     90  - 02:38 AM

              End of Phase 2 at 02:38 AM
              ==========================

Beginning Phase 3 at 02:38 AM
=============================

This Phase will try to correct the usage counts of shared documents

Error attempting to repair DAF record with key OA$SHARD7:ZUYFNX3HT.WPL
-- ?I/O channel not open

Error attempting to repair DAF record with key OA$SHARD35:ZUYAF9NNC.WPL
-- ?I/O channel not open

...

Error attempting to repair DAF record with key OA$SHARC53:ZUWLOPK0Z.WPL
-- ?I/O channel not open

New DOCDB record created: RECOVERED SHARED DOCUMENTS    000230

Summary of Shared Document Status in OA$SHARE
---------------------------------------------

Total number of shared documents ..........     6584

Total number of missing text files.........       85

Total number of usage counts correct:......     6583

Total number of usage counts incorrect:....        1

    File Cabinet usage counts
    greater than actual references:........        1


Of course, all references to OA$SHARExxx with xxx > 75, and OA$SHARyxx, with
y <> E, have no sense on BRUOA2 (node B)

Can somebody explain me how the transfer account to another system is handling
the files in the shared mail directories and the pointers in the transferred 
user's DOCDB.DAT.
    
The customer is running VMS 5.5-2 and ALL-IN-1 v3.0 US.
    
Regards,

Thanks,

Luc Bervoets - MCS Brussels.


    

    
    	Known problem, see other notes. Already QARed, may soon be
    	a CLD. No fixes or workarounds available at this time. On
    	another site it was safe to ignore the errors, this may be
    	the case for you.
    
    Regards,
    Paul

    Safe to Ignore ?
    
    I'm seeing this on a lot of internal systems now. The documents
    identified by TRM as missing often exist on the system where the
    account was tranferred from.
    
    I can only assume that the transferred accounts can no longer see the
    text of these documents, so how can this be safe to ignore ?
    
    We're also seeing references to entire mail areas that existed on the
    original system, but not the system that the system that the account
    was transferred to !
    
    I'm keen to see a quick fix to this problem.
    
    Dave, if you want access to a system with these symptoms let me know.
    
    Chris

    >>Dave, if you want access to a system with these symptoms let me know.
    
    Chris. I think this is probably a reminder for me? I am not up to speed 
    on this problem. I will talk to Paul T. and see where we are on this
    one, but with current schedule, please don't expect an answer until
    later this week.
    
    Best regards
    DaveT

    I've had a look at this with Dave and we've identified the problem.  It 
    occurs when transfer user encounters nested attachments (ie an attached 
    message which has an attachment of its own).  When the message is 
    transferred to the target system new SDAF records are created for the main 
    document and all the attachments.  But all the original attributes of the 
    1st attachment are copied over, including the reference to the lower level 
    attachment, which no longer exists.

    This does not cause an obvious problem when reading the document on the 
    target system since ALL-IN-1 has effectively flattened the attachment 
    heirarchy by copying all attachment references into the top level
    document.  However, it will show up if the attachment is filed as a
    message.  Also of course it creates problems for FCVR.
    
    Unfortunately there's no workaround, and the fix has to go in at the code 
    level.  But it should be possible to get the fix into an early version of
    the next major release. I will also look at a possible change to FCVR so
    that it gets rid of the corruptions which have already occurred.

    I think the problem has been CLDd now, so the fixes will probably go into
    an ICF patch.
    
    Andy