"Stephen Fuld" <SFuld@alumni.cmu.edu.invalid> writes:

> Tim Rentsch wrote:
>
> snip
>
>> Personally I think his assessment of JCL is harsher than it
>> deserves. Don't get me wrong, JCL is not my idea of a great
>> control language, but it was usable enough in the environment
>> that customers were used to.
>
> From 1972-1979 I worked at a site that had boh S/360s (mostly /65s)
> running OS/MVT, and Univac 1108s running Exec 8. I used both,
> though did mostly 1108 stuff.
>
> For several reasons, JCL was terrible. One was its seemingly
> needless obscurity. For example, IIRC the program name of the COBOL
> compiler was ICKFBL00. In contrast, the COBOL compiler under Exec 8
> was called COB. It aalso lacked intelligent defaults, which made a
> it more cumbersome to use. But this was mostly hidden due to a much
> bigger problem.
>
> Perhaps due to the architectures inability to swap a program out and
> reload it to any real address other than the one it had originally,
> all resources to be used had to be avaable at the beginning of the
> job, so all JCL was scanned at the beginning of the job, and no
> "dynamic" allocations were possible.
>
> So, for example, the COBOL compiler needed, besides the input file
> name, IIRC four scratch files, an output file and a place to put the
> (spooled)print listing. These must be explicitly described (JCL DD
> commands) in the JCL for the job, Similarly for other programs.
> This was so inconvenient that IBM provided "Procedures" (essentially
> JCL macros), that included all the necessry DD statements, hid the
> actual program names, etc.) Thus to compile link and execute a
> COBOL program you invoked the procedure called something like
> ICOBUCLG (I have forgotten exactly, but the last thre characters
> were for Compile, Link, and GO). Contrast that with the EXEC 8
> command
>
> @COB programname
>
> (The @ was Exec's equivalent to // to indicate a comand) The
> internal scratch files were alocated internally by the compiler,
> the default print output (which could be overridden) went to the
> printer, the default output name (again overridable) was the same
> as the input (object files and source files could have the same
> name).
>
> Similarly, to copy a file from one place to another, JCL required
> at least two DD cards and an exec card with the program IEBGENER.
> Under Exec 8, the command
>
> @Copy sourcefile, destinationfile
>
> was sufficient, as both files would be dynamically assigned (Exec
> term) internally by the copy program, and the indicator of success
> or failure went to the default print output.
>
> While, as you stated, programmers dealt with this, and it worked
> in batch mode. But it clearly wouldn't work once time sharing
> (called Demand in Exec terminology) became available. Thus IBM
> had to invent a whole new, incompatible set of commands for TSO.
> But the Exec 8 syntax was so straightforward that users used
> exactly the same commands, keyed in at the terminal as were put on
> cards or a file in batch mode. That difference persists to this
> day.

I have no problem accepting all of your characterizations as
accurate. Like I said, I'm not a fan of JCL, not at all, I just
think it wasn't as bad as the commentary in The Design of Design
makes it out to be.

>> The biggest fault of JCL is that it
>> is trying to solve the wrong problem.
>
> What problem was it trying to solve and what was the "right"
> problem?

The problem it was trying to solve is contained in its name: Job
Control Language. It tacitly accepted the non-interactive batch
model for what it needed to address.

The problem that was in need of addressing is interactive use. I
think there are two reasons why JCL was so poor at that. One is
that they knew that teleprocessing would be important, but they
tried to cram it into the batch processing model, rather than
understanding a more interactive work style. The second reason is
that the culture at IBM, at least at that time, never understood the
idea that using computers can be (and should be) easy and fun. The
B in IBM is Business, and Business isn't supposed to be fun. And I
think that's part of why JCL was not viewed (at IBM) as a failure,
because their Business customers didn't mind. Needless to say, I am
speculating, but for what it's worth those are my speculations.

>> It isn't clear that trying
>> to do something more ambitious would have fared any better in the
>> early 1960s (see also The Second System Effect in MMM).
>
> Exec 8 was roughly comtemporaeous with OS/MVT. I claim, was a
> much better choice,

Let me clarify my earlier statement: It isn't clear that >>IBM<<
trying to do something more ambitious would have fared any better
(at least not at that time). The people who did Exec 8 didn't have
the baggage of IBM's customer model (here again I am speculating),
so it was easier for them to do a better job.

John Levine <johnl@taugh.com> writes:

> According to Tim Rentsch <tr.17687@z991.linuxsc.com>:
>
>> John Levine <johnl@taugh.com> writes:
>>
>>> According to MitchAlsup1 <mitchalsup@aol.com>:
>>>
>>>> For a modern ISA, the architect should specify that various bits
>>>> of the general format "must be zero"* when those bits are not used
>>>> in the instruction.
>>>
>>> That was another innovation of the 360. It specifically said that
>>> unused bits (of which there were a few) and unused unstructions (of
>>> which there were a lot) were reserved. The unused bits had to be
>>> zero, and the instructions all trapped.
>>
>> I would describe this not so much as an innovation but just as
>> applying a lesson learned from earlier experience.
>
> Well, yes, but another 360 innovation was the whole idea of computer
> architecture, as well as the term. It was the first time that the
> programmer's view of the computer was described independently of any
> implementation.

I don't buy it. An architecture is just a description of system
behavior, and surely there were descriptions of system behavior
before System/360. Even in the 1950s companies must have changed
implementations of a given model while still conforming to its
earlier description. As for the word architecture, it seems like
an obvious and natural word choice, given the hundreds (or more)
of years of experience with blueprints and buildings.

The Forbidden City in China was designed and built in a very
short time (less than 15 years) in the early 1400s, and is
still there today. The intellectual history of architecture
is well established; it doesn't seem like any great leap to
use the word "architecture" for something that is very much
like a blueprint.

I grant you that the idea of having a single architecture for a
line of computers covering a large range of performance was a new
idea, and a revolutionary one. Certainly IBM deserves credit for
that. Furthermore that one idea is responsible for much if not
most of the success of System/360, and well worth recognizing as
such. However that idea is much more than just the notion of
describing system behavior.

>> Some earlier IBM
>> model (don't remember which one) had the property that instructions
>> were somewhat like microcode, and some undocumented combinations of
>> bits would do useful things.
>
> I wonder if that was the way that the 704 OR'ed the index registers.
> There were three of them, numbered 1, 2, and 4, so if your index field
> was 5, it OR'ed registers 1 and 4. It subtracted the index (or the
> OR'ed combination of indexes) from the base address, so it would have
> taken some really tricky programming to make use of that. But someone
> must have since they documented it and it continued to work on the
> 709, 7090, and 7094 until they provided 7 index registers and a mode
> bit to switch between the old OR and the new 7 registers.

My memory (fuzzy and unreliable though it may be) is that the
property I mentioned had nothing to do with index registers, but
rather was about what operation (or combination of operations)
would be performed. Apparently there was very little encoding of
the "opcode" bits, so undocumented combinations of bits would
have a different, and sometimes useful, effect. Like I said my
memory is less than 100% reliable so feel to apply any number of
grains of salt.

> I have never found anything that says whether it was deliberate or an
> accident of the 704's implementation, and I have looked pretty hard.

Another dim memory from ages past is that the choice in early
versions of FORTRAN to limit arrays to three dimensions was due
to an early IBM model having three index registers. Probably an
interested person could track that down if they wanted to, but
for myself I am content to let the question fade into the mists
of time.

Tim Rentsch wrote:

> "Stephen Fuld" <SFuld@alumni.cmu.edu.invalid> writes:

snip

>
> >> The biggest fault of JCL is that it
> >> is trying to solve the wrong problem.
> >
> > What problem was it trying to solve and what was the "right"
> > problem?
>
> The problem it was trying to solve is contained in its name: Job
> Control Language. It tacitly accepted the non-interactive batch
> model for what it needed to address.

You may be right, but correct me if I am wrong, there was no
non-interactive model in the mid 1960s when JCL was devised. They
didn't address it because they couldn't forcast (obviouslyincorrectly),
that it would be a problem to solve.

> The problem that was in need of addressing is interactive use. I
> think there are two reasons why JCL was so poor at that. One is
> that they knew that teleprocessing would be important, but they
> tried to cram it into the batch processing model, rather than
> understanding a more interactive work style. The second reason is
> that the culture at IBM, at least at that time, never understood the
> idea that using computers can be (and should be) easy and fun. The
> B in IBM is Business, and Business isn't supposed to be fun. And I
> think that's part of why JCL was not viewed (at IBM) as a failure,
> because their Business customers didn't mind. Needless to say, I am
> speculating, but for what it's worth those are my speculations.

Fair enough. A couple of comments. By the time TSO/360 came out,in
IIRC the early 1970s, they were already committed to JCL. TSO ran as a
batch job on top of the OS, and handled swapping, etc.itself within the
region allocated to TSO within the OS. It was a disaster. Of course
this was later addressed by unifying TSO into the OS, but that couldn't
happen until the S/370s (except the 155 and 165) and virtual memory.
But the legacy of two control languages was already set by then.

As for "fun". I agree that IBM didn't think of computers as fun, but
there were plenty of reasons to support interactive terminals for
purely business reasons, a major one being programmer productivity in
developing business applications.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:
> John Levine <johnl@taugh.com> writes:

>> Well, yes, but another 360 innovation was the whole idea of computer
>> architecture, as well as the term. It was the first time that the
>> programmer's view of the computer was described independently of any
>> implementation.
>
> I don't buy it. An architecture is just a description of system
> behavior, and surely there were descriptions of system behavior
> before System/360.

Indeed, but "independently of any implementation" is the key here.
Brooks wrote that programmers viewed the "Principle of Operations"
as *the* S/360, rather than the individual models.

Stephen Fuld <SFuld@alumni.cmu.edu.invalid> schrieb:
> but correct me if I am wrong, there was no
> non-interactive model in the mid 1960s when JCL was devised. They
> didn't address it because they couldn't forcast (obviouslyincorrectly),
> that it would be a problem to solve.

That is one of the issues that Brooks raises. OS/360 was already
predicated on terminal access, but the JCL designers missed that
and chose punched cards.

Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:

> Like I said, I'm not a fan of JCL, not at all, I just
> think it wasn't as bad as the commentary in The Design of Design
> makes it out to be.

I think the point he made is subtly different.

The UNIX shells have demonstrated that a command interface is,
and should be, a programming language in its own right. JCL has
the rudiments of a programming language with its COND parameter
(which ties my brain into knots every time I think about it) and
the possibility of iteration via submitting new jobs via INTRDR,
plus its macro facility (but with global variables only).

Viewed through that lens, I can't think of any (serious) programming
language that is worse than JCL. Joke languages need not apply.

On Tue, 7 May 2024 06:54:17 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:

> Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:
>
> > Like I said, I'm not a fan of JCL, not at all, I just
> > think it wasn't as bad as the commentary in The Design of Design
> > makes it out to be.
>
> I think the point he made is subtly different.
>
> The UNIX shells have demonstrated that a command interface is,
> and should be, a programming language in its own right.

I wouldn't give that credit to UNIX.
I was not around, but my impression is that by time of creation of UNIX
it was a common understanding. For example, DEC supplied RSX-11 with
DCL at about the same time [as UNIX got Thompson shell) and I never
heard that anybody considered it novel.

> JCL has
> the rudiments of a programming language with its COND parameter
> (which ties my brain into knots every time I think about it) and
> the possibility of iteration via submitting new jobs via INTRDR,
> plus its macro facility (but with global variables only).
>
> Viewed through that lens, I can't think of any (serious) programming
> language that is worse than JCL. Joke languages need not apply.

Michael S <already5chosen@yahoo.com> schrieb:
> On Tue, 7 May 2024 06:54:17 -0000 (UTC)
> Thomas Koenig <tkoenig@netcologne.de> wrote:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:
>>
>> > Like I said, I'm not a fan of JCL, not at all, I just
>> > think it wasn't as bad as the commentary in The Design of Design
>> > makes it out to be.
>>
>> I think the point he made is subtly different.
>>
>> The UNIX shells have demonstrated that a command interface is,
>> and should be, a programming language in its own right.
>
> I wouldn't give that credit to UNIX.

I think I whould have qualitied that statement somewhat. What I
think the full set of features of the Bourne C shells finally made
it clear to everybody that shells could and should be a complete
programming language.

> I was not around, but my impression is that by time of creation of UNIX
> it was a common understanding. For example, DEC supplied RSX-11 with
> DCL at about the same time [as UNIX got Thompson shell) and I never
> heard that anybody considered it novel.

The Thompson shell was still restricted to GOTO (as was the RSX-11
shell).

On Mon, 06 May 2024 18:22:59 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

>
> I don't buy it. An architecture is just a description of system
> behavior, and surely there were descriptions of system behavior
> before System/360. Even in the 1950s companies must have changed
> implementations of a given model while still conforming to its
> earlier description.

Were they?
My impression is that until S/360 there was no such thing as different
by 100% SW compatible models.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>John Levine <johnl@taugh.com> writes:
>> Well, yes, but another 360 innovation was the whole idea of computer
>> architecture, as well as the term. It was the first time that the
>> programmer's view of the computer was described independently of any
>> implementation.
>
>I don't buy it. An architecture is just a description of system
>behavior, and surely there were descriptions of system behavior
>before System/360. Even in the 1950s companies must have changed
>implementations of a given model while still conforming to its
>earlier description.

Sure, the 7094 was a compatible successor of the 704, but the idea of
implementation independence turns out to be much more profound than
most people (probably including its inventors at the time) realized.
The hardware behind the z16 is vastly different from that of any of
the initial members of the 360 family, its microarchitecture is also
vastly different (caches, virtual memory, out-of-order execution,
speculative execution, superscalar execution), and yet it can run
software written for the S/360 60 years ago.

And the important part is not just what to put into the architecture,
but also what to leave out. There is no end to clever ideas that
would improve performance of a particular implementation, that are bad
ideas when it comes to architecture. A widely accepted example is
branch delay slots.

An interesting example is IA-64: It was designed as a long-lived
architecture (while the VLIW machines that provided some of the ideas
for IA-64 seem to be mainly designed as implementations), but it
turned out that the special architectural features it had could be
provided through microarchitecture (in particular, OoO execution) to
earlier architectures, and that these features were pointless for OoO
microarchitectures.

Another interesting example is Alpha. It was claimed to be designed
for a 25-year lifetime (actually there were 9 years between the
introduction of the 21064 in 1992 and the cancellation of the 21464 in
2001). They left out all features that (they claimed) hindered
performance, such as a flags register and byte/word-access (BWX)
instructions; the BWX case was supposedly because they required ECC
for write-back caches. But the first implementations (EV4, EV45, EV5,
EV56) all have write-through L1 caches, so BWX instructions would have
been no problem (and they were added in EV56 in 1996, i.e. after 4
years). EV6, which has a write-back L1 cache, has a write buffer, so
generating ECC for the BWX instructions was not particularly
expensive. The downside of leaving an architectural feature like BWX
out in the first implementation is that much software would forego
using BWX for a very long time (if Alpha had lived that long).

>As for the word architecture, it seems like
>an obvious and natural word choice, given the hundreds (or more)
>of years of experience with blueprints and buildings.

I don't think that their achievement is in choosing the word
"architecture". It reflects on the division of labor between the
planner of a building and the people who implement the plan, but it
does not transport the fact that computer ISA "architects" design the
interface between software and hardware for a vast amount of software
and a vast difference in potential hardware across the decades, much
of it unforeseeable for the computer architect. By contrast, building
architects are more like computer microarchitects, designing for
building materials of the day, and the uses of the buildings tend to
be less varied than the software that runs on a general-purpose ISA;
ok, my office is in a building that was built as a residence building
in 1913, but that's not because the architect designed it for
general-purpose usage.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Michael S <already5chosen@yahoo.com> writes:
>On Mon, 06 May 2024 18:22:59 -0700
>Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>>
>> I don't buy it. An architecture is just a description of system
>> behavior, and surely there were descriptions of system behavior
>> before System/360. Even in the 1950s companies must have changed
>> implementations of a given model while still conforming to its
>> earlier description.
>
>Were they?
>My impression is that until S/360 there was no such thing as different
>by 100% SW compatible models.

The Burroughs B5500 and B3500 were contemporaneous with the S/360
and provided 100% SW compatible models across a performance range
during the same 1965 to 1978 time period as the S/360.

"Stephen Fuld" <SFuld@alumni.cmu.edu.invalid> writes:
>Tim Rentsch wrote:

>> The problem it was trying to solve is contained in its name: Job
>> Control Language. It tacitly accepted the non-interactive batch
>> model for what it needed to address.
>
>You may be right, but correct me if I am wrong, there was no
>non-interactive model in the mid 1960s when JCL was devised.

BASIC and DTSS was developed in 1963.

Thomas Koenig <tkoenig@netcologne.de> writes:
>Michael S <already5chosen@yahoo.com> schrieb:
>> On Tue, 7 May 2024 06:54:17 -0000 (UTC)
>> Thomas Koenig <tkoenig@netcologne.de> wrote:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:
>>>
>>> > Like I said, I'm not a fan of JCL, not at all, I just
>>> > think it wasn't as bad as the commentary in The Design of Design
>>> > makes it out to be.
>>>
>>> I think the point he made is subtly different.
>>>
>>> The UNIX shells have demonstrated that a command interface is,
>>> and should be, a programming language in its own right.
>>
>> I wouldn't give that credit to UNIX.
>
>I think I whould have qualitied that statement somewhat. What I
>think the full set of features of the Bourne C shells finally made

The Bourne shell and the C shell were two completely different
shells (the latter followed the former by several years).

Scott Lurndal <scott@slp53.sl.home> schrieb:
> Thomas Koenig <tkoenig@netcologne.de> writes:
>>Michael S <already5chosen@yahoo.com> schrieb:
>>> On Tue, 7 May 2024 06:54:17 -0000 (UTC)
>>> Thomas Koenig <tkoenig@netcologne.de> wrote:
>>>
>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:
>>>>
>>>> > Like I said, I'm not a fan of JCL, not at all, I just
>>>> > think it wasn't as bad as the commentary in The Design of Design
>>>> > makes it out to be.
>>>>
>>>> I think the point he made is subtly different.
>>>>
>>>> The UNIX shells have demonstrated that a command interface is,
>>>> and should be, a programming language in its own right.
>>>
>>> I wouldn't give that credit to UNIX.
>>
>>I think I whould have qualitied that statement somewhat. What I
>>think the full set of features of the Bourne C shells finally made
>
> The Bourne shell and the C shell were two completely different
> shells (the latter followed the former by several years).

Having worked with both, I certainly know the differences.

But if Wikipedia is to be trusted, Bill Joy released the C shell in
1978, and the Bourne shell was released in 1979.

That makes them roughly contemporary, considering that the C shell
may have been released at an earlier stage of development.

Thomas Koenig <tkoenig@netcologne.de> writes:
>Scott Lurndal <scott@slp53.sl.home> schrieb:
>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>>Michael S <already5chosen@yahoo.com> schrieb:
>>>> On Tue, 7 May 2024 06:54:17 -0000 (UTC)
>>>> Thomas Koenig <tkoenig@netcologne.de> wrote:
>>>>
>>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:
>>>>>
>>>>> > Like I said, I'm not a fan of JCL, not at all, I just
>>>>> > think it wasn't as bad as the commentary in The Design of Design
>>>>> > makes it out to be.
>>>>>
>>>>> I think the point he made is subtly different.
>>>>>
>>>>> The UNIX shells have demonstrated that a command interface is,
>>>>> and should be, a programming language in its own right.
>>>>
>>>> I wouldn't give that credit to UNIX.
>>>
>>>I think I whould have qualitied that statement somewhat. What I
>>>think the full set of features of the Bourne C shells finally made
>>
>> The Bourne shell and the C shell were two completely different
>> shells (the latter followed the former by several years).
>
>Having worked with both, I certainly know the differences.
>
>But if Wikipedia is to be trusted, Bill Joy released the C shell in
>1978, and the Bourne shell was released in 1979.

The V6 shell was released in 1975.

Scott Lurndal <scott@slp53.sl.home> schrieb:
> Thomas Koenig <tkoenig@netcologne.de> writes:
>>Scott Lurndal <scott@slp53.sl.home> schrieb:
>>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>>>Michael S <already5chosen@yahoo.com> schrieb:
>>>>> On Tue, 7 May 2024 06:54:17 -0000 (UTC)
>>>>> Thomas Koenig <tkoenig@netcologne.de> wrote:
>>>>>
>>>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:
>>>>>>
>>>>>> > Like I said, I'm not a fan of JCL, not at all, I just
>>>>>> > think it wasn't as bad as the commentary in The Design of Design
>>>>>> > makes it out to be.
>>>>>>
>>>>>> I think the point he made is subtly different.
>>>>>>
>>>>>> The UNIX shells have demonstrated that a command interface is,
>>>>>> and should be, a programming language in its own right.
>>>>>
>>>>> I wouldn't give that credit to UNIX.
>>>>
>>>>I think I whould have qualitied that statement somewhat. What I
>>>>think the full set of features of the Bourne C shells finally made
>>>
>>> The Bourne shell and the C shell were two completely different
>>> shells (the latter followed the former by several years).
>>
>>Having worked with both, I certainly know the differences.
>>
>>But if Wikipedia is to be trusted, Bill Joy released the C shell in
>>1978, and the Bourne shell was released in 1979.
>
> The V6 shell was released in 1975.

Wikipedia claims that this stll used the Thompson shell, and looking
at its man page at http://man.cat-v.org/unix-6th/1/sh , that seems
to be the case - it makes no mention of a lot of the more elaborate
features of the Bourne shell, which appears to be described in the man
page at http://man.cat-v.org/unix_7th/1/sh .

Scott Lurndal wrote:

> "Stephen Fuld" <SFuld@alumni.cmu.edu.invalid> writes:
> > Tim Rentsch wrote:
>
> >> The problem it was trying to solve is contained in its name: Job
> >> Control Language. It tacitly accepted the non-interactive batch
> >> model for what it needed to address.
> >
> > You may be right, but correct me if I am wrong, there was no
> > non-interactive model in the mid 1960s when JCL was devised.
>
> BASIC and DTSS was developed in 1963.

Good Point. So IBM was "guuilty" of vastly mis-understanding and under
estimating the future importance of interactive users.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

Stephen Fuld <SFuld@alumni.cmu.edu.invalid> schrieb:
> Scott Lurndal wrote:
>
>> "Stephen Fuld" <SFuld@alumni.cmu.edu.invalid> writes:
>> > Tim Rentsch wrote:
>>
>> >> The problem it was trying to solve is contained in its name: Job
>> >> Control Language. It tacitly accepted the non-interactive batch
>> >> model for what it needed to address.
>> >
>> > You may be right, but correct me if I am wrong, there was no
>> > non-interactive model in the mid 1960s when JCL was devised.
>>
>> BASIC and DTSS was developed in 1963.
>
>
> Good Point. So IBM was "guuilty" of vastly mis-understanding and under
> estimating the future importance of interactive users.

Only the team that made JCL, it seems.

Brooks claims that System/360 was premeditated for terminal
use from the start, and that somebody didn't get the memo
when designing JCL (my words).

Thomas Koenig wrote:

> Stephen Fuld <SFuld@alumni.cmu.edu.invalid> schrieb:
> > Scott Lurndal wrote:
> >
> >> "Stephen Fuld" <SFuld@alumni.cmu.edu.invalid> writes:
> >> > Tim Rentsch wrote:
> >>
> >> >> The problem it was trying to solve is contained in its name:
> Job >> >> Control Language. It tacitly accepted the non-interactive
> batch >> >> model for what it needed to address.
> >> >
> >> > You may be right, but correct me if I am wrong, there was no
> >> > non-interactive model in the mid 1960s when JCL was devised.
> >>
> >> BASIC and DTSS was developed in 1963.
> >
> >
> > Good Point. So IBM was "guuilty" of vastly mis-understanding and
> > under estimating the future importance of interactive users.
>
> Only the team that made JCL, it seems.

Just as an aside, though this thread may be somewhat OT, I consider it
fun and interesting.

I am not sure exactly what he is saying here. By JCL, does he mean
just the syntax of the language, the funky program names, etc., or doea
he include the things like the requirement that all allocation be done
before the first program executes, which is perhaps more of an OS
design issue?

>
> Brooks claims that System/360 was premeditated for terminal
> use from the start, and that somebody didn't get the memo
> when designing JCL (my words).

In what sense was the S/360 architecture, designed for terminal use? I
already talked about the base register, BALR/Using stuff that prevented
an interative program from being swapped out and swapped in to a
different real memory lcation. This was a significant hinderance to
"terminal use".

BTW, another problem occurs in transaction workloads where there is
another level of software between the user and the OS, but insteaed of
TSO, it was IMS or CICS, which did the terminal handling and imposed
another level of scheduling (i.e. IMS/CICS competed with other programs
for OS resources and the transactions within IMS/CICS competed with
each other for the resources that IMS/CICS got.) Note that this
overhead was so much that the high volume transaction users couldn't
use it and instead developed their own OS (ACP).

Also, the protection mechanism of S/360 was such that there was no
protection between transactions within CICS (Idon'tknow about IMS),
such that an errant subscript could cause the overwriting of other
transactions, or even CICS itself. This was also fixed with the
S/370s virtual memory.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

According to Scott Lurndal <slp53@pacbell.net>:
>>My impression is that until S/360 there was no such thing as different
>>by 100% SW compatible models.
>
>The Burroughs B5500 and B3500 were contemporaneous with the S/360
>and provided 100% SW compatible models across a performance range
>during the same 1965 to 1978 time period as the S/360.

Wikipedia says that while S/360 and the B3500 were announced in 1964,
the B3500 was announced in 1966. In the discussion of MCP on the B3500
it says 'It shared many architectural features with the MCP of
Burroughs' Large Systems stack machines, but was entirely different
internally, and was coded in assembly language, not an ALGOL
derivative." That suggests it was compatible for user programs, but
not for operating systems.

On the 360, if two models had similar memory and peripherals, you
could IPL and run the same operating system since it was specified
down to the details of interrupts and I/O instructions.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

According to Stephen Fuld <SFuld@alumni.cmu.edu.invalid>:
>In what sense was the S/360 architecture, designed for terminal use? I
>already talked about the base register, BALR/Using stuff that prevented
>an interative program from being swapped out and swapped in to a
>different real memory location. This was a significant hinderance to
>"terminal use".

With sufficiently disciplined programming, you could swap and move data
by updating the base registers. APL\360 did this quite successfully
and handled a lot of interactive users on a 360/50.

Reading between the lines in the IBMSJ architecture paper, I get the
impression they believed that moving code and data with base registers
would be a lot easier than it was, and missed the facts that a lot of
pointers are stored in memory, and it is hard to know what registers
are being used as base registers when.

This paper from U of Michigan lays out the problem and proposes a
paging design which soon became the 360/67:

https://dl.acm.org/doi/pdf/10.1145/321312.321313

TSS was a disaster due to an extreme case of second system syndrome,
but Michigan's MTS and IBM skunkworks CP/67 worked great.

>BTW, another problem occurs in transaction workloads where there is
>another level of software between the user and the OS, but insteaed of
>TSO, it was IMS or CICS, ...

There's two ways to write interacticve software, which I call the time-sharing
approach and the SAGE approach. In the time-sharing approach, the operating system
stops and starts user processes and transparently saves and restores the process
status. In the SAGE approach, programs are broken up into little pieces each of
which runs straight through, explicitly saves whatever context it needs to, and
then returns to the OS.

The bad news about the SAGE approach is that the programming is
tedious and as you note bugs can be catastrophic. The good news is
that it can get fantastic performance for lots of users. It was
invented for the SAGE missile defense system on tube computers in the
1950s, adapted for the SABRE airline reservation system on 7094s in
the 1960s and has been used over and over, with the current trendy
version being node.js. We now have better ways to describe
continuations which make the programming a little easier, but it's
still a tradeoff. IMS and CICS used the SAGE approach to provide good
performance on specific applications.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

According to Thomas Koenig <tkoenig@netcologne.de>:
>> I was not around, but my impression is that by time of creation of UNIX
>> it was a common understanding. For example, DEC supplied RSX-11 with
>> DCL at about the same time [as UNIX got Thompson shell) and I never
>> heard that anybody considered it novel.
>
>The Thompson shell was still restricted to GOTO (as was the RSX-11
>shell).

You're probably thinking of the Mashey shell. One of the first usenix
tapes has patches I wrote in about 1976 to add simple variables with
single character names to that shell. It was an improvement, but the
Bourne shell was way better.

Re when this stuff was invented, I did some work on CP/67 when I was
in high school in about 1970 and I recall that even then people
routinely ran files of CMS commands. Don't remember whether there were
variables and control flow or that came later with REXX.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

John Levine <johnl@taugh.com> writes:
>According to Scott Lurndal <slp53@pacbell.net>:
>>>My impression is that until S/360 there was no such thing as different
>>>by 100% SW compatible models.
>>
>>The Burroughs B5500 and B3500 were contemporaneous with the S/360
>>and provided 100% SW compatible models across a performance range
>>during the same 1965 to 1978 time period as the S/360.
>
>Wikipedia says that while S/360 and the B3500 were announced in 1964,
>the B3500 was announced in 1966. In the discussion of MCP on the B3500
>it says 'It shared many architectural features with the MCP of
>Burroughs' Large Systems stack machines, but was entirely different
>internally, and was coded in assembly language, not an ALGOL
>derivative." That suggests it was compatible for user programs, but
>not for operating systems.

I spent almost a decade working on the later versions of the
B3500 operating system. With minor changes (detected at runtime), the same MCP ran
on B3500/B3700/B4700, B4800, B4925/B4955; three generations. We rewrote the MCP
to enable access to more memory circa 1982 in a high-level language
called SPRITE, incorporating quite a bit of the assembler code
from the prior MCP and changed the name to V-Series which included
three distinct models each using the same MCP/VS: V340/V380, V420 and
the four processor ECL SMP V5x0.

The customer never needed to build the MCP or SYSGEN it.
It configured itself when installed and could be dynamically
reconfigured without a halt/load (i.e. reboot).

>
>On the 360, if two models had similar memory and peripherals, you
>could IPL and run the same operating system since it was specified
>down to the details of interrupts and I/O instructions.

Same for the B3/4/5xxx series.

The first major architectural change occured in 1982, prior
models all ran the same MCP.

User application binaries were of course forward portable to _all_ generations
of the MCP and CPU across the entire life of the product line.

The IO Subsystems were always superior to the IBM channel programs,
there was a separate I/O processor to which the OS presented
and I/O descriptor, and the I/O processor wrote a result descriptor
into memory before raising the I/O complete interrupt. the IOP
managed data transfer between the peripheral and host.

The I/O descriptor would indicate the high level operation:
- Read Card, Read Tape Forward, Read Tape Backward, Read Disk Block
- Punch Card, Write Tape Forward, Write Tape Backward, Write Tapemark, Write disk Block
- Print Line, etc.
- Terminal Read/Write
- Cancel prior operation (for e.g. interactive READ, or to recover from error)
- Identify channel (returned a peripheral identifier unique to the controller type,
which identified which driver should be loaded during boot).

It included a pair of addresses defining the bounds of the
buffer that the I/O processor would DMA to/from and for disk
included the sector number, for tape the skip count for
space forward/backward operations.

The R/D varied from 16-bits to 64 bits depending on device,
with the first 16-bits common across all devices, and the
rest was device specific.

These I/O peripherals were common across both large systems (B[567]xxx)
and medium systems (B[234]xxx).

John Levine <johnl@taugh.com> writes:
>According to Scott Lurndal <slp53@pacbell.net>:
>>>My impression is that until S/360 there was no such thing as different
>>>by 100% SW compatible models.
>>
>>The Burroughs B5500 and B3500 were contemporaneous with the S/360
>>and provided 100% SW compatible models across a performance range
>>during the same 1965 to 1978 time period as the S/360.
>
>Wikipedia says that while S/360 and the B3500 were announced in 1964,
>the B3500 was announced in 1966. In the discussion of MCP on the B3500

Sorry, I mean to imply that the B3500 (and successors) were 100% sw
compatible within the medium systems family.

Likewise for the large systems (B5500) line. I did not intend to imply
that the B3500 and B5500 were application (or MCP) compatible with each other;
they weren't (a 48-bit stack machine and a variable length BCD
machine have little in common architecturally).

The MCP had some usability and command similarites between the families,
but implementation was family specific.

John Levine wrote:

> According to Stephen Fuld <SFuld@alumni.cmu.edu.invalid>:
>>

> This paper from U of Michigan lays out the problem and proposes a
> paging design which soon became the 360/67:

> https://dl.acm.org/doi/pdf/10.1145/321312.321313

> TSS was a disaster due to an extreme case of second system syndrome,
> but Michigan's MTS and IBM skunkworks CP/67 worked great.

TSS at CMU was extensively rewritten in assembly and became quite
tolerable--hosting 30+ interactive jobs along with a background
batch processing system. When I arrived in Sept 1975 it was quite
unstable with up times less than 1 hour. 2 years later it would run
for weeks at a time without going down.

As I understand it* most of the changes were simply getting rid of
things that were not present on CMU's 360/67.

(*) was told by someone who should have known circa 1974 who also
worked in the machine room 3rd floor in what became Scaife hall.