VAX support

VAX support

Post by Phillip Helbi » Tue, 01 Jul 2003 17:30:07



Quote:> IIRC this common code base thing meant that MAIL was re-written from
> MACRO to C, and is why many of us have maintained the old MAIL
> executables after upgrades.  

I use the (undocumented) MAIL/OLD feature.

Quote:> Probably by 7.3-1, they work correctly but I have no interest in
> worrying about that.

I don't understand the MAIL rewrite at all.  It was rewritten from BLISS
to C.  MACRO I can understand.  But as far as I know BLISS is still used
internally by VMS, even on Itanium.  So why was MAIL rewritten in C?  
And what lack of quality control caused documented features to break?
(In my particular case, I run MAIL/OLD since the new executable doesn't
allow me to spawn out of EDT called from within MAIL, saying that the
command tables have invalid format.)  And why has this not yet been
fixed (as far as I know)?
 
 
 

VAX support

Post by Larry Kilgall » Tue, 01 Jul 2003 20:02:58



Quote:>> IIRC this common code base thing meant that MAIL was re-written from
>> MACRO to C, and is why many of us have maintained the old MAIL
>> executables after upgrades.  

> I use the (undocumented) MAIL/OLD feature.

>> Probably by 7.3-1, they work correctly but I have no interest in
>> worrying about that.

> I don't understand the MAIL rewrite at all.  It was rewritten from BLISS
> to C.  MACRO I can understand.  But as far as I know BLISS is still used
> internally by VMS, even on Itanium.  So why was MAIL rewritten in C?  

The feeling was that MAIL needed to be rewritten, because it was hard
to maintain.  Of course when something has to be rewritten for other
reason is about the only time it makes sense to change languages, even
if they had chosen a better language.

Quote:> And what lack of quality control caused documented features to break?

MAIL had a lot of "implicit features" not indicated in any documentation.
Without specific instructions to test for those features, they did not
turn out right.

Quote:> (In my particular case, I run MAIL/OLD since the new executable doesn't
> allow me to spawn out of EDT called from within MAIL, saying that the
> command tables have invalid format.)  And why has this not yet been
> fixed (as far as I know)?

So that was presumably an "implicit feature".

As an exercise, try to list _all_ features of MAIL.  Then go back
over old comp.os.vms to find all those that were missed in the rewrite.
Were they on the list you just made ?

Although I am a big advocate of strong typing, I believe that most of
the errors customers found in the new MAIL would not have been avoided
by using a better language than C.  Language quality might reduce the
time spent with the errors that were found in testing, but not those
that made it to customers.

======

I was involved in an effort once to rewrite a 10,000 line program
about as old as MAIL into another language (for functional reasons).
The most risky part was capturing the features of the old version.
The specification I wrote of the features of the old version and how
they had to be replicated in the new version was 400 pages long.

Writing a 400 page specification of a previous version is actually
a lot more tractable than the task of getting qualified people to
spend time reading the 400 page specification.  At least 20 people
had access to the specification.  Nine of those were even people
who had to sign on the dotted line regarding the correctness of
the specification.

There was a sentence in the middle of that specification offering
a 5 dollar reward to the first person to report the presence of that
sentence.  The one person who reported the presence of the sentence
did it a day before the one month deadline was up, and he claimed to
have accidentally stumbled across it rather than having thoroughly
read the specification.

 
 
 

VAX support

Post by Phillip Helbi » Tue, 01 Jul 2003 20:31:47


Quote:> > (In my particular case, I run MAIL/OLD since the new executable doesn't
> > allow me to spawn out of EDT called from within MAIL, saying that the
> > command tables have invalid format.)  And why has this not yet been
> > fixed (as far as I know)?

> So that was presumably an "implicit feature".

I remember needing this functionality then consulting the documentation
to figure out how to do it (XLATE etc).  So I don't see how it was
"implicit".

Quote:> Although I am a big advocate of strong typing, I believe that most of
> the errors customers found in the new MAIL would not have been avoided
> by using a better language than C.  Language quality might reduce the
> time spent with the errors that were found in testing, but not those
> that made it to customers.

But it wasn't written in Algol or Fortran I, it was written in BLISS.  
Has BLISS become hard to maintain within VMS engineering?  What is the
world coming to?  :-)

Quote:> There was a sentence in the middle of that specification offering
> a 5 dollar reward to the first person to report the presence of that
> sentence.  The one person who reported the presence of the sentence
> did it a day before the one month deadline was up, and he claimed to
> have accidentally stumbled across it rather than having thoroughly
> read the specification.

Right.  This is why Van Halen has a line in their contract saying that
they are to be provided with a bowl full of M&Ms, but with all the brown
ones removed.  They don't have some bizarre *, but rather this
serves to test whether the people responsible have read their contract
in full.  IIRC, they put this in after the stage was not up to spec,
resulting in some overloaded electrical circuits, things breaking under
weight etc.  The idea is that even in the backstage area of a rock band,
such a bowl of M&Ms with the brown ones removed is NOT something one
could expect to find by chance.
 
 
 

VAX support

Post by Larry Kilgall » Tue, 01 Jul 2003 20:56:01



Quote:>> Although I am a big advocate of strong typing, I believe that most of
>> the errors customers found in the new MAIL would not have been avoided
>> by using a better language than C.  Language quality might reduce the
>> time spent with the errors that were found in testing, but not those
>> that made it to customers.

> But it wasn't written in Algol or Fortran I, it was written in BLISS.  
> Has BLISS become hard to maintain within VMS engineering?

My point is not that Bliss code naturally is hard to maintain (although
that might have been the view of some of the DEC managers).  Rather this
code itself was hard to maintain, perhaps through lack of comments, or
just a design that made it hard to maintain.  Remember that Bliss MAIL
was written before maintainability issues were so well understood.
 
 
 

VAX support

Post by John Reaga » Wed, 02 Jul 2003 00:07:17



> My point is not that Bliss code naturally is hard to maintain (although
> that might have been the view of some of the DEC managers).  Rather this
> code itself was hard to maintain, perhaps through lack of comments, or
> just a design that made it hard to maintain.  Remember that Bliss MAIL
> was written before maintainability issues were so well understood.

Out of curiosity, I scanned over some of the BLISS code in the MAIL/OLD
images.  Personally, I don't think they are too bad at all.  They even
have comments!  I've seen much worse code.

I can't comment on the algorithm or design, but given that the new C
MAIL client still calls the same APIs in MAILSHR.EXE as the old BLISS
MAIL client, I'd say the overall design couldn't be that different.

--
John Reagan
Compaq Pascal/{A|I}MACRO Project Leader
Hewlett-Packard Company

 
 
 

VAX support

Post by Larry Kilgall » Wed, 02 Jul 2003 00:14:51




>> My point is not that Bliss code naturally is hard to maintain (although
>> that might have been the view of some of the DEC managers).  Rather this
>> code itself was hard to maintain, perhaps through lack of comments, or
>> just a design that made it hard to maintain.  Remember that Bliss MAIL
>> was written before maintainability issues were so well understood.

> Out of curiosity, I scanned over some of the BLISS code in the MAIL/OLD
> images.  Personally, I don't think they are too bad at all.  They even
> have comments!  I've seen much worse code.

> I can't comment on the algorithm or design, but given that the new C
> MAIL client still calls the same APIs in MAILSHR.EXE as the old BLISS
> MAIL client, I'd say the overall design couldn't be that different.

Perhaps they were unwilling to assign an experienced compiler developer
to maintaining Bliss MAIL :-)
 
 
 

1. VAX-11/750 and 780 support with OpenVMS VAX V7.0?


  This is probably a bunch of copy editing errors for the most part. I don't
run anything newer than V5.5-2H4 here, but I do know about some of these sys-
tems. The VAX-11/782 was desupported as of VMS V5.0 (it is an ASMP VAX that
can't be converted to SMP). The only way to run it on V5.x or later is to
[down-]convert it to a 780.

  If the 785 is supported, the 780 should also be supported - they are nearly
identical from an OS's point of view.

  The VAX 11/725 and 730 were desupported a while ago due to limits on the
size of their system disks. At the time the MicroVAX I was desupported, a
DEC developer said that DEC would not knowing break any of the per-CPU sup-
port code for desupported systems and that people (hobbyists?) who wanted
to continue to run them with later VMS versions should be able to do so -
DEC just didn't want to commit to testing on that platform and be forced to
support too-small system disks, etc.

        Terry Kennedy             Operations Manager, Academic Computing

        +1 201 915 9381 (voice)   +1 201 435-3662 (FAX)

2. Sniffer manual cnx

3. Compaq support for OpenVMS VAX licenses on the CHARON-VAX emulator

4. problems with german keyboard

5. Supporting tools that support porting to OpenVMS

6. Huge variety of Palmtops + Accessories

7. Announcement: Remote Per Event Support from Digital Customer Support Center

8. Excel link VBasic compilation error

9. VAX hardware support alternatives

10. Witch streamer supported vax-4000-90 ?

11. Official statement of support (VAX 7000, HSZ etc)

12. VAX 7000 hw support going away?

13. MIME support for OpenVMS VAX?