Ron,

The only work around that I know of is not to back up the ACLs by setting
the undocumented option SkipLanServerACP to YES in option file or command
line.  This undocumented option was put into V1R2L6 of OS/2 client.

BACKACC Lan Server command will then need to be used to backup the ACLs
into a file, then use ADSM to do the backup including this ACL-file.
Later, use ADSM to do the restore including the ACL-file.  Then, use
RESTACC Lan Server command to get the ACL back.

Two examples of steps with commands to use are listed below
-----------------------------------------------------------
1) To backup and restore entire d: drive
1) To backup and restore entire d: drive

   Use Incremental backup
   ----------------------
   a) backacc d:\ /f:d:\drived.acl /s
   b) dsmc inc d: -skip=yes

   To restore d: drive
   -------------------
   a) dsmc rest d:\* -subdir=y
   b) restacc d: /f:d:\drived.acl /s

2) To backup and restore d:\abc directory with its subdir

   Use Selective backup on d:\abc directory
   ----------------------------------------
   a) backacc d:\abc /f:d:\abc\abc.acl /s
   b) dsmc sel d:\abc\* -subdir=y -skip=yes

   To restore d:\abc directory w/ its subdir
   -----------------------------------------
   a) dsmc rest d:\abc\* -subdir=y
   b) restacc d:\abc /f:d:\abc\abc.acl /s

This new ACL-file will have the new access date/time since it was just
created, so you may want to save/store them into a separate/temporary
directory.

Please note that some backslash char above appears as "-" in my editor
and hepefully it is too confusing to you.

Shu-na
 ========================================================================
>>From:         Ron Ritchey <[email protected]>
>>Subject:      Date error
>>To:           Multiple recipients of list ADSM-L <ADSM-L AT VM.MARIST DOT EDU

>>The OS/2 client changes the last accessed date on every file it touche
>>when ran on an OS/2 LAN server with 386HPFS. When this happens, you
>>have no way of finding out the last time the file was used by an
>>actual user. Not good when you have to use that date to manage your
>>server.

>>Is there any way to get around this error? IBM's reply is Working
>>As Designed. Our current tape backup system (SYTOS) doesn't
>>change the mentioned date. If there is no work around or the error
>>is not corrected, we need to start looking for an alternative package.

>>Thanks for any suggestions...