Easy DCL question PURGE vs. DELETE - VMS

This is a discussion on Easy DCL question PURGE vs. DELETE - VMS ; On Aug 5, 2:10 pm, AEF wrote: > On Aug 5, 2:20 pm, Doug Phillips wrote: > > > > > On Aug 5, 12:33 pm, AEF wrote: > > > > On Aug 5, 12:46 pm, AEF wrote: > ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 31 of 31

Thread: Easy DCL question PURGE vs. DELETE

  1. Re: Easy DCL question PURGE vs. DELETE

    On Aug 5, 2:10 pm, AEF wrote:
    > On Aug 5, 2:20 pm, Doug Phillips wrote:
    >
    >
    >
    > > On Aug 5, 12:33 pm, AEF wrote:

    >
    > > > On Aug 5, 12:46 pm, AEF wrote:
    > > > [...]

    >
    > > > > Apparently the main sticking point is that we had very different ideas
    > > > > of what "current version" means. To me, PURGE means, above all else,
    > > > > make sure you keep at least the highest-numbered version. When I

    >
    > > > Sorry, replace "highest-numbered version" with "current version". I
    > > > mean here the highest-numbered version of ALL the versions of the file
    > > > in question, irrespective of any selection qualifiers that might be
    > > > present. This is the raison d'etre for the PURGE command. And this
    > > > version, the current version, always contributes to the keep count.

    >
    > > > > execute or read a file without specifying its version number, it will
    > > > > always run the current version. And that's because the default for a
    > > > > missing version-number spec is ";" (see my second paragraph way, way
    > > > > above). (Does anyone actually have command procedures that run
    > > > > explicitly specified intermediate versions?) So "my current version"
    > > > > is far more important than any intermediate version. How can an
    > > > > intermediate version ever be the current version? Come to think of it,
    > > > > I find the term "most-current" to be somewhat nonsensical. You're
    > > > > current or you're not.

    >
    > > > [...]

    >
    > > I'll reply here rather that waste band-width quoting one of our other
    > > incredibly long and winding posts.

    >
    > > AEF, purge does not work the way you describe.

    >
    > Yes it does.
    >
    > > Since you can't look at ITRC, and see Jon Pinkley's reproducer I'll
    > > paste it in here (hope you don't mind, Jon). It'll probably wrap, but
    > > I can't help that.

    >
    > > I've commented out the analyze/image (your VAX v6.2 would probably
    > > choke on it), removed the double-dates from the directory display, put
    > > some "white space" around the purge command, and shortened the exit to
    > > just exit. Other than the mod notice, it's as it was.

    >
    > > He included both creation and modification dates on the create fdl
    > > lines so you can "play" with different purge qualifies if you want.

    >
    > But then why was /date=(c,m) included in the DIR command when the
    > example only purges by owner?
    >
    > > This reproducer purges on by_owner.

    >
    > > Run it, see what it does. Change the purge to whatever you want, and
    > > run it as many times as you want. Based on the results, what does
    > > PURGE consider the "current version" to be?

    >
    > [... DCL code omitted ...]
    >
    > OK. I copied the code to my system, tidied it up, and ran it.
    >
    > It works exactly as I have described:
    >
    > $ directory/own/date pt.tmp;* ! we don't need /DATE here -- I
    > forgot to trim it off
    >
    > Directory DISK$DATA1:[TEST.DCL.PURGE]
    >
    > PT.TMP;5 1-JAN-2000 01:00:43.50 [SYSTEM]
    > PT.TMP;4 2-JAN-2000 01:00:43.39 [1,1]
    > PT.TMP;3 3-JAN-2000 01:00:43.28 [1,1]
    > PT.TMP;2 4-JAN-2000 01:00:43.17 [SYSTEM]
    > PT.TMP;1 5-JAN-2000 01:00:43.07 [SYSTEM]
    >
    > Total of 5 files.
    > $!
    > $ purge/keep=2/by_own=[1,1]/log pt.tmp
    > %PURGE-I-FILPURG, DISK$DATA1:[TEST.DCL.PURGE]PT.TMP;3 deleted (0
    > blocks)
    > $!
    > $ directory/own/date pt.tmp;*
    >
    > Directory DISK$DATA1:[TEST.DCL.PURGE]
    >
    > PT.TMP;5 1-JAN-2000 01:00:43.50 [SYSTEM]
    > PT.TMP;4 2-JAN-2000 01:00:43.39 [1,1]
    > PT.TMP;2 4-JAN-2000 01:00:43.17 [SYSTEM]
    > PT.TMP;1 5-JAN-2000 01:00:43.07 [SYSTEM]
    >
    > Total of 4 files.
    > $_exit:
    > $ exit
    >
    > The current version is PT.TMP;5. As I said last time, the current
    > version _always_ contributes to the keep-count. So it kept two
    > versions: ;5 and ;4.
    >
    > Had I omitted the /KEEP=2 or specified /KEEP=1, it would have also
    > deleted PT.TMP;4, keeping one version.
    >
    > The keep-count is the sum of the following two things:
    >
    > 1. The number 1 for the current version
    > 2. The number of old versions that match /BY_OWNER=[1,1]
    >
    > Nothing else contributes to the keep-count. In this example, the
    > initial keep-count (which is a function of the selction qualifiers) is
    > 3 which is from ;5, ;4, and ;3 because ;5 is the current version and
    > versions ;4 and ;3 match the selction qualifier.
    >
    > After the command only versions ;5 and ;4 contribute to the keep count
    > and that gives 2 which is what the command specified.
    >
    > Now, in general:
    >
    > If the keep-count is initially .LE. the keep-value, PURGE deletes no
    > versions of the file. If the keep-count is .GT. the keep-value, PURGE
    > then deletes matching versions in ascending version order (in this
    > case versions matching /BY_OWNER=[1,1]) until the keep-count is equal
    > to the keep-value.
    >
    > That's how it works. That's what I said in my previous post.
    >


    The bug has been reported, and it is bug. As noted in the ITRC thread,
    it worked *as documented* (e.g. only the "specified and qualified"
    files were considered --- your "current version" would be ignored if
    if was not within those qualified specs) sometime back in the v5.n era
    and before, and the bug was introduced sometime after that.

    I still don't understand why you think fixing it to consider only the
    qualified/specified files would cause you hardship, or why you think
    allowing it to consider *any* file that is not one you have specified/
    qualified is logical. If you tell it to purge files owned by [1,1] and
    keep 2 if there are that many, I don't understand why you think "start
    the count with the first file regardless of any thing else" makes
    sense... oh well, I've said that before and then you've said what you
    said before and we're back to here again. Why bother.

    That's about all the more I can say about this.



  2. Re: Easy DCL question PURGE vs. DELETE

    On Aug 5, 4:26 pm, Doug Phillips wrote:
    > On Aug 5, 2:10 pm, AEF wrote:
    >
    > > On Aug 5, 2:20 pm, Doug Phillips wrote:

    [...]
    > > > I'll reply here rather that waste band-width quoting one of our other
    > > > incredibly long and winding posts.

    >
    > > > AEF, purge does not work the way you describe.

    >
    > > Yes it does.

    >
    > > > Since you can't look at ITRC, and see Jon Pinkley's reproducer I'll
    > > > paste it in here (hope you don't mind, Jon). It'll probably wrap, but
    > > > I can't help that.


    I can look at it, but it's a struggle to read it. It's so dense. It's
    like reading STARTUP.COM. ... OK, I brought up the ITRC thread and
    pasted it into to an Outlook email window and it is finally readable.
    I printed it and read it. OK. (I wish I had a "universal translator"
    program that would automatically do this type of thing for me.)

    [...]

    > The bug has been reported, and it is bug. As noted in the ITRC thread,


    Your opinion. As is, it offers additional functionality. Yet I agreed
    that your way is also a reasonable way to do it.

    > it worked *as documented* (e.g. only the "specified and qualified"
    > files were considered --- your "current version" would be ignored if
    > if was not within those qualified specs) sometime back in the v5.n era
    > and before, and the bug was introduced sometime after that.


    I'm pretty sure that I noticed the current behavior on a VMS V5.x,
    probably on a V5.2 system. (When did V5.5 first come out?) Therefore
    I'm very surprised by the ITRC example using V5.5-2H4. Looks like
    yours. What does it do for /KEEP=1 and without /KEEP? Also, it would
    help to know the history of the PURGE code w.r.t. various versions of
    VMS.

    > I still don't understand why you think fixing it to consider only the
    > qualified/specified files would cause you hardship, or why you think
    > allowing it to consider *any* file that is not one you have specified/
    > qualified is logical.


    Because then I can't do Example 2. I might want to delete all old
    versions from before a certain date, and I can't do that with your
    algorithm without either using /CONFIRM or a very, very lengthy /
    EXCLUDE. Here it is again:

    Example 2:

    ONE.TMP;4 18:00
    ONE.TMP;3 17:00
    ONE.TMP;2 16:00
    TWO.TMP;8 14:00
    TWO.TMP;3 13:00
    TWO.TMP;1 12:00
    THREE.TMP;8 17:00
    THREE.TMP;6 15:00
    THREE.TMP;1 10:00

    Now suppose I want to PURGE this directory but only delete _old_
    versions older than 16:30. This would leave the following:

    ONE.TMP;4 18:00
    ONE.TMP;3 17:00
    TWO.TMP;8 14:00
    THREE.TMP;8 17:00

    Note that TWO.TMP;8 is older than 16:30, but it was saved because I
    used PURGE. Had I used DELETE it would be gone! NOW do you understand
    what I'm trying to do? I can easily do this with the current version
    of PURGE. I can't do this with your version of PURGE unless you add
    the possibility of /KEEP=0 which I would consider to be a rather
    bizarre option for a PURGE command.

    One more variation: I want to save the current versions of ONE.TMP,
    TWO.TMP, and THREE.TMP no matter what. That means saving ONE.TMP;4,
    TWO.TMP;8, and THREE.TMP;8. Out of the remaining versions, I want to
    delete those with a time stamp of less than 16:30. I can't do this
    with your algorithm, but I can with mine. I simply would use $ PURGE/
    BEFORE=16:30 and it would do what I want. With your algorithm I'd be
    stuck with three extra versions I'd have to manually delete.

    > If you tell it to purge files owned by [1,1] and
    > keep 2 if there are that many, I don't understand why you think "start
    > the count with the first file regardless of any thing else" makes
    > sense...


    Because /KEEP=1 is already tied to the current file. I like it because
    it allows me to do Example 2. (See Example 2 above.)

    > oh well, I've said that before and then you've said what you
    > said before and we're back to here again. Why bother.


    Because now we at least are not misunderstanding each other about what
    "current version" means. This discussion is plagued with a seemingly
    endless number of words that have multiple meanings, the intended one
    in any particular case usually not made clear by the context.

    > That's about all the more I can say about this.


    AEF


  3. Re: Easy DCL question PURGE vs. DELETE

    On Aug 5, 7:17 pm, AEF wrote:
    > On Aug 5, 4:26 pm, Doug Phillips wrote:
    >
    > > On Aug 5, 2:10 pm, AEF wrote:

    >
    > > > On Aug 5, 2:20 pm, Doug Phillips wrote:

    > [...]
    > > > > I'll reply here rather that waste band-width quoting one of our other
    > > > > incredibly long and winding posts.

    >
    > > > > AEF, purge does not work the way you describe.

    >
    > > > Yes it does.

    >
    > > > > Since you can't look at ITRC, and see Jon Pinkley's reproducer I'll
    > > > > paste it in here (hope you don't mind, Jon). It'll probably wrap, but
    > > > > I can't help that.

    >
    > I can look at it, but it's a struggle to read it. It's so dense. It's
    > like reading STARTUP.COM. ... OK, I brought up the ITRC thread and
    > pasted it into to an Outlook email window and it is finally readable.
    > I printed it and read it. OK. (I wish I had a "universal translator"
    > program that would automatically do this type of thing for me.)
    >



    A friend with very severe vision problems (character stacking and
    horizontal distortion) uses the following methods (on Windows): CTRL/+
    (how every many times it takes) to increase the size of the font; Use
    the left-click or shift-arrow to slowly high-light across the text;
    Use the Magnifier tools; Use a "nothced" index card (or folded piece
    of paper); Does what you do (cut & paste to something with better
    control.)

    There may very well be a vision aid tool that would do what you want;
    I'll ask and see if anyone knows. Or, maybe someone here has some
    experience (though it seems everyone else has either kill-filed this
    thread or has been put to sleep by it's verbosity;-)

    I agree that ITRC's formatting is lame. There is an option during
    posting that will post "as is" without formatting, but it's not the
    default.

    > [...]
    >
    > > The bug has been reported, and it is bug. As noted in the ITRC thread,

    >
    > Your opinion. As is, it offers additional functionality. Yet I agreed
    > that your way is also a reasonable way to do it.
    >


    I think quite a few others share "my opinion" because I wasn't the
    first one to have the opinion. I read what others said, ran a few
    tests myself and became a believer.

    > > it worked *as documented* (e.g. only the "specified and qualified"
    > > files were considered --- your "current version" would be ignored if
    > > if was not within those qualified specs) sometime back in the v5.n era
    > > and before, and the bug was introduced sometime after that.

    >
    > I'm pretty sure that I noticed the current behavior on a VMS V5.x,
    > probably on a V5.2 system. (When did V5.5 first come out?) Therefore
    > I'm very surprised by the ITRC example using V5.5-2H4. Looks like
    > yours. Also, it would
    > help to know the history of the PURGE code w.r.t. various versions of
    > VMS.
    >


    I don't know the code history, except as I remember the release notes
    and new features. I've "managed" VMS since v4, but I've "used" it
    since early 11/780 days and I don't remember my introductory version.
    The code base used for Alpha, I believe, was v5.5-2. v6.2 is the
    oldest thing I have, and although I can remember specific bugs
    throughout the years I can't name when they happened.

    >
    > What does it do for /KEEP=1 and without /KEEP?
    >


    If you mean "what did it do back when", the discussion indicates it
    worked as I described. It would keep the highest version of the files
    you specify/qualify and ignore the ones that don't match your specs/
    quals.

    That's also what I remember, and I was surprised to find it working
    the way it does.

    My most often usage is to purge/since to remove all but the current
    version of source code that I've worked on today (you know, the stuff
    that has all the typos and compiler errors(8-O), leaving the older
    version(s). That works just fine. Or, purge a file or directory
    without qualification; log files, scratch files, report files, etc.
    Purge seems to work as expected if you don't qualify it.

    > > I still don't understand why you think fixing it to consider only the
    > > qualified/specified files would cause you hardship, or why you think
    > > allowing it to consider *any* file that is not one you have specified/
    > > qualified is logical.

    >
    > Because then I can't do Example 2. I might want to delete all old
    > versions from before a certain date,
    > and I can't do that with your
    > algorithm without either using /CONFIRM or a very, very lengthy /
    > EXCLUDE. Here it is again:
    >
    > Example 2:
    >
    > ONE.TMP;4 18:00
    > ONE.TMP;3 17:00
    > ONE.TMP;2 16:00
    > TWO.TMP;8 14:00
    > TWO.TMP;3 13:00
    > TWO.TMP;1 12:00
    > THREE.TMP;8 17:00
    > THREE.TMP;6 15:00
    > THREE.TMP;1 10:00
    >
    > Now suppose I want to PURGE this directory but only delete _old_
    > versions older than 16:30. This would leave the following:
    >
    > ONE.TMP;4 18:00
    > ONE.TMP;3 17:00
    > TWO.TMP;8 14:00
    > THREE.TMP;8 17:00
    >
    > Note that TWO.TMP;8 is older than 16:30, but it was saved because I
    > used PURGE. Had I used DELETE it would be gone! NOW do you understand
    > what I'm trying to do? I can easily do this with the current version
    > of PURGE. I can't do this with your version of PURGE unless you add
    > the possibility of /KEEP=0 which I would consider to be a rather
    > bizarre option for a PURGE command.
    >


    No, I think "my" way would do what you want, because PURGE by
    definition always keeps at least one version of any file that meets
    the specs/quals. It should *never* delete all versions of a file that
    meet those specs/quals, and it should only "look at" the files you do
    specify. If the TWO.TMP;8 meets your specs (which it does) one version
    would be kept. The /qualifiers would operate on matching files after
    the /keep has been satisfied. Again, though for emphasis: It should
    ignore any file that doesn't match, and keep exactly the number you
    specify if there are at least that many versions.

    >
    > One more variation: I want to save the current versions of ONE.TMP,
    > TWO.TMP, and THREE.TMP no matter what. That means saving ONE.TMP;4,
    > TWO.TMP;8, and THREE.TMP;8. Out of the remaining versions, I want to
    > delete those with a time stamp of less than 16:30. I can't do this
    > with your algorithm, but I can with mine. I simply would use $ PURGE/
    > BEFORE=16:30 and it would do what I want. With your algorithm I'd be
    > stuck with three extra versions I'd have to manually delete.
    >


    Same thing.

    I did mention on ITRC that it would be a nice to have additional
    qualifiers on the /KEEP option.


    > > If you tell it to purge files owned by [1,1] and
    > > keep 2 if there are that many, I don't understand why you think "start
    > > the count with the first file regardless of any thing else" makes
    > > sense...

    >
    > Because /KEEP=1 is already tied to the current file. I like it because
    > it allows me to do Example 2. (See Example 2 above.)
    >
    > > oh well, I've said that before and then you've said what you
    > > said before and we're back to here again. Why bother.

    >
    > Because now we at least are not misunderstanding each other about what
    > "current version" means. This discussion is plagued with a seemingly
    > endless number of words that have multiple meanings, the intended one
    > in any particular case usually not made clear by the context.
    >


    I agree. I guess we're just a couple of wordy guys;-)


  4. Re: Easy DCL question PURGE vs. DELETE

    On Aug 5, 7:17 pm, AEF wrote:
    > On Aug 5, 4:26 pm, Doug Phillips wrote:
    >
    > > On Aug 5, 2:10 pm, AEF wrote:

    >
    > > > On Aug 5, 2:20 pm, Doug Phillips wrote:

    > [...]
    >
    > Example 2:
    >
    > ONE.TMP;4 18:00
    > ONE.TMP;3 17:00
    > ONE.TMP;2 16:00
    > TWO.TMP;8 14:00
    > TWO.TMP;3 13:00
    > TWO.TMP;1 12:00
    > THREE.TMP;8 17:00
    > THREE.TMP;6 15:00
    > THREE.TMP;1 10:00
    >
    > Now suppose I want to PURGE this directory but only delete _old_
    > versions older than 16:30. This would leave the following:
    >
    > ONE.TMP;4 18:00
    > ONE.TMP;3 17:00
    > TWO.TMP;8 14:00
    > THREE.TMP;8 17:00
    >
    > Note that TWO.TMP;8 is older than 16:30, but it was saved because I
    > used PURGE. Had I used DELETE it would be gone! NOW do you understand
    > what I'm trying to do? I can easily do this with the current version
    > of PURGE. I can't do this with your version of PURGE unless you add
    > the possibility of /KEEP=0 which I would consider to be a rather
    > bizarre option for a PURGE command.
    >
    > One more variation: I want to save the current versions of ONE.TMP,
    > TWO.TMP, and THREE.TMP no matter what. That means saving ONE.TMP;4,
    > TWO.TMP;8, and THREE.TMP;8. Out of the remaining versions, I want to
    > delete those with a time stamp of less than 16:30. I can't do this
    > with your algorithm, but I can with mine. I simply would use $ PURGE/
    > BEFORE=16:30 and it would do what I want. With your algorithm I'd be
    > stuck with three extra versions I'd have to manually delete.
    >


    > > Same thing.


    Sorry, I said "same thing" but in re-reading it I now understand the
    slight difference (I think??) I guess sometimes I scan too quickly and
    for that I do apologize.

    But, I don't understand which three files you think are excess.

    After your command;

    DIR would find:

    ONE.TMP;4 18:00
    ONE.TMP;3 17:00
    TWO.TMP;8 14:00
    THREE.TMP;8 17:00

    (which is the same result as the first example, so I don't understand
    your "variation.) You have saved "ONE.TMP;4, TWO.TMP;8, and THREE.TMP;
    8. Out of the remaining versions, ... those with a time stamp of less
    than 16:30 [were deleted]."


  5. Re: Easy DCL question PURGE vs. DELETE

    On Aug 6, 1:27 pm, Doug Phillips wrote:
    > On Aug 5, 7:17 pm, AEF wrote:
    >
    > > On Aug 5, 4:26 pm, Doug Phillips wrote:

    >
    > > > On Aug 5, 2:10 pm, AEF wrote:

    >
    > > > > On Aug 5, 2:20 pm, Doug Phillips wrote:

    > > [...]

    >
    > > Example 2:

    >
    > > ONE.TMP;4 18:00
    > > ONE.TMP;3 17:00
    > > ONE.TMP;2 16:00
    > > TWO.TMP;8 14:00
    > > TWO.TMP;3 13:00
    > > TWO.TMP;1 12:00
    > > THREE.TMP;8 17:00
    > > THREE.TMP;6 15:00
    > > THREE.TMP;1 10:00

    >
    > > Now suppose I want to PURGE this directory but only delete _old_
    > > versions older than 16:30. This would leave the following:

    >
    > > ONE.TMP;4 18:00
    > > ONE.TMP;3 17:00
    > > TWO.TMP;8 14:00
    > > THREE.TMP;8 17:00

    >
    > > Note that TWO.TMP;8 is older than 16:30, but it was saved because I
    > > used PURGE. Had I used DELETE it would be gone! NOW do you understand
    > > what I'm trying to do? I can easily do this with the current version
    > > of PURGE. I can't do this with your version of PURGE unless you add
    > > the possibility of /KEEP=0 which I would consider to be a rather
    > > bizarre option for a PURGE command.

    >
    > > One more variation: I want to save the current versions of ONE.TMP,
    > > TWO.TMP, and THREE.TMP no matter what. That means saving ONE.TMP;4,
    > > TWO.TMP;8, and THREE.TMP;8. Out of the remaining versions, I want to
    > > delete those with a time stamp of less than 16:30. I can't do this
    > > with your algorithm, but I can with mine. I simply would use $ PURGE/
    > > BEFORE=16:30 and it would do what I want. With your algorithm I'd be
    > > stuck with three extra versions I'd have to manually delete.

    >
    > > > Same thing.

    >
    > Sorry, I said "same thing" but in re-reading it I now understand the
    > slight difference (I think??) I guess sometimes I scan too quickly and
    > for that I do apologize.


    Sorry, I meant a variation on the explanation because you still don't
    see what I want to do is not possible with your algorithm.

    > But, I don't understand which three files you think are excess.


    [...]

    Oops, that should have been two, not three. If it followed your
    algorithm it wouldn't have deleted ONE.TMP;2 and THREE.TMP;6.

    Please let me try to explain it again.

    Short version: I want the equivalent of DELETE/BEFORE=16:30/EXCLUDE=;
    (which is not a legal command!).

    Long version:

    Suppose I have a directory containing these files (in the version-
    unaware sense of the word "file")**:

    ONE.TMP;4 18:00
    ONE.TMP;3 17:00
    ONE.TMP;2 16:00 S *

    TWO.TMP;8 14:00 S
    TWO.TMP;3 13:00 S * #
    TWO.TMP;1 12:00 S * #

    THREE.TMP;8 17:00
    THREE.TMP;6 15:00 S *
    THREE.TMP;1 10:00 S * #

    The versions marked S are the versions which Satisfy /BEFORE=16:30.

    The versions marked * are what my algorithm would delete.

    The versions marked # are what your algorithm would delete.

    To see how I arrived at the * versions, we can split up the versions
    into two sets:

    Current versions:

    ONE.TMP;4 18:00
    TWO.TMP;8 14:00 S
    THREE.TMP;8 17:00

    Old versions:

    ONE.TMP;3 17:00
    ONE.TMP;2 16:00 S *
    TWO.TMP;3 13:00 S * #
    TWO.TMP;1 12:00 S * #
    THREE.TMP;6 15:00 S *
    THREE.TMP;1 10:00 S * #

    What I want to do is to delete all the old versions that are older
    than 16:30. That means all old versions that are also S versions. I've
    marked these with asterisks.

    My algorithm would delete only the * versions because its /KEEP=1 is
    protecting the current versions. Your algorithm would delete only the
    # versions because its /KEEP=1 is protecting, for each file, the
    highest-numbered version of its S-versions. Thus I'd have to manually
    delete ONE.TMP;2 and THREE.TMP;6 to get what I want with your
    algorithm. If there were many versions of many files, this would
    quickly become a PITA.

    What I basically want can also be expressed as DELETE/BEFORE=16:30/
    EXCLUDE=; which would do exactly what I want except that ';' is not a
    valid argument for /EXCLUDE. In current VMS, PURGE/BEFORE=16:30 does
    exactly this. There is no way to do this with your algorithm without
    either adding /CONFIRM, adding a lengthy /EXCLUDE qualifier, or doing
    a manual cleanup afterwards. To do this in batch (with your algorithm)
    would require writing some DCL code. To do what you want to do with my
    algorithm would only require adding 1 to the keep value.

    ** Note that there are 3 files, 3 current versions, 6 old versions,
    and 9 total versions.

    AEF


  6. Re: Easy DCL question PURGE vs. DELETE

    On Aug 6, 12:52 pm, Doug Phillips wrote:
    > On Aug 5, 7:17 pm, AEF wrote:
    >
    > > On Aug 5, 4:26 pm, Doug Phillips wrote:

    >
    > > > On Aug 5, 2:10 pm, AEF wrote:

    >
    > > > > On Aug 5, 2:20 pm, Doug Phillips wrote:

    > > [...]
    > > > > > I'll reply here rather that waste band-width quoting one of our other
    > > > > > incredibly long and winding posts.

    >
    > > > > > AEF, purge does not work the way you describe.

    >
    > > > > Yes it does.

    >
    > > > > > Since you can't look at ITRC, and see Jon Pinkley's reproducer I'll
    > > > > > paste it in here (hope you don't mind, Jon). It'll probably wrap, but
    > > > > > I can't help that.

    >
    > > I can look at it, but it's a struggle to read it. It's so dense. It's
    > > like reading STARTUP.COM. ... OK, I brought up the ITRC thread and
    > > pasted it into to an Outlook email window and it is finally readable.


    (Usually Wordpad saves the day if I click New, Text; but not this
    time!)

    > > I printed it and read it. OK. (I wish I had a "universal translator"
    > > program that would automatically do this type of thing for me.)

    >
    > A friend with very severe vision problems (character stacking and
    > horizontal distortion) uses the following methods (on Windows): CTRL/+
    > (how every many times it takes) to increase the size of the font; Use
    > the left-click or shift-arrow to slowly high-light across the text;
    > Use the Magnifier tools; Use a "nothced" index card (or folded piece
    > of paper); Does what you do (cut & paste to something with better
    > control.)


    It's not the size. Those tricks wouldn't make STARTUP.COM any more
    readable and I don't think they'd help here either. It's also annoying
    with different parts of the screen gray and white with another shade
    of gray and white on the sides. Sorry, it's just too "orthogonal" to
    my vision system. It's ugly. And they could drop the member-status
    icons. They just mean the number of posts times average points per
    post. Who cares? If they were based on average points per reply
    (perhaps weighted toward recent posts or based on posts in the same
    category), that would be a lot more useful, I think. And something
    other than "magical answer" for posts with solutions. We're not doing
    magic here.

    Thanks for your efforts just the same.

    > There may very well be a vision aid tool that would do what you want;
    > I'll ask and see if anyone knows. Or, maybe someone here has some
    > experience (though it seems everyone else has either kill-filed this
    > thread or has been put to sleep by it's verbosity;-)


    It needs to be redone from scratch. It's beyond band-aids. Fixed-width
    font would be a good start but as for me doing that I don't want to go
    through fix-the-fonts hell and risk ruining other Web sites.

    > I agree that ITRC's formatting is lame. There is an option during
    > posting that will post "as is" without formatting, but it's not the
    > default.


    Thanks, I'll keep that in mind. I want to respond to the current
    BACKUP thread.

    > > [...]

    >
    > > > The bug has been reported, and it is bug. As noted in the ITRC thread,

    >
    > > Your opinion. As is, it offers additional functionality. Yet I agreed
    > > that your way is also a reasonable way to do it.

    >
    > I think quite a few others share "my opinion" because I wasn't the
    > first one to have the opinion. I read what others said, ran a few
    > tests myself and became a believer.


    Understood. Many do share your opinion. But that doesn't change my
    thoughts on it. And it doesn't change the fact that it's far easier
    for you and company to adjust to my algorithm than me to yours.

    [...]

    > > What does it do for /KEEP=1 and without /KEEP?

    >
    > If you mean "what did it do back when", the discussion indicates it
    > worked as I described. It would keep the highest version of the files
    > you specify/qualify and ignore the ones that don't match your specs/
    > quals.


    No. Sorry, it was Martin Hughes who posted the VMS V5.5-2H4. I'd like
    to see what his system does with /KEEP and with /KEEP=1 for the same
    example.

    > That's also what I remember, and I was surprised to find it working
    > the way it does.
    >
    > My most often usage is to purge/since to remove all but the current
    > version of source code that I've worked on today (you know, the stuff
    > that has all the typos and compiler errors(8-O), leaving the older
    > version(s). That works just fine. Or, purge a file or directory
    > without qualification; log files, scratch files, report files, etc.
    > Purge seems to work as expected if you don't qualify it.


    Yes, I use that, too (PURGE/SINCE).

    [...]

    > No, I think "my" way would do what you want, because PURGE by
    > definition always keeps at least one version of any file that meets
    > the specs/quals. It should *never* delete all versions of a file that
    > meet those specs/quals, and it should only "look at" the files you do
    > specify. If the TWO.TMP;8 meets your specs (which it does) one version
    > would be kept. The /qualifiers would operate on matching files after
    > the /keep has been satisfied. Again, though for emphasis: It should
    > ignore any file that doesn't match, and keep exactly the number you
    > specify if there are at least that many versions.


    But your way saves the highest version from those that satisfy the
    selection qualifiers, even if that highest version isn't the current
    version. If that same highest-version is not the current version, I
    want it gone. That's the difference. See my other post for an explicit
    example of our algorithms in action. (I want what DELETE/BEFORE=time/
    EXCLUDE=; would do if it were a valid command.)

    > > One more variation: I want to save the current versions of ONE.TMP,
    > > TWO.TMP, and THREE.TMP no matter what. That means saving ONE.TMP;4,
    > > TWO.TMP;8, and THREE.TMP;8. Out of the remaining versions, I want to
    > > delete those with a time stamp of less than 16:30. I can't do this
    > > with your algorithm, but I can with mine. I simply would use $ PURGE/
    > > BEFORE=16:30 and it would do what I want. With your algorithm I'd be
    > > stuck with three extra versions I'd have to manually delete.

    >
    > Same thing.


    Right, I meant one more variation on the _explanation_ of the same
    thing. Sorry, my fault.

    [...]

    AEF


  7. Re: Easy DCL question PURGE vs. DELETE

    On Aug 6, 3:48 pm, AEF wrote:
    > On Aug 6, 1:27 pm, Doug Phillips wrote:
    > > On Aug 5, 7:17 pm, AEF wrote:
    > > > On Aug 5, 4:26 pm, Doug Phillips wrote:
    > > > > On Aug 5, 2:10 pm, AEF wrote:
    > > > > > On Aug 5, 2:20 pm, Doug Phillips wrote:
    > > > [...]

    >
    > > > Example 2:

    >
    > > > ONE.TMP;4 18:00
    > > > ONE.TMP;3 17:00
    > > > ONE.TMP;2 16:00
    > > > TWO.TMP;8 14:00
    > > > TWO.TMP;3 13:00
    > > > TWO.TMP;1 12:00
    > > > THREE.TMP;8 17:00
    > > > THREE.TMP;6 15:00
    > > > THREE.TMP;1 10:00

    >
    > > > Now suppose I want to PURGE this directory but only delete _old_
    > > > versions older than 16:30. This would leave the following:

    >
    > > > ONE.TMP;4 18:00
    > > > ONE.TMP;3 17:00
    > > > TWO.TMP;8 14:00
    > > > THREE.TMP;8 17:00

    >
    > > > Note that TWO.TMP;8 is older than 16:30, but it was saved because I
    > > > used PURGE. Had I used DELETE it would be gone! NOW do you understand
    > > > what I'm trying to do? I can easily do this with the current version
    > > > of PURGE. I can't do this with your version of PURGE unless you add
    > > > the possibility of /KEEP=0 which I would consider to be a rather
    > > > bizarre option for a PURGE command.

    >
    > > > One more variation: I want to save the current versions of ONE.TMP,
    > > > TWO.TMP, and THREE.TMP no matter what. That means saving ONE.TMP;4,
    > > > TWO.TMP;8, and THREE.TMP;8. Out of the remaining versions, I want to
    > > > delete those with a time stamp of less than 16:30. I can't do this
    > > > with your algorithm, but I can with mine. I simply would use $ PURGE/
    > > > BEFORE=16:30 and it would do what I want. With your algorithm I'd be
    > > > stuck with three extra versions I'd have to manually delete.

    >
    > > > > Same thing.

    >
    > > Sorry, I said "same thing" but in re-reading it I now understand the
    > > slight difference (I think??) I guess sometimes I scan too quickly and
    > > for that I do apologize.

    >
    > Sorry, I meant a variation on the explanation because you still don't
    > see what I want to do is not possible with your algorithm.
    >
    > > But, I don't understand which three files you think are excess.

    >
    > [...]
    >
    > Oops, that should have been two, not three. If it followed your
    > algorithm it wouldn't have deleted ONE.TMP;2 and THREE.TMP;6.
    >
    > Please let me try to explain it again.
    >
    > Short version: I want the equivalent of DELETE/BEFORE=16:30/EXCLUDE=;
    > (which is not a legal command!).
    >
    > Long version:
    >
    > Suppose I have a directory containing these files (in the version-
    > unaware sense of the word "file")**:
    >
    > ONE.TMP;4 18:00
    > ONE.TMP;3 17:00
    > ONE.TMP;2 16:00 S *
    >
    > TWO.TMP;8 14:00 S
    > TWO.TMP;3 13:00 S * #
    > TWO.TMP;1 12:00 S * #
    >
    > THREE.TMP;8 17:00
    > THREE.TMP;6 15:00 S *
    > THREE.TMP;1 10:00 S * #
    >
    > The versions marked S are the versions which Satisfy /BEFORE=16:30.
    >
    > The versions marked * are what my algorithm would delete.
    >
    > The versions marked # are what your algorithm would delete.
    >
    > To see how I arrived at the * versions, we can split up the versions
    > into two sets:
    >
    > Current versions:
    >
    > ONE.TMP;4 18:00
    > TWO.TMP;8 14:00 S
    > THREE.TMP;8 17:00
    >
    > Old versions:
    >
    > ONE.TMP;3 17:00
    > ONE.TMP;2 16:00 S *
    > TWO.TMP;3 13:00 S * #
    > TWO.TMP;1 12:00 S * #
    > THREE.TMP;6 15:00 S *
    > THREE.TMP;1 10:00 S * #
    >
    > What I want to do is to delete all the old versions that are older
    > than 16:30. That means all old versions that are also S versions. I've
    > marked these with asterisks.
    >


    Ok, I get it. I know you've explained it before, and I've gotten it,
    but somehow my "light" got turned off while reading the rest of the
    post(s).

    Here's the way the documentation says it should work:

    PURGE/BEFORE=16:30 [default /KEEP=1]
    (process)
    ONE.TMP;4 18:00 -skip because of date.
    ONE.TMP;3 17:00 -skip because of date
    ONE.TMP;2 16:00 -New match: reset count: Keep because of count.

    TWO.TMP;8 14:00 -New match: reset count: Keep because of count.
    TWO.TMP;3 13:00 -match: delete because of count.
    TWO.TMP;1 12:00 -match: delete because of count.

    THREE.TMP;8 17:00 -skip because of date.
    THREE.TMP;6 15:00 -New match: reset count: Keep because of count.
    THREE.TMP;1 10:00 -match: delete because of count.

    3 files deleted.

    You want it to work (the way it works now):

    PURGE/BEFORE=16:30 [default /KEEP=1]
    (process)
    ONE.TMP;4 18:00 -New filename.ext: reset count: Keep because of
    count.
    ONE.TMP;3 17:00 -skip because of date.
    ONE.TMP;2 16:00 -match: delete because of count.

    TWO.TMP;8 14:00 -New filename.ext: reset count: Keep because of
    count.
    TWO.TMP;3 13:00 -match: delete because of count.
    TWO.TMP;1 12:00 -match: delete because of count.

    THREE.TMP;8 17:00 -New filename.ext: reset count: Keep because of
    count.
    THREE.TMP;6 15:00 -match: delete because of count.
    THREE.TMP;1 10:00 -match: delete because of count.

    5 files deleted.

    Right?

    So, the question is: Should HP change the documentation to describe
    the way it works now, or change the command to work the way it's
    documented.

    Please excuse my density. I haven't expected purge to work the way it
    does now, and I haven't expected be able to do what you're doing
    without additional effort. I most often use purge/since to clean out
    source that I've worked on today (you know, the ones with the typo's
    and compile errors(8-O) and leave the originals. If I would have
    expected anything, it would have been to find at least one version
    (or /keep=n versions) of any file dated /before=date, which is exactly
    what you *don't* want.

    Or, I often use it without concern for the date to clear out journal,
    print, and temp-work directories and such. Actually, for "important"
    journals, I usually "BACKUP/BEFORE=date" them to someplace else, and
    then DELETE/BEFORE=date the active directory. Those commands have
    always worked as expected and I test them with any new update/upgrade.
    COPY/BEFORE=date/SINCE=older-date was broken at one time, and wouldn't
    copy *any* files. I don't know when it was fixed because I've gotten
    in the habit of using BACKUP. Another long-ago bug in EDIT/FDL/NOINTER/
    ANAL=file that set the primary key to CHANGES=Y shocked me into total
    paranoia, so I've developed "my" way to do things and I spend the
    testing time on those. If something else breaks, hopefully I'll find
    it when I test it before I try to use, or some other unlucky person
    will find it first.

    Anyway, I don't want a file that hasn't been touched in a long time
    cluttering things up, and if I need to delve into the past I look at
    the archive. Of course, I do PURGEs for various reasons but until the
    ITRC discussion, I never noticed a this "idiosyncrasy."

    So, that's my excuse. It's the best one I can come up with without
    spending lots of time contriving a better one or bringing up the
    misfortunes of my childhood;-)

    [I "purged" the rest of your post where you expounded on the above.]

    P.S. to Norm: I thought you said "Easy DCL question...":-)


  8. Re: Easy DCL question PURGE vs. DELETE

    On Aug 6, 8:21 pm, Doug Phillips wrote:
    > On Aug 6, 3:48 pm, AEF wrote:
    >
    > > On Aug 6, 1:27 pm, Doug Phillips wrote:
    > > > On Aug 5, 7:17 pm, AEF wrote:
    > > > > On Aug 5, 4:26 pm, Doug Phillips wrote:
    > > > > > On Aug 5, 2:10 pm, AEF wrote:
    > > > > > > On Aug 5, 2:20 pm, Doug Phillips wrote:
    > > > > [...]

    >

    [...]
    >
    > > Please let me try to explain it again.

    >
    > > Short version: I want the equivalent of DELETE/BEFORE=16:30/EXCLUDE=;
    > > (which is not a legal command!).

    >
    > > Long version:

    >
    > > Suppose I have a directory containing these files (in the version-
    > > unaware sense of the word "file")**:

    >
    > > ONE.TMP;4 18:00
    > > ONE.TMP;3 17:00
    > > ONE.TMP;2 16:00 S *

    >
    > > TWO.TMP;8 14:00 S
    > > TWO.TMP;3 13:00 S * #
    > > TWO.TMP;1 12:00 S * #

    >
    > > THREE.TMP;8 17:00
    > > THREE.TMP;6 15:00 S *
    > > THREE.TMP;1 10:00 S * #

    >
    > > The versions marked S are the versions which Satisfy /BEFORE=16:30.

    >
    > > The versions marked * are what my algorithm would delete.

    >
    > > The versions marked # are what your algorithm would delete.

    >
    > > To see how I arrived at the * versions, we can split up the versions
    > > into two sets:

    >
    > > Current versions:

    >
    > > ONE.TMP;4 18:00
    > > TWO.TMP;8 14:00 S
    > > THREE.TMP;8 17:00

    >
    > > Old versions:

    >
    > > ONE.TMP;3 17:00
    > > ONE.TMP;2 16:00 S *
    > > TWO.TMP;3 13:00 S * #
    > > TWO.TMP;1 12:00 S * #
    > > THREE.TMP;6 15:00 S *
    > > THREE.TMP;1 10:00 S * #

    >
    > > What I want to do is to delete all the old versions that are older
    > > than 16:30. That means all old versions that are also S versions. I've
    > > marked these with asterisks.

    >
    > Ok, I get it. I know you've explained it before, and I've gotten it,
    > but somehow my "light" got turned off while reading the rest of the
    > post(s).
    >
    > Here's the way the documentation says it should work:


    I still say the doc is ambiguous on this, esp. when /KEEP is mixed
    with selection qualifiers.

    >
    > PURGE/BEFORE=16:30 [default /KEEP=1]
    > (process)
    > ONE.TMP;4 18:00 -skip because of date.
    > ONE.TMP;3 17:00 -skip because of date
    > ONE.TMP;2 16:00 -New match: reset count: Keep because of count.
    >
    > TWO.TMP;8 14:00 -New match: reset count: Keep because of count.
    > TWO.TMP;3 13:00 -match: delete because of count.
    > TWO.TMP;1 12:00 -match: delete because of count.
    >
    > THREE.TMP;8 17:00 -skip because of date.
    > THREE.TMP;6 15:00 -New match: reset count: Keep because of count.
    > THREE.TMP;1 10:00 -match: delete because of count.
    >
    > 3 files deleted.
    >
    > You want it to work (the way it works now):
    >
    > PURGE/BEFORE=16:30 [default /KEEP=1]
    > (process)
    > ONE.TMP;4 18:00 -New filename.ext: reset count: Keep because of
    > count.
    > ONE.TMP;3 17:00 -skip because of date.
    > ONE.TMP;2 16:00 -match: delete because of count.
    >
    > TWO.TMP;8 14:00 -New filename.ext: reset count: Keep because of
    > count.
    > TWO.TMP;3 13:00 -match: delete because of count.
    > TWO.TMP;1 12:00 -match: delete because of count.
    >
    > THREE.TMP;8 17:00 -New filename.ext: reset count: Keep because of
    > count.
    > THREE.TMP;6 15:00 -match: delete because of count.
    > THREE.TMP;1 10:00 -match: delete because of count.
    >
    > 5 files deleted.
    >
    > Right?


    Bingo!

    >
    > So, the question is: Should HP change the documentation to describe
    > the way it works now, or change the command to work the way it's
    > documented.


    If you ask me, leave it as is, and fix the doc to my satisfaction.

    It's late -- I'll comment on the rest later.

    good night

    [...]

    AEF

    > P.S. to Norm: I thought you said "Easy DCL question...":-)


    LOL


  9. Re: Easy DCL question PURGE vs. DELETE

    On Aug 6, 8:21 pm, Doug Phillips wrote:
    > On Aug 6, 3:48 pm, AEF wrote:
    >
    > > On Aug 6, 1:27 pm, Doug Phillips wrote:
    > > > On Aug 5, 7:17 pm, AEF wrote:
    > > > > On Aug 5, 4:26 pm, Doug Phillips wrote:
    > > > > > On Aug 5, 2:10 pm, AEF wrote:
    > > > > > > On Aug 5, 2:20 pm, Doug Phillips wrote:
    > > > > [...]

    >

    [...]

    > Please excuse my density. I haven't expected purge to work the way it
    > does now, and I haven't expected be able to do what you're doing
    > without additional effort. I most often use purge/since to clean out
    > source that I've worked on today (you know, the ones with the typo's
    > and compile errors(8-O) and leave the originals. If I would have
    > expected anything, it would have been to find at least one version
    > (or /keep=n versions) of any file dated /before=date, which is exactly
    > what you *don't* want.


    Right. And when I do want it, I use PURGE/BEFORE=time/KEEP=2.

    > Or, I often use it without concern for the date to clear out journal,
    > print, and temp-work directories and such. Actually, for "important"
    > journals, I usually "BACKUP/BEFORE=date" them to someplace else, and
    > then DELETE/BEFORE=date the active directory. Those commands have
    > always worked as expected and I test them with any new update/upgrade.


    But they're not consistent with each other! The default for DELETE is /
    CREATED while the default for BACKUP is /MODIFIED!!! VMS seems to be
    at least slightly more concerned with appropriate defaults than the
    same defaults. You really want /MODIFIED to be the default for BACKUP,
    but you wouldn't want it to be the default for all the other commands
    that use /SINCE and /BEFORE.

    > COPY/BEFORE=date/SINCE=older-date was broken at one time, and wouldn't
    > copy *any* files. I don't know when it was fixed because I've gotten
    > in the habit of using BACKUP. Another long-ago bug in EDIT/FDL/NOINTER/
    > ANAL=file that set the primary key to CHANGES=Y shocked me into total
    > paranoia, so I've developed "my" way to do things and I spend the
    > testing time on those. If something else breaks, hopefully I'll find
    > it when I test it before I try to use, or some other unlucky person
    > will find it first.
    >
    > Anyway, I don't want a file that hasn't been touched in a long time
    > cluttering things up, and if I need to delve into the past I look at
    > the archive. Of course, I do PURGEs for various reasons but until the
    > ITRC discussion, I never noticed a this "idiosyncrasy."


    What does this have to do with PURGE? A "file that hasn't been touched
    in a long time" could be the current version and PURGE would always
    keep that.

    > So, that's my excuse. It's the best one I can come up with without
    > spending lots of time contriving a better one or bringing up the
    > misfortunes of my childhood;-)


    OK.

    [...]

    AEF


  10. Re: Easy DCL question PURGE vs. DELETE

    On Aug 7, 7:49 am, AEF wrote:
    > On Aug 6, 8:21 pm, Doug Phillips wrote:> On Aug 6, 3:48 pm, AEF wrote:
    >
    > > > On Aug 6, 1:27 pm, Doug Phillips wrote:
    > > > > On Aug 5, 7:17 pm, AEF wrote:
    > > > > > On Aug 5, 4:26 pm, Doug Phillips wrote:
    > > > > > > On Aug 5, 2:10 pm, AEF wrote:
    > > > > > > > On Aug 5, 2:20 pm, Doug Phillips wrote:
    > > > > > [...]

    >
    > [...]
    >
    > > Please excuse my density. I haven't expected purge to work the way it
    > > does now, and I haven't expected be able to do what you're doing
    > > without additional effort. I most often use purge/since to clean out
    > > source that I've worked on today (you know, the ones with the typo's
    > > and compile errors(8-O) and leave the originals. If I would have
    > > expected anything, it would have been to find at least one version
    > > (or /keep=n versions) of any file dated /before=date, which is exactly
    > > what you *don't* want.

    >
    > Right. And when I do want it, I use PURGE/BEFORE=time/KEEP=2.
    >


    Right. But nothing in HELP or the docs even mentions that.

    > > Or, I often use it without concern for the date to clear out journal,
    > > print, and temp-work directories and such. Actually, for "important"
    > > journals, I usually "BACKUP/BEFORE=date" them to someplace else, and
    > > then DELETE/BEFORE=date the active directory. Those commands have
    > > always worked as expected and I test them with any new update/upgrade.

    >
    > But they're not consistent with each other! The default for DELETE is /
    > CREATED while the default for BACKUP is /MODIFIED!!! VMS seems to be
    > at least slightly more concerned with appropriate defaults than the
    > same defaults. You really want /MODIFIED to be the default for BACKUP,
    > but you wouldn't want it to be the default for all the other commands
    > that use /SINCE and /BEFORE.
    >


    I have in my login:

    BCOPY :== BACKUP/CREATED

    and that's actually what I use, but that's not the point, is it.

    BACKUP and DELETE work the way they say they do, so reading the HELP &
    docs for those is actually helpful.

    > > COPY/BEFORE=date/SINCE=older-date was broken at one time, and wouldn't
    > > copy *any* files. I don't know when it was fixed because I've gotten
    > > in the habit of using BACKUP. Another long-ago bug in EDIT/FDL/NOINTER/
    > > ANAL=file that set the primary key to CHANGES=Y shocked me into total
    > > paranoia, so I've developed "my" way to do things and I spend the
    > > testing time on those. If something else breaks, hopefully I'll find
    > > it when I test it before I try to use, or some other unlucky person
    > > will find it first.

    >
    > > Anyway, I don't want a file that hasn't been touched in a long time
    > > cluttering things up, and if I need to delve into the past I look at
    > > the archive. Of course, I do PURGEs for various reasons but until the
    > > ITRC discussion, I never noticed a this "idiosyncrasy."

    >
    > What does this have to do with PURGE? A "file that hasn't been touched
    > in a long time" could be the current version and PURGE would always
    > keep that.
    >


    Sorry I wasn't clear; I was explaining why I might use DELETE to clear
    out certain types of directories. This thread started out PURGE vs.
    DELETE, no? If you were to take my statement "haven't been touched in
    a long while" with a grain of salt, you might guess that I probably
    use DELETE/MODIFIED for those "touched" files. Anyway, whatever I want
    to do with DELETE or BACKUP, I can read HELP or the docs and they will
    tell me how to do it.


    > > So, that's my excuse. It's the best one I can come up with without
    > > spending lots of time contriving a better one or bringing up the
    > > misfortunes of my childhood;-)

    >
    > OK.


    Thanks. I'll stop trying to come up with a better one.(WHEW! I thought
    you might call me on it!)

    I don't think we have a disagreement on PURGE any longer.

    I don't care whether it works the way it does or the way it's
    documented; just one or the other and they should agree. Since I don't
    care and you do, I'll side with you. The docs and HELP should be
    corrected.

    If the docs & HELP are changed, then the release notes should state
    the VMS version where the behavior changed.

    Maybe it is stated someplace but I'm not going to go searching. (see
    above: "I don't care" :-)

    -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
    That was my last smiley and I saved it for last. Until I receive
    the next shipment, please insert smilies in this post, or any other
    post of mine, after any statement that makes you wonder if you were
    just insulted. You were not.


  11. Re: Easy DCL question PURGE vs. DELETE

    On Aug 7, 5:34 pm, Doug Phillips wrote:
    > On Aug 7, 7:49 am, AEF wrote:
    >
    > > On Aug 6, 8:21 pm, Doug Phillips wrote:> On Aug 6, 3:48 pm, AEF wrote:

    >
    > > > > On Aug 6, 1:27 pm, Doug Phillips wrote:
    > > > > > On Aug 5, 7:17 pm, AEF wrote:
    > > > > > > On Aug 5, 4:26 pm, Doug Phillips wrote:
    > > > > > > > On Aug 5, 2:10 pm, AEF wrote:
    > > > > > > > > On Aug 5, 2:20 pm, Doug Phillips wrote:
    > > > > > > [...]

    >
    > > [...]

    >
    > > > Please excuse my density. I haven't expected purge to work the way it
    > > > does now, and I haven't expected be able to do what you're doing
    > > > without additional effort. I most often use purge/since to clean out
    > > > source that I've worked on today (you know, the ones with the typo's
    > > > and compile errors(8-O) and leave the originals. If I would have
    > > > expected anything, it would have been to find at least one version
    > > > (or /keep=n versions) of any file dated /before=date, which is exactly
    > > > what you *don't* want.

    >
    > > Right. And when I do want it, I use PURGE/BEFORE=time/KEEP=2.

    >
    > Right. But nothing in HELP or the docs even mentions that.


    Agreed!

    > > > Or, I often use it without concern for the date to clear out journal,
    > > > print, and temp-work directories and such. Actually, for "important"
    > > > journals, I usually "BACKUP/BEFORE=date" them to someplace else, and
    > > > then DELETE/BEFORE=date the active directory. Those commands have
    > > > always worked as expected and I test them with any new update/upgrade.

    >
    > > But they're not consistent with each other! The default for DELETE is /
    > > CREATED while the default for BACKUP is /MODIFIED!!! VMS seems to be
    > > at least slightly more concerned with appropriate defaults than the
    > > same defaults. You really want /MODIFIED to be the default for BACKUP,
    > > but you wouldn't want it to be the default for all the other commands
    > > that use /SINCE and /BEFORE.

    >
    > I have in my login:
    >
    > BCOPY :== BACKUP/CREATED
    >
    > and that's actually what I use, but that's not the point, is it.
    >
    > BACKUP and DELETE work the way they say they do, so reading the HELP &
    > docs for those is actually helpful.


    The reason I mentioned the inconsistency is that you said that /SINCE
    and /BEFORE should work consistently across commands and/or that they
    do for other commands. I'm just pointing out that even without PURGE,
    they don't. Also, as I pointed out before, blank file-spec fields and
    sticky defaults also don't work the same across commands. In part
    that's to tailor the action to be sensible for the command and in part
    it's just the whim of the programmer.

    > > > COPY/BEFORE=date/SINCE=older-date was broken at one time, and wouldn't
    > > > copy *any* files. I don't know when it was fixed because I've gotten
    > > > in the habit of using BACKUP. Another long-ago bug in EDIT/FDL/NOINTER/
    > > > ANAL=file that set the primary key to CHANGES=Y shocked me into total
    > > > paranoia, so I've developed "my" way to do things and I spend the
    > > > testing time on those. If something else breaks, hopefully I'll find
    > > > it when I test it before I try to use, or some other unlucky person
    > > > will find it first.

    >
    > > > Anyway, I don't want a file that hasn't been touched in a long time
    > > > cluttering things up, and if I need to delve into the past I look at
    > > > the archive. Of course, I do PURGEs for various reasons but until the
    > > > ITRC discussion, I never noticed a this "idiosyncrasy."

    >
    > > What does this have to do with PURGE? A "file that hasn't been touched
    > > in a long time" could be the current version and PURGE would always
    > > keep that.

    >
    > Sorry I wasn't clear; I was explaining why I might use DELETE to clear
    > out certain types of directories. This thread started out PURGE vs.
    > DELETE, no? If you were to take my statement "haven't been touched in
    > a long while" with a grain of salt, you might guess that I probably
    > use DELETE/MODIFIED for those "touched" files. Anyway, whatever I want
    > to do with DELETE or BACKUP, I can read HELP or the docs and they will
    > tell me how to do it.


    Yes, but it quickly moved to what /KEEP should do when selection
    qualifiers are added and stayed there for a long time.

    Touch? The only time I've ever heard "touch" with regard to files is
    Unix, so I wasn't sure what you meant. It could have been accessed or
    modified.

    > > > So, that's my excuse. It's the best one I can come up with without
    > > > spending lots of time contriving a better one or bringing up the
    > > > misfortunes of my childhood;-)

    >
    > > OK.

    >
    > Thanks. I'll stop trying to come up with a better one.(WHEW! I thought
    > you might call me on it!)


    OK.

    > I don't think we have a disagreement on PURGE any longer.


    Great!

    > I don't care whether it works the way it does or the way it's
    > documented; just one or the other and they should agree. Since I don't
    > care and you do, I'll side with you. The docs and HELP should be
    > corrected.


    Thanks!

    > If the docs & HELP are changed, then the release notes should state
    > the VMS version where the behavior changed.
    >
    > Maybe it is stated someplace but I'm not going to go searching. (see
    > above: "I don't care" :-)
    >
    > -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
    > That was my last smiley and I saved it for last. Until I receive
    > the next shipment, please insert smilies in this post, or any other
    > post of mine, after any statement that makes you wonder if you were
    > just insulted. You were not.


    AEF


+ Reply to Thread
Page 2 of 2 FirstFirst 1 2