Conference iosg::all-in-1_v30

    Hi,
    
    I agree with you, but nobody has ever submitted a bug about this (to my
    knowledge). I'd love to change it, and a customer bug submitted would 
    give us a good reason.
    
    BTW does anybody think the current behaviour is correct?
    
    Cheers
    
    Stuart

    It seems consistent with VMS conventions; if you COPY a file, the
    creation date stays the same, the modification date is updated.
    
    I believe the only time COPY will update the Creation date is if you
    specify a new/differant output filename; so perhaps the logic would be
    'if you keep the same title, it keeps the same date; if you change the
    title, it gets a new creation date'...
    
    Dave

    My customer is of this opinion:
    
    "It's true that VMS behaves that way, but for an ordinary user - no
    matter whether the document title is changed or not - it is a NEW
    document which should always get a NEW created date."
    
    
    Stuart, I have raised an IPMT - DMO100036.
    
    Can a fix be given in version 3.0? The customer has done some
    application programming himself and will be able to implement changes
    if he gets instructions.
    
    Elin

    Re .3
    
    Yes - a 90% solution is possible by cutomisation. The script is
    COPYDOC.SCP and in there are three CABINET COPY function calls. The
    thing to do is after each to test OA$STATUS, and if successful add the
    created date attribute. For example:
    
            .IF OA$STATUS EQ 1
              .THEN
                 CABINET ADD_ATTRIBUTE ,"CREATED_NBS", OA$DATE_NBS
            .END_IF
    
    Similarly from the index you will need to customise form
    EM$INDEX$OPTIONS.
    
    However this would not work for cross-drawer copies (use the File
    Cabinet Server), and would not work anywhere else the CABINET COPY
    function is called. To do the job properly the changes would have to be
    made in code.
    
    Cheers
    
    Stuart

>    So running a 'document' through a copying machine creates a 'new' one?

but then you cover the body text with blank paper and out of the copying
machine comes a new copy with only the headlines left, before you finally
combine those headlines with new body text. 
Isn't the document NEW after this?
You'll get the same result, but with a new date, if you go to next screen
and select a template document when you create a new document.
But many users find it more straight forward to start with an MCD'ed document.

Personally I think the behaviour of MCD should be as in VMS (though it 
differs from my customer's opinon), using the logic you stated in .2:
    'if you keep the same title, it keeps the same date; if you change the
    title, it gets a new creation date'...

Then it is still possible to make a safety copy with all the original
attributes kept before doing advanced editing that might lead to a spoiled
doument... 

Elin 

    Hi,
    
    There is another factor that Richard Newland has pointed out to me.
    When an MCD is done there is a copy to a new document, which sets the
    DOCDB created date equal to the original, and a copy of the underlying
    file, which gets a VMS created date of today! You can verify this by
    noting the new document's filename, and then at DCL doing a $dir/dat on
    it.
    
    It seems that ALL-IN-1 is being inconsistent, and that the DOCDB
    creation date on the copy should match that of the underlying file. 
    
    Cheers
    
    Stuart

    
    not that this has much to do with MCD, but from a Mac or PC client
    point of view, the FCS sometimes is too high-handed in setting a
    creation date.  i want to file a QAR (or whatever you folks call it)
    that the Oafc interface does not let a client retain a creation date
    that is "before today" when trying to simulate a copy from one drawer
    [not necessarily an IOS drawer] to an IOS drawer.  to preserve the
    semantics expected by this Mac user, the creation date should stay
    the same no matter where the file ends up.  thus, the server should
    at least provide a way for clients to say "trust me, use this creation
    date instead of something you cook up".
    
    Paul Clark

    re: .7
    
    The reason the file's date is new is probably because it has a new
    gobbledygook filename. Of course you could set the date if desired...
    
    Actually I had another thought related to the base note;
    
    Can (should) you be able to Index based upon Modify date? VMS COPY 
    sets the Modify date to "now", which I would expect MCD to do too...
    
    This is turning out to be a 'fun' note...
    
    Dave

    
    
    I don't suppose this is fixed by the MUPA is it?