Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

MIME.EXE Not Conforming To VMS Error Status?

Robert Atkinson
Respected Contributor

MIME.EXE Not Conforming To VMS Error Status?

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.
13 REPLIES
Hoff
Honored Contributor

Re: MIME.EXE Not Conforming To VMS Error Status?

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
Respected Contributor

Re: MIME.EXE Not Conforming To VMS Error Status?

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
Honored Contributor

Re: MIME.EXE Not Conforming To VMS Error Status?

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.
http://www.mpp.mpg.de/~huber
Hoff
Honored Contributor

Re: MIME.EXE Not Conforming To VMS Error Status?

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
Respected Contributor

Re: MIME.EXE Not Conforming To VMS Error Status?

> 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
Honored Contributor

Re: MIME.EXE Not Conforming To VMS Error Status?

>> 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
Respected Contributor

Re: MIME.EXE Not Conforming To VMS Error Status?

Fair enough Hoff.

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

Rob.
Joseph Huber_1
Honored Contributor

Re: MIME.EXE Not Conforming To VMS Error Status?

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.
http://www.mpp.mpg.de/~huber
Wim Van den Wyngaert
Honored Contributor

Re: MIME.EXE Not Conforming To VMS Error Status?

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

Fwiw

Wim
Wim
Hoff
Honored Contributor

Re: MIME.EXE Not Conforming To VMS Error Status?

FWIW, MIME is a DCL command verb on recent OpenVMS releases. You don't need to RUN SYS$SYSTEM:MIME anymore.

Check the mpack and munpack stuff, too -- there are other MIME tools around for OpenVMS -- and see if that can provide what you need here.
Robert Atkinson
Respected Contributor

Re: MIME.EXE Not Conforming To VMS Error Status?

Not on my 7.3-2?

ALPHA_ROB$ mime
%DCL-W-IVVERB, unrecognized command verb - check validity and spelling
\MIME\
ALPHA_ROB$
Joseph Huber_1
Honored Contributor

Re: MIME.EXE Not Conforming To VMS Error Status?

On which VMS version is MIME a DCL verb ? Does it need some extra installation ?

$ sh sys/noproc
OpenVMS V8.3 on node DECUSI 20-FEB-2007 08:58:41.64 Uptime 84 03:29:07
$ mime
%DCL-E-PARSEFAIL, error parsing DCL$PATH:MIME.*

On IA64 8.3 system.
-
BTW mpack:
If somebody wonders, why mpack uses a special MMAIL->SFF command instead of MAIL to send the resulting MIME file: it is because of the empty line before the MIME header. In my installation (Mpack 1.5) I made a small change to put the "Mime-Version" line as the first line (before the messageID): VMS mail (UCX SMTP transport) then sends the file without the empty line. At least since some VMS 7.+/UCX 5.+ versions.
http://www.mpp.mpg.de/~huber
Hoff
Honored Contributor

Re: MIME.EXE Not Conforming To VMS Error Status?

Duh. I've set up DCL$PATH. Nevermind.