Last news April 2003: Andy Harper's pages disappeared from their old server sometime after 1997; in 2001 they were located at http://www.agh.cc.kcl.ac.uk/files/vms/pine-vms/ but by 2003 that too had disappeared.

Our group is now (June1997) on the point of phasing out the VAX/VMS operating system, so I shall not be doing any further work on PINE for VMS here. This page is therefore effectively frozen. I refer you to the other resources on this topic.

"So long, and thanks for all the fish".

PINE for VAX/VMS systems

Andy Harper did a lot of work at KCL, beyond the last version (3.91beta5) from Yehavi, but his associated web page has now disappeared, and the FTP archive does not respond.

Latest version that I spotted was 3.91 beta 12, which I can't tell you about from my own experiences - I believe it addressed many of the issues mentioned here.

I used Andy Harper's version 9 for a while, and on the whole, it seemed successful. But the handling of the newmail folder was still erratic, with error tracebacks and occasional crashes when new mail arrived during a session, and I decided to resort to the same strategem as I had done before, namely, to pretend (both in the compiled code VMS_MAIL.C and in the configuration) to PINE that the new mail folder is called INBOX, which of course it isn't, and then to treat the NEWMAIL folder as just another folder, which can be opened and closed at will. That got things working to my reasonable satisfaction, but I'm in no way intending any public argument with him about the best way to deal with this! I merely mention here what I am doing, and leave the reader to form their own opinion.

Andy H's version deliberately does not drop the mails through from NEWMAIL into MAIL folder when they have been read: this makes his version behave more like PINE does on Unix systems, but less like VMS MAIL users are accustomed to. I'm finding that VMS MAIL now gets confused about how many new mails I really have, and from time to time I have to go into VMS MAIL, empty the newmail folder, and issue READ/NEW to re-synchronise its view of the situation. A.H tells me in email that it's fixed in later versions.

A.H's version has tidied up the code for recognizing RFC822 headers, although it has not changed the principle of the method by which they are identified, and it's still necessary to tabulate all the headers that might come first in an RFC822 header block. This is an impossible task, since someone could always come along with a new, invented, header, like X-favourite-drink: that would be quite legal per RFC822 but would "throw" VMS PINE. Well, by adding three or four headers I managed to make A.H's version handle pretty well all of the mails in my current mail folders, and I fed them back to him for incorporation in the distributed version.

Much as I would like to see this all working, we only got PINE working on VMS as a transition aid; the transition took longer than we had originally envisaged, but now that we are on the point of making the transition, I don't expect to make any further contributions to this topic. The main body of this web document should now be treated as an interesting piece of history - feel free to learn anything that you can from it, but be sure to check it against current reality!

Andy already had called my attention to his ported version of IMAPD 3.91 (Yehavi's was still at 3.89). I'm afraid I have had even less time to look into that, though.


(Minor updates, mostly just cosmetic, 28 Oct 96 and 3 mar 97).
(Update 03 June 1996: we finally decided to build 3.89 IMAPD)
(Some updates added 01 Feb 1996)
(some updates to 22 Nov 1995 and version 3.91 "BETA 5")

We investigated software (preferably free) for handling MIME format mail on VMS in our own environment. This document is likely to be incomplete in many respects, as well as possibly describing problems that have been resolved in later versions: it should be regarded only as describing work-in-progress. It is offered in the hope that it might be useful, but it has to be entirely the responsibility of the reader to determine how and to what extent it is relevant to their particular situation.

Mention of "JANET mail" and the terms "CBS" and "NRS" should be disregarded by any reader who does not understand what they mean. They relate to now-obsolete networking procedures over the original JANET X25 network.

Introduction

There are two quite different classes of approach to handling MIME format mail that has arrived on VAX/VMS: 1/ to find software that will handle the MIME format mail on the VAX/VMS system, or 2/ to pass on the mail to a platform that can handle MIME format mail already. The main part of this document is concerned with the first approach, and in particular with VAX/VMS ported versions of PINE. The second approach is discussed in my MIME briefing.

PINE

PINE itself is a MIME-compatible mail package that is made available free from the University of Washington. It is available for various platforms, but not (from Washington) for VMS. The FAQ (Frequently Asked Questions) document for PINE, and related documents, are available by anonymous FTP from the directory /pine/docs at ftp.cac.washington.edu.

Versions of PINE etc. for VMS

There is a free port of PINE to VMS, available at Hebrew University of Jerusalem (HUJI), from Yehavi Bourvine. I am informed that there is also MIME support in two commercial packages, PMDF and ECSmail, but these have not been investigated in detail. On the central VAXes at DESY, I find that the command PINE calls up a VMS version of PINE 3.89: its provenance is not immediately apparent, but taking "R" [Relnotes] from the main screen reveals that this is the port of PINE associated with PMDF, and the claim is made "VMS PINE is the first implementation of PINE on VMS". This would suggest that they are claiming the name "VMS PINE" for their particular ported version. I had already referred repeatedly to Yehavi's ported PINE as "VMS PINE", but to avoid misunderstandings, I have now changed these references to "PINE for VMS", and references to "PINE" or to "PINE for VMS" below are references to Yehavi's (HUJI) ported package unless otherwise stated.

The HUJI port of PINE for VMS

The HUJI port of PINE to VMS was able to be retrieved as a ZIP file by anonymous FTP from the directory LOCAL at VMS.HUJI.AC.IL (the FTP server didn't like to be accessed by a web browser, so there is no link here). HUJI's FTP server demands a userid of "anonymous" (the customary equivalent of "ftp" is not accepted). The version that is being reported on here was PINE_3_91_BETA_3.ZIP, available in Feb'95 - naturally, you need a VMS version of UNZIP.EXE (available in the same directory) for unwrapping this dataset.

The version has since been revised to BETA_4 and then, when I looked in July'95, to BETA_5. I retrieved the BETA_5 version and built it (for MULTINET on VAX platform) without problems, but I was somewhat surprised to see that it still claimed to be version "b4" and that the file describing "changes since last version" was still describing the changes from 3 to 4, with no mention of version 5. I emailed Yehavi to enquire whether this was a mistake, and he returned me a brief reply to say that the only changes related to dealing with the UCX-type mail headers.

The software was clearly being actively worked on by a keen individual, but from the relatively little discussion it gets, I assume it is not widely used. Please assess its suitability in the light of your own circumstances. However, as it works with the same mail folders that are used by VMS MAIL, there is nothing to lose by trying it out for a while, alongside MAIL if you wish. There is nothing to prevent a user from continuing to use VMS MAIL as their chief mail client, and having recourse to PINE only when they desire its specific benefits, e.g to process an incoming mail that turned out to be MIME-encoded. Both mail clients work on the same MAIL filesystem, and offer facilities such as moving mail to folders, retrieving old mails from folders etc. and users do not have to commit themselves to using one package to the exclusion of the other.

The instructions for building the package are found in the file README.VMS, a copy of which has been provided on this web server for information only (the same text came with BETA_5 as with BETA_3, but if you are going to install a version, you should obviously use the README.VMS that comes with the version that you are installing).

There were some problems with the version of [...C-CLIENT]VMS_MAIL.C included in BETA_3. Yehavi provided some corrections, which were successful in getting the package to recognise most mail that had arrived via SMTP on our system, and to decode those that were MIME-encoded. However, there were still some items of Internet mail that were not recognised correctly; I have written a separate section of this note to explain the situation.

Recognition of mail headers in VMS_MAIL.C

In our situation, there are two kinds of mail: DECNET mail, which VMS MAIL presents with just VMS MAIL headers, and Internet (SMTP) mail, which VMS MAIL presents with first a set of VMS MAIL headers, and then a set of RFC822 headers; a third kind of mail, by now only legacy items but still in some of our users' mail folders, might also have arrived on our system by Coloured Books software, in which case they have a set of VMS MAIL headers followed by a set of CBS headers (the latter are almost identical to RFC822 headers, but always start with a header "Via: ...").

I understand that on other systems, the RFC822 headers might appear after the body of the mail, rather than appearing between the VMS MAIL headers and the body.

In the file VMS_MAIL.C (in the C-CLIENT subdirectory), there is code intended to recognize the presence of RFC822 headers in a mail. As supplied by Yehavi, this now works on a good proportion of mail items, but not on all of them. There are two similar blocks of code, both prefaced by a comment stating "Now, check for RFC822 header". I have not investigated in detail why this code is duplicated, but so far I have just gone along with what is there. The intention, apparently, is to recognize whether the first non-blank line in the appropriate part of the mail item matches one of the known RFC822 header tags. However, Internet mails show great variation in which RFC822 header comes first, and Yehavi's selection of tags does not cover all cases. I have seen cases, for example, where the first header tag was "X-Mailer:" or "X-Sender:", and there will no doubt be more.

I find it rather worrying just how little checking seems to be going on here. If by mischance a DECNET mail (i.e one without RFC822 headers) happened to begin with "Subject:" or any of the other recognized tags, it seems to me that this routine would be misled into believing it had found an RFC822 header block...

Anyhow, the quick-fix is clearly to keep adding headers to the two blocks of code (keeping them in step with each other, I guess!) until all relevant Internet mails are recognized. And to hope that if something goes wrong with the code mistakenly believing there is an RFC822 header in one or more DECNET mails, it does not cause too much confusion. In the PINE mail index, in our situation you can recognize which of the existing mail items have not been correctly recognised, by the fact that they appear to come from an address beginning "SMTP%" - then by reading that mail item and inspecting its first RFC822 header you can find which tag needs adding into the VMS_MAIL.C code.

I can't help thinking that an alternative approach would be useful, but not being fully familiar with Yehavi's existing code I did not want to go crashing in and changing it.

This works for our set-up: your mileage might vary!!!

MULTINET configuration and VMSBUILD.COM

Our MULTINET configuration has been set so that inbound mail is prefaced by both a set of VMS headers and a set of RFC822 headers (MAIL-CONFIG SET HEADER-CONTROL MAJOR). It seems plausible to me that it would also work if the VMS headers were omitted, but I believe the presence of the RFC822 headers is essential: its MIME support, in particular, could not work if the RFC822 headers were omitted. As of version BETA_4, support was included for the RFC822 headers being at the end, as happens with UCX (I am only reporting this - I have not myself used the package with UCX).

Please read the restrictions stated in the README.VMS file referenced above. Further notes follow.

I generated the package on our system thus, as a perfectly ordinary user without special privileges, having unzipped the product into a directory tree hanging from [...pine3_91]. I simply followed the instructions, finally issuing the command

@VMSBUILD MULTINET
Yehavi's VMSBUILD.COM files are written on the assumption that when run on a VAX platform, the default C compiler will be VAXC. They do not work correctly in this situation if in fact DECC is the default (you get swathes of warning messages, and the build command terminates prematurely with errors reported). The simplest workaround is to issue, from the VMS command line, the following command
cc == "cc/vaxc"
prior to starting to use the VMSBUILD commands (this tip was in the DEC C for Open/VMS VAX V5.0-003 release notes).

As you can see by inspecting the VMSBUILD.COM files, they follow a different path on an Alpha Open/VMS platform, and run the DECC compiler according to VAXC rules: I have not assessed whether this would also be a viable combination for use on the VAX platform.

We run MULTINET. I did not have nor attempt to use NETLIB. It worked for me, despite several warnings issued during the build process, including mismatches between MAILSHR.EXE and IMAGELIB.OLB.

To be specific, my home directory is $DISK11:[USERS.FLAVELL]
I put the package in subdirectory [users.flavell.pine3_91] and the PINE executable was built in the subdirectory PINE.
In my LOGIN.COM, I inserted the following:

$ pine :== "$$disk11:[users.flavell.pine3_91.pine]pine"
During testing, I did not use the SYS$MANAGER:PINE.CONF configuration file, but did all configuration via the .PINERC file in my own login directory. After tests were complete, the .EXE file was moved to a publicly-accessible area, and the SYS$MANAGER:PINE.CONF file was set up to create a reasonable default configuration for users.

Note in particular that:

Be sure to observe the configuration restrictions documented in the README.VMS file, or the results may be quite bizarre. (If you have run an earlier version of PINE for VMS, e.g Yehavi's PINE for VMS 3.89, then version 3.91 will attempt to update your .PINERC file for you, but you should go into Setup/Config and check the result against the restrictions in README.VMS.)

You might wish to consult a copy (plain text) of the user notice in which I announced the package to our users.

The Open/VMS DEC ALPHA Platform

I've been rather unclear about this, as I haven't sorted it out myself and I've received some conflicting reports in the past from other sites.

1 Feb 1996 I received a mail from Mike Doherty of RAL describing some modifications that had led to success. I understand that he is in contact with Yehavi, and I guess the modifications would find their way into the distributed version, but in the hope that it may help others in the meantime, here is an extract from what he wrote to me.


I have encountered problems with the Alpha version. I am running the same 
versions of the above software with DECC v5.0.

When I compile, I get the following warnings from [.c-client]vms_build.com

%LINK-W-NUDFSYMS, 2 undefined symbols:
%LINK-I-UDFSYM,         MAILDRIVERS
%LINK-I-UDFSYM,         STDPROTO
%LINK-W-USEUNDEF, undefined symbol STDPROTO referenced
        in psect $LINK$ offset %X00000250
        in module OS_VMS file UDISK00:[DOHERTY.PINE.PINE3_91.C-CLIENT]OS_VMS.OBJ
;3
%LINK-W-USEUNDEF, undefined symbol MAILDRIVERS referenced
        in psect $LINK$ offset %X00000380
        in module OS_VMS file UDISK00:[DOHERTY.PINE.PINE3_91.C-CLIENT]OS_VMS.OBJ
;3

                                                       
Progress as of 10/1/96....                    

Modified [.C_CLIENT]ENV_VMS.C
**New Version***
  126   /*      #if defined(__VAX) && defined(__DECC)   */
  127   #if defined(__DECC)
  128   #pragma extern_model save
**Original Version**
  126   #if defined(__VAX) && defined(__DECC)
  127   #pragma extern_model save
************

**New Version***
  193   /*      #if defined(__VAX) && defined(__DECC)   */
  194   #if defined(__DECC)
  195   #pragma extern_model save
**Original Version**
  192   #if defined(__VAX) && defined(__DECC)
  193   #pragma extern_model save
************

This now enabled me to build PINE without any errors. The program would run and
mail could be viewed, however, I could not send mail (Ctrl-X), and received the
following error message:

Bug in Pine detected:
Exiting pine.

I then used the debugger to trace this to [.PICO]COMPOSER.C to the follwing
lines of code:

        if(retval != FALSE){
            while(line != NULL){
                strcat(*headents[i].realaddr, line->text);
                if(line->text[strlen(line->text)-1] == ',')
                  strcat(*headents[i].realaddr, " ");
                line = line->next;
            }
        }

I then changed this to deal with the problem (empty strings):

        if(retval != FALSE){
            while(line != NULL){
                if (line->text[0])      {
                strcat(*headents[i].realaddr, line->text);
                if(line->text[strlen(line->text)-1] == ',')
                  strcat(*headents[i].realaddr, " ");
                }
                line = line->next;
            }

The program now seems to be OK. However, I'm not sure how some of these changes
will affect PINE.


Further comments on the package

I can confirm that in appropriate circumstances, the VMS version of XV can be fired up automatically by PINE in order to view an image enclosure. If course, you need to have your VMS session configured appropriately so that X Windows can throw a window onto your display. One slightly annoying feature is that your PINE session is then unresponsive to further commands until the XV session is closed (can someone familiar with VMS task handling tell us whether this could be improved?).

IMAPD server

In June 1996 I finally decided to try out the VMS IMAPD implementation. After checking that there had been no developments in this area at HUJI, I retrieved the 3.89 (beta 9) package from there. The build instructions were a little cryptic, as they seemed to call for various renamings of directories. After a little study I decided it was likely that the unpacked ZIP file already had the desired directory structure, so I disregarded that part of the instructions and merely issued the

@VMSBUILD MULTINET

command from the usual directory. This seemed to go well at first, but it reminded me by means of a swathe of compilation error messges that I had forgotten to issue the preparatory command

cc == "cc/vaxc"

that I mentioned earlier in this report. After doing that, and repeating the @VMSBUILD, I found I had created an IMAPD.EXE that, when run from the command line (RUN IMAPD) put out a normal looking IMAP2bis server greeting and awaited input. So far, so good.

It is then necessary to proceed to the MULTINET configuration utility (I did this from the SYSTEM userid) as described in Chap 7 of the MULTINET Administrator's Reference (V3.3 for OpenVMS).

$ MULTINET CONFIGURE /SERVERS
SERVER-CONFIG> ADD IMAP
Protocol: [TCP] TCP
TCP Port number: 143
Program to run: ...full path to IMAPD.EXE
...
SERVER-CONFIG> RESTART

The VAX was then able to accept an incoming IMAP call on port 143 and respond in an appropriate way. It does seem to work, usually. It managed to crash on several occasions, sometimes in the face of provocation (I was trying to access my mail folders at the same time as I had them opened by VMS MAIL in another session) and sometimes not. However, this was merely a crash in the software accessing the mail: there seems no reason to believe that the mail itself had come to any harm. So, this seems a useful feature, for anyone who would like to work that way.

Caveat: I had no problem (apart from the one mentioned) in building the software for one of our VAX systems, and the EXE ran fine on that system, but would not run on a different VAX system (that presumably had a different software release running) due to image ident mismatch. When I tried to re-build the software on the latter system, it didn't work, due to (I forget what) errors reported during the compile/link stage. No time to investigate the differences yet, but this suggests that you may not be entirely trouble free if you try this on an arbitrary system.

Files from the Mac platform?

Obviously, an application file from the Mac platform, even though it can be decoded on the VAX using PINE, is not normally going to be very useful on the VAX. One day, I received what appeared to be such an attachment, with headers indicating it was in multipart/appledouble format and I rather assumed it wouldn't be usable: however, this turned out to be displayed by PINE as enclosures 2.1 in format application/applefile, which one was able to disregard, and 2.2 in format application/postscript, which was a perfectly ordinary PostScript format file that I was able to print on our laser printer. So, there are indeed some special cases where it does something useful on our VMS system.

The only minor infelicity in this case was that the default filename of the postscript enclosure was not a valid VMS filename: I failed to notice that at my first attempt to save it to file, and got an uninformative error report ("65535", if I recall correctly), but when I specified a valid VMS file name it worked fine.


[Prev][Up] [PPE Home][Rag-Bag][Me]

Original materials © Copyright 1994 - 2006 A.J.Flavell