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:

In your initial testing, it is vital to configure default-fcc="" and folder-collections=SYS/[] as is stated in the README.VMS. No other settings are supported for local folders. I personally recommend using Setup/Config from the Main menu, although those with strong nerves could try editing .PINERC using a suitable text editor. In any case you should use Setup/Config to review what settings PINE is really using, if you have any problems that seem to be related to your configuration. Once you have transferred the appropriate settings to the SYS$MANAGER:PINE.CONF file, you and your users should not need to do anything special about default-fcc and folder-collections, because the correct settings will be taken from PINE.CONF. Do not worry that these settings will not appear in their private .PINERC files - as I said, you can verify via the Setup/Config menu that the correct values are being used, for example the default-fcc line should appear as:
default-fcc =
I have chosen the option to set smtp-server (i.e PINE for VMS will send mail by making an SMTP call to the designated SMTP server - see further comments below).
user-domain was set explicitly. This was necessary in our environment because only V2 complied with the rules for receiving JANET mail. (Note added 1996 - that distinction, a piece of Coloured Books software history, was no longer relevant; but it's still the case that we have to take care to stamp outgoing mail with a meaningful From address - some of our stations are DECNET-only and can only receive incoming mail via the two stations that have MULTINET running (V2 and V6, as it happens).
It is useful for each user to configure their personal-name, as the default seemed to be all in capitals.
There are some PINE commands that are not supported in this "port", as can be seen by referring to the source code of VMS_MAIL.C in the C-CLIENT subdirectory; not all of these limitations are explicitly mentioned in the README.VMS.

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

PINE only sends mail via SMTP. Mail that has arrived via other mechanisms (DECNET, CBS) can be viewed, but a reply is not supported since DECNET and CBS addresses are meaningless to SMTP.
The mail index for items that arrived by DECNET is missing a subject field, as well as having "xxx -1" in the date field. (Remark: the DECNET subject header is "Subj:" instead of "Subject:", and we have not seen any code to handle that discrepancy). The same symptoms are seen with SMTP mails whose RFC822 headers have not been identified for the reason already explained.
Two options for sending mail were offered: either by VMS MAIL foreign protocol (by defining PINE_MAIL_PROTOCOL as SMTP to VMS), or by direct SMTP to some SMTP server (defining smtp-server in the config file). Yehavi says that he prefers the latter, and his sample config file shows him pointing at the SMTP server on his own system: we do the same (pointing at our own system, of course, not at Yehavi's!) and this seems to work fine. But when I tried the first option, I got all sorts of strange results, so I had to consider the first option to be unusable in our environment. I offer no explanation as I have not investigated the reasons.
The README.VMS file makes some obscure comments about the possibility to set inbox-path=NEWMAIL. I asked on usenet and got only one answer: namely, that it is wise to take the default (inbox-path=INBOX, which on VMS will normally always be empty!) and explicitly go-to (G) NEWMAIL when PINE starts up (you can make this easier by configuring the initial keystroke list to g,n,e,w,m,a,i,l,CR if you wish). However, there was no detailed explanation of what can go wrong if one takes the other option indicated by Yehavi, to configure inbox-path=NEWMAIL. I tried it myself, briefly, and found that PINE was liable to crash when you tried to move out of the NEWMAIL folder.
When new mail arrives (screen message from VMS), if you are not in the folder NEWMAIL then you can G(oto) NEWMAIL and view the new mail, whenever convenient. If you are in the folder NEWMAIL, then going to it will have no effect. One trick that I found was to try to G(oto) a non-existent folder, say "X", PINE for VMS will then go through the motions of closing NEWMAIL, find that "X" does not exist, and re-open NEWMAIL, complete with the newly-arrived mail(s). By the way, if you find the screen messages a nuisance, you can clear them by repainting the screen (control-L within PINE).
PINE for VMS cannot explicitly create, rename or delete folders. However, if you Save a mail item to a folder that does not yet exist, it will be implicitly created; and if you delete the last mail item in a folder, the folder will be implicitly deleted. (Note that, unlike VMS MAIL, there is no prompt associated with folder creation, so that if you save a mail item to a mistyped folder name, then you'll have to go hunting for it later.)
When handling folder names for the VMS system, PINE for VMS converts them to upper case. This is usually convenient, since it does not matter what case you type them in. (There is no problem handling mixed case folder names on remote systems that you are accessing via IMAP protocol). It's in fact possible to create mixed case folder names in VMS MAIL, but PINE does not seem to be able to handle those. I look in the code for vms_mail_open and see some code there that appears to be intended to preserve the case of a VMS folder name if it has been enclosed in quotation marks, but I have not been able to make this work. This problem was pointed out be Mike Doherty and I think he plans to contact Yehavi about it.
As is correctly stated in Yehavi's README.VMS, FCC must be configured off ("") because it does not work. If you try to configure a value for default-FCC, (say, OUTMAIL), or even to take the default, it will attempt to save a copy of outgoing mail in a folder, and report that it failed. Thanks to Dave Sankey for an effective circumvention - in the .PINERC I configured (for example):
customized-hdrs=Bcc: flavell

which, indeed, convinces it to send a copy to myself. This is effective both for freshly composed mails and for replies etc. Of course, (as with VMS MAIL's COPY SELF), these copies arrive in NEWMAIL rather than being posted to your choice of sent-mail folder.
PINE for VMS calls the same routines as are used by VMS MAIL itself, so mails migrate automatically from the NEWMAIL folder to the MAIL folder after you have dealt with them, in just the same way as with the VMS MAIL command. It is presumably unwise to attempt to turn on PINE for VMS's "auto-move-read-msgs" option (I didn't try it).
Attempting to run two or more copies of PINE, or PINE and MAIL, against the same set of mail folders simultaneously, can result in a crash. It did not seem to cause any harm to the mail itself, fortunately.
README.VMS says that messages cannot be "postponed". This did not seem too surprising on VMS, since the PINE's postpone command is CTRL/O, which means something quite different to VMS. I was interested to see that there is a circumvention: PINE offers the alternative of issuing CTRL/? commands as ESC ESC ? . However, I tried ESC ESC O and that did not work either. So the README.VMS seems to be completely accurate ;-(
I have been unable to make printing work. The "system" printing command does nothing useful, and the "customized print command" option expects to pipe the document into the print command, which presumably isn't going to work on VMS. All attempts to print by these options result in an error 2 being reported. Option 1 (print to attached ansi printer) is not applicable to my situation anyhow. Please disregard whatever you see configured into my .PINERC: whatever it was, it didn't work!
When I am sent a MIME message containing (for example) a Pound Sterling character, PINE displays the following caution:
[The following text is in the "iso-8859-1" character set] [Your display is set for the "US-ASCII" character set] [Some characters may be displayed incorrectly]

The pound sterling characters are then displayed as hashes (which would be normal for using the *UK* variant of the 7-bit ASCII character code, on a US-configured display, but the caution did not actually mention the UK character set). If the display does, in fact, support the ISO-8859-1 character set, you can configure the character-set option in PINE accordingly: the warning is not then displayed (but if you move around between different kinds of display then this may not be a wise choice). Note that PINE has no facilities for mapping characters from one character set to another: it expects you to configure .PINERC to correctly reflect the character code which your terminal (/emulation) is currently supporting, and PINE's only contribution to the proceedings is to display a caution, like the one shown above, if the incoming mail (as shown by its MIME headers) had been sent using a different character set.
When executed in the absence of a .PINERC file (typically this is a new user), the package will offer to have an introductory document emailed to the user. This document contains, amongst other things, invitations to the user to report bugs to them. Your users would have to be clearly notified that the VMS ported package is NOT supported by Washington, and so they should not, in fact, consider submitting such bug reports.
PINE for VMS creates embarassingly long message-ids. This can cause trouble if mail is passed though a BITNET-style mail gateway that chokes on lines of 80 chars or more. Dave Sankey supplied a slightly modified version of REPLY.C (which contains the message-id generation code), and I have been using it satisfactorily. This fix has been incorporated in the BETA_4 package.
PINE 3.90 introduced facilities enabling PINE to act as a usenet news reader and posting client. Having tried these superficially, I must say I prefer to stay with NEWSRDR on the VMS systems. There is one specific VMS problem with PINE for VMS: it tries to update .NEWSRC by saving an old copy as .newsrc.old, which is not a valid filename on VMS.
Dave Sankey reports that addressbooks imported from Unix systems were not in a format acceptable to PINE for VMS. It seems that PINE for VMS required the addressbook to be in the VMS file format known as Stream_LF. He suggests the following procedure
1. Transfer the file from unix to VMS in binary mode
2. SET FILE/ATTR=RFM:STMLF
I have presented this package to my users as a means of manipulating local mail folders. Dave Sankey however reports success with using it as a VMS client to access, via IMAP protocol, his mail folders on remote (non-VMS) systems. Use the regular PINE documentation to determine the correct syntax to use for remote IMAP folders, there is nothing special about the VMS port in this respect. In order to avoid problems, though, if you don't normally take mail on the VMS system (and therefore don't have a MAIL.MAI file) Dave recommends to send yourself at least one mail on the VMS system in order to create the MAIL.MAI file that the VMS mail routines expect (if you normally have VMS MAIL "SET FORWARD" active, then turn it off temporarily while you do this). Dave has set up PINE for VMS with a customized header "Reply-to:" to specify his preferred email address, since the From: address of PINE for VMS will be that appropriate to the host from which the mail is being sent, not the remote host where this type of user keeps their mailbox.
Yehavi offers his port of the IMAPD server daemon from PINE 3.89. Running this would allow users who take their mail on the VMS system to view it via IMAP clients (such as PINE) running elsewhere.
VMS has a little joke up its sleeve for those who try to e.g RENAME .PINERC OLD.PINERC, carry out some tests, and then rename the old file back again. You find that RENAME OLD.PINERC .PINERC, or even COPY OLD.PINERC .PINERC, are ineffective! You might RENAME .PINERC .OLDPINERC, which can be reversed, or, if you have already got yourself into the trap, you could EDIT .PINERC and INCLUDE OLD.PINERC.
Occasionally, an error such as
Can't read from terminal; status=1, iosb=2104
is reported, and PINE exits to the command line, losing the work in progress. The times I have got this, I have either been trying to paste several lines of text into the terminal window, or trying to scroll rapidly using auto-repeat of the cursor buttons, while composing a mail. Yehavi's response to this was to confirm that iosb=2104 did indeed signify overrun, but he did not suggest any circumvention - other than refraining from the kind of activity that causes the problem, of course.
I did, however, later discover a useful solution to this. Before starting to compose the mail, use the "alternate editor" command (control-underscore) to call up your favourite VMS editor: you will then be able to paste pretty-well ad lib into your edited document, etc., and if the editor is one that keeps a journal (crusty old me still uses EDT, sorry; you can configure your favourite editor command in PINE's setup, or you can let it prompt you for it) then even if it crashes out for some reason, you'll still be able to recover the partly-composed mail, whereas PICO loses all of your work when it crashes.

When you exit from the editor, you will find that your composed mail is presented in PICO: then just use control-X in the usual way to send it. Note - if you construct a significant amount of mail in PICO and then decide to invoke your choice of alternate editor, it may not be successful (i.e it may crash and lose your work so far): I recommend that if you are going to use this technique, you select the alternate editor, before starting to compose your mail.

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.