HP3000-L Archives

August 1998, Week 1

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Dirickson Steve <[log in to unmask]>
Reply To:
Dirickson Steve <[log in to unmask]>
Date:
Fri, 7 Aug 1998 17:02:55 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (42 lines)
        <<Steve writes:
        >> patch has evidently altered the PURGE entrypoint functionality.
        ...
        > If it wasn't documented adequately in the Communicator, it's
probably OK to
        > complain about that, but we don't want to harass HP for doing, in
this case,
        > exactly what we asked them to do, exactly the way we asked them to
do it.

        Sorry, but there's no evidence apparent that we asked them to do
"exactly"
        anything.

        The SIGIMAGE enhancement list has always been somewhat less than
precise.
        (e.g., the 'what *does* "FIELD A = FIELD B" really mean?' debate
this week
        at SIGIMAGE.)

        In the case of this enhancement, it was probably something like "add
        confirmation before purging a database".>>


In fact, I think that's pretty close to the way it was worded. No
qualifiers, no exceptions, no alternate-mode considerations. We said "make
DBUTIL ask for confirmation when we specify the PURGE command", and that's
what we got.

        <<Unfortunately, that fails to specify: interactive runs?  batch
runs?  runs with stdin/stdlist that aren't duplicative/interactive?  And,
yes, runs with the "PURGE" entrypoint.>>


Agreed, but a deficiency in the request should not be used as a basis for
complaining about the servicing of the request as submitted, and that was my
point: we got what we asked for, and we want to be careful about complaining
about such service. Though we can certainly learn from the experience, and
word our requests more carefully in the future.

Steve

ATOM RSS1 RSS2