Re: Expiration date on Files - VMS

This is a discussion on Re: Expiration date on Files - VMS ; BHall wrote on 08/07/2008 03:54:35 PM: > On Aug 7, 1:35 pm, "Richard B. Gilbert" > wrote: > > norm.raph...@metso.com wrote: > > > > > Does a file with an Expiration date get automagically deleted when that > > ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: Re: Expiration date on Files

  1. Re: Expiration date on Files

    BHall wrote on 08/07/2008 03:54:35 PM:

    > On Aug 7, 1:35 pm, "Richard B. Gilbert"
    > wrote:
    > > norm.raph...@metso.com wrote:
    > >
    > > > Does a file with an Expiration date get automagically deleted when

    that
    > > > date-time occurs?
    > > > If I want to restore an expired file from a backup, how can I keep

    this
    > > > from happening instantaneously?

    > >
    > > > Where is the discussion of the behavior of this field?

    > >
    > > An expiration date prevents a file from being deleted prior to the
    > > expiration date. This can be overridden if you have VOLPRO privilege.
    > >
    > > I used to put expiration dates on backup tapes to ensure that they

    could
    > > not be accidentally overwritten.

    >
    > An expiration date on a file does not prevent that file from being
    > deleted! Unless, you use the /EXPIRED qualifier to modify the DELETE
    > filespec selection criteria. /BACKUP, /CREATED,/EXPIRED, and /
    > MODIFIED all select the file date field to which the /BEFORE and /
    > SINCE date/time selection criteria is applied. I'd like to see
    > support for the last accessed date added to DCL.
    >
    > Bill


    I have (re)learned that the expiration date on the file is just another
    date to use for maintenance.

    In fact, the application in question does invoke a procedure around
    midnight
    every night (in conjuction with other activities to start the next day)
    that
    deletes files where the expiration date is passed.

    This does not explain what sent me down this rathole, which was that I
    restored
    some file that were (by that date) expired, and they are gone,
    nevertheless.
    I am going to repeat the process and see what's what.

  2. Re: Expiration date on Files

    On Aug 7, 3:18*pm, norm.raph...@metso.com wrote:
    > BHall wrote on 08/07/2008 03:54:35 PM:
    >
    >
    >
    >
    >
    > > On Aug 7, 1:35 pm, "Richard B. Gilbert"
    > > wrote:
    > > > norm.raph...@metso.com wrote:

    >
    > > > > Does a file with an Expiration date get automagically deleted when

    > that
    > > > > date-time occurs?
    > > > > If I want to restore an expired file from a backup, how can I keep

    > this
    > > > > from happening instantaneously?

    >
    > > > > Where is the discussion of the behavior of this field?

    >
    > > > An expiration date prevents a file from being deleted prior to the
    > > > expiration date. *This can be overridden if you have VOLPRO privilege.

    >
    > > > I used to put expiration dates on backup tapes to ensure that they

    > could
    > > > not be accidentally overwritten.

    >
    > > An expiration date on a file does not prevent that file from being
    > > deleted! *Unless, you use the /EXPIRED qualifier to modify the DELETE
    > > filespec selection criteria. */BACKUP, /CREATED,/EXPIRED, and /
    > > MODIFIED all select the file date field to which the /BEFORE and /
    > > SINCE date/time selection criteria is applied. *I'd like to see
    > > support for the last accessed date added to DCL.

    >
    > > Bill

    >
    > I have (re)learned that the expiration date on the file is just another
    > date to use for maintenance.
    >
    > In fact, the application in question does invoke a procedure around
    > midnight
    > every night (in conjuction with other activities to start the next day)
    > that
    > deletes files where the expiration date is passed.
    >
    > This does not explain what sent me down this rathole, which was that I
    > restored
    > some file that were (by that date) expired, and they are gone,
    > nevertheless.
    > I am going to repeat the process and see what's what.


    Restore the files once more. Then do a $set file/
    expiration_date= on the each of the restored
    files. You could also do a $set file/noexpiration_date to completely
    remove the date. In either case the expiration date may be adjusted
    again the next time the file is opened depending on the volumes
    retention settings.

    Bill

  3. Re: Expiration date on Files

    In article , norm.raphael@metso.com writes:
    >
    > In fact, the application in question does invoke a procedure around
    > midnight
    > every night (in conjuction with other activities to start the next day)
    > that
    > deletes files where the expiration date is passed.
    >
    > This does not explain what sent me down this rathole, which was that I
    > restored
    > some file that were (by that date) expired, and they are gone,
    > nevertheless.
    > I am going to repeat the process and see what's what.


    If the application is deleting expired files, you'll need a backup
    tape made before the files were deleted (obvious). Butin the dark
    reaches of my mind I recall reading that BACKUP will not restore
    expired files unless told to do so, probably the /expired qualifier.


  4. Re: Expiration date on Files

    In article <3f1da8b3-a07a-44c4-b669-346adbe3b8c6@k36g2000pri.googlegroups.com>, BHall writes:
    >
    > Restore the files once more. Then do a $set file/
    > expiration_date=3D on the each of the restored
    > files. You could also do a $set file/noexpiration_date to completely
    > remove the date. In either case the expiration date may be adjusted
    > again the next time the file is opened depending on the volumes
    > retention settings.


    For volumes not using retention, setting the expiration date to the
    0 value mimics part of the UNIX touch command, since this updates the
    modified date:

    $ touch == "set file/expiration_date=17-nov-1858


  5. Re: Expiration date on Files

    Bob Koehler wrote:
    (snip)

    > For volumes not using retention, setting the expiration date to the
    > 0 value mimics part of the UNIX touch command, since this updates the
    > modified date:


    > $ touch == "set file/expiration_date=17-nov-1858


    I remember some years ago working with VMS on a system
    that used expiration dates. I would once in a while
    do something like

    set file/expiration_date=31-dec-1999 *.*;*

    (that was about 1986 so 1999 was far enough in the future.)

    What I never figured out was why I was allowed to do that.
    If they are trying to expire files that aren't accessed often
    enough, then I shouldn't be allowed to set it.

    -- glen


  6. Re: Expiration date on Files

    glen herrmannsfeldt writes:

    >Bob Koehler wrote:
    >(snip)


    >> For volumes not using retention, setting the expiration date to the
    >> 0 value mimics part of the UNIX touch command, since this updates the
    >> modified date:


    >> $ touch == "set file/expiration_date=17-nov-1858


    >I remember some years ago working with VMS on a system
    >that used expiration dates. I would once in a while
    >do something like


    >set file/expiration_date=31-dec-1999 *.*;*


    >(that was about 1986 so 1999 was far enough in the future.)


    >What I never figured out was why I was allowed to do that.
    >If they are trying to expire files that aren't accessed often
    >enough, then I shouldn't be allowed to set it.


    That wouldn't be a problem for a smart system manager. The same batch job
    that deletes 'expired' files could also delete without mercy (or backup :-)
    any file whose expiration date was far enough into the future that it
    could not be set via "normal" means.

    I think the expiration field was just never well thought out. Other
    operating systems I used had a simple 'last access' date field, and batch
    jobs to free disk space could just delete files whose last access date was
    before a certain time ago. There was no need to "hack" that with the
    volume retention to get the expiration date ~= the last access date.

  7. Re: Expiration date on Files

    Michael Moroney wrote:
    > glen herrmannsfeldt writes:
    >
    >> Bob Koehler wrote:
    >> (snip)

    >
    >>> For volumes not using retention, setting the expiration date to the
    >>> 0 value mimics part of the UNIX touch command, since this updates the
    >>> modified date:

    >
    >>> $ touch == "set file/expiration_date=17-nov-1858

    >
    >> I remember some years ago working with VMS on a system
    >> that used expiration dates. I would once in a while
    >> do something like

    >
    >> set file/expiration_date=31-dec-1999 *.*;*

    >
    >> (that was about 1986 so 1999 was far enough in the future.)

    >
    >> What I never figured out was why I was allowed to do that.
    >> If they are trying to expire files that aren't accessed often
    >> enough, then I shouldn't be allowed to set it.

    >
    > That wouldn't be a problem for a smart system manager. The same batch job
    > that deletes 'expired' files could also delete without mercy (or backup :-)
    > any file whose expiration date was far enough into the future that it
    > could not be set via "normal" means.
    >
    > I think the expiration field was just never well thought out. Other
    > operating systems I used had a simple 'last access' date field, and batch
    > jobs to free disk space could just delete files whose last access date was
    > before a certain time ago. There was no need to "hack" that with the
    > volume retention to get the expiration date ~= the last access date.


    The way I see it, expiration dates were well thought out.

    A "last access" field needs to be updated any time the file is touched,
    even if it is just read.

    Remember that directory lookups can be cached, but writing an access
    time can not.

    This means that reading a lot of files results in a lot of writes to the
    disk.

    Since the expiration is defined as a range, the disk only needs to be
    updated when the access falls outside of that range. For certain mixes
    of I/O, this can result in a considerable reduction in disk writes.

    Also remember that this was implemented when disks were much slower than
    they are now.

    --
    -----------------------------------------------------------------------
    Chris Scheers, Applied Synergy, Inc.

    Voice: 817-237-3360 Internet: chris@applied-synergy.com
    Fax: 817-237-3074

  8. Re: Expiration date on Files

    Michael Moroney wrote:
    > glen herrmannsfeldt writes:
    >
    >> Bob Koehler wrote:
    >> (snip)

    >
    >>> For volumes not using retention, setting the expiration date to the
    >>> 0 value mimics part of the UNIX touch command, since this updates the
    >>> modified date:

    >
    >>> $ touch == "set file/expiration_date=17-nov-1858

    >
    >> I remember some years ago working with VMS on a system
    >> that used expiration dates. I would once in a while
    >> do something like

    >
    >> set file/expiration_date=31-dec-1999 *.*;*

    >
    >> (that was about 1986 so 1999 was far enough in the future.)

    >
    >> What I never figured out was why I was allowed to do that.
    >> If they are trying to expire files that aren't accessed often
    >> enough, then I shouldn't be allowed to set it.

    >
    > That wouldn't be a problem for a smart system manager. The same batch job
    > that deletes 'expired' files could also delete without mercy (or backup :-)
    > any file whose expiration date was far enough into the future that it
    > could not be set via "normal" means.
    >
    > I think the expiration field was just never well thought out. Other
    > operating systems I used had a simple 'last access' date field, and batch
    > jobs to free disk space could just delete files whose last access date was
    > before a certain time ago. There was no need to "hack" that with the
    > volume retention to get the expiration date ~= the last access date.


    The way I see it, expiration dates were well thought out.

    A "last access" field needs to be updated any time the file is touched,
    even if it is just read.

    Remember that directory lookups can be cached, but writing an access
    time can not.

    This means that reading a lot of files results in a lot of writes to the
    disk.

    Since the expiration is defined as a range, the disk only needs to be
    updated when the access falls outside of that range. For certain mixes
    of I/O, this can result in a considerable reduction in disk writes.

    Also remember that this was implemented when disks were much slower than
    they are now.

    --
    -----------------------------------------------------------------------
    Chris Scheers, Applied Synergy, Inc.

    Voice: 817-237-3360 Internet: chris@applied-synergy.com
    Fax: 817-237-3074

+ Reply to Thread