MIME.EXE Not Conforming To VMS Error Status?

[Robert Atkinson]

I was running a script using MIME.EXE, and noticed that although there had been an error, the command procedure didn't trap it :-

$ SET ON
$ ON ERROR THEN GOTO ERROR
$ !
.......
$ @SYS$TEMP:UAM_MIMESCRIPT_20815A5D.TMP
$ RUN SYS$SYSTEM:MIME.EXE
OPEN SYS$TEMP:UAM_MIMEHEADER_20815A5D.TMP /DRAFT
ADD NET$DATA:[FORMATE.PDF.READY]ROPS_4AEF.PDF /BINARY
SAVE
EXIT
Message Headers:
Content-Type: text/html; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 7bit/8Bit ASCII
%MIME-E-NOATTFILE, cannot find attachment file
-RMS-E-FLK, file currently locked by another user
%MIME-W-NOTOSAVE, nothing to save

$ !
$ GOSUB EXPAND_ADDRESS
$EXPAND_ADDRESS:
......


I think that MIME has reported back the '-W-' to DCL instead of the '-E-'.

If the forum agrees, I'll log an official call to HP.

Rob.

[Hoff]

Do look at what the status code was within the DCL to be sure of it, but the percent signs certainly indicate that the NOTOSAVE was the last main error reported.

You can use a DCL OPEN command or other such to lock a file for testing, and Bob's your uncle.

There are MIME ECOs for various OpenVMS releases.

[Robert Atkinson]

It's worse that that - it's wrong Jim!!


MIME> OPEN SYS$TEMP:UAM_MIMEHEADER_20815A5D.TMP /DRAFT
Message Headers:
Content-Type: text/html; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 7bit/8Bit ASCII
MIME> add awsrelease.sheet
%MIME-E-NOATTFILE, cannot find attachment file
-RMS-E-FLK, file currently locked by another user
MIME> save
%MIME-W-NOTOSAVE, nothing to save
MIME> exit


ALPHA_ROB$ sh sym $status
$STATUS == "%X10000001"
ALPHA_ROB$

[Joseph Huber_1]

Well, I would say it is consistent with all other programs, which interpret a series of commands (from sys$input) until quit or exit:

MAIL,FTP,SYSMAN etc. they all behave the same:
the image $STATUS code is the one of the last command (usually success), and how could it be
different ? Exit immediately at the first error ?

Mail and FTP can be invoked in a single DCL command-line: in this case they return the status of the one action.
Mime has no such single command invocation.

[Hoff]

Ayup. Check for ECOs, then (if no ECO or if replicated) report it, and consider mpack or another similar tool in the interim.

It might well be that there simply isn't a mechanism within the MIME tool preserving and propagating the status for use into the EXIT. That there simply isn't a mechanism to preserve and propagate errors for the exit.

I'd prefer that MAIL should be dealing with MIME-encoding and decoding within the utility itself. This is what the mail mechanism within Mozilla, and other similar mail clients, do. Having that would make for a cleaner interface.

[Robert Atkinson]

> the image $STATUS code is the one of the last command

Not sure I completely agree with this. My assumption was that the most severe status is returned when exiting the utility, which we use in our FTP scripts for example :-

$ FTP ftp.site.com
username
password
bin
hash
put netcmd.str
get net.ack
bye
$!
$ STATUS = $STATUS
$ SH SYM STATUS

My question still stands. Is this method in MIME by design, or something that's been missed?

Rob.

[Hoff]

>> My question still stands. Is this method in MIME by design, or something that's been missed? <<

That's a question for OpenVMS Engineering, and specifically for the maintainer of the MIME utility.

While I can understand the coding that can lead up to the (lack of an) error status, not having a way to field and propagate errors detracts from the usefulness of the command.

Some command tools propagate the most severe error, and some don't. Those that do propagate the most severe will also typically provide a way to force a successful return.

But whether or not this case is an error is up to the MIME maintainer within OpenVMS Engineering. (The fellow that was maintaining MIME when last I knew hasn't posted here -- not under his own name.) And if this behavior isn't considered an error, then this change (implemented in a compatible fashion) would then be an entirely reasonable enhancement request.

[Robert Atkinson]

Fair enough Hoff.

I'll log a call with HP then, and see what their take is on it.

Rob.

[Joseph Huber_1]

My experience is: neither MAIL nor FTP (UCX) or HGFTP forward errors from commands (the last severe or whatever) to the exit/quit status.

Would be good for the MIME utility to implement the execution of a DCL command like

MIME/result_file=x/input=y
or
MIME/result=x ADD thisfile

In this one shot mode it easily could return the status of the command.

[Wim Van den Wyngaert]

I learned to use "on warning" instead of "on error". There are simply too many warning that should be errors.

Fwiw

Wim