Yet another (new-to-me) MIME utility problem.

[sms]

Code: Select all

ITS $ tcpip show version

  HP TCP/IP Services for OpenVMS Industry Standard 64 Version V5.7 - ECO 5
  on an HP rx2600  (1.50GHz/6.0MB) running OpenVMS V8.4-2L3


ITS $ MIME anmac1789_1.mail
MIME> show version
MIME Version: V1.93
MIME> list
Message Headers:
        Content-Type:  multipart/related
        Content-Transfer-Encoding:  7bit/8Bit ASCII
  Attachment: 1
        Content-Type:  multipart/alternative
        Content-Transfer-Encoding:  7bit/8Bit ASCII
  Attachment: 2
        Content-Type:  text/plain
        Content-Transfer-Encoding:  7bit/8Bit ASCII
  Attachment: 3
        Content-Type:  text/html
        Content-Transfer-Encoding:  Quoted-printable
  Attachment: 4
        Content-Type:  image/png
        Content-Disposition:  inline;
          filename="Screenshot from 2023-05-30 21-56-31.png"
        Content-Transfer-Encoding:  Base64
  Attachment: 5
        Content-Type:  image/png
        Content-Disposition:  inline;
          filename="Screenshot from 2023-05-30 22-02-59.png"
        Content-Transfer-Encoding:  Base64
MIME> extract /attachment = 4  
%MIME-I-SAVEFILE, saving file . . . 
SCREENSHOTFROM2023-05-3021-56-31.PNG
MIME> extract /attachment = 5 
%MIME-I-SAVEFILE, saving file . . . 
SCREENSHOTFROM2023-05-3022-02-59.PNG
MIME> [Ctrl/Z]

its $ dire /size
Directory ITS$DKA0:[SMS.IZ.anmac1789]

anmac1789_1.mail;1          525
MIME$204078FA_SCREENSHOTFROM2023-05-302.PNG;2
                            107
MIME$204078FA_SCREENSHOTFROM2023-05-302.PNG;1
                            265
SCREENSHOTFROM2023-05-3021-56-31.PNG;1
                            107
SCREENSHOTFROM2023-05-3022-02-59.PNG;1
                            107

Total of 5 files, 1111 blocks.

   I've grown accustomed to renaming the extracted files to match the
original, mixed-case/extended names, and deleting the spurious
"MIME$<PID>_<whatever>" files, but in this case, the (misnamed?) noise
files conveyed some useful information.  Compare the sizes of the two
different noise files with the sizes of the two not-different extract
files.  (And attend to the names of the noise files.)

its $ diff SCREENSHOTFROM2023-05-3021-56-31.PNG -
 SCREENSHOTFROM2023-05-3022-02-59.PNG
Number of difference sections found: 0
Number of difference records found: 0

DIFFERENCES /MERGED=1-
    ITS$DKA0:[SMS.IZ.anmac1789]SCREENSHOTFROM2023-05-3021-56-31.PNG;1-
    ITS$DKA0:[SMS.IZ.anmac1789]SCREENSHOTFROM2023-05-3022-02-59.PNG;1

   So, mangling the original names causes the data to be lost, too, or
what?

  The obsolete, MIME-unaware e-mail client program is lame enough, but
the result of stacking the still more lame MIME utility on top of it
ought to be embarrassing enough to have triggered some action before
now.  I claim.

   I haven't run this test on E9.2-1, but the MIME version is the same.

[arne_v]

OK.

The server only argument only "discard" the MAIL and MIME utility.

SMTP, POP and IMAP servers are potentially part of a server OS.

And VSI could decide to do something about those.

I suspect enhancing the SMTP server would provide more benefit/cost than enhancing POP/IMAP as those would have to look at email storage and that would requite a significant effort.

Added in 9 minutes 52 seconds:
Re MAIL and MIME utilities deficiencies then they are old. MAIL must go back to the beginning. And I believe MIME is from 7.2 (1998).

Ideally they should have been updated continuously.

But we all know how much (read: little!) CPQ, HP and HPE invested in VMS.

VSI is different. But they have limited resources and need to prioritize.

The functionality of MAIL and MIME are not likely to impact VMS sales at all.

[sms]

Code: Select all

> The server only argument only "discard" the MAIL and MIME utility.

   I believe that I could imagine situations where some program on a
server might want to send _or_ receive an e-mail message.  Ideally,
without having to write/port some kind of e-mail client program to do
the work.

   I don't follow this market closely, so I know nothing.  How many
competitive (server-only?) operating systems are similarly unable to
perform these tasks?

> The functionality of MAIL and MIME are not likely to impact VMS sales
> at all.

   Perhaps not directly.  I suspect, however, that failing to support
basic computer operations which are commonly supported elsewhere might
not be the best way to increase or maintain VMS sales.

   I might flatter myself in thinking that my efforts on VMS (freeware,
mostly) have some small value, too.  But when it gets to the point where
too many simple tasks become too difficult or bothersome to justify
trying to use VMS for them, I'd expect my interest to decline.  Not a
crippling loss, I suppose.

[arne_v]

I might flatter myself in thinking that my efforts on VMS (freeware,
mostly) have some small value, too. But when it gets to the point where
too many simple tasks become too difficult or bothersome to justify
trying to use VMS for them, I'd expect my interest to decline. Not a
crippling loss, I suppose.

If you stopped working on VMS freeware then I would consider that a big loss for VMS!

But it is not obvious to me that email on VMS should impact how easy or difficult it is to develop/maintain code on VMS.

I believe that I could imagine situations where some program on a
server might want to send _or_ receive an e-mail message. Ideally,
without having to write/port some kind of e-mail client program to do
the work.

Having applications use command line utilities to do email is sort of a hack.

Newer languages like Java, Python, PHP etc. have email libraries available.

I suspect that some are available for C/C++ as well, but as always depending on the code it will be either "just a build" or "a big porting effort".

Traditional languages Fortran/Cobol/Pascal/Basic would be a problem. First getting a C/C++ library build/ported and then write a VMS calling convention friendly set of wrapper functions would be a hassle.

[sms]

Code: Select all

> But it is not obvious to me that email on VMS should impact how easy
> or difficult it is to develop/maintain code on VMS.

  It would affect how much I _care_ about developing software on VMS.
It's not a question of "difficult", it's a question of _desirable_.

   I've been running a VMS server for years because it can do what I
want done (FTP/Web server, DNS, e-mail, text editing, data storage with
a reliable backup, and so on).  As it ceases to be capable of handling
those tasks, it loses its value to me.

> Having applications use command line utilities to do email is sort of
> a hack.

   Perhaps, but, however you describe it, it's a capability which I use.