From: lionel@quark.enet.dec.com (Steve Lionel)
Subject: Re: COBRTL
Reply-To: lionel@quark.enet.dec.com (Steve Lionel)
Organization: Digital Equipment Corporation, Nashua NH
Date: Thu, 16 Apr 92 18:45:51 GMT


In article <1992Apr16.093602.1865@admin1.memst.edu>, flowers@admin1.memst.edu (Harry Flowers) writes:
|>
|>The problem is documented in a DSIN/DSNlink article "Problems With COBRTL
|>And VAX COBOL V4.4 After Upgrade To VMS V5.5".  Briefly, here's the problem:
|>
|>What ships with COBOL V4.4:   image file identification: "V05-013"
|>
|>What ships with CSCPAT_0312:  image file identification: "V05-015"
|>
|>What ships with VMS V5.5:     image file identification: "V05-014"
|>    
|>Basically, you have to re-apply the patch after the upgrade to keep from
|>loosing the bug fixes (which were crucial in this case).  Also note that
|>COBOL will fail to install correctly after the upgrade because of image
|>header changes.  I guess that problem will be fixed in a later version
|>of COBOL :-(.

Ok, now I understand.  What this means is that the COBRTL developers didn't
submit their fix for VMS V5.5, or it was submitted too late.  Unfortunately,
the schedule of V5.5 meant that bug fixes, unless they were considered
"show-stoppers", had to be in by last March!  I just checked the list of
fixes intended for the next VMS maintenance update (it may be the second
you receive), and I see nine COBRTL fixes included, so I think it's safe
to say that things will get back in synch fairly soon.

This particular VMS release was a real problem, in that there were three
(or maybe four) "major" release streams which got set up and cancelled over
the past two years.  This meant that a lot of things which should have been
in your hands a long time ago didn't make it, even into V5.5.  But from what
I can see, the "buses" are rolling again and the long delay we've had shouldn't
recur.  I can tell you that it's frustrating for us as well.

|>
|>Hmmm... I seem to remember that DEC gave permission to distribute the VAXCRTL
|>prior to VMS 4.2 because it wasn't included in the distribution.  I had heard
|>that, on earlier versions, some operating system utility had to be written in
|>that language to ship the RTL with VMS; the software engineers managed to use
|>most all the languages, forcing the ship.  I guess this was just folklore.

VAX C was a special case - for a while, the VAX C RTL was actually licensed
separately, even though this was not done for any of the other products.
Eventually it was merged into VMS where it resides today.  Yes, for a while,
customers were given permission to copy the RTL where needed, and this
happens today for other RTL images for which newer versions are on the
language kit while waiting for the next VMS "bus".

As for the story about some piece of VMS having to be written in each of
the languages, this is indeed just folklore.  It's true that VMS components
are or have been written in a number of languages (Fortran, Pascal, even 
PL/I!), but certainly not all of the two-dozen-odd languages have been
represented.  (I have yet to see any VMS component written in RPG, for
example!)

|>
|>What other languages currently include the RTL in the compiler kit?  I was
|>under the impression that this was a no-no, for the obvious reasons.  It
|>seems fairly obvious that, if there's a problem with the RTL routine and
|>you can't update the RTL, you wouldn't call the routine in the RTL, but
|>put the correct code in the program image until the RTL could be updated.
|>I assume that this is what the other compiler teams are doing.  Am I
|>missing something?

The only one I'm aware of is Ada, and that's again to provide new feature
support.  Once VMS catches up, it will be removed from the kit.  No, we don't
"put the correct code in the program image", especially for features which
interact with other parts of the RTL.  But I'll give you an example of what
we sometimes can do.  In recent versions of VAX FORTRAN-HPO, the kit adds
to STARLET.OLB some modules which provide support for a new feature.  VMS
won't have this code until the next major release after V5.5, but as it didn't
interact with the other FORRTL code I could design it such that it didn't
require replacing FORRTL.  Luckily, VMS releases merge STARLET.OLB changes,
so it won't replace the new Fortran stuff.

In another message, Jim Walker suggests that the VMS upgrades check the
idents of the RTL images and not overwrite them if they're newer.  This is
a good idea, and I'll pass it on to the VMS folks.  One problem is that
there isn't currently a good way to tell what's "newer" in a consistent
and automatic fashion, but we can work on that.  Jim also suggests
documenting which images are replaced in an upgrade - well, that's all of
them, really.  Language developers sometimes will put into the release notes
for a VMS version a warning about potential interaction with newer RTL 
images, but this doesn't always happen.

I couldn't agree more that this is a big headache for users (as well as
for language developers), and I'll propose some changes to help to VMS
management.

A suggestion - for those of you who belong to DECUS (or if you don't belong,
join!) - bring this problem up with the VAX and L&T SIG leadership.  Submit
an SIR (Software Improvement Request) on it; these (especially the top
vote-getters) get wide visibility inside VMS development, and a majority of
the top SIR items do get implemented.  In the past there have been few
requests pertaining to the interactions of VMS and language products. 
If you'll be at the symposium in Atlanta, bring it up there.  (And stop
by the L&T campground, look me up and say hello.)
--

Steve Lionel                    lionel@quark.enet.dec.com
Languages Group
Digital Equipment Corporation
110 Spit Brook Road
Nashua, NH 03062
Newsgroups: comp.os.vms