OpenVMS history
Ruslan R. Laishev
Hi !
I heard many time about Dave Cutler and his role in VAX/VMS, I search at
Digital WEB site any reference to "Dave and Cutler" but 2 reference ONLY
found.
So, point me, please, to any information about "Dave Cutler and his work
in VAX/VMS project".
--
---
@RRL, Best regards.
---------------------------------------------------------------------
CB "Petrovskiy", EDP Departement, |198013, Russia,St.Petersburg,
Chief Consultant | Ruzovskaya 8 St.
I-net:lai...@host1.petrobank.spb.su | Phone:(812) 316-6265
Fido :2:5030/279 | Fax: (812) 316-5765
---------------------------------------------------------------------
Alan Frisbie
In article <3392D957...@star.zko.dec.youknowwhere>,
Andy Goldstein <Gold...@star.zko.dec.youknowwhere> writes:
> Unfortunately little has been written down regarding the history of VMS,
> and even less has been published. However, the VMS 20th anniversary is
> drawing near, and work is underway to put together as much historical
> material we can gather for the celebration. Watch
> www.openvms.digital.com late this summer for developments.
I have a copy of the Starlet Working Design Document
(August 1977, Revision 2). Since Revision 1 was dated
October 1976, and Revision 0 was dated May 1976, it looks
like the 20th anniversary has already passed, in one respect.
> Meanwhile, keep those Robotron 8000's running!
I have a copy of the brochure for the Robotron RVS K 1840
and 1845 (VAX 780 and 785 clones), but am not familiar with
the 8000. Which machine is that a clone of?
--
-- "From:" line deliberatly munged to prevent harvesting by spambots.
-- Alan E. Frisbie Frisbie "@" Flying-Disk.Com
-- Flying Disk Systems, Inc. (Remove quotes before replying)
Tim Shoppa
In article <01bc6f3f$4dbdabf0$040110ac@naked>,
Ruslan R. Laishev <lai...@host1.petrobank.spb.su> wrote:
> I heard many time about Dave Cutler and his role in VAX/VMS, I search at
>Digital WEB site any reference to "Dave and Cutler" but 2 reference ONLY
>found.
> So, point me, please, to any information about "Dave Cutler and his work
>in VAX/VMS project".
IMHO, the best information would come from the comments in the original
source for VMS V1, V2, or V3. There are probably still some of his
comments in the V7.x sources, though I haven't actually seen the fiche
to confirm this. Even in the latest RSX-11M+ sources there are still
comments by Cutler in the executive.
Tim. (sho...@triumf.ca)
Matthias Maisenbacher
>I have a copy of the Starlet Working Design Document
Is that the reason why you can still find some
starlet.* in SYS$LIBRARY ?
Matthias
Andy Goldstein
Matthias Maisenbacher wrote:
>
> >I have a copy of the Starlet Working Design Document
> >---------------------^^^^^^^------------------------
> Is that the reason why you can still find some
> starlet.* in SYS$LIBRARY ?
Yes. STARLET was the project code name for the operating system. The
name VAX/VMS wasn't chosen until a few weeks before the announcement and
no one felt like expending the energy to change the names of the
libraries, not to mention the disruption it would have caused then.
STARLET was derivative of the name of the code name of the 780, STAR.
VAX, BTW, was the original code name of the architecture project. (It
stood for Virtual Address eXtension.) By announcement time, so much news
about the project had leaked that people decided keeping the code name
VAX was worth it just to take advantage of all the free publicity.
(Besides being a reasonably catchy product name.)
Andy Goldstein
Steve Lionel wrote:
>
> Dave Cutler was the "project leader" for VAX/VMS V1.0, meaning that his
> role was to make sure the project was completed on time. He was one of many
> design and code contributors, though most of his code is no longer around.
> He did a lot of work on DCL and on exception processing. Cutler left the
> VMS project in 1980.
Steve, I beg to differ. Dave also wrote the entire kernel I/O system and
a number of the device drivers. Most of Dave's code, including much of
DCL, is still recognizably present. You may have been thinking of
another engineer, who I will not name, whose code was ruthlessly
expunged from the system over the next couple of releases because much
of it was pretty bad.
You're right that Dave went on to other things after VMS V1 was shipped.
Andy Goldstein
Alan Frisbie wrote:
> I have a copy of the Starlet Working Design Document
> (August 1977, Revision 2). Since Revision 1 was dated
> October 1976, and Revision 0 was dated May 1976, it looks
> like the 20th anniversary has already passed, in one respect.
>
Obviously it depends on when you start counting. The big celebration
that's coming up this fall will be of the announcement, which occurred
in October, 1977.
> I have a copy of the brochure for the Robotron RVS K 1840
> and 1845 (VAX 780 and 785 clones), but am not familiar with
> the 8000. Which machine is that a clone of?
Sorry, you probably have the numbers right; I was just guessing from
faulty memory.
Dan Oreilly
At 02:34 PM 6/3/97 -0400, Andy Goldstein
<Gold...@star.zko.dec.youknowwhere> wrote:
>Matthias Maisenbacher wrote:
>>
>> >I have a copy of the Starlet Working Design Document
The 11/780 was originally going to be the PDP 11/700. If you look
at the PDP 11/70 and VAX 11/780 architecture (bus structure, etc),
you'll see some similarities there, particularly in the MASSBUS and
UNIBUS architectures, plus the way the 11/70 cached and used data.
It was KO's idea (and I think Gordon Bell had something to do with
it as well) to name it the VAX 11/780. KO wanted a totally new,
totally integrated architecture, and needed to differentiate it from
the PDP-11. Of course, at the time, the DECsystem 20 was still far
faster than the VAX, and I remember when the follow-on processors
to the KL10 were killed for political reasons (they would run faster
than any VAX on the drawing board!).
--
Dan O'Reilly
MCI Telcommunications
Systems Engineering/BT NIP
MS 1183/117
2424 Garden of the Gods Rd
Colorado Springs, CO 80919
719-535-1418
Andy Goldstein
Dan Oreilly wrote:
>
> The 11/780 was originally going to be the PDP 11/700. If you look
> at the PDP 11/70 and VAX 11/780 architecture (bus structure, etc),
> you'll see some similarities there, particularly in the MASSBUS and
> UNIBUS architectures, plus the way the 11/70 cached and used data.
The 11/780 was developed by the "medium/large PDP-11 engineering group,
so the family resemblance should not be surprising. The original
motivation for the product was as a follow-on to the PDP-11, which had
outgrown its 16-bit address space. You can see elements of the PDP-11
ancestry all over, from peripherals, bus organization, to the complete
emulation of the PDP-11 instruction set, to much of the architecture of
the VMS operating system.
> It was KO's idea (and I think Gordon Bell had something to do with
> it as well) to name it the VAX 11/780. KO wanted a totally new,
> totally integrated architecture, and needed to differentiate it from
> the PDP-11.
There was a general engineering consensus that modest extensions of the
PDP-11 would not cut it, and that a whole new architecture was needed.
As I said, VAX was the original project code name. The decision to use
it as the product name was made late in the game, and probably by Ken
and Gordon.
> Of course, at the time, the DECsystem 20 was still far
> faster than the VAX, and I remember when the follow-on processors
> to the KL10 were killed for political reasons (they would run faster
> than any VAX on the drawing board!).
Initially, the product direction of the VAX was clearly aimed to not
overlap with the DEC-20, leaving the latter as the company's high end
system. This is supported by the fact that the first two 780 follow-ons,
the 750 and 730, were slower, smaller, and cheaper than the 780.
After a few years, however, there was growing customer demand for bigger
and faster VAXes. The response was the 8600, built by the DEC-20
engineering group that was also building the next DEC-20 machine (code
named Jupiter). It's my understanding that the two machines were
expected to be comparable in performance. Jupiter was cancelled because
the engineering organization did not have the resources to build both
machines concurrently. Whether the right machine was cancelled is a
financial and marketing question that I do not have the data to
second-guess. Whether you consider this to be a political decision is a
matter of perspective.
Jan Vorbrueggen
Andy Goldstein <Gold...@star.zko.dec.youknowwhere> writes:
> Steve, I beg to differ. Dave also wrote the entire kernel I/O system and
> a number of the device drivers. Most of Dave's code, including much of
> DCL, is still recognizably present. You may have been thinking of
> another engineer, who I will not name, whose code was ruthlessly
> expunged from the system over the next couple of releases because much
> of it was pretty bad.
What part of VMS did that belong to? Apparently not the memory management
code...some of tightest, most evil kind of code I've seen, co-routines and
all...almost incomprehensible and very few comments...(that's not _your_ code,
Andy, is it??)...is that still in the VAX code base? If so, I'll be the
PFN-mapped page table bug I found ten years ago is still there...it was really
fun finding and understanding that one! (immediate crash on demand)
Jan
Robert Koehler
Dan Oreilly (Dan.O...@MCI.Com) wrote:
: It was KO's idea (and I think Gordon Bell had something to do with
: it as well) to name it the VAX 11/780. KO wanted a totally new,
: totally integrated architecture, and needed to differentiate it from
: the PDP-11. Of course, at the time, the DECsystem 20 was still far
: faster than the VAX, and I remember when the follow-on processors
: to the KL10 were killed for political reasons (they would run faster
: than any VAX on the drawing board!).
KL10 based systems were also a lot harder to program, and therefor more
costly to construct, modify, and maintain in a day where the cost and
importance of the software were begining to overtake that of the hardware.
Many hardware engineers will tell you that DEC had nothing special in the
VAX. It was VMS (and PDP-11/RSX-11 compatability) that sold the system.
It's not suprizing that DEC decided to put their money where they could
get the most bang for the buck.
In TOPS-20 one could not readily access the JSYS routines (roughly equivalent
to VMS System Services) from a high level language. Programming in MACRO-10
on my DECSYSTEM 20 (everything was all caps in those days) is what drove me to
learn BLISS (there was a free BLISS-10 compiler on the unsupported software
tape).
If I recall, MODCOMP was one of the competitors who looked at the VAX, saw
hardware they could easily keep up with and tried to sell competing systems
without comparable software. Where are they today?
------------------------------------------------------------------------------
Bob Koehler | Computer Sciences Corporation
| System Sciences Division
christopher f. chiesa
In article <33942EBE...@star.zko.dec.youknowwhere>,
Andy Goldstein <Gold...@star.zko.dec.youknowwhere> wrote:
>Alan Frisbie wrote:
>
>> I have a copy of the Starlet Working Design Document
>> October 1976, and Revision 0 was dated May 1976, it looks
>> like the 20th anniversary has already passed, in one respect.
>>
>Obviously it depends on when you start counting. The big celebration
>that's coming up this fall will be of the announcement, which occurred
>in October, 1977.
Wow... just a month after I started high school! :-)
So... do YOU feel really OLD now? I'm starting to...
Chris
lvt...@servtech.com
timl@bbcit3
In article <5n44rn$3...@cyber1.servtech.com>, lvt...@cyber1.servtech.com (christopher f. chiesa) writes:
|> In article <33942EBE...@star.zko.dec.youknowwhere>,
[snip]
|> >Obviously it depends on when you start counting. The big celebration
|> >that's coming up this fall will be of the announcement, which occurred
|> >in October, 1977.
|> ^^^^^^^^^^^^^
|>
|> Wow... just a month after I started high school! :-)
|>
|> So... do YOU feel really OLD now? I'm starting to...
|>
Nah, its the people trying to run production systems on NT who are feeling
old :-) :-) :-)
|> Chris
|> lvt...@servtech.com
|>
--
Tim Llewellyn, OpenVMS System Manager, Remarcs Project
BBC, Whiteladies Road, Bristol, UK. Email tim.ll...@bbc.co.uk.
Sorry, my web server is down due to circumstances beyond my control
Read at your own risk, standard disclaimer applies.
Andy Goldstein
Jan Vorbrueggen wrote:
>
> > You may have been thinking of
> > another engineer, who I will not name, whose code was ruthlessly
> > expunged from the system over the next couple of releases because much
> > of it was pretty bad.
>
> What part of VMS did that belong to? Apparently not the memory management
> code...some of tightest, most evil kind of code I've seen, co-routines and
> all...almost incomprehensible and very few comments...(that's not _your_ code,
> Andy, is it??)...is that still in the VAX code base? If so, I'll be the
> PFN-mapped page table bug I found ten years ago is still there...it was really
> fun finding and understanding that one! (immediate crash on demand)
Loginout, the old job controller (both of which have been rewritten
several times) and parts of DCL come to mind. There may have been more.
The memory management code was written by Peter Lipman. Peter was well
aware of how performance-critical the page fault code would be, so it's
devilishly tight. It's still there on the VAX. One of the reasons it's
held up so well is very few people had the courage to go near it. Peter
had this delightful tendency to just leave values in registers for
pages, and then suddenly use them when you'd completely lost track of
the origin. (MOVL R6,@PFN$L_FOOBAR(R4)... hmmm... now where the hell did
R6 come from???)
If you reported the PFN map bug to us it oughta be fixed. If you give me
some idea of what it was about I can check.
Jim Mehlhop
Andy Goldstein wrote:
>
> Jan Vorbrueggen wrote:
> >
> > > You may have been thinking of
> > > another engineer, who I will not name, whose code was ruthlessly
> > > expunged from the system over the next couple of releases because much
> > > of it was pretty bad.
> >
> > What part of VMS did that belong to? Apparently not the memory management
> > code...some of tightest, most evil kind of code I've seen, co-routines and
> > all...almost incomprehensible and very few comments...(that's not _your_ code,
> > Andy, is it??)...is that still in the VAX code base? If so, I'll be the
> > PFN-mapped page table bug I found ten years ago is still there...it was really
> > fun finding and understanding that one! (immediate crash on demand)
> The memory management code was written by Peter Lipman. Peter was well
> aware of how performance-critical the page fault code would be, so it's
> devilishly tight. It's still there on the VAX. One of the reasons it's
> held up so well is very few people had the courage to go near it. Peter
> had this delightful tendency to just leave values in registers for
> pages, and then suddenly use them when you'd completely lost track of
> the origin. (MOVL R6,@PFN$L_FOOBAR(R4)... hmmm... now where the hell did
> R6 come from???)
Lots of JSB's vs CALLS's (also good for preformance but harder to
maintain), but he was very good about documenting stack and register
contents at the beginning of routines.
_________________________________________________________________________
Jim Mehlhop, Support Engineer || ||
Cisco Systems || ||
JMeh...@cisco.com |||| ||||
Phone 719-638-8448 |||||||| ||||||||
Alpha Pager jmeh...@airnote.net
..:|||||||||||||||||||||:..
Pager 800-796-7363 pin 101-0442 C i s c o S y s t e m s
_________________________________________________________________________
Jan Vorbrueggen
Andy Goldstein <Gold...@star.zko.dec.youknowwhere> writes:
> The memory management code was written by Peter Lipman. Peter was well
> aware of how performance-critical the page fault code would be, so it's
> devilishly tight. It's still there on the VAX. One of the reasons it's
> held up so well is very few people had the courage to go near it.
Yeah, that's exactly the impression I got. Did he alos write the parts of the
linker that finally got revamped (more like rewritten, I'd guess) for the
Alpha port?
> If you reported the PFN map bug to us it oughta be fixed. If you give me
> some idea of what it was about I can check.
It definitely was reported, but I actually doubt it was fixed, because it only
showed up in arcane circumstances whose likelihood was rapidly dropping at the
time. To boot: If you PFN map a section, the MMG code forgot to increment the
reference counter on the page table. The machine this happened on was very
tight for memory, and the process was subjected to a dead page table scan,
which of course decided to remove that page table from the working set. Then,
that interface device to the physics experiment the thing was driving came
alive (I think they were using the CONNINT driver), the programm wanted to
look at the PFN mapped page...and the page fault code looked at the page
tables and PFN database and didn't much like what it saw. (If you're looking
for an old SPR: Physics Institute, University of Bonn.)
That was _fun_.
Jan
Peter Quodling
timl@bbcit3 wrote:
>
> In article <5n44rn$3...@cyber1.servtech.com>, lvt...@cyber1.servtech.com (christopher f. chiesa) writes:
> |> In article <33942EBE...@star.zko.dec.youknowwhere>,
>
> |> >that's coming up this fall will be of the announcement, which occurred
> |> >in October, 1977.
> |> ^^^^^^^^^^^^^
Hey pups, we used to have computers that used punched cards for input.
Or as Mr. Goldstein will recall the way of improving the reading of a
Dectape on a TU56 by holding your finger on the read head. Andy, also
still has the distinct appearance of being involved in the 1970's :-)
> |> Wow... just a month after I started high school! :-)
> |>
> |> So... do YOU feel really OLD now? I'm starting to...
> Nah, its the people trying to run production systems on NT who are feeling
> old :-) :-) :-)
No, they would be feeling tired, and scared, very scared....
Peter Q - Alpha Wrangler Extraordinaire.
Alan Greig
Robert Koehler wrote:
> In TOPS-20 one could not readily access the JSYS routines (roughly equivalent
> to VMS System Services) from a high level language. Programming in MACRO-10
> on my DECSYSTEM 20 (everything was all caps in those days) is what drove me
Chuck Hedrick's SPascal (System Programmer's Pascal) provided
easy access to the TOPS-20 JSYS calls and I can recall seeing
(and indeed writing) quite a number of system utilities with
this compiler. Simula and BCPL also provided good access to the
underlying operating system. SPascal in particular also provided
a simple to use interface to the CMND% JSYS (command parser with
command recognition, completion, inline help, filename completion
and parsing, switches etc).
None of these languages shipped with the base operating system but
SPascal and BCPL were public domain and Simula was relatively low
cost with older versions PD and on DECUS tapes.
--
Alan Greig Tel: (01382) 308802
University of Abertay Dundee Email: A.G...@tay.ac.uk
** Never underestimate the power of human stupidity **
Warren Sander
In the next few weeks and for the next 6 months there will be increasing
'historical' information about VAX and VMS put up on the web site. This is all
in planning for the 20th anniversary of the VAX announcement and the
mini-computer revolution.
Watch www.openvms.digital.com.. In fact if you go to
www.openvms.digital.com/openvms/vax-survey.html you can fill out a copy of
a survey looking for historical and anecdotal information on vax and vms
(this is the same survey that was available at the campground at DECUS)
--
------------------------------------------------------------------
Warren Sander OpenVMS Marketing
Digital Equipment Corporation Work: san...@mail.dec.com
129 Parker Street PK03-2/T20 Personal: san...@ultranet.com
Maynard, MA 01754 (508) 493-5470/0084 voice/fax
My opinions are my own and I only speak for myself
Read http://www.openvms.digital.com/
------------------------------------------------------------------
Frank da Cruz
In article <339696AE...@tay.ac.uk>, Alan Greig <A.G...@tay.ac.uk> wrote:
: Chuck Hedrick's SPascal (System Programmer's Pascal) provided
: easy access to the TOPS-20 JSYS calls and I can recall seeing
: (and indeed writing) quite a number of system utilities with
: this compiler. Simula and BCPL also provided good access to the
: underlying operating system. SPascal in particular also provided
: a simple to use interface to the CMND% JSYS (command parser with
: command recognition, completion, inline help, filename completion
: and parsing, switches etc).
And also SAIL, which also had a COMND JSYS package (which we developed
here and distributed).
But eventually we gave up on high-level languages and used assembler for
everything, because it was so easy to use and so powerful, and, well,
fun. But obviously nothing of lasting value can be coded in assembler.
While the lack of a serious, supported high-level implementation language
might not have been the downfall of the DEC-20, it contributed (*). In any
case, even if the cost-of-ownership and similar problems had been solved,
its emphasis on 7-bit bytes for text would have proven a major obstacle
in the following years, when it became important to support Latin-1 and
other 8-bit character sets (as well as multibyte character sets for
Japanese, etc). Yes, the 36-bit line had variable byte sizes, but far too
much software was hardwired to 7 bits (and this was encouraged by the
instruction set too, e.g. the ubiquitous HRROI A, [ASCIZ /blah/]).
Nevertheless, it was an operating system that had features 20 years ago
that most of us wish that designers of modern desktop operating systems
had a clue about...
- Frank
(*) OK, there was Bliss-36, but who could afford it?
Andy Goldstein
Jan Vorbrueggen wrote:
>
> Yeah, that's exactly the impression I got. Did he also write the parts of the
> linker that finally got revamped (more like rewritten, I'd guess) for the
> Alpha port?
>
> It definitely was reported, but I actually doubt it was fixed, because it only
> showed up in arcane circumstances whose likelihood was rapidly dropping at the
> time. To boot: If you PFN map a section, the MMG code forgot to increment the
> reference counter on the page table. The machine this happened on was very
> tight for memory, and the process was subjected to a dead page table scan,
> which of course decided to remove that page table from the working set. Then,
> that interface device to the physics experiment the thing was driving came
> alive (I think they were using the CONNINT driver), the programm wanted to
> look at the PFN mapped page...and the page fault code looked at the page
> tables and PFN database and didn't much like what it saw. (If you're looking
> for an old SPR: Physics Institute, University of Bonn.)
>
All "unprivileged user can crash the system" bugs are considered
showstoppers and get fixed immediately. Incurring this bug required
PFNMAP privilege; however, any crash that results from legitimate
application behavior gets fixed just as promptly.
This was fixed in or before V4.0. Module SYSCREDEL contains the routine
MMG$CREPAG, which actually sets up the PTE for each page mapped. I see
the following revision history entry in SYSCREDEL:
; V03-002 KDM46395 Kathleen D. Morse 25-Jun-1982
; Place the WSLEs for page table pages that contain
; PFNMAP and MA780 global pages, into the locked portion
; of the working set.
In the routine, there is the following code segment:
85$: MOVL R8,@(R3)[R1] ;STORE NEW PTE
BBC #PTE$V_VALID,R8,87$ ;BR IF NOT WINDOW/MA780 GLOBAL
PAGE
BBS #PTE$V_WINDOW,R8,86$ ;BR IF IT IS A WINDOW PAGE
EXTZV #PTE$V_PFN,#PTE$S_PFN,R8,-(SP) ;EXTRACT PFN
CMPL (SP)+,G^MMG$GL_MAXMEM ;IS THIS A MA780 GLOBAL PAGE?
BLEQ 87$ ;BR IF NOT MA780 GLOBAL PAGE
86$: MOVAL @(R3)+[R1],R3 ;GET SVAPTE
MOVL #1,R0 ;INDICATE ADDITIONAL LOCK
DSBINT #IPL$_SYNCH ;RAISE TO SYNCH
JSB G^MMG$MOVPTLOCK ;LOCK THE PAGE TABLE PAGE IN WS
ENBINT ;RESTORE IPL
87$: ;
MOVZWL #SS$_NORMAL,R0 ;INDICATE SUCCESSFUL COMPLETION
The code between 85$ and 87$ is not present in the V3.0 version of the
module (which is the release in which we introduced PFN mapped
sections). The date of the edit is very soon after we shipped V3.0, so I
strongly suspect that this fix was shipped in an early V3.x update.
Norm Lastovica
I recall plowing through the sources at one point in time
(seems like it was either loginout or the image activator)
and ran into a comment (andy goldstein's?) reading something
along the lines of:
! The following is a flagrant violation of the
! vax/vms calling standard. Such is life.
I believe that the code was busy dummying up a call frame to
REI back to. Anyone with a source license wanna double-check
my memory?
Peter Quodling
One piece of Mythology about David N. Cutler that I heard (from one of
the RSX devos as I recall, was a piece of Macro Code that he had written
in the bowels of RSX. A customer had a source license, and could not for
the life of them, fathom a piece of his code. They finally surmised
that his initials DNC, sprinkled through the code, stood for "Did not
code" meaning noone would admit ownership of the clever but obtuse code.
The other story is that he was responsible for Terminal Drivers, and
having never gotten quite perfected them, gave up and did a Window-ed
Environment instead... :-)
Q
Glenn C. Everhart
Didn't SAIL (available on large systems sig tapes) allow access to
system calls?
Andy Goldstein
It's in the PROTCLI module in LOGINOUT. The actual text reads
"Modification of a call frame is a flagrant violation of the VAX-11
Calling Standard. Such is life."
The module has Len Kawell's name on it, part of the first rewrite of
LOGINOUT in 1980. What the routine was doing was implementing the effect
of a $CMSUPR service, which doesn't exist. The code in LOGINOUT that
used it called it with a $CMEXEC. The routine then peeled back the call
frames, built a PC/PSL pair for supervisor mode, and entered it by doing
an REI through the PC/PSL pair just built. It then called the routine
originally specified by the caller.
This routine was used to map and protect the CLI so that the CLI pages
would be owned by and accessible to supervisor mode. Calling this a
flagrant violation of the calling standard may be a bit of
grandstanding. Certainly the code has carnal knowledge of call frames,
but other places in VMS do this as well.
Jim Mehlhop
Norm Lastovica wrote:
>
> I recall plowing through the sources at one point in time
> (seems like it was either loginout or the image activator)
> and ran into a comment (andy goldstein's?) reading something
> along the lines of:
>
> ! The following is a flagrant violation of the
> ! vax/vms calling standard. Such is life.
>
> I believe that the code was busy dummying up a call frame to
> REI back to. Anyone with a source license wanna double-check
> my memory?
PROTCLI.LIS Part of the login stuff in routine LGI$CMSUPR wipes out the
call frame(from EXE$CMKRNL(my favorite system service)) by modifiying
the saved AP and Return pc and then RET'ing. It also moves an entire
call frame (generated by the system service dispatcher) and the
exception PC/PSL, from the change mode kernel INSTRUCTION, from exec
stack to super.
--
Malcolm Dunnett
In article <33986974...@star.zko.dec.youknowwhere>,
>
> This routine was used to map and protect the CLI so that the CLI pages
> would be owned by and accessible to supervisor mode. Calling this a
> flagrant violation of the calling standard may be a bit of
> grandstanding. Certainly the code has carnal knowledge of call frames,
> but other places in VMS do this as well.
Reminds me of a routine I wrote many years ago to allow "computed GOTOs"
and "computed GOSUBS" in VAX BASIC. It took an integer argument containing
the line number you wanted to GOTO or GOSUB, figured out the PC of that
line number (from the traceback data) and munged the return PC of the
call frame.
I never actually had the nerve to use it in a production program, but
it was kind of fun to write.
--
=============================================================================
Malcolm Dunnett Malaspina University-College Email: dun...@mala.bc.ca
Computer Services Nanaimo, B.C. CANADA V9R 5S5 Tel: (250)755-8738
Alan Frisbie
In article <5mul32$9u4$1...@nntp.ucs.ubc.ca>,
sho...@alph02.triumf.ca (Tim Shoppa) writes:
> IMHO, the best information would come from the comments in the original
> source for VMS V1, V2, or V3. There are probably still some of his
> comments in the V7.x sources, though I haven't actually seen the fiche
> to confirm this. Even in the latest RSX-11M+ sources there are still
> comments by Cutler in the executive.
In the RSX-11M v2.0 (yes, you read that right) kit, there was a
separate file detailing the updates. *Many* of them were done
by Dave Cutler on holidays. I guess that is when he could ignore
the DEC office distractions and get some real work done.
Later releases did not include this file.
--
-- "From:" line deliberatly munged to prevent harvesting by spambots.
-- Alan E. Frisbie Frisbie "@" Flying-Disk.Com
-- Flying Disk Systems, Inc. (Remove quotes before replying)
Charles Hall
Yes, Digital seems to have blurred some of their history, which is a
shame. I had occassion to use PDP-8s and PDP-11s and thought they were
marvelous. I thought Digital did a great job in helping move from those
machines to the DECSYSTEMS and then later to the VAXes and now the
ALPHAs. By simplifying their history, DEC is also forgetting some of
the things which endeared them to their users.
Tony Scandora 630-252-7541
In article <5n91rg$6sq$2...@mrnews.mro.dec.com>, ever...@arisia.gce.com (Glenn C. Everhart) writes:
>
>Didn't SAIL (available on large systems sig tapes) allow access to
>system calls?
It used or at least came with its own assembler, FAIL, and if my memory serves
me correctly, SAIL allowed inline escapes to FAIL, from which you could do
anything.
Tony Scandora, Argonne National Lab, 630-252-7541
scan...@cmt.anl.gov
Larry Schuldt
On 5 Jun 1997 16:52:49 GMT, san...@rm222.enet.dec.com (Warren Sander)
wrote:
>
>In the next few weeks and for the next 6 months there will be increasing
>'historical' information about VAX and VMS put up on the web site. This is all
>in planning for the 20th anniversary of the VAX announcement and the
>mini-computer revolution.
>
I thought the PDP-8 started the mini-computer revolution... first
computer under $100k and all that. Anyway, I remember the signs
outside Maynard advertising the "Minicomputer capital of the world"
were there years before the VAX.
It's funny how DEC re-writes history. The ads for the VAX 9000 used to
claim that it was DEC's first mainframe class computer as if the
36-bit line never existed. Also they claimed (I think it was) the
ESE20 as their first solid state disk drive. Anyone remember the ML11?
Yeah, you could improve reads from the tu56 by putting a finger on the
tape, but removing the tape guides and cleaning out all the
accumulated oxides was a better fix. btw, the TU55 was a MUCH more
reliable drive.
larry ... who used to fix PDP8, RF08/DF32, DECtape and lots of fun
stuff like that. and who hated working on Teletypes.
--
Larry Schuldt
Chicago Title & Trust
Joseph J. Ambrose
Charles Hall <ha...@thorin.brooks.af.mil> wrote in article
<339C24...@thorin.brooks.af.mil>...
How true,
I have many fond memories ( core mostly ) of programming PDP-8's and -11's
on ASR-33's. with earplugs firmly in place :-0
Joe Ambrose