History of preprocessing (Burroughs ALGOL)
Ian Joyner
preprocessor came from. Was it a Burroughs (Bob Barton) invention, or
come from Atlas or something? Did C get it's inferior #define from
Burroughs ALGOL, or was it some other common source?
Is there another mailing list for Burroughs related topics these days?
Sorry to see Dave Dahm died. I think I sat in his office once.
Cheers
Ian
Tim McCaffrey
says...
I'm cross posting this to alt.folklore.computers. Dennis Ritchie used to lurk
there (and maybe still does)..
- Tim
Arthur Shapiro
>I'm just trying to research where the idea of ALGOL's define .... #
>preprocessor came from. Was it a Burroughs (Bob Barton) invention
It was implemented by one of my coworkers whom I won't identify in the public
forum. I just watched him drive away, probably for the day, so I can't ask
him whether the idea was his or not.
Art
Paul Kimpel
Richard Waychoff's B5000 memoir has a brief discussion on the origin of
the DEFINE. From that, it appears the idea was originally Don Knuth's.
http://ed-thelen.org/comp-hist/B5000-AlgolRWaychoff.html#17
--
Paul
Ian Joyner
I have a better formatted version of Waychoff at:
http://web.me.com/ianjoyner/Files/Waychoff.pdf
so I should have remembered the story about the defines.
Anyone have any other information on this?
The similarities between ALGOL's define ... # and C's #define ... are so
striking that it is hard to believe that it came from anywhere else (the
use of the '#' and the same word 'define' rather than 'macro' or
something. And it seems Ritchie was aware of the "missing #" where the
compiler will skip everything if you forget the terminating # (with a
colouring editor these days, that should not be a problem), but in his
fix for it, made the define much worse.
Ian
Edward Feustel
I used it on the B5500 in 1969.
ED
HVlems
> In article <20081031233247532+1...@news.iinet.net.au>, i.joy...@acm.org
> says...
>
>
>
> >I'm just trying to research where the idea of ALGOL's define .... #
> >preprocessor came from. Was it a Burroughs (Bob Barton) invention, or
> >come from Atlas or something? Did C get it's inferior #define from
> >Burroughs ALGOL, or was it some other common source?
>
> >Is there another mailing list for Burroughs related topics these days?
>
> >Sorry to see Dave Dahm died. I think I sat in his office once.
>
> >Cheers
> >Ian
>
> I'm cross posting this to alt.folklore.computers. Dennis Ritchie used to lurk
> there (and maybe still does)..
>
> - Tim
I doubt there's a connection here. One might just as well argue
there's a connection because
both filesystems use a slash to identify directory-levels. I learned
programming in 1976 (at the same school where Edsger Dijkstra taught)
on a B6700. The MCP and ALGOL at that time were way beyond Unix and C.
ALGOL still is IMHO.
Hans
PS
I spent most of my life with DEC's VMS environment and am quite
comfortable with it.
But even today the elegance and versatality of ALGOL as implemented on
Burroughs large systems
is severaly missed. I wish I'd be able to run it at home. Sigh.
Peter Flass
> I spent most of my life with DEC's VMS environment and am quite
> comfortable with it.
> But even today the elegance and versatality of ALGOL as implemented on
> Burroughs large systems
> is severaly missed. I wish I'd be able to run it at home. Sigh.
Maybe someday. You have the hardware doc and the listings, at least for
MCP and ESPOL. Perhaps some of the software has survived. If not, it
should be possible to bootstrap MCP via another system.
Paul Kimpel
Actually, you can do it now, and have been able to do so since about
2000. I do it all the time, both at home, and not infrequently on an
airplane -- compiling Algol at 35,000 feet.
It's not inexpensive -- $3000 (U.S. pricing), plus the cost of whatever
PC/laptop you will be running it on. That may be a little much for the
occasional hobbyist, but it's within reach if you are serious enough,
and certainly if you are an independent developer.
Unisys markets this as the "ClearPath MCP Software Developer's Kit"
(SDK), or more informally as the "LX Laptop". There are two flavors:
* a demonstration-only version which allows you to run MCP
applications, but which does not include compilers or other development
tools. This is somewhat less expensive (I don't know how much exactly,
but think it's $1500-2000).
* a full-fledged development version, including all compilers and
utilities, along with most of the software that is normally unbundled
and sold separately. It does not include, for example, LINC/EAE/ABS.
This is the version that costs $3000. For an additional $800 you can get
source code (or as much as is still being made available).
What most people would want is the full SDK, so that's all I'll discuss
from here on.
Unisys qualifies the SDK on a particular model of laptop (currently the
Dell Latitude D830), and will only support it on that, although in my
experience it will run on most other Wintel systems with the appropriate
resources and level of Windows. You're on your own, though, if you
decided to run on anything other than the qualified configurations.
What you get for your $3000 is a box of CD-ROMs, a USB dongle that is
required to boot the MCP environment, and a paper manual with
installation instructions. The rest of the system documentation comes on
CD-ROM. Installation is not difficult, but it helps if you have some MCP
administration experience.
The SDK is a variant of the same vmMCP (virtual machine) implementation
used with the LX and low-end Libra systems. The MCP hardware is emulated
in software on the Intel processor. It runs real MCP (E-mode) object
code, so you can exchange codefiles, in both directions, with
production-model MCP systems.
Disk units are emulated as large files within the Windows file system.
You cannot attach SCSI or Fibre Channel devices to the SDK system, so
things like tape drives are out. There is, however, full support for
TCP/IP and BNA networking (the MCP shares the NIC with Windows and can
communicate with the Windows environment using TCP/IP APIs). There are a
number of ways of moving source code and data files among the SDK,
Windows, Linux/Unix, and other MCP systems over the network.
MCP-specific file structures (codefiles, DMSII data bases, etc.) can be
"wrapped" into a container file (something like a Unix tar file), the
container file transmitted over the network, and that file unwrapped at
the destination MCP system.
If you haven't worked with MCP systems in a while, the networking
capabilities will probably surprise you. Old datacom (poll/select, etc.)
is gone, and everything is now done with TCP/IP -- even BNA runs over IP
these days. The MCP plays well with Windows, including support for
shared directories and named pipes. There is a nice Telnet
implementation, which you can use with low-end clients like the built-in
one for Windows, but most people either spring for a proper TCP/IP-based
TD830/T27 emulator (prices start around $80), or use the Java-based Web
Enabler that comes with the MCP.
When you purchase the SDK, you get it for a particular (usually the
current) release of the MCP. Officially, you don't get support, but I've
never had a UCF rejected. You can purchase upgrades to new versions for
half the price of the original SDK (in which case you get everything but
a new dongle).
There are some additional caveats and configuration information detailed
on the Unisys ecommunity web site (http://ecommunity.unisys.com). You
need to register to join (it's free). Once on the home page, search for
"LX laptop". The current product is the LX170 (although I think the
LX160 is still supported) and the current MCP release is 12.0 (also
known as SSR 53.1).
I highly recommend this product if you want to do MCP development. I
bought my first SDK in 2001 and used it on an HP Omnibook 6000 (the
qualified laptop at the time) with MCP 6.0 through 10.1. It still works,
but decided to buy a new Dell D830 about six months ago and also bought
a new LX170 SDK with MCP 12.0.
Here are two Unisys VARs that I know sell the SDK in the U.S. There are
probably others, but I don't know of them:
Computer Resolutions (now Virtera)
Dave Lowenbaum <dloew...@cri1.com>
G-Force Global Technologies
http://www.gforceglobal.com
--
Paul
Edward Reid
> I doubt there's a connection here. One might just as well argue
> there's a connection because
> both filesystems use a slash to identify directory-levels.
In fact proving the point: MCP and Unix are related on this point via
Multics. I started to write that both got the slash from Multics, but now
I'm thinking that the B5000 MCP pre-dated Multics. I can't remember, did
the B5000 have multi-level file names? If not, then it's probably true that
both MCP and Unix got the slash from Multics.
Edward
--
Art Works by Melynda Reid: http://paleo.org
Scott Lurndal
>a "multi-file ID" and a "file ID" in FILE declarations. I believe that
>these were separated by a slash in control cards, SPO commands, etc.
>
Typically the 'multi-file ID' was the tape or pack label.
scott
Thomas Schaefer
enjoyed reading that memoir. Wonderful stuff right up there with my copy
of Computer System Organization. Certainly required reading for anyone
that works on ClearPath systems.
Regards,
Tom Schaefer
Ian Joyner
Security Evaluation". In a footnote to the claim that Multics was one of
the first OSs written in a high-level language (PL/I), it says that the
Multics designers were well aware of the B5000.
Further to my question on defines, it would be nice to trace what
features of the B5000 (and subsequent Burroughs systems) were
influential on Unix.
Ian
HVlems
>
> G-Force Global Technologieshttp://www.gforceglobal.com
>
> --
> Paul
Paul,
I am aware of that product. Unfortunately, $3000 is somewhat more than
I'm willing to spend on a
hobby :-).
I still have a few Algol programs (anno 1980) and it would be fun to
compile and run them after all these years.
As much as I like the B6700/B7700/B7900 systems that I worked with,
that price is a lttle to steep.
Perhaps eBay is an option.
Hans
HVlems
Edward,
that same idea crossed my mind while writing that post. But the
argument was about Unix and MCP similarities, not Multics.
Kernighan&Pike, "The Unix programming Environment" claims that work on
Unix started in 1969.
Work on the B5000 predates that by some margin according to Waychoff.
Hans
HVlems
What I missed in Waychoff's story is the close connection between
hardware and compiler.
I studied chemistry in Eindhoven and like all other students,
programming 101 was mandatory.
This was the same school where Dijkstra taught programming and so I
learned that trade on a Burroughs B6700.
And was spoiled by the system. Most programming faults lead to integer
oveflow, array index value out of range etc.
And the MCP would catch the error, tell you where it went wrong and
give a hint on the offence I committed.
A brief stint on a CDC6600 and an IBM 370 learned me that other
hardware was not as a careful and would merrily continue when an
integer no longer fitted in a word.
As an aside, we had BEATHE: an extension of Burroughs Algol with type
COMPLEX and STRING. It also had quotes so one could use 'REAL' REAL;
and so on. The single quotes were not funny at all on a cardpunch...
Rich Alderson
Multics does *not* use a slash character as the directory-level separator, it
uses the greater-than ">" (ASCII 076).
--
Rich Alderson "You get what anybody gets. You get a lifetime."
ne...@alderson.users.panix.com --Death, of the Endless
HVlems
>
> G-Force Global Technologieshttp://www.gforceglobal.com
>
> --
> Paul
Are you still using the old version of the virtual MCP or would you be
interested in selling it?
Hans
jmfbahciv
> On 8 nov, 20:39, Paul Kimpel <paul.kim...@digm.com> wrote:
>> On 11/8/2008 4:58 AM, Peter Flass wrote:
>>
>>> HVlems wrote:
>>>> I spent most of my life with DEC's VMS environment and am quite
>>>> comfortable with it.
>>>> But even today the elegance and versatality of ALGOL as implemented on
>>>> Burroughs large systems
>>>> is severaly missed. I wish I'd be able to run it at home. Sigh.
<snip>
> I am aware of that product. Unfortunately, $3000 is somewhat more than
> I'm willing to spend on a
> hobby :-).
> I still have a few Algol programs (anno 1980) and it would be fun to
> compile and run them after all these years.
> As much as I like the B6700/B7700/B7900 systems that I worked with,
> that price is a lttle to steep.
> Perhaps eBay is an option.
If you have your ALGOL sources, why don't you try compiling
them using one of DEC's ALGOLs and see what happens?
TOPS-10 had an ALGOL. I don't know if it's available on
the demo machine that Rich looks after.
/BAH
HVlems
Barb,
I ran TOPS-10 on SIMH just to see DEC's ALGOL compiler. Actually,
nothing comes close to Burroughs' Algol.
It's about as close to Algol60 as ADA is to Algol58. In fact,
Burroughs would have been wise to give it a different name altogether.
Which they did for ESPOL and later for NEWP, both languages have a lot
more in common with Burroughs Algol.
It it was just the 'call-by-name' concept then DEC Algol is equally up
to the task.
Hans
Rob Warnock
+---------------
| jmfbahciv <jmfbahciv@aol> wrote:
| > If you have your ALGOL sources, why don't you try compiling
| > them using one of DEC's ALGOLs and see what happens?
| > TOPS-10 had an ALGOL. I don't know if it's available on
| > the demo machine that Rich looks after.
|
| I ran TOPS-10 on SIMH just to see DEC's ALGOL compiler. Actually,
| nothing comes close to Burroughs' Algol.
| It's about as close to Algol60 as ADA is to Algol58. In fact,
| Burroughs would have been wise to give it a different name altogether.
The users did, didn't they? ;-} Wasn't it generally called "BALGOL"?
FWIW, there were some guys at Georgia Tech in the late 70's who had
a B5500 simulator running on a PDP-8/e, good enough to run MCP and
BALGOL on top of it. I wonder if any of that ever made it into the
DECUS Library...?
-Rob
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Paul Kimpel
BALGOL was the name of the Algol 58-ish compiler that ran on the
Burroughs 220 -- a predecessor to the B5000. I think there was one at
Stanford in the late 1950s or early 1960s. I am pretty sure that both
Don Knuth and Dave Dahm worked on that compiler. There is some
documentation on it at www.bitsavers.org.
Officially, the language on the B5000/B5500 was called Burroughs
Extended Algol, but I only ever heard it referred to as simply Algol.
--
Paul
jmfbahciv
So the languages are not alike? Was there ever a standard for
ALGOL?
/BAH
HVlems
>
> - Tekst uit oorspronkelijk bericht weergeven -
Umm, standards for programming languages are like bicycles for
fish :-)
The quick answer to your second question is: yes. For most people,
Algol is similar to Algol60 (like Fortran implies Fortran IV). Algol60
is well documented in its Revised Report. The problem with Algol60 is
that the Rev.Rep. has no I/O functions. The language is ideal for
writing down algorithms and I'm sure that was one of its design goals.
It's somewhat of a drawback for a programming language though and all
Algol(60) implementations have different ways of getting input and
writing output.
Burroughs extended the language considerably, and Burroughs Extended
Algol (BEA) offers a lot more language constructs then Algol60. It had
to because most of the system software (compilers, batch subsystem,
interactive subsystem etc.) was written in Algol (or DCALGOL, which
was syntactically the same and gave you access to functions of the
operating system). In that respect BEA serves the same purpose as C in
a unix environment.
Your first question is also easily answered: no ;-)
Most hardware architectures are sufficiently different to affect the
implementation of a language. Languages like Algol, Pascal and C let
you declare integers. The range of an integer value (minint .. maxint)
is platform dependent. The PDP-10 had 36 bit words, the PDP-11 had 16
bits, the PDP-8 was 12 bits, a B6700 word held 48 bits, 39 were used
to store integers. Programs written in languages that support concept
class declarations ('integer', 'real', 'boolean' etc.) are difficult
to port.
Languages that suport storage class declarations (COBOL, PL/I) are
possibly a pain to implement on some platforms but a COBOL program
that complies to a given standard of the language ought to compile
without a problem with a version-compatible compiler, irrespective of
the platform. Every variable can be neatly specified and thus
improving the chance that a strange compiler understands how it has to
deal with it.
Even then porting may be a problem because your magtape or punched
cards may be in EBCDIC (Burroughs' flavor) and the target machine
might be a VAX (ASCII) or an ICL system (EBCDIC, but a different set).
I'm a chemist and had to take up programming because we had to move
data from our measurement systems (various platforms) to (at least)
four different computers to handle the data: Data General Nova 4
(RDOS), DEC's VAX (VMS) and PDP-11/40 (RT-11) and a B7700 (MCP). I do
understand E.W.Dijkstra's wish "Free us from the curse of
portability" :-)
Hans
HVlems
Even stranger, there used to be an early Burroughs Extended Algol
compiler for RSX-11 or RT-11 on the PDP-11.
I think there's copy somewhere in the attic. On DECtape I
unfortunately....
Hans
Anne & Lynn Wheeler
HVlems <hvl...@freenet.de> writes:
> The quick answer to your second question is: yes. For most people,
> Algol is similar to Algol60 (like Fortran implies Fortran IV). Algol60
> is well documented in its Revised Report. The problem with Algol60 is
> that the Rev.Rep. has no I/O functions. The language is ideal for
> writing down algorithms and I'm sure that was one of its design goals.
> It's somewhat of a drawback for a programming language though and all
> Algol(60) implementations have different ways of getting input and
> writing output.
APL had similar lack of I/O functions ... or any sort of semantics for
dealing with standard operating system functions.
the (cambridge) science center created some contention for the port of
apl\360 to cms\apl. Part of the port was drastically increasing the
workspace size ... which was typically 16k or 32k bytes in apl\360
installations. cms\apl opened it up to size of virtual memory, although
the original APL (internal) storage management had to be reworked to be
much more virtual memory friendly.
I recently referred to cms\apl opened APL use up to a lot more real
world applications (part of that was just the significant increase in
workspace size) ...
http://www.garlic.com/~lynn/2008p.html#42 Password Rules
however, another change for cms\apl (creating some contention in the APL
community about violating purity of APL language) was that interfaces
were defined for accessing system services (including i/o operations).
This was later reworked (to the satisfaction of the APL purists) to use
"shared variables" abstraction (where the "shared variables" were sort
of a message passing interface between an APL application and specific
operations ... like I/O or other system services) ... reference here:
http://en.wikipedia.org/wiki/Shared_Variables
the above slightly garbles the reference ... since cms\apl and apl\cms
predated apl\sv (cms\apl was first done by cambridge science center for
cp67/cms ... then the palo alto science center did apl\cms for vm370/cms
... palo alto also did the 370/145 apl microcode "assist").
lots of past posts mentioning apl (&/or HONE ... which made extensive
use of APL in delivering applications world-wide for sales & marketing)
http://www.garlic.com/~lynn/subtopic.html#hone
--
40+yrs virtualization experience (since Jan68), online at home since Mar70
Bill Gunshannon
Not really a problem. There are still people who can read those tapes.
And anyway, if it was from DECUS it is porbably available on one of the
freeware collections. If anyone really cares, I could look.
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
Charlie Gibbs
<d1001475-ca48-4b7d...@o40g2000prn.googlegroups.com>,
hvl...@freenet.de (HVlems) writes:
> Even then porting may be a problem because your magtape or punched
> cards may be in EBCDIC (Burroughs' flavor) and the target machine
> might be a VAX (ASCII) or an ICL system (EBCDIC, but a different set).
Ah, yes... I remember how under Sperry->Unisys OS/3 a few EBCDIC
characters became somewhat, uh, nomadic. I took to calling it
UBCDIC (Univac's binary-coded...).
> I'm a chemist and had to take up programming because we had to move
> data from our measurement systems (various platforms) to (at least)
> four different computers to handle the data: Data General Nova 4
> (RDOS), DEC's VAX (VMS) and PDP-11/40 (RT-11) and a B7700 (MCP).
> I do understand E.W.Dijkstra's wish "Free us from the curse of
> portability" :-)
Dijkstra? I thought Bill Gates said that... 1/2 :-)
--
/~\ cgi...@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
Peter Flass
>
> So the languages are not alike? Was there ever a standard for
> ALGOL?
>
Sure, lots of them;-)
Peter Flass
>
> Even stranger, there used to be an early Burroughs Extended Algol
> compiler for RSX-11 or RT-11 on the PDP-11.
> I think there's copy somewhere in the attic. On DECtape I
> unfortunately....
Or fortunately. I would suspect that DECTape is somewhat more resistant
to bit rot than magtape. I'm sure if it's readable, someone has the
hardware.
Joachim Pense
The Multics I know didn't use slash but >. (It also had < to denote the step
upwards the tree, as /../ in Unix).
Joachim
HVlems
> In article <33f2b9a7-ad2a-40d4-acc7-3246d39e9...@f40g2000pri.googlegroups.com>,
> University of Scranton |
> Scranton, Pennsylvania | #include <std.disclaimer.h>
Bill,
it's a tape written around 1980 on a PDP-11/40 under RT-11 V5.03.
And DECtape I was considered old, even then. The dept. of chemistry
got the
PDP-11/40 free of charge from electrical engineering. The deal
included a PR11, a CR11,
an LP-11, LAB-11 interface and 32 kB core memory, one RK05 and a TU56.
Data came on an RK05, and the 11/40 booted RT-11 V3 from DECtape I and
copied the data
to another DECtape. Next, boot V5.03 from RK05 and copy the data from
DECtape to RK05.
Then the data could be processed.
It would be nice if you could find the compiler on a DECUS tape
though.
I have no PDP-11 hardware but SIMH would do nicely, provided we can
(a) find the compiler,
(b) find that tape and (c) find a working DECtape I drive...
Hans
HVlems
> In article
> <d1001475-ca48-4b7d-aa96-78f630a6f...@o40g2000prn.googlegroups.com>,
What happened is this: I was asked to convert a few FORTAN IV routines
that resided in a library on a Burroughs B7700 to a Polish system
called an Odra 1900. Now the Odra 1190 was a copy of the ICL 1900.
Eindhoven University owned the B7700 and offered connections to
Utrecht (CDC 6600) and Tilburg ((ICL 2900).
BTW one had to be prepared to travel because the ICL 2900 had no
terminal in Eindhoven. The CDC 6600 had one DECwriter IIRC.
The CDC 6600 was used sporadically, possibly because of its precision,
64 bits compared to 48 bit reals on the B6700. The ICL 2900 was never
used, so the person in charge of that cooperation program was really
happy to see me. I got all the support I needed, manuals and even
travel expenses. The ICL 2900 ran in ICL 1900 emulation mode twice a
week, two afternoons to accommodate users who hadn't ported their
software to the new 2900.
So I copied the routines to my own pack, compiled them and produced a
listing on paper and punched a card deck. I sure wasn't taking risks
with tapes. I knew of IBM sites that used the B7700 to convert their
tapes from one IBM os to another and did not want to end up in that
tarpit.
So I arrived in Tilburg and got a short introduction in JCL; The
operations staff were very helpful, they had even punched the
appropriate JCL cards. Lucky for me because JCL as used on the 1900
when compared to Burroughs' WFL was, err, somewhat user unfriendly.
Anyway, all I had to do was insert my card deck and run it. I've never
seen so many syntax errors in a listing. The ICL EBCDIC was way
different from Burroughs. The operators gave me a manual with the card
punch codes and with that I could write an ALGOL program on the B7700
that relied heavily on TRANSLATETABLEs and punched the correct cards.
Unfortunately without a text on them because the Burroughs cardpunch
obviously did not understand at all what the program was punching.
During the second visit everything worked fine and the carddeck was
mailed to Poland.
I learned that Burroughs and IBM used the same EBCDIC set, perhaps
with some minor differences. ICL used a different EBCDIC collating
sequence. Cards punched on the B7700 could be read on the PDP-11/40
when it ran as an RJE emulator: its CR11 and LP11 acted as remote
stations for the B7700. The PDP-11 is an ASCII machine though under
RT-11 it could read EBCDIC cards and translate them to ASCII. I am not
sure whether this was built into RT-11 or that I had written a
conversion program. The CDC6600 had an entirely different character
set IIRC.
So EBCDIC is like any other standard: there are more than enough of
them around to make life interesting :-)
Hans
HVlems
I'm more worried about sticky tape. DECtape I was second sourced by
Scotch. Like with audio reels tapes, Scotch used an adhesive that is
slightly hygroscopic. After a several years of storage a small water
film forms between the tape layers, usually fairly tightly wound to
begin with. The result is that while reading the tape, the water film
won't let the tape roll off. The cohesion forces between water film,
magnetic layer and plastic carrier are very high, like creating a
vacuum. After a while the tape transport simply stops, even a DECtape
I. The solution is to put the tape in an electric oven for an hour,
possibly more at, say, 70 celsius. The water evaporates and you can
read the tape. Just once because the higher temperature can damage the
adhesive properties of the glue.
Hans
jmfbahciv
<grin> I'm getting it. If it had just been the I/O extensions
(thanks to Tim for the explanation), I couldn't see much
problem writing an I/O set of routines for the -10's, or -11's,
ALGOL to call. A little DDT patch could divert all I/O calls
to the user's subroutine package. But numbers and arithmetic
pose more futzier problems. That would be through the whole
EXE of the user.
/BAH
Peter Flass
I think Bitsavers bakes the tape in an oven for a while before trying to
read it. I don't know the tem or length of time.
jmfbahciv
Not if you had to pass the Navy tests. There was a requirement in
the US for selling gear to the government and they based their
requirements on IBM-influenced standards.
> The quick answer to your second question is: yes. For most people,
> Algol is similar to Algol60 (like Fortran implies Fortran IV). Algol60
> is well documented in its Revised Report. The problem with Algol60 is
> that the Rev.Rep. has no I/O functions. The language is ideal for
> writing down algorithms and I'm sure that was one of its design goals.
> It's somewhat of a drawback for a programming language though and all
> Algol(60) implementations have different ways of getting input and
> writing output.
All I know about Algol is that a guy used it for everything he did
in one of the groups that supported the development groups. Nothing
he did worked; and all of his legacy, when he left the job, was
eradicated. I don't remember if this was due to Algol not working
or the guy not knowing what he was doing.
Just by hearing the chatter over the walls, I learned to be allergic
to Algol and just let the customers, who wanted it, use it. I know
this was another superstition, but...
> Burroughs extended the language considerably, and Burroughs Extended
> Algol (BEA) offers a lot more language constructs then Algol60. It had
> to because most of the system software (compilers, batch subsystem,
> interactive subsystem etc.) was written in Algol (or DCALGOL, which
> was syntactically the same and gave you access to functions of the
> operating system). In that respect BEA serves the same purpose as C in
> a unix environment.
> Your first question is also easily answered: no ;-)
> Most hardware architectures are sufficiently different to affect the
> implementation of a language.
That didn't matter if all had to pass the Navy tests. You wrote the
compilers, assemblers, and interpreters so that it gave consistent
results. This isn't difficult to do as long as there is a standard
to measure the results.
>Languages like Algol, Pascal and C let
> you declare integers. The range of an integer value (minint .. maxint)
> is platform dependent. The PDP-10 had 36 bit words, the PDP-11 had 16
> bits, the PDP-8 was 12 bits, a B6700 word held 48 bits, 39 were used
> to store integers. Programs written in languages that support concept
> class declarations ('integer', 'real', 'boolean' etc.) are difficult
> to port.
If the requirement was a larger field for integers, a larger field
would have been supplied.
> Languages that suport storage class declarations (COBOL, PL/I) are
> possibly a pain to implement on some platforms but a COBOL program
> that complies to a given standard of the language ought to compile
> without a problem with a version-compatible compiler, irrespective of
> the platform. Every variable can be neatly specified and thus
> improving the chance that a strange compiler understands how it has to
> deal with it.
> Even then porting may be a problem because your magtape or punched
> cards may be in EBCDIC (Burroughs' flavor) and the target machine
> might be a VAX (ASCII) or an ICL system (EBCDIC, but a different set).
That's why ANSI and ASCII and all the other standards committees
were created. And they've been around longer than computers have
been.
> I'm a chemist and had to take up programming because we had to move
> data from our measurement systems (various platforms) to (at least)
> four different computers to handle the data: Data General Nova 4
> (RDOS), DEC's VAX (VMS) and PDP-11/40 (RT-11) and a B7700 (MCP). I do
> understand E.W.Dijkstra's wish "Free us from the curse of
> portability" :-)
Yea, well. I won't get into that here.
Where did you do your work? If it was in Europe, I thought
European countries each had their own equivalent to our Navy
tests. They had to have something for arithmetic results
so that the same answer, even if wrong, would be produced.
/BAH
HVlems
I work in the Netherlands. BTW Burroughs large systems were mainly
sold to the US armed forces.
My time spent with Burroughs equipment was at university, which was a
world of its own during the 70ies.
The problem with standards committees is that there are many of them,
so we have IEEE and ANSI standards for Ethernet.
Unfortunately DEC, Intel and another company got there first so
besides their standard (which got build and actually sold to
customers) was replaced by ANSI and IEEE standards. Us poor customers
had to figure out the resulting compatibilty problems (heartbeat,
spanning tree etc.). But all the different implementations followed at
least one respected US committee standaard..
Hans
Bill Gunshannon
I will look and see if I have anything in my collection.
> I have no PDP-11 hardware but SIMH would do nicely, provided we can
> (a) find the compiler,
> (b) find that tape and (c) find a working DECtape I drive...
I have running PDP-11's with support for floppies, DECTape, 9track
and TK50 (when the wind blows in the right direction and I have a
chicken to wave over my head!)
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
Bill Gunshannon
The more common failure mode for DECTape, in my experince, has been
deterioration of the pinch-roller in the drive. It turns into a
sticky gummy mess and then destroys the tape as well. (kind of like
what all my old 8-track cartridges did. :-)
Bill Gunshannon
jmfbahciv <jmfbahciv@aol> writes:
>
> Where did you do your work? If it was in Europe, I thought
> European countries each had their own equivalent to our Navy
> tests.
Is that like the official finger?
> They had to have something for arithmetic results
> so that the same answer, even if wrong, would be produced.
And that sounds like ISO 9000. :-)
Scott Lurndal
This happened to all my QIC-150 drives.
scott
Bill Gunshannon
Interesting. I still have piles of 1/4" QIC tapes and a number of drives.
None has failed like that. Their only shortcoming is they tend not to hold
much data. :-)
Al Kossow
> I think Bitsavers bakes the tape in an oven for a while before trying to
> read it. I don't know the tem or length of time.
55 deg C for up to a day, depending on the brand, in a dehydration chamber
which has two large banks of fans and a heat source added, cooldown,
cleaning, and retensioning.
Temperature and humidity are controlled, and
there is a LOT of airflow inside. You can see a picture of it (the large white
box) on the main page of the bitsavers web site.
Airflow is critical to saving sticky tape near the hub.
Silver-labeled MRX V from the early 80's one of the worst as far as sticky shed.
I've only had one slightly sticky DECtape. The binder on DECtape has a plastic
protective overlay. The 3M spec for the tape can be found at
http://bitsavers.org/pdf/dec/dectape/3M_DECtape_Spec_Nov66.tif
Larry Sheldon
the hazards of talking to non-technical management....
We used (extensively) "Checkpoint/Restart) where any batch job that
might run more that 20 minutes had to take a "Checkpoint" every 30 minutes.
We had a siege of (DMS 1100) Audit Trail failures right after the
Checkpoint had been taken. (I suspect the whole concept of
Checkpoint/Restart may be foreign to the youngsters--if there is an
interest, start a new thread on the topic.)
Because I was not long away from the world of 256-BPI 7-track tapes (we
had a few Uniservos on-line for interchange purposes) where developing
the image on tapes with "Magnasee" or a hand-held reader was common, I
got a can of Magnasee from somewhere and without anybodies permission (I
knew it would never be granted) and to the horror of the Console
Managers on duty, shut off the Uniservo and removed the tape.
What I found was that the IBG where the tape had stopped had a deposit
of crude in an image of the tape-head-gaps.
After several such examinations I pondered the possible explanations and
finally decided that I knew the probably answer, so I wrote a paper to
my masters on-staff explaining what I had found.
I the paper O theorized that when the Audit Trail was moving (which it
did at close to tape-speed) the heads A) got hot, and B) collected oxide
and binder debris from the tape.
When the tape stopped (as it did for the several minutes that a
Checkpoint took), the head cooled and deposited the collection of crude
onto the tape, leaving a raised area "as if somebody had touched the
tape while eating a jelly donut". When the Audit Trail started to move
again the first motion is a back space to overwrite the tapemark but the
lump of crude would raise the tape off the head, causing a misread.
Anyway the only thing that registered with the uptown suits was "jelly
donut" so there were many heated discussions about identifying the
culprits and treating them badly.
I am not sure (memories do not work ass well as they used to) but I
think we changed brands of tape to solve the problem.
--
Requiescas in pace o email Two identifying characteristics
of System Administrators:
Ex turpi causa non oritur actio Infallibility, and the ability to
learn from their mistakes.
Eppure si rinfresca
ICBM Targeting Information: http://tinyurl.com/4sqczs
Al Kossow
> Interesting. I still have piles of 1/4" QIC tapes and a number of drives.
> None has failed like that.
They will. Most 1980's QIC pinch rollers are past their useful life. Their failure
modes can be catastrophic. They look OK, but as soon as the motor shaft heats up
the rubber turns to tar.
If the roller is soft enough to push your finger nail into, it will disintegrate
when heated.
There was someone offering replacements for Wangtek and Archive, but I haven't
looked lately.
I would strongly suggest anyone with QIC or Extabyte tape data that they care about
from the 80's transfer it to more modern media as quickly as possible, since the drives
capable of reading it have rubber parts that will fail, and the tensioning belts in QIC
cartridges loose their tension and they are not being made any more.
Tim McCaffrey
<cc638a6f-c6a9-4c0f...@w39g2000prb.googlegroups.com>,
hvl...@freenet.de says...
>
>On 13 nov, 17:07, "Charlie Gibbs" <cgi...@kltpzyxm.invalid> wrote:
>> In article
>> <d1001475-ca48-4b7d-aa96-78f630a6f...@o40g2000prn.googlegroups.com>,
>>
>> hvl...@freenet.de (HVlems) writes:
>> > Even then porting may be a problem because your magtape or punched
>> > cards may be in EBCDIC (Burroughs' flavor) and the target machine
>> > might be a VAX (ASCII) or an ICL system (EBCDIC, but a different
set).
>>
>> Ah, yes... I remember how under Sperry->Unisys OS/3 a few EBCDIC
>> UBCDIC (Univac's binary-coded...).
>>
>> > I'm a chemist and had to take up programming because we had to
move
>> > data from our measurement systems (various platforms) to (at
least)
>> > four different computers to handle the data: Data General Nova 4
>> > (RDOS), DEC's VAX (VMS) and PDP-11/40 (RT-11) and a B7700 (MCP).
>> > I do understand E.W.Dijkstra's wish "Free us from the curse of
>> > portability" :-)
>>
>>
>> --
>> /~\ =A0cgi...@kltpzyxm.invalid (Charlie Gibbs)
>> \ / =A0I'm really at ac.dekanfrus if you read it the right way.
>> =A0X =A0 Top-posted messages will probably be ignored. =A0See
RFC1855.
>> / \ =A0HTML will DEFINITELY be ignored. =A0Join the ASCII ribbon
campaign=
Yeah, CDC 6600 were 60 bit machines, with 6 bit "display code" for the
character set (what do you need lower case for?). ANSI later came up
with 6-bit ASCII, which moved a few characters around. If I remember
right, the 6600 detected 3 user level error conditions, trying to
access outside your memory bounds, trying to execute outside your
memory bounds, and divide by zero. Program and data were all in one
big chunk, so you could happly :( overwrite your program....
Fast machine though.
- Tim
H Vlems
> In article <06df5044-348f-4d4f-b3b9-bcbab9de0...@v13g2000pro.googlegroups.com>,
>
> - Tekst uit oorspronkelijk bericht weergeven -
Bill, I'll have a look in the attic. If I find a DECtape I (whatever
it says on the label), I'll send it to you.
Hans
Peter Flass
>
> I will look and see if I have anything in my collection.
>
>> I have no PDP-11 hardware but SIMH would do nicely, provided we can
>> (a) find the compiler,
>> (b) find that tape and (c) find a working DECtape I drive...
>
I think it is a DECUS program. Try Google.
Peter Flass
> Bill Gunshannon wrote:
>
>> Interesting. I still have piles of 1/4" QIC tapes and a number of
>> drives.
>> None has failed like that.
>
> They will. Most 1980's QIC pinch rollers are past their useful life.
> Their failure
> modes can be catastrophic. They look OK, but as soon as the motor shaft
> heats up
> the rubber turns to tar.
I had the same problem with the feed rollers on a Lexmark printer. It
seemed like it would be a silple matter to replace them, but apparently not.
>
> If the roller is soft enough to push your finger nail into, it will
> disintegrate
> when heated.
>
> There was someone offering replacements for Wangtek and Archive, but I
> haven't
> looked lately.
>
> I would strongly suggest anyone with QIC or Extabyte tape data that they
> care about
> from the 80's transfer it to more modern media as quickly as possible,
> since the drives
> capable of reading it have rubber parts that will fail, and the
> tensioning belts in QIC
> cartridges loose their tension and they are not being made any more.
Say it ain't so. I recently picked up an unused QIC-50 drive and was
goint to think about getting some cartridges for it.
Charles Richmond
I had an MGM 8-track cartridge pinch roller that turned into
a "sticky gummy mess". Yuck!!! But my Columbia tapes and others
did *not* have deteriorated pinch rollers. And these tapes were
all stored in the *same* brief case!!!
I also have a TI SR-52 programmable calculator that had a pinch
roller (for reading the magnetic cards) that turned into a gummy mess!!!
--
+----------------------------------------------------------------+
| Charles and Francis Richmond richmond at plano dot net |
+----------------------------------------------------------------+
Bill Gunshannon
OK, I have looked at the RT-11 and RSX-11 and there is an RT-11 ALGOL
from the late 70's and an RSX-11 ALGOL from the early 80's. Neither
is listed as having come from Burroughs.
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
Rob Warnock
+---------------
| The more common failure mode for DECTape, in my experince, has been
| deterioration of the pinch-roller in the drive. It turns into a
| sticky gummy mess and then destroys the tape as well. (kind of like
| what all my old 8-track cartridges did. :-)
Uh... You must be talking about "DECtape-II" [TU58], that cartridge
thingy. *Real* DECtape (a.k.a. LINCtape) [TU55, TU56] didn't *have*
any pinch roller, nor even a capstan, for that matter. It was driven
reel-to-reel solely by the synchronous torque motors in the hubs
[that is, they were programmable-torque motors below the synchronous
speed, but synchronous motors when running at full speed].
Yes, that did mean that the actual linear tape speed varied ~25%
from one end to the other, but the combination of a dedicated
pre-formatted[1] clock track, Manchester encoding, and dual
heads/tracks for every "track" meant that the tape speed wasn't
an issue.
-Rob
[1] Well, yes, the tape media did come blank from the factory.
As we all remember, one had to run a formatting program
on a blank DECtape (once) to write the Clock & Mark tracks
before you could use it.
One of the great wonders of the period was the PDP-10 user-mode
DECtape formatting program that used User-I/O Mode to talk
directly to the hardware, allowiing formatting DECtapes even
while timesahring was running!!! [Well, that is, if you had
MA-10 or ME-10 memory. If you had MB-10 or MD-10, the program
was sometimes just *slightly* too slow. (Oops.) In that case
you had to take down timesharing and use the standalone version
of the formatting program (one of the DEC-supplied diags).]
-----
Rob Warnock <rp...@rpw3.org>
jmfbahciv
> In article <06df5044-348f-4d4f...@v13g2000pro.googlegroups.com>,
> HVlems <hvl...@freenet.de> writes:
<snip>
>
>> I have no PDP-11 hardware but SIMH would do nicely, provided we can
>> (a) find the compiler,
>> (b) find that tape and (c) find a working DECtape I drive...
>
> I have running PDP-11's with support for floppies, DECTape, 9track
> and TK50 (when the wind blows in the right direction and I have a
> chicken to wave over my head!)
Only a chicken? I would think at least an elephant, or maybe a
purple unicorn would be necessary. Or do you use one of those
fancy, schmancy chickens?
/BAH
Peter Flass
>>> - Tekst uit oorspronkelijk bericht weergeven -
>> Bill, I'll have a look in the attic. If I find a DECtape I (whatever
>> it says on the label), I'll send it to you.
>
> OK, I have looked at the RT-11 and RSX-11 and there is an RT-11 ALGOL
> from the late 70's and an RSX-11 ALGOL from the early 80's. Neither
> is listed as having come from Burroughs.
>
I looked again last nite too. I had googled it at work, but had to
leave before I'd had time to do more than a quick scan. The compiler
didn't come from Burroughs, but was supposedly compatible with Burroughs
Algol. I found RT-11 Algol, but it doesn't have source.
As an aside, the large number of web sites thata are caching newsgroup
messages are really polluting cyberspace. Given a discussion like this
that's gone on for a few days, the majority of google hits now are
messages from this thread. Talk about contemplating your own navel.
peter capek
through
this transcript of a conference of a lot of the B5000 and B5500
implementers and
designers, including a sales guy or two:
http://www.cbi.umn.edu/oh/display.phtml?id=53 (Click on Link to
Transcript toward the bottom)
It's almost 200 pages, and not very edited, so a bit rough going in
parts, but pretty interesting. The
meeting took place more than 20 years ago, so memories are fresher
than they would be if it were done
today, but many of the people might not be able to participate....
Chaired by Bernie Galler of U of Michigan.
Peter Capek
HVlems
>
> - Tekst uit oorspronkelijk bericht weergeven -
I found a (the?) DECtape I reel. Let's discuss this outside this
group. My email address is hvlems/at/zonnet/dot/nl
Edward Reid
> Multics does *not* use a slash character as the directory-level separator, it
> uses the greater-than ">" (ASCII 076).
Well, in that case, I'm not sure where I got that impression. I've had it
for much too long to figure out the source.
Edward
--
Art Works by Melynda Reid: http://paleo.org
Edward Reid
> Umm, standards for programming languages are like bicycles for
> fish :-)
Someone said "the great thing about standards is that there are so many to
choose from". Someone here can probably remind who said it ...
> The problem with Algol60 is
> that the Rev.Rep. has no I/O functions.
And also no character handling -- perhaps even more significant in terms of
the extensions required for real-world use.
> Burroughs extended the language considerably
Yeah, the opinion I've often expressed is that Burroughs Algol is 80%
extensions. A lot of the extensions maintain the basic flavor of the
language -- for example, the block structure is fully intact. Passing
procedures as parameters works exactly as it should -- even the kind with
the parameters to the formal procedure unspecified, though I've always
written formal procedures using the extensions to specify the parameters.
I remember getting upset when they introduced a new data type (I think it
was strings) and made the default parameter passing method
call-by-reference instead of call-by-name. In retrospect, that was a bit
over the top, considering how much the SCAN and REPLACE statements already
mangled the basic syntax of the language. They read more like COBOL than
like Algol, and are really just HLL syntax for the machine instructions
underlying them. Also, there are numerous extensions which use procedure
call syntax on the surface -- except that the actual parameters are not
restricted in type as they would be in Algol60.
> Algol (BEA) offers a lot more language constructs then Algol60. It had
> to because most of the system software (compilers, batch subsystem,
> interactive subsystem etc.) was written in Algol (or DCALGOL, which
> was syntactically the same and gave you access to functions of the
> operating system).
The significance of DCALGOL in this context is overrated. For the most
part, the additional access is in the form of access to procedures, and
calling those procedures would result in failure anyway unless the program
were given the right to call them, so allowing them in the language was not
a security issue. DCALGOL also added data types for MESSAGE and QUEUE. The
notable aspect of these is that messages move through queues without data
movement -- messages are special kinds of arrays which can be linked into
the queue data structure. Shortcuts were taken for efficiency, with the
result that a few insecurities were left open. It would have been difficult
to use these to gain access to protected data, but I'm pretty sure that
crashing the system wouldn't have been difficult at all. I never tried it,
and the insecurities were long ago closed by architecture improvements.
So today, one could just use the DCALGOL compiler for everything. The only
conflicts would be due to additional reserved words in DCALGOL. There would
be no insecurities.
Steve O'Hara-Smith
Edward Reid <edw...@paleoNOTTHIS.org.NOTTHIS> wrote:
> Someone said "the great thing about standards is that there are so many to
> choose from". Someone here can probably remind who said it ...
Andrew Tanenbaum - "The nice thing about standards is that there
are so many of them to choose from" in his book "Computer Networks".
--
C:>WIN | Directable Mirror Arrays
The computer obeys and wins. | A better way to focus the sun
You lose and Bill collects. | licences available see
| http://www.sohara.org/
jmfbahciv
> On Wed, 26 Nov 2008 22:28:45 -0800
> Edward Reid <edw...@paleoNOTTHIS.org.NOTTHIS> wrote:
>
>> Someone said "the great thing about standards is that there are so many to
>> choose from". Someone here can probably remind who said it ...
>
> Andrew Tanenbaum - "The nice thing about standards is that there
> are so many of them to choose from" in his book "Computer Networks".
>
a decade or two to the best working, and still implementable, ones.
/BAH
Roland Hutchinson
"I don't know what the networking standard of the year 2100 will be like,
but I know it will be called TCP/IP over Ethernet".
--
Roland Hutchinson Will play viola da gamba for food.
NB mail to my.spamtrap [at] verizon.net is heavily filtered to
remove spam. If your message looks like spam I may not see it.
Charlie Gibbs
writes:
As long as there are companies who feel they have something to gain
by perverting standards to lock people into their products, there
will be glitches. When I wrote a simple to send e-mail, I had to
add an option to make it work with Microsoft Exchange servers, which
reject any e-mail addresses enclosed in the angle brackets that are
required by RFC2821.
--
/~\ cgi...@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
Al Kossow
> Further to my question on defines, it would be nice to trace what
> features of the B5000 (and subsequentBurroughssystems) were
> influential on Unix.
>
documents on http://bitsavers.org/pdf/burroughs/B5000_5500_5700 should
help with that.
I've also just put the listings for the Algol version of Snobol
for the 5000 from CUBE up under listings in that directory.
Marc Wilson
<1254.288T...@kltpzyxm.invalid>::
>In article <ggm59...@news1.newsguy.com>, jmfbahciv@aol (jmfbahciv)
>writes:
>
>> Steve O'Hara-Smith wrote:
>>
>>> On Wed, 26 Nov 2008 22:28:45 -0800
>>> Edward Reid <edw...@paleoNOTTHIS.org.NOTTHIS> wrote:
>>>
>>>> Someone said "the great thing about standards is that there are so
>>>> many to choose from". Someone here can probably remind who said it
>>>> ...
>>>
>>> Andrew Tanenbaum - "The nice thing about standards is that there
>>> are so many of them to choose from" in his book "Computer Networks".
>>
>> But is that still true with networks? Things usually shake out over
>> a decade or two to the best working, and still implementable, ones.
>
>As long as there are companies who feel they have something to gain
>by perverting standards to lock people into their products, there
>will be glitches. When I wrote a simple to send e-mail, I had to
>add an option to make it work with Microsoft Exchange servers, which
>reject any e-mail addresses enclosed in the angle brackets that are
>required by RFC2821.
Exchange. Yuch. Try sending mail with MAPI from a batch process, if
you don't have enough stress in your life.
--
Marc Wilson
Cleopatra Consultants Limited - IT Consultants
Fernrhoyd, Chester Road, Alpraham, Tarporley, Cheshire CW6 9JE
Tel: (44/0) 1829 262696 Tel: (44/0) 161 408 6449
Fax: (44/0) 871 236-1531 Mobile: (44/0) 7973 359850
Skype: cleo-marc Mail: enqu...@cleopatra.co.uk
Web: http://www.cleopatra.co.uk
Registered in England and Wales no: 2588943 VAT Reg: 561 1182 69
Registered office: St George's House, 215-219 Chester Road
Manchester M15 4JE
_________________________________________________________________
Try MailTraq at https://my.mailtraq.com/register.asp?code=cleopatra
HVlems
> On Thu, 13 Nov 2008 06:52:58 -0800 (PST), HVlems wrote:
[snip]
> Yeah, the opinion I've often expressed is that Burroughs Algol is 80%
> extensions. A lot of the extensions maintain the basic flavor of the
> language -- for example, the block structure is fully intact. Passing
> procedures as parameters works exactly as it should -- even the kind with
> the parameters to the formal procedure unspecified, though I've always
> written formal procedures using the extensions to specify the parameters.
It is not enforced by the language but a lot easier to maintain the
program.
>
> I remember getting upset when they introduced a new data type (I think it
> was strings) and made the default parameter passing method
AFAIK your memory is right, that was type STRING.
> call-by-reference instead of call-by-name. In retrospect, that was a bit
> over the top, considering how much the SCAN and REPLACE statements already
> mangled the basic syntax of the language. They read more like COBOL than
> like Algol, and are really just HLL syntax for the machine instructions
> underlying them. Also, there are numerous extensions which use procedure
> call syntax on the surface -- except that the actual parameters are not
> restricted in type as they would be in Algol60.
Type COMPLEX was quite useful, and for scientific work it was an
advantage.
IIRC we did COMPLEX arithmetic in FORTRAN subroutines bound to the
ALGOL host and passed the RE(Z) and IM(Z) as separate
REAL variables. BTW I noted that the BINDER no longer produces
BOUNDCODE but sticks to the language of the main program.
>
> > Algol (BEA) offers a lot more language constructs then Algol60. It had
> > to because most of the system software (compilers, batch subsystem,
> > interactive subsystem etc.) was written in Algol (or DCALGOL, which
> > was syntactically the same and gave you access to functions of the
> > operating system).
>
> The significance of DCALGOL in this context is overrated. For the most
> part, the additional access is in the form of access to procedures, and
> calling those procedures would result in failure anyway unless the program
> were given the right to call them, so allowing them in the language was not
I know and wasn't implying that. Just that if you wanted to enter SPO
commands you did need access to the DCALGOL compiler.
And a way to make the codefile privileged, which was (once you knew
how) not very difficult to do. That is, at the III.4 release or
earlier.
Later on that security loophole got closed pretty fast.
> a security issue. DCALGOL also added data types for MESSAGE and QUEUE. The
> notable aspect of these is that messages move through queues without data
> movement -- messages are special kinds of arrays which can be linked into
> the queue data structure. Shortcuts were taken for efficiency, with the
> result that a few insecurities were left open. It would have been difficult
> to use these to gain access to protected data, but I'm pretty sure that
> crashing the system wouldn't have been difficult at all. I never tried it,
> and the insecurities were long ago closed by architecture improvements.
>
> So today, one could just use the DCALGOL compiler for everything. The only
> conflicts would be due to additional reserved words in DCALGOL. There would
> be no insecurities.
>
> Edward
> --
> Art Works by Melynda Reid:http://paleo.org
Some SPO commands (actually ODT commands, right) were accessible via a
non-priv DCALGOL program.
I noticed that *SYSTEM/RJE recognized a subset of these commands which
made life a little easier.
Like knowing when my pack was mounted or not (P PK ?). Or spinning it
down fro the operators to speed up things...
Hans
Edward Reid
>> language -- for example, the block structure is fully intact. Passing
>> procedures as parameters works exactly as it should -- even the kind with
>> the parameters to the formal procedure unspecified, though I've always
>> written formal procedures using the extensions to specify the parameters.
>
> It is not enforced by the language but a lot easier to maintain the
> program.
Actually it is enforced. If the formal parameters of the formal procedure
are not specified, then it's enforced at run time. If they are specified,
then it's usually enforced at compile time. (The only exception I can think
of, the reason I say "usually", is when the procedure being passed as the
actual parameter is itself a formal procedure without specified
parameters.)
The only thing not enforced is that you are not required to specify the
formal parameters of the formal procedure.
Anything else would have a security nightmare. While a parameter mismatch
would have usually just caused a program fault, it could have caused a
system fault or (much less likely) a security breach.
Yes, some things in DCALGOL can't be done any other way, with security
issues which wre complex at the time. One example is GETSTATUS directory
calls -- a non-privileged user can make the call, but it only returns
information which the user has the right to see. The MCP always preferred
to make such checks early, for efficiency and security, and making the
check so late was unusual. (Of course, in today's networked systems, far
more complex security decisions are made this late and even later.)
RJE was an odd beast, in that it had to be secured for end users to use,
but sometimes system operators used it to. As a result, many sites patched
it to allow commands not allowed in the released version.
Paul Kimpel
> On 27 nov, 07:28, Edward Reid <edw...@paleoNOTTHIS.org.NOTTHIS> wrote:
>> On Thu, 13 Nov 2008 06:52:58 -0800 (PST), HVlems wrote:
<snip>
>> The significance of DCALGOL in this context is overrated. For the most
On 12/3/2008 6:22 PM, Edward Reid wrote:
<snip>
>
> RJE was an odd beast, in that it had to be secured for end users to use,
> but sometimes system operators used it to. As a result, many sites patched
> it to allow commands not allowed in the released version.
>
> Edward
Wow, RJE. I haven't thought about that product in years. I found a copy
of the 3.6 source and looked to see how it handled the ODT commands that
Hans mentioned.
It turns out that RJE didn't use GETSTATUS or SYSTEMSTATUS for these
commands (although it used both of those for other purposes), nor did it
use DCKEYIN. It used a DCALGOL feature I had forgotten about -- intercom
queues. This is a reference to a queue array that allows an MCS (Message
Control System, of which RJE was one) to communicate with the CONTROLLER
(the part of the MCP that handles the ODTs and WFL job queues) and other
MCSes. Intercom queue [0] is connected to the CONTROLLER. The
remaining queue array entries are (potentially) connected to MCSes and
are indexed by MCS number.
RJE would insert a message with the text of an ODT command (along with
several header fields in the front of the message) into queue [0] and
receive a response via a separate queue that it supplied. I suspect this
approach was chosen over DCKEYIN because it was asynchronous -- ODT
commands that took a significant amount of time to process did not block
RJE from handling other events.
It does not appear that an RJE station could function entirely as a
remote ODT. The scope of the ODT commands that affected the state of the
MCP host appears to have been restricted to the usercode associated with
a particular remote station. Therefore one RJE user could not kill
another user's tasks. This restriction appears to have been enforced by
the CONTROLLER based on information in the message header supplied by
RJE. Query-only commands with a global scope (such as the P PK command
to view mounted disk packs that Hans mentioned) were allowed because
they couldn't damage anything.
--
Paul
HVlems
>
> - Tekst uit oorspronkelijk bericht weergeven -
PO PK was indeed not possible :-)
One Second Burden
> I learned
> programming in 1976 (at the same school where Edsger Dijkstra taught)
> on a B6700. The MCP and ALGOL at that time were way beyond Unix and C.
> ALGOL still is IMHO.
One of the entries in my random signature tag file (a feature which I
originally implemented for A Series Mail and now happily use with Mac
Eudora) is:
Algol was a great improvement on most of its successors.
--C.A.R Hoare
> But even today the elegance and versatality of ALGOL as implemented on
> Burroughs large systems
> is severaly missed. I wish I'd be able to run it at home. Sigh.
Yes, indeed. I never cease to be amazed at how primitive today's
modern systems are. How I miss the Editor's ]SHOW CODE HERE or the
"]" that showed where all places where a variable was assigned. How I
miss the elegance of the system architecture. How I miss the way
everything was tightly coupled into the language. It made more work
for the compiler developers, yes, but it made everyone else's life so
much easier. I am always running across some problem that would not
exist on A Series.
One Second Burden
> Most programming faults lead to integer
> oveflow, array index value out of range etc.
> And the MCP would catch the error, tell you where it went wrong and
> give a hint on the offence I committed.
> A brief stint on a CDC6600 and an IBM 370 learned me that other
> hardware was not as a careful and would merrily continue when an
> integer no longer fitted in a word.
As I recall, when Unisys first implemented a C compiler and we started
porting programs, we'd find all sorts of such faults, and when we'd
alert the developers, we'd get a reply that they'd been looking for
that bug for ages but could never track it down.
> As an aside, we had BEATHE: an extension of Burroughs Algol with type
> COMPLEX and STRING. It also had quotes so one could use 'REAL' REAL;
> and so on. The single quotes were not funny at all on a cardpunch...
I thought ALGOL already had a COMPLEX type (was that FORTRAN only?)
and I know I used single quotes when specifying a 48-bit literal.
One Second Burden
> I'm just trying to research where the idea of ALGOL's define .... #
> preprocessor came from.
As an aside, one of the joys of ALGOL and curses of C is that the
DEFINE in ALGOL is *not* a preprocessor facility but is integrated
into the language and compiler, while in C it is a preprocessor and
was originally a separate program if I recall correctly. This is most
glaring when one makes a mistake, and gets a fairly helpful error
message from the ALGOL compiler that includes the DEFINE and what it
expanded to (including nested DEFINEs) while in C one gets a bizarre
error nowhere near the problem.
Eugene Miya
peter capek <peter...@gmail.com> wrote:
>Readers of this group might be interested to spend an evening reading
>through
>this transcript of a conference of a lot of the B5000 and B5500
>implementers and
>designers, including a sales guy or two:
>
>http://www.cbi.umn.edu/oh/display.phtml?id=53
Awk! You should have told me.
I stopped at the Babbage Institute for an official call the last day of
my vacation at the end of the month before returning from the North
countries. They showed me all the Burroughs paper archives etc. while I
was visiting.
--
Looking for an H-912 (container).
------------ And now a word from our sponsor ----------------------
For a quality mail server, try SurgeMail, easy to install,
fast, efficient and reliable. Run a million users on a standard
PC running NT or Unix without running out of power, use the best!
---- See http://netwinsite.com/sponsor/sponsor_surgemail.htm ----
Eugene Miya
In article <20081031233247532+1...@news.iinet.net.au>, i.joy...@acm.org
says...
>>I'm just trying to research where the idea of ALGOL's define .... #
>>come from Atlas or something? Did C get it's inferior #define from
>>Burroughs ALGOL, or was it some other common source?
>I'm cross posting this to alt.folklore.computers. Dennis Ritchie used
>to lurk there (and maybe still does)..
I don't have time to track down all posts in this thread.
Last month, I was at a conference where we discussed what happened to
Bell Labs in one session. Knuth was there. And I think it was he who
mentioned that Doug McIlroy deserved credit for the first macro
preprocessor. And I think there was a CACM article about it.
--
Looking for an H-912 (container).
------------ And now a word from our sponsor ---------------------
For a secure high performance FTP using SSL/TLS encryption
upgrade to SurgeFTP
---- See http://netwinsite.com/sponsor/sponsor_surgeftp.htm ----
(see below)
<eug...@cse.ucsc.edu> wrote:
> timcaff...@aol.com (Tim McCaffrey) wrote:
> In article <20081031233247532+1...@news.iinet.net.au>, i.joy...@acm.org
> says...
>>> I'm just trying to research where the idea of ALGOL's define .... #
>>> preprocessor came from. Was it a Burroughs (Bob Barton) invention, or
>>> come from Atlas or something? Did C get it's inferior #define from
>>> Burroughs ALGOL, or was it some other common source?
>
>> I'm cross posting this to alt.folklore.computers. Dennis Ritchie used
>> to lurk there (and maybe still does)..
>
> I don't have time to track down all posts in this thread.
>
> Last month, I was at a conference where we discussed what happened to
> Bell Labs in one session. Knuth was there. And I think it was he who
> mentioned that Doug McIlroy deserved credit for the first macro
> preprocessor. And I think there was a CACM article about it.
The concept, as applied to the generation of program code, is due to Turing
of course. I'm not aware of any immediate practical implementation of his
ideas, though.
--
Bill Findlay
<surname><forename> chez blueyonder.co.uk
Dennis Ritchie
"Eugene Miya" <eug...@cse.ucsc.edu> wrote in message
news:4946dfff$1@darkstar...
> ... Knuth was there. And I think it was he who
> mentioned that Doug McIlroy deserved credit for the first macro
> preprocessor. And I think there was a CACM article about it.
McIlroy definitely did early work in macros, but not as a preprocessor.
They were integrated into the BL version of FAP (709x assembler).
The first C preprocessor was done by Mike Lesk. The initial one
was very simple, basically just replacing names. It grew by stages
into what's standard today.
Dennis
Eugene Miya
Dennis Ritchie <d...@bell-labs.com> wrote:
>"Eugene Miya" <eug...@cse.ucsc.edu> wrote in message
>news:4946dfff$1@darkstar...
>> ... Knuth was there. And I think it was he who
>> mentioned that Doug McIlroy deserved credit for the first macro
>> preprocessor. And I think there was a CACM article about it.
>
>McIlroy definitely did early work in macros, but not as a preprocessor.
>They were integrated into the BL version of FAP (709x assembler).
I will pass that on to Don.
>The first C preprocessor was done by Mike Lesk. The initial one
>was very simple, basically just replacing names. It grew by stages
>into what's standard today.
As the meeting session was about the Labs (many Weinburger jokes like
the water tower), and Mike was not able to attend the meeting by a week,
I sent some notes to him and others (mostly now at Google).
Talk to Duff, he was the guy who organized the session.
Mike's mentioned prank was a pad of parking tickets:
ticket of a ski rack out of ski season for instance.
Mike came back from my notes in his NSF tone wishing for more
distingished discussion (former Lab glories like the transistor or black
body radiation, etc.).
--
Looking for an H-912 (container).
------------ And now a word from our sponsor ----------------------
Wojja62
news:1wc4xnsw6lng3$.oxfmmoy0emnh.dlg@40tude.net...
> On Thu, 13 Nov 2008 06:52:58 -0800 (PST), HVlems wrote:
> Yeah, the opinion I've often expressed is that Burroughs Algol is 80%
> language -- for example, the block structure is fully intact. Passing
> procedures as parameters works exactly as it should -- even the kind with
> the parameters to the formal procedure unspecified, though I've always
> written formal procedures using the extensions to specify the parameters.
Hello! Roger Jefferyes here!! :-)
I left Glasgow University computing department to join Burroughs Machines
Ltd during the Easter Holidays of 1970. We had an interesting machine in
Glasgow called a KDF9. Interesting for (at least) two reasons.
Firstly it had hardware implementations of a return address stack and an
arithmetic stack. So those of us who were bold enough to write 'Usercode'
(the assembler language) were used to stack handling and what were the
principles for writing fast running code. Also looking at the machine code
resulting from compiling higher level languages showed how to write these
other languages to best effect too.
Secondly it was one of a number of machines that ran the Whetstone Algol 60
compiler controller system. This implemented a version of Algol that was
very close to the Algol 60 report. The report didn't define input/output
constructs and a number of other things so these were added. The Whetstone
controller interpreted pseudo op-codes inside a virtual machine very similar
to the hardware of the Burroughs Large Systems. Many of the virtual
registers were even called by the same names.
So when a couple of salesmen (Garth Tillot was one) came trying to sell us a
B6500 and described a machine so similar to what we already understood it
seemed like a good idea to go and see how computing would be out in the
'real' world with these machines.
After a year or two of getting to know the B6500/B6700 I went back to
Glasgow to explain to my former colleagues what a wonderful machine it was.
Many of them were horrified at the 'liberties' the implementers of Burrough
Extended Algol 60 had taken with their pet language. They balked at
various constructs. Bit manipulation. Character handling with pointers and
array rows. The attributes stuff. The rules about everything being
declared before it is used. E.G. The requirement for FORWARD declarations
of mutually calling procedures. (This restriction is not in the Algol 60
report.) And a number of other things.
In fact when I landed up supporting Academic Branch I heard it called
"Over-extended Algol" several times and found myself asking what our
accusers would have done given the tasks the company faced. The conflict
between 'purity' and 'practicality' was not often resolved to everyone's
satisfaction! :-(
Well! I seem to have rambled on far enough. What does everyone else think?
With Regards,
Roger Jefferyes
SteveT
news:HvKdne_M5-ysZWTU...@giganews.com...
> "Edward Reid" <edw...@paleoNOTTHIS.org.NOTTHIS> wrote in message
> news:1wc4xnsw6lng3$.oxfmmoy0emnh.dlg@40tude.net...
>> On Thu, 13 Nov 2008 06:52:58 -0800 (PST), HVlems wrote:
> [snip]
>> Yeah, the opinion I've often expressed is that Burroughs Algol is 80%
>> extensions. A lot of the extensions maintain the basic flavour of the
>> language -- for example, the block structure is fully intact. Passing
>> procedures as parameters works exactly as it should -- even the kind with
>> the parameters to the formal procedure unspecified, though I've always
>> written formal procedures using the extensions to specify the parameters.
> [snip]
>
> Hello! Roger Jefferyes here!! :-)
>
> After a year or two of getting to know the B6500/B6700 I went back to
> Glasgow to explain to my former colleagues what a wonderful machine it
> was.
> Many of them were horrified at the 'liberties' the implementers of
> Burrough
> Extended Algol 60 had taken with their pet language. They balked at
> various constructs. Bit manipulation. Character handling with pointers
> and
> array rows. The attributes stuff. The rules about everything being
> declared before it is used. E.G. The requirement for FORWARD
> declarations
> of mutually calling procedures. (This restriction is not in the Algol 60
> report.) And a number of other things.
>
> In fact when I landed up supporting Academic Branch I heard it called
> "Over-extended Algol" several times and found myself asking what our
> accusers would have done given the tasks the company faced. The conflict
> between 'purity' and 'practicality' was not often resolved to everyone's
> satisfaction! :-(
>
> Well! I seem to have rambled on far enough. What does everyone else
> think?
>
> With Regards,
>
> Roger Jefferyes
The purists' argument reminds me of the story of the child querying
her/his mom's method of cooking a roast. "Why do you cut off the ends before
putting it in the pan, Mom?"
"Gee, I don't really know," replied the mom, "I've just always done it
that way. I think it's because that's the way Grandma did it. Let's call her
and ask." <ring> "Mom, why do you cut off the ends of a roast before putting
it in the pan?"
"Oh, honey, that is just because the pan I received as a wedding gift
wasn't wide enough to hold the whole roast!"
:) <grin>
Thomas Schaefer
the size they are is due to the size of a horse's rear-end? The old
story about everything related to trains is the size it is because that
is the size the teams of horses were for the Romans. The ruts ended
being a certain size and everyone just kept the same thing throughout
history.
http://www.astrodigital.org/space/stshorse.html
Regards,
Tom Schaefer
Mike Hore
>
> Hello! Roger Jefferyes here!! :-)
>
> I left Glasgow University computing department to join Burroughs Machines
> Ltd during the Easter Holidays of 1970. We had an interesting machine in
> Glasgow called a KDF9. Interesting for (at least) two reasons.
Interesting! We must be about the same vintage :-)
I was at Sydney University in those days, and we, too, had a KDF9.
>
> Firstly it had hardware implementations of a return address stack and an
> arithmetic stack. So those of us who were bold enough to write 'Usercode'
> (the assembler language) were used to stack handling and what were the
> principles for writing fast running code. Also looking at the machine code
> resulting from compiling higher level languages showed how to write these
> other languages to best effect too.
Loved Usercode!!!!
>
> Secondly it was one of a number of machines that ran the Whetstone Algol 60
> compiler controller system. This implemented a version of Algol that was
> very close to the Algol 60 report. The report didn't define input/output
> constructs and a number of other things so these were added. The Whetstone
> controller interpreted pseudo op-codes inside a virtual machine very similar
> to the hardware of the Burroughs Large Systems. Many of the virtual
> registers were even called by the same names.
I think the Whetstone interpreter was based on Randall and Russell's
"Algol 60 Implementation" which used all those terms. I'm fairly sure
the B5000 developers (Bob Barton et al) were familiar with that.
Certainly by the time the B6500 was being developed.
I was almost offered a programming job in Pasadena in 1970 because I'd
been working on a subset PL/I compiler for the KDF9 and Burroughs wanted
to develop one. I think they withdrew the "almost offer" because of the
cost of relocating me from Australia, though I'm guessing. The reason
they gave related to office space and I didn't really buy that.
Anyway, thanks for the interesting post!
Cheers, Mike.
---------------------------------------------------------------
Mike Hore mike_h...@OVE.invalid.aapt.net.au
---------------------------------------------------------------
--
---------------------------------------------------------------
Mike Hore mike_h...@OVE.invalid.aapt.net.au
---------------------------------------------------------------