NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/os/vms/20732

Text File | 1993-01-11 | 3.7 KB | 81 lines

Newsgroups: comp.os.vms
Path: sparky!uunet!gatech!darwin.sura.net!paladin.american.edu!howland.reston.ans.net!usc!cs.utexas.edu!csc.ti.com!tilde.csc.ti.com!mksol!usenet
From: [e-mail] (Dillon Pyron)
Subject: Re: Running old executables on later VMS versions
Message-ID: <[e-mail]>
Lines: 67
Sender: [e-mail] (Usenet News)
Nntp-Posting-Host: skndiv.dseg.ti.com
Reply-To: [e-mail]
Organization: TI/DSEG VAX Support
References:  <[e-mail]>
Date: Mon, 11 Jan 1993 16:03:28 GMT


In article <[e-mail]>, [e-mail] (Joe Meadows) writes:
>>This seems to be one of those persistent myths about VMS.
>>
>>I don't know who "strongly suggests" this.  Most applications do NOT need to
>>be recompiled and relinked for VMS upgrades.
>
>Actually, I recall statements such as this being made in the release notes for
>at least one version of VMS, if not several.

I have a small demo program that I wrote in FORTRAN and last compiled and
linked under 2.2.  It still runs, although it does no useful function, I like
to keep it around to show the youngsters.

>
>The first time was when they broke up VMSRTL into several images (forgive a
>possibly fading memory, it was one of the run-time libraries however, if not
>VMSRTL) and they suggested that you relink to improve image activation time.

It does run like a dead dog.  But it did that from the beginning.  It's just
that, at that time, it looked speedy.

>
>The most recent time was when they introduced the "modular executive". Of
>course, the idea with introducing the modular executive was to further reduce
>the amount of relinking required (for images linking against the executive
>that is).
>
>Other times have generally been for specific reasons, such as the TPU case
>cited earlier. In fact, the callable tpu fiasco was the first time I ever had
>non-internals code break from an upgrade (call me lucky [or carefull]).
>
>I'd say VMS has done a very good job of maintaining compatability, and as
>Jamie points out, there were & are several very old pieces of VMS code sitting
>around that still work just fine.
>
>While there have been things that they have obsoleted, generally that just
>means they stop documenting a routine or interface (or at least move it to the
>obsolete features manual). Off the top of my head I can't even think of one
>that has actually been removed. Of course, not actually killing these things
>has been what allows old code to run so well, but on the flip-side it's also a
>fair bit of extra baggage to be carrying around!

This code has several SS calls that are now "obsolete", but still work due to
revectoring and the like.

>
>Anyone care to dredge up some old memories? It's gotta be a lot funner than
>the flame-fest we've been having lately (not to they they haven't been
>somewhat humorous, but even [name-your-comedian-here] gets boring after a
>while).

I did have one guy complain when we went to 4.0 (so did a lot of people :-).
His code not only crashed, it took the machine with it.  He swore up and down
that it had to be the machine, that VMS didn't require any type of
recompile/relink.  Welllll, the short story is that playing with priviledged
data structures is one of the few times when you MUST relink.

I have a tape with 2.2 on it, if anyone has DSC and a Massbus 11/780  :-0
--
Dillon Pyron                      | The opinions expressed are those of the
TI/DSEG Lewisville VAX Support    | sender unless otherwise stated.
[phone] (when I'm here)     |
[phone] (when I'm home)     |"Pacts with the devil are not legally
[e-mail]          |binding!"
PADI DM-54909                     |-Friar Tuck   _Robin Hood:The Hooded Man_