[Info-vax] Unexpected error using ZIP for OpenVMS

[AEF]

On Dec 18, 2:15 am, Steven Schweda <sms.antin... at gmail.com> wrote:
> On Dec 17, 11:56 am, Alan Feldman <alanfeldma... at gmail.com> wrote:
>
> > What is an unexpected error?  [...]
>
>    Seriously?  Is this really a complicated or otherwise
> tricky concept?

I think it's partly the different points of view: from the coder and
from the user.

>
>    Here's an example of an error which I'd expect:
>
> alp $ zip31l d0:[0000000]fred.zip login.com
> zip I/O error: no such file or directory
> zip error: Could not create output file (d0:[0000000]fred.zip)

So if you expected "no such file or directory", why didn't you fix the
problem before you ran zip?

>
>    The (excessively quoted) original complaint shows an error
> which I wouldn't (and didn't) expect.  (And don't expect to
> see again, in the next Zip beta kit, and beyond.)

zip warning: non-translatable vms error code: 0x181A8
%rms-w-rtb, !ul byte record too large for user's buffer
        zip warning: could not read input file:
[.usr.robertson.test.MSVCRuntimeDLLS.x86_Microsoft^.VC80^.CRT_1fc8b3b9a1e18e3b_8^.
0^
.50727^.4053_x-ww_e6967989]msvcm80.dll
 (deflated 69%)

In the "expected" case, something that is assumed to be there, and
needs to be there, wasn't. So you were expecting this?

To rephrase: Your code assumes something is there, but when it's not
there it is expected not to be there (the "expected error"), yet still
produces the error message.

I understand assuming it's there. I understand the need to display the
error message when it's not there. I don't see how you can assume
something is there and then expect it not to be. Sorry, I don't follow
that.

In the "unexpected" case, there was a problem with a VMS error code
and and I'd guess a record that was too long.

So you're expecting there to be something missing in the environment
but you're not expecting a strange VMS error code and/or a record
that's too long.

I don't get it. Maybe using a different word would make it more clear.
Upon further reflection, maybe "anticipated" would be more accurate.
But that would sound funny, too: Unanticipated error. Perhaps an
improvement, nonetheless.

As far as anticipating goes, is it really so far fetched to get a non-
translatable vms error code? You've never seen VMS error messages that
didn't get translated properly? Here is a rather contrived one, which
produces the same result that we sometimes see, anyway:

$ BACKUP/IMAGE DSA1: DSA2:[ASDF]
%BACKUP-F-IMGFILSPE, /IMAGE specification must have only device name
$ STAT '$STATUS'
  STATUS = "%X10A380C4"
  SEVERITY = 4   Hex = 00000004  Octal = 00000000004
  ERRMSG = "%BACKUP-F-NOMSG, Message number 10A380C4"
$

So you've never seen error messages like this?

%BACKUP-F-NOMSG, Message number 10A380C4

I'd say this is more annoying than unexpected!

> > "I wasn't expecting an error."
>
>    I wasn't expecting an inquiry so devoid of value.  (Call

LOL!

> me an optimist.)  Time spent on specious nit-picking might be
> better spent on testing the actual code involved here.

I don't have the code, and don't have the time. (Yeah, I have the time
to write this, but debugging would certainly take longer, as I'd have
to get the code, read the code, try the code, etc. So please spare
me!)

I'm sorry, but it just comes across rather strange. It's sort of like
an "unexpected surprise"! Gee, I wasn't expecting a surprise. (^_^)

This reminds me of my favorite error message, the first one in the
error message book. This is the best candidate for an "unexpected
error" I've ever seen:

  AAA,  'file-spec'

  Facility:     RUNOFF, DIGITAL Standard Runoff (DSR)

  Explanation:  This message should never be displayed.

  User Action:  Contact a Digital support representative.

OK, you could convince me that _this_ is an "unexpected error." On the
other hand, does the fact that the coder actually anticipated this
make it an "expected error"?

Gee, I wasn't expecting that.

>    Just a thought.

Steven, you're too much! I love it when you write comedy. Remember the
"File spec wildcard match test?" thread? You were in truly excellent
form. I'd quote a snippet or two here, but it would be out of context.
Here's the ref: http://groups.google.com/group/comp.os.vms/msg/07eaf7e5f4d7a171?dmode=source
for those interested.

Thank you, sir.

AEF

This sig should never be displayed.