Unisys Beginner
Halldór Ísak Gylfason
Unisys Mainframe computers using terminals and screenscraping. I have
been searching the internet for any information, but there doesn't
seem to be much around. And since I only graduated like 3 years ago I
wasn't borned when some of these computers were built!
Anyway I need some stuff on how to communicate with Unisys MAinframes,
definitions of terms like PID numbers , SID/RID etc etc...
Any websites or books you know of that could help?
And by the way what is a PID number, is it a "Process ID", "Position
ID" or what. The way I understand it it uniquely identifies a
terminal, but then again the SID/RID/DID triplet is also supposed to
do that.
I am quite confused, and any help would be appreciated.
Best Regards, Halldor Isak Gylfason
Stephen Fuld
"Halldór Ísak Gylfason" <hgyl...@calidris.com> wrote in message
news:f1ef0aa1.03020...@posting.google.com...
> I am working for a software company that needs to interface with
> Unisys Mainframe computers using terminals and screenscraping. I have
> been searching the internet for any information, but there doesn't
> seem to be much around. And since I only graduated like 3 years ago I
> wasn't borned when some of these computers were built!
>
> Anyway I need some stuff on how to communicate with Unisys MAinframes,
> definitions of terms like PID numbers , SID/RID etc etc...
Others know far more about this than I do, but here is a start . . .
First of all, let us get straight that there are two totally different
Unisys mainframe lines. From your questions, you are talking about a 2200
Series or IX serries.
Now, you need to be more specific about what you are trying to do. If you
want to write software that emulates a terminal, you have a lot of work
ahead of you, and the protocols are not generally freely available. But if
you want to get information, you can use one of the available terminal
emulators with a scripting language interface to do most of the work for
you.
> Any websites or books you know of that could help?
Few. Most of the Unisys manuals are on line, but I don't think they will
help you much.
> And by the way what is a PID number, is it a "Process ID", "Position
> ID" or what. The way I understand it it uniquely identifies a
> terminal, but then again the SID/RID/DID triplet is also supposed to
> do that.
RID/SID/DID are hardware addresses for the terminal device. In the old
days, they were physically set in the terminals with jumpers. PID is
"pseudoID", which is a software "aggregate" of these that is used within the
software for convenience. It is sort of like the difference in the Ethernet
world between a MAC address (hardware set in the NIC) and a TCP/IP address
(used by the software).
> I am quite confused, and any help would be appreciated.
Hope that helps getting you started. As I said before, if you better define
what you need, others will be able to help you muich more.
--
- Stephen Fuld
e-mail address disguised to prevent spam
Hans Rutgers
> I am working for a software company that needs to interface with
> Unisys Mainframe computers using terminals and screenscraping.
> Anyway I need some stuff on how to communicate with Unisys MAinframes,
> definitions of terms like PID numbers , SID/RID etc etc...
There are many ways to communicate with unisys mainframes.
There is batch, online remote, and tip. There is also a nice operator
interface that communicates very well to the system.
> And by the way what is a PID number,
it is a number used by TIP and CMS to identify a "station".
>in the SID/RID/DID triplet is also supposed to do that.
it is a number used by EXEC / demand to identify a "station".
To capture a screen you could use a print command containing a
retransmit. This way a copy of the screen arrives in your working
storage. You have to use cursor position too. See escape commands.
Best Regards,
Hans
Halldór Ísak Gylfason
I am almost sure that I am talking about the 2200 Series (UNIVAC
right?). In anycase I will be communicating through the UTS protocol.
I will not be writing terminal emulation software, it will either be
provided to me, or you can get it at places like www.qw.com . Writing
terminal emulation software would be fun... but I'd like to do
something else this year!!
My interest is "theoretical" in the sense that I would like to know a
bit about the inner working and architecture of these machines. It's
not strictly needed for the company I am working for, it's just my
interest! I'd like to know about the protocols these guys talk, how
that can be mapped over TCP/IP, what network protocol is this machine
capable of speakings, and some low level stuff like the architecture
of the operating system. For example does the UNIVAC create an
individual process for each terminal, or not (in which case they must
solve the "stateful" conversation with the terminal otherwise). Is it
interrupt driven or polled.
I do not expect you to answer these questions (since you must have
better things to do ;) ), but if somebody could provide a reference to
an article, web page or something...
Best Regards
Halldor Isak Gylfason
Hans Rutgers
> Thanks for your answer.
>
> My interest is "theoretical" in the sense that I would like to know a
> bit about the inner working and architecture of these machines.
The 2200 is a 1960 machine with excellent hardware and software features
most of them still not available on a PC or server today.
Although most computers of today are inferior to
most of the mainframes of yesterday,
there is a difference...... the PRICE !
PC and server are around 1000 times less expensive....
> what network protocol is this machine
> capable of speaking, and some low level stuff like the architecture
> of the operating system.
The 2200 is capable of doing datacommunication through its CMI$ and CMO$
complex, since 1970 or so it uses a DCP to do that.
(datacommunication processor) On this DCP you can X21, X25, SNA, DCA TCP
and other protocols. It runs everything. Very allround.
> For example does the UNIVAC create an
> individual process for each terminal,
This depends on the term "process" which is probably an IBM term ?
Don't know what you are asking here.
It is a multitasking machine if that answers your question ?
>Is it interrupt driven or polled.
The terminals are polled and send line mode.
(not char by char)
> I do not expect you to answer these questions (since you must have
> better things to do ;)
There could be much said about it.
But it is enough for today :-)
greetings
hans
Halldór Ísak Gylfason
> Halldór Ísak Gylfason wrote:
> > Thanks for your answer.
> >
> > My interest is "theoretical" in the sense that I would like to know a
> > bit about the inner working and architecture of these machines.
> Why would you want to know a machine that is definitely legacy ?
> The 2200 is a 1960 machine with excellent hardware and software features
> most of them still not available on a PC or server today.
> >
I admit that it may sound pervertic to be interested in this ;)
> For example does the UNIVAC create an
> > individual process for each terminal,
> This depends on the term "process" which is probably an IBM term ?
> Don't know what you are asking here.
> It is a multitasking machine if that answers your question ?
I was meaning process in the Operating System term. Linux , Windows
and every modern operating system has the concept of a process,
virtual memory etc. I was just wondering how these machines handled
that.
For example when you create a TCP server socket, and you get an
incoming request, the traditional way is to spawn of a thread to
handle the incoming conversation. I was just wondering if the same
thing applied to the 2200 series
Hans Rutgers
> I admit that it may sound pervertic to be interested in this ;)
>
> I was meaning "process" in the Operating System term. Linux , Windows
> and every modern operating system has the concept of a process,
> virtual memory etc. I was just wondering how these machines handled
> that.
Well this might become a word game, but a process is probably
in 2200 terms an activity. Yes, it spawns of a thread.
Yes it is is multi tasking in the sense multithreading.
The 2200 term is multi-activity.
The OS consists of several basic parts, one of them is the Dispatcher,
which task it is to distribute cpu-time to the programs asking for it,
using a priority scheme.
But also within a program you can do this yourself (Forking), and run
parallel threads. Making yourself faster (and others slower).
I wonder what you mean with "modern operating system".
Are there old fashioned OS ? What defines an oldfashioned OS ?
And BTW you can't really call Windows a operating system my dear...
isn't it just DOS with a lot of window dressing ? :-))
>
> For example when you create a TCP server socket, and you get an
> incoming request, the traditional way is to spawn of a thread to
> handle the incoming conversation. I was just wondering if the same
> thing applied to the 2200 series
I guess theoretically the answer is yes. But in reality this kind of job
is taken care of by TELCON, the operating systen of the DCP.
These main frames are very large machines, in the sense that the cpu is
reserved to do main things only, delegating minor issues to
specialised hardware. IO handling e.g. is done by several dedicated IO
processors (handling IO-channels), datacommunication is delegated to the
DCP. All the protocols are handled there, by the DCP-cpu, and never
arrived at the main-cpu.
Virtual storage is another story.
bye
hans
Stephen Fuld
Hans is correct. You really have to "adjust" your thinking. All the
details of the communications protocol are totally hidden from the "main"
operating system. It talks to the "front end" computer (called, as Hans
said, a DCP (Data Communications Processor). The DCP has "slots" for
different interface cards and runs its own OS (Again, paraphrasing Hans)
called Telcon. By the time the user's input gets to the "main OS" called
the "2200 Operating System", or more colloquially the "Exec". (for
historical reasons) it is in a standardized form.
As for terminology, what is now commonly called a Process is called in Exec
terms a Task. What Exec calls an activity is pretty equivalent to what is
today commonly called a thread, but they are controlled by the OS, not a
"user thread library".
Now to try to drill down to your question, if you mean is there a separate
task for each terminal, the answer depends on whether you mean to do the
detailed terminal handling stuff or to run whatever the user wants to run
from the terminal (i.e. call a compiler, and applications program, a
transaction, etc.). If the second, then there is definitly a task for each
terminal. If the first, then there is not. The details of how the first is
handled has changed several times over the years, but these changes were
totally user transparent as the user sees only the characters sent from ther
terminal with all the protoccol stuff stripped off. How that stuff is
stripped off doesn't concern the user.
Mike
nothing else provides many ways of performing any task.)
RID/SID/DID
For Uniscope terminals and there successors RID (Remote Identifier -I
believe) and SID (Site Identifier - I believe) were used to physically
identify a terminal. Uniscopes had the RID and SID strapped via either
jumpers, or switches. Generally a RID identified a group (or cluster) of
terminals and a SID identified one terminal within the cluster. Terminal
multiplexors (T-Mux) were used to allow multiple terminals to use one
physical connection to the system. Hanging off a terminal multiplexor could
be either another T-Mux, Uniscope Terminals, or a combination.
DID (Device Identifier) was (and still is) used to identify a device
connected to a Uniscope terminal. Typical devices in the 1970's timeframe
were tape cassettes (@@TCO) and printers.
The UTS terminals, which replaced the Uniscope terminals, used the Uniscope
protocol, but the RID and SID were set via microcode. You could access and
change the RID/SID in the 'control page'. DID continued to be used for
device identifier with diskettes replacing tape cassettes and printers
living on.
Most CURRENT terminal emulators have done away with RID/SID and use a
protocol (int-1) that was developed for communications between the DCP
(Distributed Communications Processor) and CMS.
PID
PID (Positional Id) is defined in the Message Control Bank (MCB) manuals as
a logical terminal. PID is only used in the TIP (Transaction Interface
Package) environment. The Communications software (CMS, CMS 1100, CPComm,
...) is responsible for converting the PID to a physical location, whether
the physical location is RID/SID or TCP/IP address/port.
TELETYPE / TELNET
Talk of RID/SID/DID is centered on the Uniscope protocol. OS 2200 (a.k.a.,
EXEC, EXEC-8, OS 1100) also supported teletype protocol. Historically, the
major drawbacks to teletype were that there was an interupt for each
character received, only one terminal could connect per communications line,
and that OS 2200 did not support screen formatting (after all it was viewed
as a paper based device).
Remote Batch versus Demand versus TIP
Once you have gotten beyond having a terminal communicating with OS 2200,
there are different ways of using it.
Remote Batch
Although seldom used, Uniscope terminals (as well as teletypes) could be
used to submit batch runs. Even the current terminal emulators will submit
a batch run. A batch run is indicated by using the B option on the @RUN
card. For example:
Enter your user-id/password and clearance level:
*UNISYS 1100 Operating System Level 46R4-002 (RSI)*
Current session number: 797
Previous session was: 03 Feb 12 22:38:38
@run,/b m,0,a
*BATCH RUN MODE-ENTER RUN STREAM*
Note: The userid must be configured to allow the user to submit their own
run card.
Demand
Demand is similar to a Telnet session into a Unix box. It is also similar
to a batch run with the input (READ$ - standard input) coming from the
keyboard/messages sent, and output (PRINT$ - standard output) being directed
to the screen. Anything you can do in a batch run you can do in demand.
With the exception of screen formating, anything you can do in demand you
can do in batch.
TIP
TIP is essentially a stateless processing. Each input is a discrete unit of
processing.
TIP Session Control, which is seldom used, casts a logon/logoff over a
series of TIP transactions. The TIP logon establishes accounts and security
information which is persisted. Containers to persist this information are
configured as part of enabling TIP session control.
Several methods of establishing some form of state were developed (e.g.,
passoff, conversational mode, DPS logon, DPS scratch area, etc.).
And more options HVTIP, HVTIP-II
Given your mention of PID, I would assume that you are running in a TIP
environment. If this is correct, I would recommend looking at Chapter 1 of
"OS 2200 Transaction Processing Conceptual Overview".
Best Regards,
Mike Baker (email address mangled to reduce the spam)
"Halldór Ísak Gylfason" <hgyl...@calidris.com> wrote in message
news:f1ef0aa1.03020...@posting.google.com...
Halldór Ísak Gylfason
Halldor
Colin Zealley
I think the question you originally asked was based on the principle that in
most Unix applications, each open user session holds a process open in the
main cpu.
This is true on OS2200 for "Demand" sessions, which are the developer
interface, and are roughly equivalent to using a Unix command shell or a DOS
window under Windows; but on OS2200, Transaction processing is a completely
different thing, and a fresh activity ("process" to you) is normally opned
for each message as it comes in, then closed again when its processing is
complete. And various other bits of the OS and supporting software take care
of maintaining session continuity so that the transaction user sees what
appears to be a single continuous process.
In fact, it's rather like an internally-managed client/server mechanism. The
net result is that the total number of "active" users is pretty much
irrelevant to machine load; it's simply the number of transactions per
second that counts, not who's submitting them.
Finally, guys - surely talk of the DCP is a bit outdated? I thought most TCP
traffic was handled by Ethernet Channel Adapters nowadays. No doubt there's
still a certain amount of intelligence between that and the 2200 cpu, but
nothing as heavy-duty as a DCP any more. Note - although I'm a Unisys (and
ex-Sperry) employee, I'm a bit out of touch with OS2200, so this latter is
personal opinion, not authoritative info.
"Stephen Fuld" <s.f...@PleaseRemove.att.net> wrote in message
news:vtv2a.49098$zF6.3...@bgtnsc04-news.ops.worldnet.att.net...
Jim McMahon
<snip>
>Finally, guys - surely talk of the DCP is a bit outdated? I thought most TCP
>traffic was handled by Ethernet Channel Adapters nowadays. No doubt there's
>still a certain amount of intelligence between that and the 2200 cpu, but
>nothing as heavy-duty as a DCP any more. Note - although I'm a Unisys (and
>ex-Sperry) employee, I'm a bit out of touch with OS2200, so this latter is
>personal opinion, not authoritative info.
<snip>
I don't work on Unisys anymore, but two years ago the site I left was
still using DCPs connected to an IX series (2200) having just upgraded
from an old OS1100 connected to both DCP and GCS cabinets. The
equipment might be old, but it sure seemed to work well.
Being ordinary and nothing special is a full-time job.
jp_mc...@hotmail.com (Jim McMahon in real life)
Halldór Ísak Gylfason
that every computer science student should be taught the history of
computer science. Otherwise we'll just end up with graduates that
think that .NET was the beginning (and probably the end) of
everything.
For instance when I was being taught Object Oriented Design with UML,
I got the feeling that this was the first attempt to do some design of
computer programs. That is very very far from the truth since
procedural design methodologies have been around for many decades,
supporting encapsulation and most of the things that object oriented
methodologies incorporate.
Or as one of my collegue put it: "We should reject every new
methodology unless it is a refinement of existing methodology". Maybe
a bit harsh, but has got some truth in it.
Anyway... One question: Does there exist a "Software Emulation" of
unisys mainframes. Maybe this is a stupid question, but I'm not sure
that I can afford to buy such computer myself, to be able to play with
it.
Stephen Fuld
> All this has made more interested in these "old" computers. I think
> that every computer science student should be taught the history of
> computer science. Otherwise we'll just end up with graduates that
> think that .NET was the beginning (and probably the end) of
> everything.
Absolutely! And there is even an economic advantage as much time is spent
today "re-inventing" what has already been done, its advantages and
disadvantages probed and documented, but ignored or unknown by the current
generation.
> For instance when I was being taught Object Oriented Design with UML,
> I got the feeling that this was the first attempt to do some design of
> computer programs. That is very very far from the truth since
> procedural design methodologies have been around for many decades,
> supporting encapsulation and most of the things that object oriented
> methodologies incorporate.
Yup.
> Or as one of my collegue put it: "We should reject every new
> methodology unless it is a refinement of existing methodology". Maybe
> a bit harsh, but has got some truth in it.
>
> Anyway... One question: Does there exist a "Software Emulation" of
> unisys mainframes. Maybe this is a stupid question, but I'm not sure
> that I can afford to buy such computer myself, to be able to play with
> it.
Since you were talking about the 2200 series, I think that the answer is no.
There is a software emulator for the other Unisys mainframe line, but it is
completely different from the 2200 series, with its own set of advantages,
disadvantages, features and quirks. There at least used to be some
universities with 2200 series systems where you might be able to take a
course or two. Other than that, I guess the only thing is to try to get a
job with a 2200 series site, or with Unisys itself.
Marc Wilson
Fuld) wrote in
<qMc1a.39644$zF6.2...@bgtnsc04-news.ops.worldnet.att.net>::
|> And by the way what is a PID number, is it a "Process ID", "Position
|> ID" or what. The way I understand it it uniquely identifies a
|> terminal, but then again the SID/RID/DID triplet is also supposed to
|> do that.
|
|RID/SID/DID are hardware addresses for the terminal device. In the old
|days, they were physically set in the terminals with jumpers. PID is
|"pseudoID", which is a software "aggregate" of these that is used within the
|software for convenience. It is sort of like the difference in the Ethernet
|world between a MAC address (hardware set in the NIC) and a TCP/IP address
|(used by the software).
"PID" in the 2200 world is an arbitrary number that acts as index into a
table- the table contains info that determines whether that PID is active
and which CMS "owns" it. I always thought is was "Position ID", BICBW.
Lots of years since I did CMS/Exec internals.
--
Marc Wilson
___________________________________________________________________
Cleopatra Consultants Limited - IT Consultants - CoolICE Partner - MAPPER Associate
Tel: (44/0) 70-500-15051 Fax: (44/0) 870-164-0054
Mail: in...@cleopatra.co.uk Web: http://www.cleo-net.co.uk
___________________________________________________________________
MAPPER User Group mailing list: send *SUBSCRIBE to M...@cleopatra.co.uk
Marc Wilson
Rutgers) wrote in <3e4976a6$0$23901$8fcf...@news.wanadoo.nl>::
| > For example does the UNIVAC create an
|> individual process for each terminal,
|This depends on the term "process" which is probably an IBM term ?
"Activity" would be the Unisys equivalent. Similar, but not quite the same.
|Don't know what you are asking here.
|It is a multitasking machine if that answers your question ?
There are a number of activities within the communications processing, but
there is not one per terminal- it's a queue-driven multi-activity process.
There is more than one program involved in getting data to and from display
devices.
Marc Wilson
Zealley) wrote in <b2gars$b72$1...@si05.rsvl.unisys.com>::
|Finally, guys - surely talk of the DCP is a bit outdated? I thought most TCP
|traffic was handled by Ethernet Channel Adapters nowadays. No doubt there's
|still a certain amount of intelligence between that and the 2200 cpu, but
|nothing as heavy-duty as a DCP any more.
HCAs (Host Channel Adaptors) talk to the mainframe one side and TCP/IP the
other (though the client software still talks the old Sperry INT1 protocols
via InfoConnect, it's "tunnelled" through TCP).
Marc Wilson
|And BTW you can't really call Windows a operating system my dear...
|isn't it just DOS with a lot of window dressing ? :-))
Unless it's Windows NT/2000/XP, in which case it has more in common with
VMS. :)
Marc Wilson
|The 2200 is capable of doing datacommunication through its CMI$ and CMO$
|complex, since 1970 or so it uses a DCP to do that.
|(datacommunication processor)
"Distributed Communications Processor", IIRC, later known as FEP ("Front End
Processor").
Marc Wilson
|> Anyway... One question: Does there exist a "Software Emulation" of
|> unisys mainframes. Maybe this is a stupid question, but I'm not sure
|> that I can afford to buy such computer myself, to be able to play with
|> it.
|
|Since you were talking about the 2200 series, I think that the answer is no.
|There is a software emulator for the other Unisys mainframe line, but it is
|completely different from the 2200 series, with its own set of advantages,
|disadvantages, features and quirks. There at least used to be some
|universities with 2200 series systems where you might be able to take a
|course or two. Other than that, I guess the only thing is to try to get a
|job with a 2200 series site, or with Unisys itself.
There was talk of a "2200 on a laptop", but so far, nothing seems to have
come of it. I'd like to have one of those!
Hans Rutgers
> Otherwise we'll just end up with graduates that
> think that .NET was the beginning (and probably the end) of
> everything.
and the norm of everything.
===============================================quote of Churchill:
"This is not the end, it's not even the beginning of the end,
it's only the end of the beginning."
=====================================================================
> For instance when I was being taught Object Oriented Design with UML,
> I got the feeling that this was the first attempt to do some design of
> computer programs.
Very funny you say that, because I am actually reading a book on UML.
My toes curl, since it's all new terms for very old concepts.
The question is, is this an improvement ? Could be. Think not.
It is possibly just an bookpublisher inventing a new market.
In fact this is not the first this happens.
When mainframes were "out" and UNIX became the norm, and we got
client/server and alike, the whole thing was in fact reinvented
instead of learning from the mainframes.
Strangely enough, excellent old solutions like @Secure rollout /
rollback did not make it widely in this field or on the PC.
(This is a program that saved automatically on tape or another medium
depending on file-use count and some other file-usage attributes)
Other examples are main frame stability, reliability and guard mode, and
so on.
> Or as one of my collegue put it: "We should reject every new
> methodology unless it is a refinement of existing methodology". Maybe
> a bit harsh, but has got some truth in it.
That has never been the case, unfortunately.
The best example to this is computer languages.
The first requirement would be compatibility, right ?
But no language is, algol, modula, cobol, fortran, ... java, pascal,
ada, and so on, none of them are intercompatible.
And only offering a new aspect to the language. There is no integration
growing. On the contrary universities thrive at reinventing another
"new" language, which is the reason there still isn't a standard
programming language.
The fact that people want to reinvent and not learn from others has a
name : it is called a GENERATION CONFLICT....
> Anyway... One question: Does there exist a "Software Emulation" of
> unisys mainframes. Maybe this is a stupid question, but I'm not sure
> that I can afford to buy such computer myself, to be able to play with
> it.
Well, there is a program that simulates the 2200, @Flit does that, it's
the online debugger, it runs on a 2200 :-) Of course this does not help
you. It is not so complicated to write a simulator, just around 100 cpu
instructions should do, but what code do you want to run ? And what
about the enormous amount of available libraries ?
It is not just a different instruction set, a mainframe is a whole
different scale of thinking and processing. (I am not saying better)
Probably this is because it is a true multi-user system in a
multi-environment. Mainframes simply have more dimensions than the
average "modern" operating system :-)
regards
hans
Hans Rutgers
> There was talk of a "2200 on a laptop", but so far, nothing seems to have
> come of it. I'd like to have one of those!
I remember talk of Mapper on a laptop, I even saw a demo (in 1980?)
What happened to Mapper on a laptop ? (Mapper5 I believe)
hans
Stephen Fuld
snip
> Strangely enough, excellent old solutions like @Secure rollout /
> rollback did not make it widely in this field or on the PC.
> (This is a program that saved automatically on tape or another medium
> depending on file-use count and some other file-usage attributes)
But it has been rediscovered in the guise of the mane Hierarchical Storage
Manager programs now available.
> Other examples are main frame stability, reliability and guard mode, and
> so on.
Stability and reliability take time to develop. The newer OSs are getting
there, but still have a ways to go. As for guard mode, except for Win 9X
(and ME) AFAIK, all systems have it. On Windows NT and above (including
XP), pretty much the exact equivalent of a guard mode error is a general
protection fault.
> > Or as one of my collegue put it: "We should reject every new
> > methodology unless it is a refinement of existing methodology". Maybe
> > a bit harsh, but has got some truth in it.
> That has never been the case, unfortunately.
> The best example to this is computer languages.
> The first requirement would be compatibility, right ?
No. See below.
> But no language is, algol, modula, cobol, fortran, ... java, pascal,
> ada, and so on, none of them are intercompatible.
> And only offering a new aspect to the language. There is no integration
> growing. On the contrary universities thrive at reinventing another
> "new" language, which is the reason there still isn't a standard
> programming language.
Stating that university's love for creating new languages is the cause of
the lack of a single standard language is simply bunk. Multiple languages
exist because they are better (or at least try to be) at solving a certain
type of problem. Many languages are developed to at least explore new
programming paradigms. For example, Algol was the "new" language that
introduced block structuing which eased program development, etc. Prolog is
a "new" language that was developed to solve certain types of AI problems.
Several languages were developed to implemenmt object orientation. Similar
larguments can be made for most new languages. There are lots of examples
of this. There are multiple different programming languages for the same
reason that a carpenter's tool box contains both hammers and saws.
Different tools are better adapted to different uses.
As a contrary example to your thesis, I cite PL/1, which was expliticly
designed to combine the featues of COBOL and Fortran (and add a few new
things). The result was a large, ungainly language that was hard to
compile, hard to generate efficient code for, and not wildly popular. This
is perhaps, to stretch the previous analogy, like some sort of "all-in-one"
tool that tries to do everything, but as a result does nothing as well as
the dedicated purpose tools.
Saying that universities should not research new language paradigms is sort
of like saying that they shouldn't research new bridge designs because we
have the stone arch, which has served us since Roman times, so who needs
anything else.
Marc Wilson
I'm running MAPPER on the laptop that I'm using to post this item! But it's
not 2200 MAPPER, it's the NT variant of MAPPER-C (in fact, it's CoolICE, but
what the heck).
And that's the expensive way to do it; there's a MAPPER for Windows AKA
Personal MAPPER that's quite a lot cheaper.
There were various attempts at a personal MAPPER:
- MAPPER 5 was a small "departmental" MAPPER system that was basically a PC
with a card in- all the real smarts were on the card.
- Personal MAPPER was the card without the PC; you installed it in a PC, and
it basically used the PC as a console and for disc space: it had its own
CPU, RAM and ROM on the card.
- MAPPER for Windows was/is a software only solution, a cut-down version of
the MAPPER-C system.
- And now we have MAPPER for NT and CoolICE, both of which run on
NT/Win2K/XP. There's talk of the two products being rationalised into a
single product stream.
Hans Rutgers
> - And now we have MAPPER for NT and CoolICE, both of which run on
> NT/Win2K/XP. There's talk of the two products being rationalised into a
> single product stream.
interesting, Marc !
I completely lost track of Mapper since I left Unisys.
Beautiful product, I still remember the culture shock it gave :-)
(because it supposedly attacked tip/cms/dms)
hans
Marc Wilson
Um. That's an interesting viewpoint :)
Horses for courses- you wouldn't (or at least shouldn't) do the sort of
high-volume transaction processing in MAPPER that TIP[1] was designed for.
Though a lot of systems were created that should not have been, partly
because Sperry rather oversold MAPPER as the answer to the applications
backlog- it's rather better positioned now, as a "Business Information
Server". I reckon they should call the proposed merged product "Result!";
it's much snappier than the "essay-style" names that are current, it gives a
clue about what it does, it's positive and ... contains a nice in-joke for
the techies.
The abilities of the new platform are quite exciting- we've recently
implemented a CoolICE Web Service for a client, using SOAP, .NET, C# and XML
so that a remote system can seamlessly interact with a CoolICE server.
We've also created applications where CoolICE systems talk to remote systems
over a socket interface or a named pipe.
[1]Anyway, MAPPER (2200) is a TIP/CMS application!
Keith Stone
> Strangely enough, excellent old solutions like @Secure rollout /
> rollback did not make it widely in this field or on the PC.
> (This is a program that saved automatically on tape or another medium
> depending on file-use count and some other file-usage attributes)
Funny thing about that, I was just configuring a Win2K server
yesterday and noticed the "new" feature; the ability to store
infrequently accessed files on tape! ;-)
Hans Rutgers
- you wouldn't (or at least shouldn't) do the sort of
Well, when it came out, we didn't know.
And it was not tip/cms back then but stand alone.
it came out as a real time application (dispatcher TAL 2).
so taking priority over everything else.
They changed all that later, because Mapper blocked the entire system.
It was indeed rather silly to run backoffice reports at real time TAL.
The good old days !!
Speaking of which: I always admired @SSG. Do you agree with me that XML
is doing about the same thing? The rest of the world finally caught up!
Bye for now
hans
Colin Zealley
[snip]
> The good old days !!
>
> Speaking of which: I always admired @SSG. Do you agree with me that XML
> is doing about the same thing? The rest of the world finally caught up!
>
principle to the rules for SGS statements, yes, Hans.
My own favourite thing about SSG is that I believe Symstream may well have
been the world's first GOTO-less language. I know SSG was around when I
first saw Exec 8, in 1969 or thereabouts.
Colin
Marc Wilson
|Marc Wilson wrote:>
|- you wouldn't (or at least shouldn't) do the sort of
|> high-volume transaction processing in MAPPER that TIP was designed for.
|
|Well, when it came out, we didn't know.
|And it was not tip/cms back then but stand alone.
|it came out as a real time application (dispatcher TAL 2).
|so taking priority over everything else.
Oh yeah, I remember! I have worked on MAPPER for as long as it has been a
released product. But as soon as it was possible, I moved it to running at
high TIP and via CMS. It's amazing how many sites I visited that hadn't
made the change: it was like magic to some folks, how much better their
systems got, with little impact on MAPPER.
|
|They changed all that later, because Mapper blocked the entire system.
|It was indeed rather silly to run backoffice reports at real time TAL.
Or even high TIP! Back office stuff belongs in the lowest TIP level or even
batch.
|The good old days !!
|
|Speaking of which: I always admired @SSG. Do you agree with me that XML
|is doing about the same thing? The rest of the world finally caught up!
Well- a bit. @SSG is a peculiar beast: it's very powerful, especially for
maintaining/integrating codebases, but I'm not convinced it does the same
job as XML, though I can see the philosophical similarities (e.g. the coarse
ordering of inputs is generally not relevant).
XML goes a little further in the abstraction stakes though.
Tom
Small corrections below...
In article <5g305v8j8hp1hh4ak...@4ax.com>, ma...@cleopatra.co.uk
(Marc Wilson) wrote:
>In comp.sys.unisys, Hans Rutgers <hans.r...@consultant.com> (Hans
>Rutgers) wrote in <3e4f7ef3$0$23906$8fcf...@news.wanadoo.nl>::
>
>|Marc Wilson wrote:
>|
>|> There was talk of a "2200 on a laptop", but so far, nothing seems to have
>|> come of it. I'd like to have one of those!
>|
>|I remember talk of Mapper on a laptop, I even saw a demo (in 1980?)
>|What happened to Mapper on a laptop ? (Mapper5 I believe)
>
>I'm running MAPPER on the laptop that I'm using to post this item! But it's
>not 2200 MAPPER, it's the NT variant of MAPPER-C (in fact, it's CoolICE, but
>what the heck).
>
>And that's the expensive way to do it; there's a MAPPER for Windows AKA
>Personal MAPPER that's quite a lot cheaper.
>
>There were various attempts at a personal MAPPER:
>
>- MAPPER 5 was a small "departmental" MAPPER system that was basically a PC
>with a card in- all the real smarts were on the card.
>
MAPPER 5 ran "native" on a Motorola 68020 processor ... Uniscope terminals.
>- Personal MAPPER was the card without the PC; you installed it in a PC, and
>it basically used the PC as a console and for disc space: it had its own
>CPU, RAM and ROM on the card.
Personal MAPPER was a PC with a "MAPPER card" inserted. The MAPPER card was a
Motorola 68??? (020?) with its own memory. It looked like a memory card to
the PC. MAPPER PC ran a derivative of the MAPPER 5 software "native" on the
Motorola chip. The PC did I/O and communications.
>
>- MAPPER for Windows was/is a software only solution, a cut-down version of
>the MAPPER-C system.
>
>- And now we have MAPPER for NT and CoolICE, both of which run on
>NT/Win2K/XP. There's talk of the two products being rationalised into a
>single product stream.
Cheers,
Tom Sherren
Tom
I should have been more explicit about MAPPER 5...
It ran on a Motorol 68020 box, not on a PC.
Tom
Marc Wilson
in <6bbad151.03021...@posting.google.com>::
Well, as Win2K crawls slowly towards being a "mainframe"[1] OS, you'd expect
these "new" technologies to appear.
[1] Or should that be "Enterprise Server"?
Halldór Ísak Gylfason
I think most people have realized that we will not ever get "The
Programming Language". There have been attempts to it, which usually
end up in overly complex languages (like PL or RPG right?). I actually
tend to think that C++ suffers from this.
Stephen Fuld
"Halldór Ísak Gylfason" <hgyl...@calidris.com> wrote in message
news:f1ef0aa1.03021...@posting.google.com...
>
> I think most people have realized that we will not ever get "The
> Programming Language". There have been attempts to it, which usually
> end up in overly complex languages (like PL or RPG right?).
I assume you meant Pl/1 and yes for that one as it was initially designed to
be all things to all people. RPG suffered from another problem. Originally
it was purely a report generator (RPG stands for Report Generator Program,
after all), but later it got extended with all kinds of additional
capabilites (I think to a large extent by the System/3 folks at IBM
Rochester). These additiona made the language more powerfull, but at the
expense of ading things to the design in a non-intuitive way in order to add
them in a backwards compatible way when they were never envisioned in the
original design. This had been repeated - see below :-)
> I actually
> tend to think that C++ suffers from this.
I think C++ (also called C double cross) is another prime example of
extending a language in ways that were never envisioned by the original
designers and ending up more functionality, but also with a complicated,
syntactically ugly mess. I think there is some ratio of special characters
to alphanumerics that should not be exceeded in order for a language to be
reasonably readable. C++ has significantly exceeded that ratio. And don't
get me started about APL!
Marc Wilson
<b2r8ni$1gpd$1...@si05.rsvl.unisys.com>::
|Personal MAPPER was a PC with a "MAPPER card" inserted. The MAPPER card was a
|Motorola 68??? (020?) with its own memory. It looked like a memory card to
|the PC. MAPPER PC ran a derivative of the MAPPER 5 software "native" on the
|Motorola chip. The PC did I/O and communications.
IIRC, it had its own OS, called "MUS" or something similar.
Tom
>
<snip>
> ... And don't get me started about APL!
>
Heck, its all Greek to me!
(sorry)
Tom
Tom
>In comp.sys.unisys, So...@No.Spam.I.Am (Tom) (Tom) wrote in
><b2r8ni$1gpd$1...@si05.rsvl.unisys.com>::
>
>|Personal MAPPER was a PC with a "MAPPER card" inserted. The MAPPER card was a
>
>|Motorola 68??? (020?) with its own memory. It looked like a memory card to
>|the PC. MAPPER PC ran a derivative of the MAPPER 5 software "native" on the
>|Motorola chip. The PC did I/O and communications.
>
>IIRC, it had its own OS, called "MUS" or something similar.
M.U.S.S. Manchester (U.K.) University Software System.
Programming language was M.U.S.L. => Manchester University Systems Language.
The other candidate software platform was some funky thing from AT&T called
"Unix" which had a programming language called "C".
Cheers,
Tom Sherren
Marc Wilson
|In article <cgp25v47nebrbu5gj...@4ax.com>, ma...@cleopatra.co.uk (Marc Wilson) wrote:
|>In comp.sys.unisys, So...@No.Spam.I.Am (Tom) (Tom) wrote in
|><b2r8ni$1gpd$1...@si05.rsvl.unisys.com>::
|>
|>|Personal MAPPER was a PC with a "MAPPER card" inserted. The MAPPER card was a
|>
|>|Motorola 68??? (020?) with its own memory. It looked like a memory card to
|>|the PC. MAPPER PC ran a derivative of the MAPPER 5 software "native" on the
|>|Motorola chip. The PC did I/O and communications.
|>
|>IIRC, it had its own OS, called "MUS" or something similar.
|
|M.U.S.S. Manchester (U.K.) University Software System.
OK- never saw it written down, just spoken. Memory better than I thought!
I always assumed the M was related to M68000 processor, somehow. Never knew
Manchester was involved.
|
|Programming language was M.U.S.L. => Manchester University Systems Language.
Pronounced "muscle", I guess?
|The other candidate software platform was some funky thing from AT&T called
|"Unix" which had a programming language called "C".
Naw, it'll never catch on.
Tom
>In comp.sys.unisys, So...@No.Spam.I.Am (Tom) (Tom) wrote in
><b2tv5j$9fd$1...@si05.rsvl.unisys.com>::
>
>|In article <cgp25v47nebrbu5gj...@4ax.com>, ma...@cleopatra.co.uk
> (Marc Wilson) wrote:
>|>In comp.sys.unisys, So...@No.Spam.I.Am (Tom) (Tom) wrote in
>|><b2r8ni$1gpd$1...@si05.rsvl.unisys.com>::
<snip>
>|
>|Programming language was M.U.S.L. => Manchester University Systems Language.
>
>Pronounced "muscle", I guess?
Yep! "MUSL Programmer" certainly *sounds* impressive...
>
>|The other candidate software platform was some funky thing from AT&T called
>|"Unix" which had a programming language called "C".
>
>Naw, it'll never catch on.
Just another techno-fad.
Tom Sherren
Colin Zealley
"mainframe" again - the world has finally noticed that mainframes have this
interesting habit of being quite powerful, and not falling over all that
often, and not needing as much admin to keep them going (well, that one may
be slightly dubious where IBM's concerned, but let's not split hairs).
Colin
"Marc Wilson" <ma...@cleopatra.co.uk> wrote in message
news:dg725vobn7qaefhe7...@4ax.com...
[snip for brevity]
Colin Zealley
I have this personal belief that the creator of c-double-cross should be
taken out and nailed up by his Sjokstrups.
As far as I can see(++), c++ is rather a good way of making a c programmer
comparatively productive in an OO environment quickly; but as a "pure" OO
language, it sucks.
Still, that's the way the cookie crumbles. Even Java, in my opinion, has
rather too much obvious c heritage about it.
TTFN
Colin
"Stephen Fuld" <s.f...@PleaseRemove.att.net> wrote in message
news:8dc4a.39896$rq4.3...@bgtnsc05-news.ops.worldnet.att.net...
[snip for brevity]
Eugene Miya
In article <gLQ3a.55854$zF6.3...@bgtnsc04-news.ops.worldnet.att.net>,
Stephen Fuld <s.f...@PleaseRemove.att.net> wrote:
>"Hans Rutgers" <hans.r...@consultant.com> wrote in message
>news:3e4f7d63$0$23906$8fcf...@news.wanadoo.nl...
>> That has never been the case, unfortunately.
>> The best example to this is computer languages.
>> The first requirement would be compatibility, right ?
>
>No. See below.
I have to agree to a point.
Cray's earlier machines were incompatible from his time in Univac thru
CDC and even earli CRI.
>> On the contrary universities thrive at reinventing another
>> "new" language, which is the reason there still isn't a standard
>> programming language.
>
>Stating that university's love for creating new languages is the cause of
>the lack of a single standard language is simply bunk.
...
>As a contrary example to your thesis, I cite PL/1, which was expliticly
>designed to combine the featues of COBOL and Fortran (and add a few new
>things). The result was a large, ungainly language that was hard to
>compile, hard to generate efficient code for, and not wildly popular. This
>is perhaps, to stretch the previous analogy, like some sort of "all-in-one"
>tool that tries to do everything, but as a result does nothing as well as
>the dedicated purpose tools.
All-in-one was a DEC product. ;^)
I started in an IBM environment before working on an 1108 (with some
inbetween CDC time). I did learn COBOL, too. There was a cute cartoon
drawn some where and used in a programming languages class I had a few
years later when in grad school. The cartoon was a living room with a
husband (Fortran) and wife (COBOL) looking at their baby (PL/1) with the
milk man (ALGOL) visible thru a picture window.
IBM's intent with PL/1 was never to teach/learn the entire language.
The idea was to learn enough that you would work and not need to know
the whole language. Not to say that it worked. It did span other languages.
This just illustrates that it's a good idea to do something "right" the
first time because change will come hard later. This was also one of
the reasons why smaller languages, libaries, and different partitionings
of machine labor became successful. Ada and the realization that
support environments became more popular, which is why the whole Unix
tools philosohy became important.
And there are whole other paradigms: LISP, Smalltalk, and others which
don't emphasize statically programmed languages.
A reasonably written (not perfect) but hard to find document (may now be
scanned) was the Rationale for the Design of Ada to get into the
thinking of PL designers (speaking as a person who once sat on an ANSI
committee).
Louis Krupp
> A reasonably written (not perfect) but hard to find document (may now be
> scanned) was the Rationale for the Design of Ada to get into the
> thinking of PL designers (speaking as a person who once sat on an ANSI
> committee).
A Google search for 'rationale design ada' (just the words, no quotes)
turned up:
http://archive.adaic.com/standards/83rat/html/Welcome.html
http://www.silicon-press.com/books/isbn.0-9615336-5-X
http://www.informatik.uni-stuttgart.de/ifi/ps/ada-software/html/language_def.html
Louis Krupp
Lueko Willms
schrieb eug...@cse.ucsc.edu (Eugene Miya)
auf /COMP/SYS/UNISYS
in 3e53d143$1...@news.ucsc.edu
ueber Re: Unisys Beginner / generation conflict
EM> A reasonably written (not perfect) but hard to find document (may now
EM> be scanned) was the Rationale for the Design of Ada to get into the
EM> thinking of PL designers (speaking as a person who once sat on an
EM> ANSI committee).
I happen to have that document in my shelves: SIGPLAN Notices, Vo. 14,
No. 6, June 1979, Part B (Part A is the "Preliminary ADA Reference
Manual").
But what relationship to you see to PL/1?
BTW, Sperry had a similar undertaking with PLUS; must have been very
similar to PL/1, isn't it?
Yours,
Lüko Willms http://www.mlwerke.de
/--------- L.WI...@jpberlin.de -- Alle Rechte vorbehalten --
"Es sind nicht die Generäle und Könige, die die Geschichte machen,
sondern die breiten Massen des Volkes" - Nelson Mandela
David W. Schroth
> Am 19.02.03
> schrieb eug...@cse.ucsc.edu (Eugene Miya)
> auf /COMP/SYS/UNISYS
> in 3e53d143$1...@news.ucsc.edu
> ueber Re: Unisys Beginner / generation conflict
>
> EM> A reasonably written (not perfect) but hard to find document (may now
> EM> be scanned) was the Rationale for the Design of Ada to get into the
> EM> thinking of PL designers (speaking as a person who once sat on an
> EM> ANSI committee).
>
> I happen to have that document in my shelves: SIGPLAN Notices, Vo. 14,
> No. 6, June 1979, Part B (Part A is the "Preliminary ADA Reference
> Manual").
>
> But what relationship to you see to PL/1?
I think the PL designers is referring to Programming Language designers...
>
> BTW, Sperry had a similar undertaking with PLUS; must have been very
> similar to PL/1, isn't it?
PLUS is, as best I recall, descended from JOVIAL. I don't think it
looks very much like PL/I. I may be mistaken in this, of course...
Regards,
David W. Schroth
Donald Gregory
take a look at Unisys' Extended ALGOL. The Unisys ALGOL is an
example of how to build a masterpiece from a starting point in
an orderly fashion. There are warts (like the semantics of the
STRING type), but overall it is a design and an example that has
yet to be beat.
I use both C++ and ALGOL and find I can get my work done with either
one. When it comes to elegance, Unisys ALGOL is definitely superior
(and safer).
A C++ programmer might find it interesting how Unisys has started
to implement OO-like constructs in their ALGOL. Hopefully we'll
see some more down the road, since Structure Blocks provide only
the bare beginning. But it's a start.
Regards,
Don
--
--------------------------------------
Donald J. Gregory
Gregory Publishing Company, Inc.
See our A-Series Documentation Library
at: www.gregpub.com
E-Mail: don...@gregpub.com
---------------------------------------
Stephen Fuld
news:b313cf$2ent$1...@si05.rsvl.unisys.com...
> Lueko Willms wrote:
snip
> > BTW, Sperry had a similar undertaking with PLUS; must have been very
> > similar to PL/1, isn't it?
>
> PLUS is, as best I recall, descended from JOVIAL. I don't think it
> looks very much like PL/I. I may be mistaken in this, of course...
You are very much correct. PLUS (originally an acronym of Programming
Language for Univac Systems) was derived from JOVIAL (which is an acronym
for Jules Own Version of the International Algorithmic Language - named for
Jules Schwartz). If course, the IAL (International Algorithmic Language)
that Jules made his own version of, was Algol. So PLUS is an enhancement of
a language that was an enhancement of Algol. At the time, Univac's stated
reason for making up their own language and not choosing a standard one was
to be expliticly free to extend it however they wanted without any
constraints of beinng standards compliant, etc.
Marc Wilson
Schroth) wrote in <b313cf$2ent$1...@si05.rsvl.unisys.com>::
|>
|> BTW, Sperry had a similar undertaking with PLUS; must have been very
|> similar to PL/1, isn't it?
|
|PLUS is, as best I recall, descended from JOVIAL. I don't think it
|looks very much like PL/I. I may be mistaken in this, of course...
More like Pascal.
Hans Rutgers
>>PLUS is, as best I recall, descended from JOVIAL. I don't think it
>>looks very much like PL/I. I may be mistaken in this, of course...
>
>
> You are very much correct. PLUS (originally an acronym of Programming
> Language for Univac Systems) was derived from JOVIAL (which is an acronym
> for Jules Own Version of the International Algorithmic Language - named for
> Jules Schwartz). If course, the IAL (International Algorithmic Language)
> that Jules made his own version of, was Algol.
How interesting. I thought it was some old language. When I
joined Sperry (1973) some old book of JOVIAL was lying
around in the library.
As far as I remember, I thought it meant
"Jensons Own Version of Interpreted ALgol"
an early interactive Algol, by some norwegian professor...
But may be I remember wrongly?
Anyway we had interactive BASIC in those days and later
@CTS, so I never really looked at the product.
hans
---------------------------------------
there's never time to do it right,
there's always to do it over. Murphy.
Edward Reid
> As far as I remember, I thought it meant
> "Jensons Own Version of Interpreted ALgol"
> an early interactive Algol, by some norwegian professor...
>
> But may be I remember wrongly?
I wasn't personally involved, but the expansion given by Stephen --
Jules' Own Version of the International Algorithmic Language -- is the
one cited by all references and is generally accepted. JOVIAL was
influential enough that it's mentioned in every book on the history of
programming languages.
Edward
Eugene Miya
David W. Schroth <David....@unisys.com> wrote:
>Lueko Willms wrote:
>> schrieb eug...@cse.ucsc.edu (Eugene Miya)
>> EM> A reasonably written (not perfect) but hard to find document (may now
>> EM> be scanned) was the Rationale for the Design of Ada to get into the
>> EM> thinking of PL designers (speaking as a person who once sat on an
>> EM> ANSI committee).
>>
>> I happen to have that document in my shelves: SIGPLAN Notices, Vo. 14,
>> No. 6, June 1979, Part B (Part A is the "Preliminary ADA Reference
>> Manual").
>>
>> But what relationship to you see to PL/1?
>
>I think the PL designers is referring to Programming Language designers...
Yep, got that right.
>> BTW, Sperry had a similar undertaking with PLUS; must have been very
>> similar to PL/1, isn't it?
>
>PLUS is, as best I recall, descended from JOVIAL. I don't think it
>looks very much like PL/I. I may be mistaken in this, of course...
I thought Univac did offer a PL/1 in days past.
The relationship between programming languages and natural languages is
a funny thing. When German C and troff/nroff started to appear,
this did not imply that the Germans knew English based keywords,
if-then-else, were just symbols or tokens. Pascal is somewhat lucky to
have had English keywords (on a CDC machine in Geneva if I remember
right). And I doubt many people ever heard of the Lau programming
language and know the country which produced it (googling aside:
actually might be a interesting test case).
Stephen Fuld
"Eugene Miya" <eug...@cse.ucsc.edu> wrote in message
news:3e5581dc$1...@news.ucsc.edu...
> In article <b313cf$2ent$1...@si05.rsvl.unisys.com>,
> David W. Schroth <David....@unisys.com> wrote:
snip
> >
> >PLUS is, as best I recall, descended from JOVIAL. I don't think it
> >looks very much like PL/I. I may be mistaken in this, of course...
>
> I thought Univac did offer a PL/1 in days past.
Yes, it did. Not very popular and dropped long ago. But, as David pointed
out. it was a totally different animal than PLUS, which was the new system's
implementation language, replacing assembler for most non-time critical
code. I suspect Univac was the only, or at best on of the very few, who
rewrote much of an existing operating system from assembler into a higher
level language a few pieces at a time over about 15 years. The mind
boggles.
Scott Lurndal
"Stephen Fuld" <s.f...@PleaseRemove.att.net> writes:
>
>Yes, it did. Not very popular and dropped long ago. But, as David pointed
>out. it was a totally different animal than PLUS, which was the new system's
>implementation language, replacing assembler for most non-time critical
>code. I suspect Univac was the only, or at best on of the very few, who
>rewrote much of an existing operating system from assembler into a higher
>level language a few pieces at a time over about 15 years. The mind
>boggles.
>
V-Series. MCPVI/MCPIX/MCPVS 1.0 were written entirely in assembler (mostly
in small < 100kdigits overlays[*]).
MCPVS 2.0 was completely rewritten, most of it in a higher-level language
called Sprite; the rewrite took about 5 years (1982 - 1987) and added
considerable capability to the system (e.g. much larger main memory support,
much larger program support, multitasking, symmetric multiprocessing,
hardware tasking, hardware synchronization (mutexes, condition variables)
usw.)
scott
[*] There was the HIHO overlay which was responsible for roll-in/roll-out (swap)
and memory-to-memory movements (to consolidate free space into larger
chunks). Various assembler labels were prince, mirror, sleepy, etc.
(as in Hi Ho, Hi Ho, it's off to work we go...)
(wordplay like the MotherForker in Large Systems and the Nursery and
Morgue segments in HP's MPE).
Tom Herbertson
...
> Stability and reliability take time to develop. The newer OSs are getting
> there, but still have a ways to go. As for guard mode, except for Win 9X
> (and ME) AFAIK, all systems have it. On Windows NT and above (including
> XP), pretty much the exact equivalent of a guard mode error is a general
> protection fault.
...
Is "guard mode" something like index checking?
I find it unbelievable that the "buffer overruns" that invite so much
malevolent code are still possible, having spent so much time working
with the MCP-based systems with their index checking, tags, and boundary
interrupts.
--
Tom Herbertson
Unisys (Net2: 656 6427) Mail Stop 320, Mission Viejo CA 92691-2792 USA
Voice: +1 949 380 6427 mailto:tom.her...@unisys.com (office)
FAX: +1 949 380 6560 or mailto:herbe...@cox.net (home)
- My opinions are my own; I do not speak for Unisys or anyone else -
Tom Herbertson
At one time we had quite a nice APL called APLB. And you could use it
from non-APL terminals with the use of keywords.
A is 3 4 rho iota 12
for example
Closest I've been able to find these days is A+ from Morgan Stanley.
It's for Unix-based systems (so I can use it on Mac OS X), and does also
have the keyword capability. In fact it has two sets of keywords to
choose from, but neither is exactly the same as the Unisys set.
I've also tried a demo version of APL from IBM that runs under PC-DOS,
but it's hard to go back to the APL keyboard mapping after using PC
keyboards. For example, the brackets and parentheses are just to the
right of the L.
http://www.users.cloud9.net/~bradmcc/cgi-bin/vuImag3.pl?i=149
At least the A+ keyboard has the characters where the PC keyboard does.
http://www.aplusdev.org/keyboard.html
Lots more about keyboard arrangements at
http://www.hypermaths.org/quadibloc/comp/kybint.htm
which particularly mentions the bit-paired Teletype keyboard. You
remember the Teletype, where the shift-2 was the double quote rather
than the at sign, don't you? If I recall correctly, when we had APLB and
its predecessor APL\700, there were NDL Request Sets and NDLII
Algorithms for both bit-paired Teletypes and typewriter-paired ASCII
terminals.
I still have my Unisys A Series APLB Programming Reference Manual, form
number 1203643, dated July 1987. Inside of the covers, its typography is
unlike any other Unisys manual. I wonder if it was done in TeX?
Louis Krupp
<snip>
> I find it unbelievable that the "buffer overruns" that invite so much
> malevolent code are still possible, having spent so much time working
> with the MCP-based systems with their index checking, tags, and boundary
> interrupts.
Believe it. Stack overflows don't necessarily get caught on most
systems, either.
My guess is that the Burroughs tagged architecture was designed to
protect the MCP from user programs and user programs from each
other, since everyone shared the same memory space. I don't know
enough about other early multi-user systems to know how (or if)
they accomplished the same thing.
I'm not sure Burroughs would have gone to that much trouble just to
protect user programs from themselves. It's a nice feature, and one
I frequently miss.
Anyone else remember the invalid index message on the B5500? It
told the user what the (invalid) effective index value was, right
there with the program output.
Louis Krupp
Stephen Fuld
"Tom Herbertson" <herbe...@cox.net> wrote in message
news:3E56E06A...@cox.net...
> Tom wrote:
> > In article <8dc4a.39896$rq4.3...@bgtnsc05-news.ops.worldnet.att.net>,
"Stephen Fuld" <s.f...@PleaseRemove.att.net> wrote:
> >
> >
> > <snip>
> >
> >>... And don't get me started about APL!
> >>
> >
> >
> > Heck, its all Greek to me!
> >
> > (sorry)
> >
> > Tom
> >
>
> At one time we had quite a nice APL called APLB. And you could use it
> from non-APL terminals with the use of keywords.
>
> A is 3 4 rho iota 12
>
> for example
>
> Closest I've been able to find these days is A+ from Morgan Stanley.
>
> http://www.aplusdev.org/
I remember an article in the old Byte magazine about a language called IIRC
"J". the idea is that it was APL but without the requirements for the
really oddball characters. Basically they had sequences of special
characters that meant the same things. So that (I'm making this up) you
might have *&) for the pillow character. The net results was that it was
even more unreadable than APL! But there might be an implementation of it
floating around somewhere for those masochistically inclined. :-)
Stephen Fuld
> Stephen Fuld wrote:
> ...
> > Stability and reliability take time to develop. The newer OSs are
getting
> > there, but still have a ways to go. As for guard mode, except for Win
9X
> > (and ME) AFAIK, all systems have it. On Windows NT and above (including
> > XP), pretty much the exact equivalent of a guard mode error is a general
> > protection fault.
> ...
>
> Is "guard mode" something like index checking?
Not exactly. Guard mode was the method of controlling how much memory a
user program could access. It is pretty much analogous to page protection
schemes in today's processors as a way of preventing a user program from
writing (or reading) from another program's (or the Exec's) memory. There
was no protection within the program, so your out of bounds index could
clobber your own data, but not anyone elses' data or program.
Edward Reid
> My guess is that the Burroughs tagged architecture was designed to
> protect the MCP from user programs and user programs from each
> other, since everyone shared the same memory space.
For this, it would not have been necessary to distinguish between data
and code via tags, as the B6700 did. Many ideas about protection were
quite well developed by 1970 -- long before the PC revolution started
ignoring them. The importance of separating code from data for overall
reliability was certainly known.
> I don't know
> enough about other early multi-user systems to know how (or if)
> they accomplished the same thing.
AFAIK, they did it mostly by protecting complete pages, and sometimes
by giving each program its own address space which was mapped to memory
reserved for the user of that program. Those techniques work, but with
a much larger memory grain. The Burroughs approach was clearly chosen
to provide greater intra-program reliability and smaller granularity,
whereas other schemes only provided inter-program protection.
> Anyone else remember the invalid index message on the B5500? It
> told the user what the (invalid) effective index value was, right
> there with the program output.
I've always wondered why the B6700 (and descendents) don't do that.
Usually the value is right there on top of the stack. To have it there
reliably would require some support from the ISA and the compilers (for
example, in COBOL85 an invalid index often shows up as an assertion
failure, and off the top of my head I can't tell you where the
subscript value is). But then what else is new -- the MCP and the ISA
and the compilers have always been heavily interdependent on this
system.
Edward Reid
Marc Wilson
wrote in <3E56DC06...@cox.net>::
|Stephen Fuld wrote:
|...
|> Stability and reliability take time to develop. The newer OSs are getting
|> there, but still have a ways to go. As for guard mode, except for Win 9X
|> (and ME) AFAIK, all systems have it. On Windows NT and above (including
|> XP), pretty much the exact equivalent of a guard mode error is a general
|> protection fault.
|...
|
|Is "guard mode" something like index checking?
Well, it sometimes achieves index checking by another means! Basically, it
happens when a program tries to access memory it doesn't have, so broken
index values are one way to get there. As is not bothering to check the
status after a memory request because "there's plenty available". :)
Marc Wilson
|which particularly mentions the bit-paired Teletype keyboard. You
|remember the Teletype, where the shift-2 was the double quote rather
|than the at sign, don't you?
Still is, on a UK keyboard, and some other European variants IIRC.
Tom Herbertson
> I remember an article in the old Byte magazine about a language called IIRC
> "J". the idea is that it was APL but without the requirements for the
> really oddball characters. Basically they had sequences of special
> characters that meant the same things. So that (I'm making this up) you
> might have *&) for the pillow character. The net results was that it was
> even more unreadable than APL! But there might be an implementation of it
> floating around somewhere for those masochistically inclined. :-)
>
Yes, I've run into that one, and it is available. It was designed in
part by APL inventor Ken Iverson, along with Roger Hui. Some links:
http://www.ptf.com/ptf/products/UNIX/current/0320.0.html
http://www.jsoftware.com
http://home1.gte.net/res057qw/APL_J/
http://home1.gte.net/res057qw/APL_J/IversonAPL.htm
http://cantaforda.com/cfcl/tin/P/199404.shtml
Eugene Miya
=?ISO-8859-1?Q?Halld=F3r_=CDsak_Gylfason?= <hgyl...@calidris.com> wrote:
>All this has made more interested in these "old" computers. I think
>that every computer science student should be taught the history of
>computer science.
Well, working with a Museum has opened my eyes somewhat.
On one hand, there is history in prog. language and compiler theory, as
well as other subjects. On the other hand, I think the halting problem
is becoming increasingly irrelevant, and simply knowing who worked on it
is even less relevant (i.e., people and dates).
History depends upon who is speaking.
>Otherwise we'll just end up with graduates that
>think that .NET was the beginning (and probably the end) of everything.
We are going to get them anyways.
>For instance when I was being taught Object Oriented Design with UML,
>I got the feeling that this was the first attempt to do some design of
>computer programs. That is very very far from the truth since
>procedural design methodologies have been around for many decades,
>supporting encapsulation and most of the things that object oriented
>methodologies incorporate.
The problem is that it's hard to replicate the stuff of the Simula 67 era
to then go back and relate what Alan Kay did on his FLEX thesis which
got him his job at Xerox PARC where he and others developed windowing
interfaces (Xerox Corp. jewels which still have not been released).
One can certainly attempt to learn the Smalltalk-80 language (I've seen
books which appear to butcher it).
>Or as one of my collegue put it: "We should reject every new
>methodology unless it is a refinement of existing methodology". Maybe
>a bit harsh, but has got some truth in it.
This is largely tenure driven.
>Anyway... One question: Does there exist a "Software Emulation" of
>unisys mainframes. Maybe this is a stupid question, but I'm not sure
>that I can afford to buy such computer myself, to be able to play with
>it.
I have heard emulators exist which run State of California systems, but
I have yet to see those systems for myself, and I am very patient.