f



Languages influenced by PL/1

Hi,

not exactly new-news, but I noticed that the CL programming language (JCL/shell-script for the IBM iSeries/System i/whatever it's called now) had some enhancements a few releases ago.

You can now declare based and defined variables. If you don't declare the storage class, it defaults to automatic (which you can also declare explicitly) although the syntax is different, this seems very PL/1 like.
0
7/14/2012 9:44:14 AM
comp.lang.pl1 1741 articles. 0 followers. Post Follow

913 Replies
1598 Views

Similar Articles

[PageSpeed] 34

On Saturday, 14 July 2012 19:44:14 UTC+10, (unknown)  wrote:
 
> not exactly new-news, but I noticed that the CL programming language (JCL/shell-script for the IBM iSeries/System i/whatever it's called now) had some enhancements a few releases ago.
> 
> You can now declare based and defined variables. If you don't declare the storage class, it defaults to automatic (which you can also declare explicitly) although the syntax is different, this seems very PL/1 like.

Interesting.

Other older ones include PL/M and XPL. Any others?
0
robin.vowels (428)
7/14/2012 11:49:49 PM
On 2012-07-14 09:44:14 +0000, john_maybury@hotmail.com said:

> Hi,
> 
> not exactly new-news, but I noticed that the CL programming language 
> (JCL/shell-script for the IBM iSeries/System i/whatever it's called now)

"IBM i". There is no longer an iSeries as such because IBM i is written 
to run on the very same systems (IBM Power Systems) that run AIX.

>  had some enhancements a few releases ago.
> 
> You can now declare based and defined variables. If you don't declare 
> the storage class, it defaults to automatic (which you can also declare 
> explicitly) although the syntax is different, this seems very PL/1 like.

And C-like and Ada-like and ALGOL-like and (modern) Fortran-like. But 
CL is indeed strongly influenced by PL/I, as were most other IBM 
command languages of the late 60s and 70s, such as TSO and IDCAMS.

-- 
John W Kennedy
"Only an idiot fights a war on two fronts.  Only the heir to the throne 
of the kingdom of idiots would fight a war on twelve fronts"
 -- J. Michael Straczynski.  "Babylon 5", "Ceremonies of Light and Dark"

0
jwkenne (1442)
7/15/2012 12:22:54 AM
On 2012-07-14 23:49:49 +0000, robin.vowels@gmail.com said:

> On Saturday, 14 July 2012 19:44:14 UTC+10, (unknown)  wrote:
> 
>> not exactly new-news, but I noticed that the CL programming language 
>> (JCL/shell-script for the IBM iSeries/System i/whatever it's called 
>> now) had some enhancements a few releases ago.
>> 
>> You can now declare based and defined variables. If you don't declare 
>> the storage class, it defaults to automatic (which you can also declare 
>> explicitly) although the syntax is different, this seems very PL/1 like.
> 
> Interesting.
> 
> Other older ones include PL/M and XPL. Any others?

Some /very/ common features, such as "/* ... */" comments, can be 
traced back to PL/I. On the other hand, many languages have been 
influenced in a negative way by PL/I. All modern languages have typed 
pointers, for example, because the experience with PL/I anonymous 
pointers was so terrible. Similarly, all modern languages have lexical 
scoping of exception handlers, and do not allow return to the point of 
exception because the dynamic PL/I ON statement and the ability to 
return from an ON-unit were so destructive. In many ways, PL/I was as 
much a "great leap forward" experiment as anything else, and, as usual 
in such cases, it was as valuable for its failures as for its successes.

-- 
John W Kennedy
"You can, if you wish, class all science-fiction together; but it is 
about as perceptive as classing the works of Ballantyne, Conrad and W. 
W. Jacobs together as the 'sea-story' and then criticizing _that_."
  -- C. S. Lewis.  "An Experiment in Criticism"

0
jwkenne (1442)
7/15/2012 12:32:51 AM
John W Kennedy <jwkenne@attglobal.net> wrote:

(snip, someone wrote)
>> You can now declare based and defined variables. If you don't declare 
>> the storage class, it defaults to automatic 
(snip)

> And C-like and Ada-like and ALGOL-like and (modern) Fortran-like. But 
> CL is indeed strongly influenced by PL/I, as were most other IBM 
> command languages of the late 60s and 70s, such as TSO and IDCAMS.

Fortran only defaults to automatic in RECURSIVE routines.
Otherwise, variables can be either static (SAVEd) or automatic.

-- glen
0
gah (12851)
7/15/2012 12:42:51 AM
In <50020d5e$0$1223$607ed4bc@cv.net>, on 07/14/2012
   at 08:22 PM, John W Kennedy <jwkenne@attglobal.net> said:

>And C-like and Ada-like and ALGOL-like and (modern) Fortran-like. But
> CL is indeed strongly influenced by PL/I, as were most other IBM 
>command languages of the late 60s and 70s, such as TSO and IDCAMS.

No. It's true that CLIST uses /* */ to delimit comments, but there the
resemblance stops. JCL in DOS/360 and OS/360 looked nothing like PL/I
and had a vaguely assembler syntax. EXEC in CP/67 through z/VM looked
nothing like PL/I, nor did the later EXEC 2. The only IBM command
language that looked vaguely like PL/I was REXX, and even there their
were more differences than similarities.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
spamtrap16 (3722)
7/15/2012 1:33:42 AM
Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> wrote:
> In <50020d5e$0$1223$607ed4bc@cv.net>, on 07/14/2012
>   at 08:22 PM, John W Kennedy <jwkenne@attglobal.net> said:

>>And C-like and Ada-like and ALGOL-like and (modern) Fortran-like. But
>> CL is indeed strongly influenced by PL/I, as were most other IBM 
>>command languages of the late 60s and 70s, such as TSO and IDCAMS.

> No. It's true that CLIST uses /* */ to delimit comments, but there the
> resemblance stops. JCL in DOS/360 and OS/360 looked nothing like PL/I
> and had a vaguely assembler syntax. 

And as I read somewhere, I believe written by someone involved in
the decision, the JCL use of /* was unrelated to the PL/I use.

That is, neither knew about the other at the time. 

It does complicate starting comments in column 1.

-- glen
0
gah (12851)
7/15/2012 7:18:44 PM
On Monday, 16 July 2012 05:18:44 UTC+10, glen herrmannsfeldt  wrote:

> It does complicate starting comments in column 1.

Not on Windows and other implementations.

Only on the mainframe.  But isn't there a way around that?
0
robin.vowels (428)
7/16/2012 12:09:44 AM
On Sunday, 15 July 2012 10:32:51 UTC+10, John W Kennedy  wrote:

> Some /very/ common features, such as "/* ... */" comments, can be 
> traced back to PL/I. On the other hand, many languages have been 
> influenced in a negative way by PL/I. All modern languages have typed 
> pointers, for example, because the experience with PL/I anonymous 
> pointers was so terrible.

Languages after PL/I offered untyped pointers.
My experience with the original pointers in PL/I was favorable.
Now you have the choice of both typed and untyped pointers.

> Similarly, all modern languages have lexical 
> scoping of exception handlers, and do not allow return to the point of 
> exception because the dynamic PL/I ON statement and the ability to 
> return from an ON-unit were so destructive.

The trapping of an error condition in PL/I is like a procedure call.
There's nothing strange or unruly about that.
It provides the ability to handle the error and to recover from it.
That's especially useful in the case of conversion errors,
and in the case of stringrange and stringsize errors,
where the normal action is to continue execution from the
point where the error occurred.  Similarly for underflow and overflow.

It's an essential feature of a real-time system.

At a time when waiting a week for a re-run of a non-PL/I program
that failed because of an error, the ability of PL/I to continue
processing from the point of interruption for certain non-fatal
classes of error was a masterful design.

> In many ways, PL/I was as 
> much a "great leap forward" experiment as anything else, and, as usual 
> in such cases, it was as valuable for its failures as for its successes.

PL/I wasn't an "experiment".  It was a huge advance over
anything else at the time, and offered facilities that
until then had only been available in individual languages.

Where the language incorporated features from other languages,
they were considerably improved upon, most notably in the area
of I/O.
0
robin.vowels (428)
7/16/2012 12:36:31 AM
On 2012-07-16 00:09:44 +0000, robin.vowels@gmail.com said:

> On Monday, 16 July 2012 05:18:44 UTC+10, glen herrmannsfeldt  wrote:
> 
>> It does complicate starting comments in column 1.
> 
> Not on Windows and other implementations.
> 
> Only on the mainframe.  But isn't there a way around that?

Only on //SYSIN DD * -- and the solution, going back to the very 
beginning of PL/I, is to exclude column 1 from the input. (And soon 
after, someone came up with the idea to put '1', '0', or '-' in column 
1 to format the print listing.) Nowadays, source code is normally read 
from a file (or PDS member), and '/*' in column 1 is not a problem.

-- 
John W Kennedy
"...when you're trying to build a house of cards, the last thing you 
should do is blow hard and wave your hands like a madman."
  --  Rupert Goodwins

0
jwkenne (1442)
7/16/2012 12:58:51 AM
robin.vowels@gmail.com wrote:
> On Sunday, 15 July 2012 10:32:51 UTC+10, John W Kennedy  wrote:

(snip)
>> Similarly, all modern languages have lexical 
>> scoping of exception handlers, and do not allow return to the point of 
>> exception because the dynamic PL/I ON statement and the ability to 
>> return from an ON-unit were so destructive.

> The trapping of an error condition in PL/I is like a procedure call.
> There's nothing strange or unruly about that.

On many systems, it isn't so easy to do.
Especially note the IBM 360/91 where I ran many PL/I programs.

> It provides the ability to handle the error and to recover from it.
> That's especially useful in the case of conversion errors,
> and in the case of stringrange and stringsize errors,
> where the normal action is to continue execution from the
> point where the error occurred.  Similarly for underflow and overflow.

Overflow and underflow are not easy in the case of imprecise
interrupts. You can't get back to where the error actually
occured, and you can't get the address of the data to fix it.

> It's an essential feature of a real-time system.

> At a time when waiting a week for a re-run of a non-PL/I program
> that failed because of an error, the ability of PL/I to continue
> processing from the point of interruption for certain non-fatal
> classes of error was a masterful design.

Depending on how close you need to get. With the Java try/catch
system you get close, and to a known spot at the appropriate
time, but not exactly back to the point of interruption.

>> In many ways, PL/I was as  much a "great leap forward" 
>> experiment as anything else, and, as usual in such cases, 
>> it was as valuable for its failures as for its successes.

> PL/I wasn't an "experiment".  It was a huge advance over
> anything else at the time, and offered facilities that
> until then had only been available in individual languages.

It was a huge advance, but also an experiment. Many things
hadn't been done before and were defined into the language
before anyone had time to try them out and understand them.

> Where the language incorporated features from other languages,
> they were considerably improved upon, most notably in the area
> of I/O.

In that case, you can say it wasn't an experiment.

If you look at most language updates, the new features were
extensions in some previous version before being added.
That wan't done for much of PL/I.

-- glen
0
gah (12851)
7/16/2012 2:05:12 AM
John W Kennedy <jwkenne@attglobal.net> wrote:

(snip regarding /* and OS/360 JCL)

>>> It does complicate starting comments in column 1.
 
>> Not on Windows and other implementations.
 
>> Only on the mainframe.  But isn't there a way around that?

> Only on //SYSIN DD * -- and the solution, going back to the very 
> beginning of PL/I, is to exclude column 1 from the input. 

I once had a file that contained a PL/I program and a Fortran
callable assembler program. All the PL/I lines had * in column 1
(assembler comment) and the assembler program had /* and */
around it.

> (And soon after, someone came up with the idea to put '1', '0', 
> or '-' in column 1 to format the print listing.) 

I once did this, including '+' to double print (bold) some comments.
You can make nice looking program listings this way.

> Nowadays, source code is normally read 
> from a file (or PDS member), and '/*' in column 1 is not a problem.

But you have to get it into the PDS.

Sometime later, I believe MVS, DD DATA,DLM=xx

was added, where you can supply your own two character delimiter.

DD * will stop at either /* or // (other JCL), DD DATA will
read through // (so you can read in JCL, such as PROCLIB).

-- glen
0
gah (12851)
7/16/2012 2:11:42 AM
On Monday, 16 July 2012 10:58:51 UTC+10, John W Kennedy  wrote:
> On 2012-07-16 00:09:44 +0000, r......@gmail.com said:
> 
> > On Monday, 16 July 2012 05:18:44 UTC+10, glen herrmannsfeldt  wrote:
>
> >> It does complicate starting comments in column 1.
>
> >> Not on Windows and other implementations.
>
> > Only on the mainframe.  But isn't there a way around that?
> 
> Only on //SYSIN DD * --

Wasn't it something like //SYSIN DD DATA?

> and the solution, going back to the very 
> beginning of PL/I, is to exclude column 1 from the input.

No it wasn't.  We used columns 1-80, as it was always and
obviously intended.

> (And soon 
> after, someone came up with the idea to put '1', '0', or '-' in column 
> 1 to format the print listing.)

We didn't use that.  Silly idea.

> Nowadays, source code is normally read 
> from a file (or PDS member), and '/*' in column 1 is not a problem.
0
robin.vowels (428)
7/16/2012 9:54:17 AM
On Monday, 16 July 2012 12:05:12 UTC+10, glen herrmannsfeldt  wrote:
> r......@gmail.com wrote:
> &gt; On Sunday, 15 July 2012 10:32:51 UTC+10, John W Kennedy  wrote:
> 
> (snip)
> &gt;&gt; Similarly, all modern languages have lexical 
> &gt;&gt; scoping of exception handlers, and do not allow return to the point of 
> &gt;&gt; exception because the dynamic PL/I ON statement and the ability to 
> &gt;&gt; return from an ON-unit were so destructive.
> 
> &gt; The trapping of an error condition in PL/I is like a procedure call.
> &gt; There&#39;s nothing strange or unruly about that.
> 
> On many systems, it isn't so easy to do.
> Especially note the IBM 360/91 where I ran many PL/I programs.

I seem to recall the option NOIMPRECISE.

> &gt; It provides the ability to handle the error and to recover from it.
> &gt; That's especially useful in the case of conversion errors,
> &gt; and in the case of stringrange and stringsize errors,
> &gt; where the normal action is to continue execution from the
> &gt; point where the error occurred.  Similarly for underflow and overflow.
> 
> Overflow and underflow are not easy in the case of imprecise
> interrupts. You can&#39;t get back to where the error actually
> occured, and you can&#39;t get the address of the data to fix it.

The data is in a register when underflow and overflow occur.
A HLL programmer doesn't usually get the address of registers.

In the case of underflow, the standard system action is to proceed with zero.  Normal return is to the next instruction.

In the case of overflow, normal return is to the next instruction.

> &gt; It&#39;s an essential feature of a real-time system.
> 
> &gt; At a time when waiting a week for a re-run of a non-PL/I program
> &gt; that failed because of an error, the ability of PL/I to continue
> &gt; processing from the point of interruption for certain non-fatal
> &gt; classes of error was a masterful design.
> 
> Depending on how close you need to get. With the Java

Java hadn't been invented when PL/I was released.

> try/catch
> system you get close, and to a known spot at the appropriate
> time, but not exactly back to the point of interruption.

Precisely my point.
In PL/I, you have the choice.  Either continue from the point
of interruption(for certain classes of error) , or,
continue from some other appropriate and well-defined place in the
program (such as the beginning of a loop, or to terminate the
procedure, etc).
You don't have that choice with the language you mention.

And let's not forget user-defined conditions, that can be
activated by a SIGNAL statement; in such cases, control
normally returns to the following statement.

> &gt;&gt; In many ways, PL/I was as  much a &quot;great leap forward&quot; 
> &gt;&gt; experiment as anything else, and, as usual in such cases, 
> &gt;&gt; it was as valuable for its failures as for its successes.
> 
> > PL/I wasn't an "experiment".  It was a huge advance over
> > anything else at the time, and offered facilities that
> > until then had only been available in individual languages.
> 
> It was a huge advance, but also an experiment.

No it wasn't.  It was a new language, intended for production.
Are you going to say that the first implementations of
Algol, BASIC, C, etc etc etc were 'experiments'?

> Many things
> hadn't been done
> before and were defined into the language
> before anyone had time to try them out and understand them.

It is unlikely that at the time that a new language is released
that anyone has time to "try them out".

> > Where the language incorporated features from other languages,
> > they were considerably improved upon, most notably in the area
> > of I/O.
> 
> In that case, you can say it wasn't an experiment.

In all cases, it wasn't an experiment.

> If you look at most language updates, the new features were
> extensions in some previous version before being added.
> That wan't done for much of PL/I.

But in all languages there was a first version,
and PL/I was no different from any of the other languages
in that respect.
Any changes that were made were made as a result of experience
with the language, and that was done in the case of PL/I.
Though, of course, fewer changes were warranted in the case of PL/I (compared with other languages) because it was well-designed in the first place.
0
robin.vowels (428)
7/16/2012 10:53:49 AM
robin.vowels@gmail.com wrote:

(snip on exception models for high-level languages)

>> On many systems, it isn't so easy to do.
>> Especially note the IBM 360/91 where I ran many PL/I programs.

> I seem to recall the option NOIMPRECISE.

There is a hardware switch that will turn off much of the
instruction overlap. 

Also, some compilers have options to generate different code.

PL/I (F) with the, I believe, M91 option changes the run-time
messages to say NEAR instead of IN. 

With the STMT option (to keep track of statement numbers at
run time) it generates BR 0 instruction between statements,
so that there won't be any out-of-order execution across statement
boundaries (and likely run slower).

(snip)

>> Overflow and underflow are not easy in the case of imprecise
>> interrupts. You can't get back to where the error actually
>> occured, and you can't get the address of the data to fix it.

> The data is in a register when underflow and overflow occur.
> A HLL programmer doesn't usually get the address of registers.

To find which register, the tradition is to use the instruction
length code to back up from the address in the OPSW, then examine
the offending instruction. From that, you can figure out which
register contains the result.

> In the case of underflow, the standard system action is to 
> proceed with zero.  Normal return is to the next instruction.

Depends on the program mask bit, and also is different on the 91.

> In the case of overflow, normal return is to the next instruction.

(snip)

>> try/catch
>> system you get close, and to a known spot at the appropriate
>> time, but not exactly back to the point of interruption.

> Precisely my point.

> In PL/I, you have the choice.  Either continue from the point
> of interruption(for certain classes of error) , or,
> continue from some other appropriate and well-defined place in the
> program (such as the beginning of a loop, or to terminate the
> procedure, etc).
> You don't have that choice with the language you mention.

With try/catch the programmer can make sure that the appropriate
variables have the right value in each case. As not all processors
can get back to the point of interruption with the registers
in the appropriate condition, it might be a better choice.

(snip, I wrote) 
>> It was a huge advance, but also an experiment.

> No it wasn't.  It was a new language, intended for production.
> Are you going to say that the first implementations of
> Algol, BASIC, C, etc etc etc were 'experiments'?

ALGOL, likely. Notice that call-by-name has not been used by
any other language. 

BASIC has mostly ideas that previously existed in other
languages, simplified somewhat.

C was preceded by BCPL and B, which could be considered the
experiments. It took three tries to get it right.

>> Many things hadn't been done
>> before and were defined into the language
>> before anyone had time to try them out and understand them.

> It is unlikely that at the time that a new language is released
> that anyone has time to "try them out".

(snip)

> But in all languages there was a first version,
> and PL/I was no different from any of the other languages
> in that respect.

It was different in the number of features added that hadn't
existed in other languages, or in the way those features were
combined.

Fortran I was the experiment, many things were changed for
Fortran II, and more for Fortran IV. Note how fast Fortran I
and Fortran II died out, while Fortran IV lasted much longer.

> Any changes that were made were made as a result of experience
> with the language, and that was done in the case of PL/I.
> Though, of course, fewer changes were warranted in the case 
> of PL/I (compared with other languages) because it was 
> well-designed in the first place.

Personally, yes, they did an amazingly good job given the time
and processors available. They might have done better with more
time and more testing.

-- glen

0
gah (12851)
7/16/2012 11:30:51 AM
robin.vowels@gmail.com wrote:

(snip regarding starting comments in column 1.)

>> Only on //SYSIN DD * --

> Wasn't it something like //SYSIN DD DATA?

DD DATA will read through // in column 1, but not /*.

Somewhat later, DD DATA,DLM=xx was added. You choose the two character
delimiter that you will use.

>> and the solution, going back to the very 
>> beginning of PL/I, is to exclude column 1 from the input.

> No it wasn't.  We used columns 1-80, as it was always and
> obviously intended.

Many systems used SORMGIN=(2,72) or (2,80). (Depending on putting
sequence numbers in 73-80 or not.)

>> (And soon 
>> after, someone came up with the idea to put '1', '0', or '-' in column 
>> 1 to format the print listing.)

> We didn't use that.  Silly idea.

The third field of SORMGIN, allows one to generate carriage control
for the listing file. I did it once to make a nice listing, 
including overprinting (bold) for some comments. Start procedures
at the top of a page, things like that.

-- glen
0
gah (12851)
7/16/2012 11:35:23 AM
On 2012-07-16 02:11:42 +0000, glen herrmannsfeldt said:

> John W Kennedy <jwkenne@attglobal.net> wrote:
> 
> (snip regarding /* and OS/360 JCL)
> 
>>>> It does complicate starting comments in column 1.
> 
>>> Not on Windows and other implementations.
> 
>>> Only on the mainframe.  But isn't there a way around that?
> 
>> Only on //SYSIN DD * -- and the solution, going back to the very
>> beginning of PL/I, is to exclude column 1 from the input.
> 
> I once had a file that contained a PL/I program and a Fortran
> callable assembler program. All the PL/I lines had * in column 1
> (assembler comment) and the assembler program had /* and */
> around it.
> 
>> (And soon after, someone came up with the idea to put '1', '0',
>> or '-' in column 1 to format the print listing.)
> 
> I once did this, including '+' to double print (bold) some comments.
> You can make nice looking program listings this way.
> 
>> Nowadays, source code is normally read
>> from a file (or PDS member), and '/*' in column 1 is not a problem.
> 
> But you have to get it into the PDS.

That's why God gave us ISPF.

> Sometime later, I believe MVS, DD DATA,DLM=xx
> 
> was added, where you can supply your own two character delimiter.
> 
> DD * will stop at either /* or // (other JCL), DD DATA will
> read through // (so you can read in JCL, such as PROCLIB).

Yes, but the column-1 convention was already standard in PL/I by then.

-- 
John W Kennedy
"The pathetic hope that the White House will turn a Caligula into a 
Marcus Aurelius is as naïve as the fear that ultimate power inevitably 
corrupts."
  -- James D. Barber (1930-2004)


0
jwkenne (1442)
7/16/2012 1:25:27 PM
On 2012-07-16 11:30:51 +0000, glen herrmannsfeldt said:

> robin.vowels@gmail.com wrote:
> 
> (snip on exception models for high-level languages)
> 
>>> On many systems, it isn't so easy to do.
>>> Especially note the IBM 360/91 where I ran many PL/I programs.
> 
>> I seem to recall the option NOIMPRECISE.
> 
> There is a hardware switch that will turn off much of the
> instruction overlap.
> 
> Also, some compilers have options to generate different code.
> 
> PL/I (F) with the, I believe, M91 option changes the run-time
> messages to say NEAR instead of IN.
> 
> With the STMT option (to keep track of statement numbers at
> run time) it generates BR 0 instruction between statements,
> so that there won't be any out-of-order execution across statement
> boundaries (and likely run slower).
> 
> (snip)
> 
>>> Overflow and underflow are not easy in the case of imprecise
>>> interrupts. You can't get back to where the error actually
>>> occured, and you can't get the address of the data to fix it.
> 
>> The data is in a register when underflow and overflow occur.
>> A HLL programmer doesn't usually get the address of registers.
> 
> To find which register, the tradition is to use the instruction
> length code to back up from the address in the OPSW, then examine
> the offending instruction. From that, you can figure out which
> register contains the result.
> 
>> In the case of underflow, the standard system action is to
>> proceed with zero.  Normal return is to the next instruction.
> 
> Depends on the program mask bit, and also is different on the 91.
> 
>> In the case of overflow, normal return is to the next instruction.
> 
> (snip)
> 
>>> try/catch
>>> system you get close, and to a known spot at the appropriate
>>> time, but not exactly back to the point of interruption.
> 
>> Precisely my point.
> 
>> In PL/I, you have the choice.  Either continue from the point
>> of interruption(for certain classes of error) , or,
>> continue from some other appropriate and well-defined place in the
>> program (such as the beginning of a loop, or to terminate the
>> procedure, etc).
>> You don't have that choice with the language you mention.
> 
> With try/catch the programmer can make sure that the appropriate
> variables have the right value in each case. As not all processors
> can get back to the point of interruption with the registers
> in the appropriate condition, it might be a better choice.
> 
> (snip, I wrote)
>>> It was a huge advance, but also an experiment.
> 
>> No it wasn't.  It was a new language, intended for production.
>> Are you going to say that the first implementations of
>> Algol, BASIC, C, etc etc etc were 'experiments'?
> 
> ALGOL, likely. Notice that call-by-name has not been used by
> any other language.

And neither has the notion of two different syntaxes, one for 
publication, and one for actually getting one's hands dirty with 
compilation.

> BASIC has mostly ideas that previously existed in other
> languages, simplified somewhat.
> 
> C was preceded by BCPL and B, which could be considered the
> experiments. It took three tries to get it right.

And even then it has the horrible zero-terminated-string feature.


> 
>>> Many things hadn't been done
>>> before and were defined into the language
>>> before anyone had time to try them out and understand them.
> 
>> It is unlikely that at the time that a new language is released
>> that anyone has time to "try them out".
> 
> (snip)
> 
>> But in all languages there was a first version,
>> and PL/I was no different from any of the other languages
>> in that respect.
> 
> It was different in the number of features added that hadn't
> existed in other languages, or in the way those features were
> combined.
> 
> Fortran I was the experiment, many things were changed for
> Fortran II, and more for Fortran IV. Note how fast Fortran I
> and Fortran II died out, while Fortran IV lasted much longer.
> 
>> Any changes that were made were made as a result of experience
>> with the language, and that was done in the case of PL/I.
>> Though, of course, fewer changes were warranted in the case
>> of PL/I (compared with other languages) because it was
>> well-designed in the first place.
> 
> Personally, yes, they did an amazingly good job given the time
> and processors available. They might have done better with more
> time and more testing.

-- 
John W Kennedy
"The poor have sometimes objected to being governed badly; the rich 
have always objected to being governed at all."
  -- G. K. Chesterton.  "The Man Who Was Thursday"

0
jwkenne (1442)
7/16/2012 1:48:20 PM
On Mon, 16 Jul 2012 02:11:42 +0000 (UTC), glen herrmannsfeldt wrote in post 
: <news:jtvt8u$phc$1@speranza.aioe.org> :

>> (And soon after, someone came up with the idea to put '1', '0', 
>> or '-' in column 1 to format the print listing.) 
> 
> I once did this, including '+' to double print (bold) some comments.
> You can make nice looking program listings this way.

It was quite common for us to do that during the 80s and early 90s, at 
least in the UK, Germany and Austria.
As you say, make important bits of the code bold, nicely breaking up code 
blocks .... very useful it was too.

-- 
Tim C.  
0
7/16/2012 2:18:33 PM
In <jtvt8u$phc$1@speranza.aioe.org>, on 07/16/2012
   at 02:11 AM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:

>Sometime later, I believe MVS, DD DATA,DLM=xx

>was added,

OS/360; I don't recall the release.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
spamtrap16 (3722)
7/16/2012 2:19:01 PM
In <ju0u1b$vg3$1@speranza.aioe.org>, on 07/16/2012
   at 11:30 AM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:

>There is a hardware switch that will turn off much of the instruction
>overlap.

You can also flush it under program control. From GA22-6907-3, IBM
System/360 Model 91, Functional Characteristics:

"If preciseness is a principal concern, the unwanted effects of
imprecise program interruptions can usually be eliminated by testing
and masking, as appropriate, and by using this BRANCH ON CONDITION
instruction:

 MNEMONIC   TYPE   Ml FIELD   R2 FIELD
   BCR       RR    Not zero    Zero

This branch instruction is a no-operation instruction for all of
System/360 but is implemented in the Model 91 in such a way that its
execution is delayed until all previously decoded instructions have
been completed."

>To find which register, the tradition is to use the instruction
>length code to back up from the address in the OPSW, then examine
>the offending instruction.

That won't work for multiple imprecise interrupts.

>ALGOL, likely. Notice that call-by-name has not been used by any
>other language. 

Thunks for the memories.

>C was preceded by BCPL and B, which could be considered the
>experiments. It took three tries to get it right.

FSVO right.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
spamtrap16 (3722)
7/16/2012 2:36:50 PM
Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> wrote:

(snip regarding the IBM 360/91)

>>There is a hardware switch that will turn off much of the 
>> instruction overlap.

> You can also flush it under program control. From GA22-6907-3, IBM
> System/360 Model 91, Functional Characteristics:

> "If preciseness is a principal concern, the unwanted effects of
> imprecise program interruptions can usually be eliminated by testing
> and masking, as appropriate, and by using this BRANCH ON CONDITION
> instruction:

> MNEMONIC   TYPE   Ml FIELD   R2 FIELD
>   BCR       RR    Not zero    Zero

With the M91 and STMT option, the PL/I (F) compiler puts such
instruction between statements. 

I found a bug in a debugger once while debugging a PL/I program.

If you put a breakpoint in a program (it replaced two bytes
with an SVC) and then continued after the breakpoint, it
had to emulate the instruction that was there. It seems that
they didn't get the logic right, and it actually branched to
the address in register zero.

> This branch instruction is a no-operation instruction for all of
> System/360 but is implemented in the Model 91 in such a way that its
> execution is delayed until all previously decoded instructions have
> been completed."

>>To find which register, the tradition is to use the instruction
>>length code to back up from the address in the OPSW, then examine
>>the offending instruction.

> That won't work for multiple imprecise interrupts.

I won't work for single imprecise interrupts, either. Among
others, the Fortran fixup for misaligned data (usually in COMMON)
didn't work on the 91. (Better to fix the COMMON, anyway.)

There is a table on which exceptions are always, sometimes,
or never imprecise, assuming overlap mode is on.

>>ALGOL, likely. Notice that call-by-name has not been used by any
>>other language. 

> Thunks for the memories.

Ha ha.

>>C was preceded by BCPL and B, which could be considered the
>>experiments. It took three tries to get it right.

> FSVO right.

Well, right enough to get pretty popular. 

I would call BCPL and B the experiments.

As I noted recently in a different newsgroup, WATFIV had
many Fortran 77 features in 1973. At the time, I just thought
of them as new extensions, but it seems more like trying
them out before the standard was final.

-- glen

0
gah (12851)
7/16/2012 7:42:22 PM
On 2012-07-16 14:17:07 +0000, Shmuel (Seymour J.) Metz said:

> In <5002edd2$0$11531$607ed4bc@cv.net>, on 07/15/2012
>    at 12:20 PM, John W Kennedy <jwkenne@attglobal.net> said:
> 
>> Not "late 60s and 70s".
> 
> WTF? When do you think that JCL and EXEC came along?
> 
>> You're neglecting the general schema of:
> 
>> command [pos-arg...] [keyword(operand [, operand]...)]
> 
> That's not enough to make it PL/I like, especially when there an & in
> front of every variable name, there's a SET statement instead of a
> simple assignment statement and string constants are not quoted.
> 
>> Early 360-era command languages looked like assembler. Later ones
>> looked like PL/I
> 
> FSVO looked, as in "A mouse looks like an elephant, if you've never
> seen a mouse and never seen an elephant."

It remains a fact that OS/360, from the start, used assembler-like 
constructs for everything from JCL, to utility-program control cards, 
to PARM values, and IBM then made a consistent shift to PL/I-like 
constructs for such purposes in new applications starting around 1969.


-- 
John W Kennedy
"When a man contemplates forcing his own convictions down another man's 
throat, he is contemplating both an unchristian act and an act of 
treason to the United States."
  -- Joy Davidman, "Smoke on the Mountain"

0
jwkenne (1442)
7/16/2012 10:01:06 PM
On 2012-07-16 19:46:35 +0000, glen herrmannsfeldt said:

> Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> wrote:
> 
> (snip)
>>> Not "late 60s and 70s".
> 
>> WTF? When do you think that JCL and EXEC came along?
> 
> (snip)
> 
>>> Early 360-era command languages looked like assembler. Later ones
>>> looked like PL/I
> 
>> FSVO looked, as in "A mouse looks like an elephant, if you've never
>> seen a mouse and never seen an elephant."
> 
> Well, JCL does have a similar form to S/360 assembler, especially
> before the continuation was changed. As I understand it, in early
> JCL you had to have a continuation character in column 72 to
> continue on the next card. Sometime later, ending with a comma,
> at the appropriate point, was enough.

Yup. And all the IBC..., IEB..., and IEH... utilities were more or less 
the same. (IEBUPDAT and its successor, IEBUPDTE, of course, needed the 
special './' delimiter, from the very nature of what they did). The 
second version of IEBCOPY (the program was rewritten from the ground up 
at one point) stretched the assembler-like syntax about as far as it 
could go, but it was still rooted in assembler.

-- 
John W Kennedy
"Only an idiot fights a war on two fronts.  Only the heir to the throne 
of the kingdom of idiots would fight a war on twelve fronts"
 -- J. Michael Straczynski.  "Babylon 5", "Ceremonies of Light and Dark"

0
jwkenne (1442)
7/16/2012 10:08:38 PM
On 7/14/2012 8:32 PM, John W Kennedy wrote:
> On 2012-07-14 23:49:49 +0000, robin.vowels@gmail.com said:
>
>> On Saturday, 14 July 2012 19:44:14 UTC+10, (unknown)  wrote:
>>
>>> not exactly new-news, but I noticed that the CL programming language
>>> (JCL/shell-script for the IBM iSeries/System i/whatever it's called
>>> now) had some enhancements a few releases ago.
>>>
>>> You can now declare based and defined variables. If you don't declare
>>> the storage class, it defaults to automatic (which you can also
>>> declare explicitly) although the syntax is different, this seems very
>>> PL/1 like.
>>
>> Interesting.
>>
>> Other older ones include PL/M and XPL. Any others?
>
> Some /very/ common features, such as "/* ... */" comments, can be traced
> back to PL/I. On the other hand, many languages have been influenced in
> a negative way by PL/I. All modern languages have typed pointers, for
> example, because the experience with PL/I anonymous pointers was so
> terrible. Similarly, all modern languages have lexical scoping of
> exception handlers, and do not allow return to the point of exception
> because the dynamic PL/I ON statement and the ability to return from an
> ON-unit were so destructive. In many ways, PL/I was as much a "great
> leap forward" experiment as anything else, and, as usual in such cases,
> it was as valuable for its failures as for its successes.
>

Once again, John, we'll have to "agree to disagree."  I think the reason 
other languages don't have lexically scoped error handling is because 1) 
It is difficult to implement properly, 2) It confuses programmers who 
don't understand it.  I have found it very useful end elegant, and it 
solves a lot of otherwise difficult problems.

As for typed pointers I haven't looked too closely, but I believe 
Enterprise PL/I has typed "handles", and uses builtins instead of the 
confusing C mishmash.  I have had C statements that I changed six ways 
from Sunday and still couldn't get to compile.  I had to create 
temporary pointers and assign values to them with casts to get the code 
to work - or be understandable.

-- 
Pete


0
Peter_Flass (956)
7/16/2012 11:38:55 PM
On 7/15/2012 8:09 PM, robin.vowels@gmail.com wrote:
> On Monday, 16 July 2012 05:18:44 UTC+10, glen herrmannsfeldt  wrote:
>
>> It does complicate starting comments in column 1.
>
> Not on Windows and other implementations.
>
> Only on the mainframe.  But isn't there a way around that?
>

//SYSIN DD DATA,DLM=$$ and the PL/I option M(1,72) [I believe].  Then 
end your source deck with '$$' instead of '/*'.  Of course no one uses 
cards these days, so the question is moot.

-- 
Pete


0
Peter_Flass (956)
7/16/2012 11:42:35 PM
On 7/15/2012 8:36 PM, robin.vowels@gmail.com wrote:

>
> PL/I wasn't an "experiment".  It was a huge advance over
> anything else at the time, and offered facilities that
> until then had only been available in individual languages.

And a huge advance over its successors, as well ;-)


-- 
Pete


0
Peter_Flass (956)
7/16/2012 11:43:52 PM
On 7/15/2012 10:11 PM, glen herrmannsfeldt wrote:
> John W Kennedy <jwkenne@attglobal.net> wrote:
>
> (snip regarding /* and OS/360 JCL)
>
>>>> It does complicate starting comments in column 1.
>
>>> Not on Windows and other implementations.
>
>>> Only on the mainframe.  But isn't there a way around that?
>
>> Only on //SYSIN DD * -- and the solution, going back to the very
>> beginning of PL/I, is to exclude column 1 from the input.
>
> I once had a file that contained a PL/I program and a Fortran
> callable assembler program. All the PL/I lines had * in column 1
> (assembler comment) and the assembler program had /* and */
> around it.

That's also the PL/S technique for dual-language macros.

-- 
Pete


0
Peter_Flass (956)
7/16/2012 11:46:19 PM
Peter Flass <Peter_Flass@yahoo.com> wrote:
> On 7/15/2012 8:36 PM, robin.vowels@gmail.com wrote:

>> PL/I wasn't an "experiment".  It was a huge advance over
>> anything else at the time, and offered facilities that
>> until then had only been available in individual languages.

All of which doesn't prove it wasn't an experiment.

> And a huge advance over its successors, as well ;-)

Fortran 2008 might be close. Maybe we will see compilers by 2030.

-- glen

0
gah (12851)
7/16/2012 11:51:56 PM
Peter Flass <Peter_Flass@yahoo.com> wrote:

(snip)
> //SYSIN DD DATA,DLM=$$ and the PL/I option M(1,72) [I believe].  Then 
> end your source deck with '$$' instead of '/*'.  Of course no one uses 
> cards these days, so the question is moot.

If you use batch submission with MVS or z/OS it is still there,
real cards or virtual cards.

In the 1970's and 1980's I worked with WYLBUR more than real
cards, submitting jobs with DD * and DD DATA. 

I am not sure by now, if DLM is an OS feature or a JES feature.

If JES gets to the job stream early enough, it might be that OS
never sees them. (And ASP/JES3 works somewhat different from 
HASP/JES2 as far as input stream processing.)

-- glen
0
gah (12851)
7/16/2012 11:58:13 PM
On Monday, 16 July 2012 21:30:51 UTC+10, glen herrmannsfeldt  wrote:
> ro.....@gmail.com wrote:
> 
> (snip on exception models for high-level languages)
> 
> &gt;&gt; On many systems, it isn&#39;t so easy to do.
> &gt;&gt; Especially note the IBM 360/91 where I ran many PL/I programs.
> 
> &gt; I seem to recall the option NOIMPRECISE.
> 
> There is a hardware switch that will turn off much of the
> instruction overlap. 

I'm referring to the PL/I compiler option.

> Also, some compilers have options to generate different code.
> 
> &gt;&gt; Overflow and underflow are not easy in the case of imprecise
> &gt;&gt; interrupts. You can&#39;t get back to where the error actually
> &gt;&gt; occured, and you can&#39;t get the address of the data to fix it.
> 
> &gt; The data is in a register when underflow and overflow occur.
> &gt; A HLL programmer doesn&#39;t usually get the address of registers.

> To find which register,

That's irrelevant.  You said that you can't get back
to the data to fix it [in the PL/I program].

You are now talking about analyzing a memory dump,
and using a PSW.

> the tradition is to use the instruction
> length code to back up from the address in the OPSW, then examine
> the offending instruction. From that, you can figure out which
> register contains the result.

Totally irrelevant.

> &gt; In the case of underflow, the standard system action is to 
> &gt; proceed with zero.  Normal return is to the next instruction.
> 
> Depends on the program mask bit, and also is different on the 91.
> 
> &gt; In the case of overflow, normal return is to the next instruction.
> 
> (snip)
> 
> &gt;&gt; try/catch
> &gt;&gt; system you get close, and to a known spot at the appropriate
> &gt;&gt; time, but not exactly back to the point of interruption.
> 
> &gt; Precisely my point.
> 
> &gt; In PL/I, you have the choice.  Either continue from the point
> &gt; of interruption(for certain classes of error) , or,
> &gt; continue from some other appropriate and well-defined place in the
> &gt; program (such as the beginning of a loop, or to terminate the
> &gt; procedure, etc).
> &gt; You don&#39;t have that choice with the language you mention.
> 
> With try/catch the programmer can make sure that the appropriate
> variables have the right value in each case. As not all processors
> can get back to the point of interruption with the registers
> in the appropriate condition,

When an interrupt occurs, either the processor saves the registers,
or the OS saves the registers.  From that, the registers
are restored when the program resumes.
That is required whenever an interrupt occurs.
Without that guarantee, a program could never be guaranteed
to complete execution, because interrupts occur at any time
during the execution of a program from any cause (including
from other programs and/or threads that the OS may be running).

> it might be a better choice.


> 
> (snip, I wrote) 
> &gt;&gt; It was a huge advance, but also an experiment.
> 
> &gt; No it wasn&#39;t.  It was a new language, intended for production.
> &gt; Are you going to say that the first implementations of
> &gt; Algol, BASIC, C, etc etc etc were &#39;experiments&#39;?
> 
> ALGOL, likely.

No it never was.

>Notice that call-by-name has not been used by
> any other language.

That's irrelevant.

> BASIC has mostly ideas that previously existed in other
> languages, simplified somewhat.
> 
> C was preceded by BCPL and B, which could be considered the
> experiments. It took three tries to get it right.

It still isn't.

But that doesn't mean anything.  PL/I was preceded by Algol, FORTRAN, COBOL, and many other languages.

> &gt;&gt; Many things hadn&#39;t been done
> &gt;&gt; before and were defined into the language
> &gt;&gt; before anyone had time to try them out and understand them.
> 
> &gt; It is unlikely that at the time that a new language is released
> &gt; that anyone has time to &quot;try them out&quot;.
> 
> (snip)
> 
> &gt; But in all languages there was a first version,
> &gt; and PL/I was no different from any of the other languages
> &gt; in that respect.
> 
> It was different in the number of features added that hadn&#39;t
> existed in other languages, or in the way those features were
> combined.

You are forgetting that PL/I improved on what was in COBOL,
Algol, and FORTRAN.  It was no different from any of those.
Algol improved on what was previously available.
FORTRAN improved on what preceded it.
In that sense, PL/I was not different from Algol, COBOL, and
FORTRAN, and others that preceded and followed it in time.

> Fortran I was the experiment,

It wasn't an "experiment"  It was a serious attempt to get a
compiler that produced code that approached the efficiency
of hand-coded assembler/machine code.

> many things were changed for
> Fortran II, and more for Fortran IV. Note how fast Fortran I
> and Fortran II died out, while Fortran IV lasted much longer.

That's again irrelevant.
In any case, users could perceive things that could be added
to deal with things like changing hardware.

> &gt; Any changes that were made were made as a result of experience
> &gt; with the language, and that was done in the case of PL/I.
> &gt; Though, of course, fewer changes were warranted in the case 
> &gt; of PL/I (compared with other languages) because it was 
> &gt; well-designed in the first place.
> 
> Personally, yes, they did an amazingly good job given the time
> and processors available.

The processor was the S/360.

> They might have done better with more
> time and more testing.

Unlikely.  It was many years before new features were added.
0
robin.vowels (428)
7/17/2012 2:21:38 AM
On Monday, 16 July 2012 21:35:23 UTC+10, glen herrmannsfeldt  wrote:
> r......@gmail.com wrote:
> 
> (snip regarding starting comments in column 1.)
> 
> &gt;&gt; Only on //SYSIN DD * --
> 
> &gt; Wasn&#39;t it something like //SYSIN DD DATA?
> 
> DD DATA will read through // in column 1, but not /*.
> 
> Somewhat later, DD DATA,DLM=xx was added. You choose the two character
> delimiter that you will use.
> 
> &gt;&gt; and the solution, going back to the very 
> &gt;&gt; beginning of PL/I, is to exclude column 1 from the input.
> 
> &gt; No it wasn&#39;t.  We used columns 1-80, as it was always and
> &gt; obviously intended.
> 
> Many systems used SORMGIN=(2,72) or (2,80). (Depending on putting
> sequence numbers in 73-80 or not.)

We used (1,80).
Where IBM's SSP used columns 73-80 for sequence numbers,
we modified the source by enclosing the number in /* and */ .

> &gt;&gt; (And soon 
> &gt;&gt; after, someone came up with the idea to put &#39;1&#39;, &#39;0&#39;, or &#39;-&#39; in column 
> &gt;&gt; 1 to format the print listing.)
> 
> &gt; We didn&#39;t use that.  Silly idea.
> 
> The third field of SORMGIN, allows one to generate carriage control
> for the listing file. I did it once to make a nice listing, 
> including overprinting (bold) for some comments. Start procedures
> at the top of a page, things like that.

%PAGE and %SKIP were intended for doing that.

0
robin.vowels (428)
7/17/2012 2:45:33 AM
On Monday, 16 July 2012 23:48:20 UTC+10, John W Kennedy  wrote:
> On 2012-07-16 11:30:51 +0000, glen herrmannsfeldt said:

> > C was preceded by BCPL and B, which could be considered the
> > experiments. It took three tries to get it right.

> And even then it has the horrible zero-terminated-string feature.

And the facility to produce garbage results on output.

0
robin.vowels (428)
7/17/2012 2:51:13 AM
On Tuesday, 17 July 2012 00:18:33 UTC+10, Tim C.  wrote:
> On Mon, 16 Jul 2012 02:11:42 +0000 (UTC), glen herrmannsfeldt wrote in post 
> : &lt;news:jtvt.......@speranza.aioe.org&gt; :
> 
> &gt;&gt; (And soon after, someone came up with the idea to put &#39;1&#39;, &#39;0&#39;, 
> &gt;&gt; or &#39;-&#39; in column 1 to format the print listing.) 
> &gt; 
> &gt; I once did this, including &#39;+&#39; to double print (bold) some comments.
> &gt; You can make nice looking program listings this way.
> 
> It was quite common for us to do that during the 80s and early 90s, at 
> least in the UK, Germany and Austria.
> As you say, make important bits of the code bold, nicely breaking up code 
> blocks .... very useful it was too.

%PAGE and %SKIP were intended for that purpose.

0
robin.vowels (428)
7/17/2012 2:55:09 AM
On Tuesday, 17 July 2012 09:38:55 UTC+10, Peter Flass  wrote:

> As for typed pointers I haven't looked too closely, but I believe 
> Enterprise PL/I has typed "handles", and uses builtins instead of the 
> confusing C mishmash.

Yes.  Typed pointers (handles) and the built-ins were introduced in
PL/I for OS/2 (1994); that compiler was subsequently ported to
the mainframe.

0
robin.vowels (428)
7/17/2012 3:04:55 AM
On Tuesday, 17 July 2012 09:42:35 UTC+10, Peter Flass  wrote:
> On 7/15/2012 8:09 PM, r.........@gmail.com wrote:
> &gt; On Monday, 16 July 2012 05:18:44 UTC+10, glen herrmannsfeldt  wrote:
> &gt;
> &gt;&gt; It does complicate starting comments in column 1.
> &gt;
> &gt; Not on Windows and other implementations.
> &gt;
> &gt; Only on the mainframe.  But isn&#39;t there a way around that?
> &gt;
> 
> //SYSIN DD DATA,DLM=$$ and the PL/I option M(1,72) [I believe].  Then 
> end your source deck with &#39;$$&#39; instead of &#39;/*&#39;.  Of course no one uses 
> cards these days, so the question is moot.

In Windows, "/*" from the keyboard is taken as end-of-file.

0
robin.vowels (428)
7/17/2012 3:07:11 AM
On Tuesday, 17 July 2012 09:43:52 UTC+10, Peter Flass  wrote:
> On 7/15/2012 8:36 PM, xxxxxx@gmail.com wrote:
> 
> &gt;
> &gt; PL/I wasn&#39;t an &quot;experiment&quot;.  It was a huge advance over
> &gt; anything else at the time, and offered facilities that
> &gt; until then had only been available in individual languages.
> 
> And a huge advance over its successors, as well ;-)

Including Fortran.

You have possibly noted a few recent comments of mine about
Fortran's hack for dealing with variable-width format items
and other things.
For instance, the function CMPLX for handling complex numbers
isn't generic, and precision can be lost without warning.
It lacks error handling and recovery, I/O in recursive procedures, to mention a few.

0
robin.vowels (428)
7/17/2012 3:30:12 AM
On Tuesday, 17 July 2012 09:51:56 UTC+10, glen herrmannsfeldt  wrote:
> Peter Flass &lt;Pet......@yahoo.com&gt; wrote:
> &gt; On 7/15/2012 8:36 PM, xxxxxx@gmail.com wrote:
> 
> &gt;&gt; PL/I wasn&#39;t an &quot;experiment&quot;.  It was a huge advance over
> &gt;&gt; anything else at the time, and offered facilities that
> &gt;&gt; until then had only been available in individual languages.
> 
> All of which doesn&#39;t prove it wasn&#39;t an experiment.

What proof do you want?

PL/I was introduced with the S/360.
No manufacturer is going to introduce an "experiment" with
its flagship hardware and flagship compiler.

> &gt; And a huge advance over its successors, as well ;-)
> 
> Fortran 2008 might be close. Maybe we will see compilers by 2030.

I can't wait.  It's taken Fortran 45 years to get this far,
and it's not even close to what can be done with PL/I.

Meanwhile, I'll enjoy using PL/I.
0
robin.vowels (428)
7/17/2012 3:36:50 AM
robin.vowels@gmail.com wrote:
(snip, I wrote)
>> There is a hardware switch that will turn off much of the
>> instruction overlap. 

> I'm referring to the PL/I compiler option.

(snip) 
>>> The data is in a register when underflow and overflow occur.
>>> A HLL programmer doesn&#39;t usually get the address of registers.

>> To find which register,

> That's irrelevant.  You said that you can't get back
> to the data to fix it [in the PL/I program].

> You are now talking about analyzing a memory dump,
> and using a PSW.

No, it is done by the program. I have seen the programs
that do it, but only for precise interrupts. 

>> the tradition is to use the instruction
>> length code to back up from the address in the OPSW, then examine
>> the offending instruction. From that, you can figure out which
>> register contains the result.

> Totally irrelevant.

Probably not, but I am not likely to go look for it.

With precise interrupts, you can go back, find the register
(where it is saved), change it, then return from the interrupt.

For the 360/91, that is done inside the OS to emulate decimal
instructions. It is done inside a SPIE routine for the extended
precision emulators. It is done in the alignment fixup routine
for Fortran.

-- glen
0
gah (12851)
7/17/2012 3:57:53 AM
On Tuesday, 17 July 2012 13:57:53 UTC+10, glen herrmannsfeldt  wrote:
> xxxxxxx@gmail.com wrote:
> (snip, I wrote)
> &gt;&gt; There is a hardware switch that will turn off much of the
> >> instruction overlap. 
> 
> > I'm referring to the PL/I compiler option.
> 
> (snip) 
> >>> The data is in a register when underflow and overflow occur.
> >>> A HLL programmer doesn't usually get the address of registers.
> 
> >> To find which register,
> 
> > That's irrelevant.  You said that you can't get back
> > to the data to fix it [in the PL/I program].
> 
> > You are now talking about analyzing a memory dump,
> > and using a PSW.
> 
> No, it is done by the program. I have seen the programs
> that do it, but only for precise interrupts. 

It's not done by the program.
It's nothing to do with PL/I.  PL/I programmers
don't see registers, and moreover, don't care about registers.
PL/I doesn't get down to that level.
In a memory dump, such information might be useful to a programmer.

> >> the tradition is to use the instruction
> >> length code to back up from the address in the OPSW, then examine
> >> the offending instruction. From that, you can figure out which
> >> register contains the result.
> 
> > Totally irrelevant.
> 
> Probably not, but I am not likely to go look for it.

Because it's irrelevant.

> With precise interrupts, you can go back, find the register
> (where it is saved), change it, then return from the interrupt.

Who is "you"?
Certainly not a PL/I programmer.
PL/I is not defined down to that level.

In some cases, results are not available in registers
(e.g., bit operations, decimal arithmetic, etc).

> For the 360/91, that is done inside the OS to emulate decimal
> instructions. It is done inside a SPIE routine for the extended
> precision emulators. It is done in the alignment fixup routine
> for Fortran.

Again, irrelevant.  Emulating decimal instructions has nothing
to do with the price of fish.  It has nothing to do with PL/I
other than to support decimal arithmetic.  The only thing that
the PL/I programmer sees is the variable (i.e., storage).
Whether instructions are emulated, microcoded, hardwired, or whatever,
is entirely transparent to the PL/I programmer.

Similarly for the extended precision instructions.
0
robin.vowels (428)
7/17/2012 4:36:32 AM
On 7/16/2012 7:58 PM, glen herrmannsfeldt wrote:
> Peter Flass <Peter_Flass@yahoo.com> wrote:
>
> (snip)
>> //SYSIN DD DATA,DLM=$$ and the PL/I option M(1,72) [I believe].  Then
>> end your source deck with '$$' instead of '/*'.  Of course no one uses
>> cards these days, so the question is moot.
>
> If you use batch submission with MVS or z/OS it is still there,
> real cards or virtual cards.
>
> In the 1970's and 1980's I worked with WYLBUR more than real
> cards, submitting jobs with DD * and DD DATA.
>
> I am not sure by now, if DLM is an OS feature or a JES feature.

Probably JES, because JES creates a separate spool file for each spooled 
dataset.

-- 
Pete


0
Peter_Flass (956)
7/17/2012 9:33:15 AM
On 2012-07-16 23:38:55 +0000, Peter Flass said:

> On 7/14/2012 8:32 PM, John W Kennedy wrote:
>> On 2012-07-14 23:49:49 +0000, robin.vowels@gmail.com said:
>> 
>>> On Saturday, 14 July 2012 19:44:14 UTC+10, (unknown)  wrote:
>>> 
>>>> not exactly new-news, but I noticed that the CL programming language
>>>> (JCL/shell-script for the IBM iSeries/System i/whatever it's called
>>>> now) had some enhancements a few releases ago.
>>>> 
>>>> You can now declare based and defined variables. If you don't declare
>>>> the storage class, it defaults to automatic (which you can also
>>>> declare explicitly) although the syntax is different, this seems very
>>>> PL/1 like.
>>> 
>>> Interesting.
>>> 
>>> Other older ones include PL/M and XPL. Any others?
>> 
>> Some /very/ common features, such as "/* ... */" comments, can be traced
>> back to PL/I. On the other hand, many languages have been influenced in
>> a negative way by PL/I. All modern languages have typed pointers, for
>> example, because the experience with PL/I anonymous pointers was so
>> terrible. Similarly, all modern languages have lexical scoping of
>> exception handlers, and do not allow return to the point of exception
>> because the dynamic PL/I ON statement and the ability to return from an
>> ON-unit were so destructive. In many ways, PL/I was as much a "great
>> leap forward" experiment as anything else, and, as usual in such cases,
>> it was as valuable for its failures as for its successes.
>> 
> 
> Once again, John, we'll have to "agree to disagree."  I think the 
> reason other languages don't have lexically scoped error handling is 
> because 1) It is difficult to implement properly, 2) It confuses 
> programmers who don't understand it.  I have found it very useful end 
> elegant, and it solves a lot of otherwise difficult problems.

No, other languages /do/ have lexically-scoped error handling. What 
they don't have is PL/I's imperative error handling (the ON statement). 
And, no, not because it's particularly difficult to implement, although 
it does add some overhead. They don't do it because, like ALGOL-60 
call-by-name, it's conceptually elegant, but is good for nothing but 
creating code that no one can understand. (Except it really isn't all 
that conceptually elegant, either; I'd bet a considerable amount that 
the ON statement was originally inspired by OS/360 services like SPIE 
and STAE. But OS/360 Assembler doesn't have scoping in the first place.)

> As for typed pointers I haven't looked too closely, but I believe 
> Enterprise PL/I has typed "handles",

Yes, because anonymous pointers suck, and everybody knows it.

> and uses builtins instead of the confusing C mishmash.  I have had C 
> statements that I changed six ways from Sunday and still couldn't get 
> to compile.  I had to create temporary pointers and assign values to 
> them with casts to get the code to work - or be understandable.

I don't think anyone regards C's syntax for typed pointers as 
exemplary. That does not mean that typed pointers are a bad idea.

-- 
John W Kennedy
"The poor have sometimes objected to being governed badly; the rich 
have always objected to being governed at all."
  -- G. K. Chesterton.  "The Man Who Was Thursday"

0
jwkenne (1442)
7/17/2012 4:04:40 PM
On 2012-07-16 23:58:13 +0000, glen herrmannsfeldt said:

> Peter Flass <Peter_Flass@yahoo.com> wrote:
> 
> (snip)
>> //SYSIN DD DATA,DLM=$$ and the PL/I option M(1,72) [I believe].  Then
>> end your source deck with '$$' instead of '/*'.  Of course no one uses
>> cards these days, so the question is moot.
> 
> If you use batch submission with MVS or z/OS it is still there,
> real cards or virtual cards.
> 
> In the 1970's and 1980's I worked with WYLBUR more than real
> cards, submitting jobs with DD * and DD DATA.
> 
> I am not sure by now, if DLM is an OS feature or a JES feature.

JCL, though I daresay the JESs have some awareness.

> If JES gets to the job stream early enough, it might be that OS
> never sees them. (And ASP/JES3 works somewhat different from
> HASP/JES2 as far as input stream processing.)
> 
> -- glen


-- 
John W Kennedy
"Sweet, was Christ crucified to create this chat?"
  -- Charles Williams.  "Judgement at Chelmsford"

0
jwkenne (1442)
7/17/2012 4:06:57 PM
On 2012-07-17 03:36:50 +0000, robin.vowels@gmail.com said:

> On Tuesday, 17 July 2012 09:51:56 UTC+10, glen herrmannsfeldt  wrote:
>> Peter Flass &lt;Pet......@yahoo.com&gt; wrote:
>> &gt; On 7/15/2012 8:36 PM, xxxxxx@gmail.com wrote:
>> 
>> &gt;&gt; PL/I wasn&#39;t an &quot;experiment&quot;.  It was a huge advance over
>> &gt;&gt; anything else at the time, and offered facilities that
>> &gt;&gt; until then had only been available in individual languages.
>> 
>> All of which doesn&#39;t prove it wasn&#39;t an experiment.
> 
> What proof do you want?
> 
> PL/I was introduced with the S/360.
> No manufacturer is going to introduce an "experiment" with
> its flagship hardware and flagship compiler.

Bwah-ha-ha-ha-ha-ha-ha!

You really don't know a damn thing about the history of the S/360, do you?

> 
>> &gt; And a huge advance over its successors, as well ;-)
>> 
>> Fortran 2008 might be close. Maybe we will see compilers by 2030.
> 
> I can't wait.  It's taken Fortran 45 years to get this far,
> and it's not even close to what can be done with PL/I.
> 
> Meanwhile, I'll enjoy using PL/I.


-- 
John W Kennedy
"Those in the seat of power oft forget their failings and seek only the 
obeisance of others!  Thus is bad government born!  Hold in your heart 
that you and the people are one, human beings all, and good government 
shall arise of its own accord!  Such is the path of virtue!"
  -- Kazuo Koike.  "Lone Wolf and Cub:  Thirteen Strings" (tr. Dana Lewis)

0
jwkenne (1442)
7/17/2012 4:08:41 PM
On 2012-07-17 02:45:33 +0000, robin.vowels@gmail.com said:

> On Monday, 16 July 2012 21:35:23 UTC+10, glen herrmannsfeldt  wrote:
>> r......@gmail.com wrote:
>> 
>> (snip regarding starting comments in column 1.)
>> 
>> &gt;&gt; Only on //SYSIN DD * --
>> 
>> &gt; Wasn&#39;t it something like //SYSIN DD DATA?
>> 
>> DD DATA will read through // in column 1, but not /*.
>> 
>> Somewhat later, DD DATA,DLM=xx was added. You choose the two character
>> delimiter that you will use.
>> 
>> &gt;&gt; and the solution, going back to the very
>> &gt;&gt; beginning of PL/I, is to exclude column 1 from the input.
>> 
>> &gt; No it wasn&#39;t.  We used columns 1-80, as it was always and
>> &gt; obviously intended.
>> 
>> Many systems used SORMGIN=(2,72) or (2,80). (Depending on putting
>> sequence numbers in 73-80 or not.)
> 
> We used (1,80).
> Where IBM's SSP used columns 73-80 for sequence numbers,
> we modified the source by enclosing the number in /* and */ .
> 
>> &gt;&gt; (And soon
>> &gt;&gt; after, someone came up with the idea to put &#39;1&#39;, 
>> &#39;0&#39;, or &#39;-&#39; in column
>> &gt;&gt; 1 to format the print listing.)
>> 
>> &gt; We didn&#39;t use that.  Silly idea.
>> 
>> The third field of SORMGIN, allows one to generate carriage control
>> for the listing file. I did it once to make a nice listing,
>> including overprinting (bold) for some comments. Start procedures
>> at the top of a page, things like that.
> 
> %PAGE and %SKIP were intended for doing that.

They appeared only in the Optimizer/Checker generation, and (at least 
in that generation) didn't apply to the macro-input listing.

-- 
John W Kennedy
"Though a Rothschild you may be
In your own capacity,
    As a Company you've come to utter sorrow--
But the Liquidators say,
'Never mind--you needn't pay,'
    So you start another company to-morrow!"
  -- Sir William S. Gilbert.  "Utopia Limited"

0
jwkenne (1442)
7/17/2012 4:12:10 PM
On 2012-07-17 02:51:13 +0000, robin.vowels@gmail.com said:

> On Monday, 16 July 2012 23:48:20 UTC+10, John W Kennedy  wrote:
>> On 2012-07-16 11:30:51 +0000, glen herrmannsfeldt said:
> 
>>> C was preceded by BCPL and B, which could be considered the
>>> experiments. It took three tries to get it right.
> 
>> And even then it has the horrible zero-terminated-string feature.
> 
> And the facility to produce garbage results on output.

Just like every other language from Plankalkül on.

-- 
John W Kennedy
"Those in the seat of power oft forget their failings and seek only the 
obeisance of others!  Thus is bad government born!  Hold in your heart 
that you and the people are one, human beings all, and good government 
shall arise of its own accord!  Such is the path of virtue!"
  -- Kazuo Koike.  "Lone Wolf and Cub:  Thirteen Strings" (tr. Dana Lewis)

0
jwkenne (1442)
7/17/2012 4:14:19 PM
John W Kennedy <jwkenne@attglobal.net> wrote:

(snip)
> No, other languages /do/ have lexically-scoped error handling. What 
> they don't have is PL/I's imperative error handling (the ON statement). 
> And, no, not because it's particularly difficult to implement, although 
> it does add some overhead. They don't do it because, like ALGOL-60 
> call-by-name, it's conceptually elegant, but is good for nothing but 
> creating code that no one can understand. (Except it really isn't all 
> that conceptually elegant, either; I'd bet a considerable amount that 
> the ON statement was originally inspired by OS/360 services like SPIE 
> and STAE. But OS/360 Assembler doesn't have scoping in the first place.)

Well, sometimes the global nature is nice, but often it isn't.

With try/catch, you can make the try block as small or large as
you like. With ON, it is hard to know what other blocks are doing.

>> As for typed pointers I haven't looked too closely, but I believe 
>> Enterprise PL/I has typed "handles",

> Yes, because anonymous pointers suck, and everybody knows it.

For locate mode I/O, maybe they aren't so bad, but for many
pointer uses, yes. 

>> and uses builtins instead of the confusing C mishmash.  I have had C 
>> statements that I changed six ways from Sunday and still couldn't get 
>> to compile.  I had to create temporary pointers and assign values to 
>> them with casts to get the code to work - 

Usually I can get them to work, but ...

> or be understandable.

Yes, that is always the question. 

> I don't think anyone regards C's syntax for typed pointers as 
> exemplary. That does not mean that typed pointers are a bad idea.

-- glen
0
gah (12851)
7/17/2012 7:49:43 PM
John W Kennedy <jwkenne@attglobal.net> wrote:

(snip regarding /* as an EOF notation, I wrote)

>> If you use batch submission with MVS or z/OS it is still there,
>> real cards or virtual cards.
 
(snip) 
>> I am not sure by now, if DLM is an OS feature or a JES feature.

> JCL, though I daresay the JESs have some awareness.

As well as I know, it for OS/360 JES was optional. 

That is, HASP or ASP were add-ons, but the system could run
without one of them. At least by the later MVS days, as well
as I know, one is required.

>> If JES gets to the job stream early enough, it might be that OS
>> never sees them. (And ASP/JES3 works somewhat different from
>> HASP/JES2 as far as input stream processing.)

There is a previous claim that DLM was added in the OS/360 days.

But was it added to OS/360, or just to one or both JES?
(and what ever happened to JES1?)

Also, having two choices (JES2 and JES3) complicates the 
description of what is, and isn't, part of JCL. I believe
I have an MVS 3.8 JCL manual nearby.

-- glen
0
gah (12851)
7/17/2012 7:56:43 PM
On 2012-07-17 19:49:43 +0000, glen herrmannsfeldt said:

> John W Kennedy <jwkenne@attglobal.net> wrote:
> 
> (snip)
>> No, other languages /do/ have lexically-scoped error handling. What
>> they don't have is PL/I's imperative error handling (the ON statement).
>> And, no, not because it's particularly difficult to implement, although
>> it does add some overhead. They don't do it because, like ALGOL-60
>> call-by-name, it's conceptually elegant, but is good for nothing but
>> creating code that no one can understand. (Except it really isn't all
>> that conceptually elegant, either; I'd bet a considerable amount that
>> the ON statement was originally inspired by OS/360 services like SPIE
>> and STAE. But OS/360 Assembler doesn't have scoping in the first place.)
> 
> Well, sometimes the global nature is nice, but often it isn't.
> 
> With try/catch, you can make the try block as small or large as
> you like. With ON, it is hard to know what other blocks are doing.
> 
>>> As for typed pointers I haven't looked too closely, but I believe
>>> Enterprise PL/I has typed "handles",
> 
>> Yes, because anonymous pointers suck, and everybody knows it.
> 
> For locate mode I/O, maybe they aren't so bad, but for many
> pointer uses, yes.

Locate-mode I/O doesn't really exist anymore, except in OS/360 (and 
DOS/360) legacy features -- unless you count data-in-virtual.

>>> and uses builtins instead of the confusing C mishmash.  I have had C
>>> statements that I changed six ways from Sunday and still couldn't get
>>> to compile.  I had to create temporary pointers and assign values to
>>> them with casts to get the code to work -
> 
> Usually I can get them to work, but ...
> 
>> or be understandable.
> 
> Yes, that is always the question.
> 
>> I don't think anyone regards C's syntax for typed pointers as
>> exemplary. That does not mean that typed pointers are a bad idea.
> 
> -- glen


-- 
John W Kennedy
"There are those who argue that everything breaks even in this old dump 
of a world of ours. I suppose these ginks who argue that way hold that 
because the rich man gets ice in the summer and the poor man gets it in 
the winter things are breaking even for both. Maybe so, but I'll swear 
I can't see it that way."
  -- The last words of Bat Masterson

0
jwkenne (1442)
7/17/2012 11:16:47 PM
On 2012-07-17 19:56:43 +0000, glen herrmannsfeldt said:

> John W Kennedy <jwkenne@attglobal.net> wrote:
> 
> (snip regarding /* as an EOF notation, I wrote)
> 
>>> If you use batch submission with MVS or z/OS it is still there,
>>> real cards or virtual cards.
> 
> (snip)
>>> I am not sure by now, if DLM is an OS feature or a JES feature.
> 
>> JCL, though I daresay the JESs have some awareness.
> 
> As well as I know, it for OS/360 JES was optional.
> 
> That is, HASP or ASP were add-ons, but the system could run
> without one of them. At least by the later MVS days, as well
> as I know, one is required.

VS1 had JES from the beginning, which superficially emulated QSAM 
spooling, but internally was more like HASP. SVS, like OS/360, was 
based on QSAM spooling, but allowed HASP and ASP. MVS dropped QSAM 
spooling, and required JES2 (based on HASP) or JES3 (based on ASP).

DLM was introduced on OS/360, with QSAM spooling.

>>> If JES gets to the job stream early enough, it might be that OS
>>> never sees them. (And ASP/JES3 works somewhat different from
>>> HASP/JES2 as far as input stream processing.)
> 
> There is a previous claim that DLM was added in the OS/360 days.
> 
> But was it added to OS/360, or just to one or both JES?
> (and what ever happened to JES1?)

JES1 was never the official name of anything, but it was sometimes 
applied to VS1's mandatory JES as a retronym.

> Also, having two choices (JES2 and JES3) complicates the
> description of what is, and isn't, part of JCL. I believe
> I have an MVS 3.8 JCL manual nearby.

-- 
John W Kennedy
"Compact is becoming contract,
Man only earns and pays."
  -- Charles Williams.  "Bors to Elayne:  On the King's Coins"

0
jwkenne (1442)
7/17/2012 11:23:25 PM
On 2012-07-17 21:59:38 +0000, Fritz Wuehler said:

> John W Kennedy <jwkenne@attglobal.net> wrote:
> 
>> On 2012-07-16 11:30:51 +0000, glen herrmannsfeldt said:
> 
>>> C was preceded by BCPL and B, which could be considered the
>>> experiments. It took three tries to get it right.
> 
> That's debateable. I would say hundreds of tries later they still can't get
> it right. And they never will, because all that existing broken legacy code
> must compile and work like it did before. C and the prople who use it are
> C's own worst enemy.
> 
>> And even then it has the horrible zero-terminated-string feature.
> 
> Which is fine as far as performance goes since Intel (where 99.9% of C
> "runs") doesn't have storage/storage moves longer than a quadword (our
> fullword).

Have you ever looked at the object code produced for strcpy, etc., on 
/any/ modern architecture? The 370 line had to add some new opcodes. 
(Before that was available, it used a TRT loop to scan the source 
before staring the actual copy.) And code for Intel is nearly as bad.

> The worst part of zero terminated strings is the stuff like
> blowing off the end of a string and inability to handle binary zeros as part
> of a string, etc. etc. etc. Fine for the toy computers and OS it was
> "designed" to run on.

Oh for God's sake, grow up!

-- 
John W Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
  -- Charles Williams.  "Taliessin through Logres: Prelude"

0
jwkenne (1442)
7/17/2012 11:45:25 PM
John W Kennedy <jwkenne@attglobal.net> wrote:

(snip regarding the exception model and ON units)

>> Well, sometimes the global nature is nice, but often it isn't.
 
>> With try/catch, you can make the try block as small or large as
>> you like. With ON, it is hard to know what other blocks are doing.
 
>>>> As for typed pointers I haven't looked too closely, but I believe
>>>> Enterprise PL/I has typed "handles",
 
>>> Yes, because anonymous pointers suck, and everybody knows it.

(then I wrote) 
>> For locate mode I/O, maybe they aren't so bad, but for many
>> pointer uses, yes.

> Locate-mode I/O doesn't really exist anymore, except in OS/360 (and 
> DOS/360) legacy features -- unless you count data-in-virtual.

That is pretty much true. Even so, you can remove one level of
copying to/from buffers that otherwise is done.

The S/360 I/O hardware and OS/360 access methods were well 
designed to minimize the memory needed to store and buffer data.

Locate mode I/O allows I/O direct from the actual data to storage.

The unix disk I/O model is based on the system buffering disk
blocks, reading, modifying, and writing as needed. That especially
works well as memory prices decrease. 

Even so, the normal I/O method copies user data to/from a user
buffer before handing it off to the system. Using locate mode
allows one to eliminate that one copy. If the system internally
wants to copy the data one or ten times before it reaches iron
oxide, that is out of our control. (Note that disks now have
internal buffers, so count that one, too.)

There are certain cases, locate mode being one, where much work
is done with the members of one structure. Setting an anonymous
pointer and then working with that one is pretty convenient, as
long as there is only one. Maybe not so bad for a linked list,
but even for a tree it starts to get hard. 

-- glen
0
gah (12851)
7/17/2012 11:54:42 PM
In <50048f22$0$26886$607ed4bc@cv.net>, on 07/16/2012
   at 06:01 PM, John W Kennedy <jwkenne@attglobal.net> said:

>It remains a fact that OS/360, from the start, used assembler-like 
>constructs for everything from JCL, to utility-program control 
>cards, to PARM values, and IBM then made a consistent shift to 
>PL/I-like constructs for such purposes in new applications 
>starting around 1969.

It remains a fact that what you call "PL/I-like constructs" had syntax
grossly at variance with that of PL/I. Nor is "OS/360 command
languages" a plausible reading of your "command languages". EXEC is
every bit as much of a command language as anything in OS/360, and it
inherits nothing from either assembler syntax or PL/I syntax.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
spamtrap16 (3722)
7/18/2012 12:03:32 AM
John W Kennedy <jwkenne@attglobal.net> wrote:

(snip, I wrote)
>>>> I am not sure by now, if DLM is an OS feature or a JES feature.
 
>>> JCL, though I daresay the JESs have some awareness.
 
>> As well as I know, it for OS/360 JES was optional.
 
>> That is, HASP or ASP were add-ons, but the system could run
>> without one of them. At least by the later MVS days, as well
>> as I know, one is required.

> VS1 had JES from the beginning, which superficially emulated QSAM 
> spooling, but internally was more like HASP. SVS, like OS/360, was 
> based on QSAM spooling, but allowed HASP and ASP. MVS dropped QSAM 
> spooling, and required JES2 (based on HASP) or JES3 (based on ASP).

> DLM was introduced on OS/360, with QSAM spooling.

I think that partly answers the question. The OS/360 system I
used in those days ran HASP for some time, and then ASP.

I didn't remember DLM until late in the ASP years. It may or
may not have been available on the JESless OS or HASP on
or before that time.

I don't remember actually using it until MVS.

-- glen
0
gah (12851)
7/18/2012 12:07:08 AM
In <ju29ql$kk2$1@speranza.aioe.org>, on 07/16/2012
   at 11:58 PM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:

>I am not sure by now, if DLM is an OS feature or a JES feature.

DLM itself is a JES faeture. In general, handling SYSIN data is
both JES and BCP.  The JES handles the instream data but passes
some information on to the Converter.

>(And ASP/JES3 works somewhat different from
>HASP/JES2 as far as input stream processing.)

There are significant differences between ASP and HASP processing of
SYSIN and SYSOUT data, but I'm not aware of any significant[1]
differences between JES2 and JES3 in that regard.

[1] I don't consider having a different limit for LRECL to be
    major.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
spamtrap16 (3722)
7/18/2012 12:08:10 AM
In <ju4g1q$om4$1@speranza.aioe.org>, on 07/17/2012
   at 07:56 PM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:

>As well as I know, it for OS/360 JES was optional.

No. MFT II and MVT came with SPOOL support whether you chose to use it
or not.  Both ASP and HASP replaced DD statements for SPOOL data sets
that they were handling, bypassing the native Spool facilities.

>There is a previous claim that DLM was added in the OS/360 days.
>But was it added to OS/360, or just to one or both JES?

It was added to OS/360, but IBM added parallel code to ASP and HASP.

>(and what ever happened to JES1?)

As an OS/VS1 component, it went away with OS/VS1.

>Also, having two choices (JES2 and JES3) complicates the 
>description of what is, and isn't, part of JCL.

IBM distinguishes between JCL, which is mostly JES independent, and
JECL, which is JES dependent.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
spamtrap16 (3722)
7/18/2012 12:37:08 AM
On Wednesday, 18 July 2012 02:08:41 UTC+10, John W Kennedy  wrote:
> On 2012-07-17 03:36:50 +0000, xxxxxxxx@gmail.com said:
> 
> &gt; On Tuesday, 17 July 2012 09:51:56 UTC+10, glen herrmannsfeldt  wrote:
> &gt;&gt; Peter Flass &amp;lt;Pet......@yahoo.com&amp;gt; wrote:
> &gt;&gt; &amp;gt; On 7/15/2012 8:36 PM, xxxxxx@gmail.com wrote:
> &gt;&gt; 
> &gt;&gt; &amp;gt;&amp;gt; PL/I wasn&amp;#39;t an &amp;quot;experiment&amp;quot;.  It was a huge advance over
> &gt;&gt; &amp;gt;&amp;gt; anything else at the time, and offered facilities that
> &gt;&gt; &amp;gt;&amp;gt; until then had only been available in individual languages.
> &gt;&gt; 
> &gt;&gt; All of which doesn&amp;#39;t prove it wasn&amp;#39;t an experiment.
> &gt; 
> &gt; What proof do you want?
> &gt; 
> &gt; PL/I was introduced with the S/360.
> &gt; No manufacturer is going to introduce an &quot;experiment&quot; with
> &gt; its flagship hardware and flagship compiler.
> 
> Bwah-ha-ha-ha-ha-ha-ha!
> 
> You really don't know a damn thing about the history of the S/360, do you?

Sorry to hear that you "don't know a damn thing" about the history of the S/360.
You can read about it on Wiki.

0
robin.vowels (428)
7/18/2012 1:24:14 AM
On Wednesday, 18 July 2012 02:12:10 UTC+10, John W Kennedy  wrote:
> On 2012-07-17 02:45:33 +0000, rxxxxxxxx@gmail.com said:

> > %PAGE and %SKIP were intended for doing that.
> 
> They appeared only in the Optimizer/Checker generation, and (at least 
> in that generation) didn't apply to the macro-input listing.

%PAGE and %SKIP are in current systems.

The alternative (column 1) didn't appear in F initially.
0
robin.vowels (428)
7/18/2012 1:32:26 AM
On Wednesday, 18 July 2012 02:14:19 UTC+10, John W Kennedy  wrote:
> On 2012-07-17 02:51:13 +0000, oxxxxxxx@gmail.com said:
>=20
> &gt; On Monday, 16 July 2012 23:48:20 UTC+10, John W Kennedy  wrote:
> &gt;&gt; On 2012-07-16 11:30:51 +0000, glen herrmannsfeldt said:
> &gt;=20
> &gt;&gt;&gt; C was preceded by BCPL and B, which could be considered the
> &gt;&gt;&gt; experiments. It took three tries to get it right.
> &gt;=20
> &gt;&gt; And even then it has the horrible zero-terminated-string feature=
..
>
> > And the facility to produce garbage results on output.
>=20
> Just like every other language from Plankalk=FCl on.

But in C you can do it without even trying.
0
robin.vowels (428)
7/18/2012 1:37:05 AM
On Wednesday, 18 July 2012 09:16:47 UTC+10, John W Kennedy  wrote:

> Locate-mode I/O doesn't really exist anymore, except in OS/360 (and 
> DOS/360) legacy features -- unless you count data-in-virtual.

Locate mode still exists, even on Windows.
0
robin.vowels (428)
7/18/2012 1:43:24 AM
On Wednesday, 18 July 2012 09:54:42 UTC+10, glen herrmannsfeldt  wrote:
> John W Kennedy &lt;jxxxxxxx@attglobal.net&gt; wrote:
> 
> (snip regarding the exception model and ON units)
> 
> &gt;&gt; Well, sometimes the global nature is nice, but often it isn&#39;t.
>  
> &gt;&gt; With try/catch, you can make the try block as small or large as
> &gt;&gt; you like. With ON, it is hard to know what other blocks are doing.
>  
> &gt;&gt;&gt;&gt; As for typed pointers I haven&#39;t looked too closely, but I believe
> &gt;&gt;&gt;&gt; Enterprise PL/I has typed &quot;handles&quot;,
>  
> &gt;&gt;&gt; Yes, because anonymous pointers suck, and everybody knows it.
> 
> (then I wrote) 
> &gt;&gt; For locate mode I/O, maybe they aren&#39;t so bad, but for many
> &gt;&gt; pointer uses, yes.
> 
> &gt; Locate-mode I/O doesn&#39;t really exist anymore, except in OS/360 (and 
> &gt; DOS/360) legacy features -- unless you count data-in-virtual.
> 
> That is pretty much true. Even so, you can remove one level of
> copying to/from buffers that otherwise is done.
> 
> The S/360 I/O hardware and OS/360 access methods were well 
> designed to minimize the memory needed to store and buffer data.
> 
> Locate mode I/O allows I/O direct from the actual data to storage.

It also permits I/O and computation to proceed concurrently.


0
robin.vowels (428)
7/18/2012 2:13:54 AM
robin.vowels@gmail.com wrote:

(snip)
>> Locate mode I/O allows I/O direct from the actual data to storage.

> It also permits I/O and computation to proceed concurrently.

I suppose, but that can be done even without locate mode.

Fortran has asynchronous I/O which isn't locate mode.
It might be that the copy to an I/O buffer doesn't happen
concurrently, but you never know.

-- glen
0
gah (12851)
7/18/2012 3:31:44 AM
On Mon, 16 Jul 2012 19:55:09 -0700 (PDT), robin.vowels@gmail.com wrote in
post : <news:f1d70be6-685a-4e29-90c4-926f6302e2d4@googlegroups.com> :

> On Tuesday, 17 July 2012 00:18:33 UTC+10, Tim C.  wrote:
>> On Mon, 16 Jul 2012 02:11:42 +0000 (UTC), glen herrmannsfeldt wrote in post 
>>: &lt;news:jtvt.......@speranza.aioe.org&gt; :
>> 
>> &gt;&gt; (And soon after, someone came up with the idea to put &#39;1&#39;, &#39;0&#39;, 
>> &gt;&gt; or &#39;-&#39; in column 1 to format the print listing.) 
>> &gt; 
>> &gt; I once did this, including &#39;+&#39; to double print (bold) some comments.
>> &gt; You can make nice looking program listings this way.
>> 
>> It was quite common for us to do that during the 80s and early 90s, at 
>> least in the UK, Germany and Austria.
>> As you say, make important bits of the code bold, nicely breaking up code 
>> blocks .... very useful it was too.
> 
> %PAGE and %SKIP were intended for that purpose.

And were also extensively used. 
-- 
Tim C.  
0
7/18/2012 7:45:03 AM
On Wednesday, 18 July 2012 09:45:25 UTC+10, John W Kennedy  > On 2012-07-17 21:59:38 +0000, Fritz Wuehler said:

> Have you ever looked at the object code produced for strcpy, etc., on 
> /any/ modern architecture? The 370 line had to add some new opcodes. 
> (Before that was available, it used a TRT loop to scan the source 
> before staring the actual copy.) And code for Intel is nearly as bad.

Intel had/has the REP instruction for helping with
zero-terminated strings.


0
robin.vowels (428)
7/18/2012 1:41:49 PM
On 2012-07-17 23:44:07 +0000, glen herrmannsfeldt said:

> Fritz Wuehler <fritz@spamexpire-201207.rodent.frell.theremailer.net> wrote:
> 
> (I wrote)
>>>> C was preceded by BCPL and B, which could be considered the
>>>> experiments. It took three tries to get it right.
> 
>> That's debateable. I would say hundreds of tries later they still can't get
>> it right. And they never will, because all that existing broken legacy code
>> must compile and work like it did before. C and the prople who use it are
>> C's own worst enemy.
> 
> Yes.
> 
> But using the metric of popularity, BCPL and B usage died out,
> but C, so far, hasn't. That is, it was "good enough."
> 
> I am not so sure now if the growth coefficient is positive or
> negative, but, so far, it hasn't obviously died out.

Especially if you count C++, Objective-C, and Objective-C++.

-- 
John W Kennedy
"The poor have sometimes objected to being governed badly; the rich 
have always objected to being governed at all."
  -- G. K. Chesterton.  "The Man Who Was Thursday"

0
jwkenne (1442)
7/18/2012 2:53:47 PM
On 2012-07-17 23:54:42 +0000, glen herrmannsfeldt said:

> John W Kennedy <jwkenne@attglobal.net> wrote:
> 
> (snip regarding the exception model and ON units)
> 
>>> Well, sometimes the global nature is nice, but often it isn't.
> 
>>> With try/catch, you can make the try block as small or large as
>>> you like. With ON, it is hard to know what other blocks are doing.
> 
>>>>> As for typed pointers I haven't looked too closely, but I believe
>>>>> Enterprise PL/I has typed "handles",
> 
>>>> Yes, because anonymous pointers suck, and everybody knows it.
> 
> (then I wrote)
>>> For locate mode I/O, maybe they aren't so bad, but for many
>>> pointer uses, yes.
> 
>> Locate-mode I/O doesn't really exist anymore, except in OS/360 (and
>> DOS/360) legacy features -- unless you count data-in-virtual.
> 
> That is pretty much true. Even so, you can remove one level of
> copying to/from buffers that otherwise is done.
> 
> The S/360 I/O hardware and OS/360 access methods were well
> designed to minimize the memory needed to store and buffer data.
> 
> Locate mode I/O allows I/O direct from the actual data to storage.

Yes, but even by the time VSAM was being designed, it was seen as a 
reliability exposure. Locate mode in PL/I for VSAM has to be faked with 
an extra buffer. (Perhaps not with input-only files -- I don't recall 
for certain.)

> The unix disk I/O model is based on the system buffering disk
> blocks, reading, modifying, and writing as needed. That especially
> works well as memory prices decrease.
> 
> Even so, the normal I/O method copies user data to/from a user
> buffer before handing it off to the system. Using locate mode
> allows one to eliminate that one copy. If the system internally
> wants to copy the data one or ten times before it reaches iron
> oxide, that is out of our control. (Note that disks now have
> internal buffers, so count that one, too.)
> 
> There are certain cases, locate mode being one, where much work
> is done with the members of one structure. Setting an anonymous
> pointer and then working with that one is pretty convenient, as
> long as there is only one. Maybe not so bad for a linked list,
> but even for a tree it starts to get hard.

In any case, I can't think of any language where anonymous pointers or 
pointer casting can't be forced, except for Java and some others that, 
by their fundamental design goal, have nothing corresponding to a COBOL 
group, or PL/I or C structure to begin with).

-- 
John W Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
  -- Charles Williams.  "Judgement at Chelmsford"

0
jwkenne (1442)
7/18/2012 3:10:54 PM
On 2012-07-18 02:13:54 +0000, robin.vowels@gmail.com said:

> On Wednesday, 18 July 2012 09:54:42 UTC+10, glen herrmannsfeldt  wrote:
>> John W Kennedy &lt;jxxxxxxx@attglobal.net&gt; wrote:
>> 
>> (snip regarding the exception model and ON units)
>> 
>> &gt;&gt; Well, sometimes the global nature is nice, but often it isn&#39;t.
>> 
>> &gt;&gt; With try/catch, you can make the try block as small or large as
>> &gt;&gt; you like. With ON, it is hard to know what other blocks are doing.
>> 
>> &gt;&gt;&gt;&gt; As for typed pointers I haven&#39;t looked too 
>> closely, but I believe
>> &gt;&gt;&gt;&gt; Enterprise PL/I has typed &quot;handles&quot;,
>> 
>> &gt;&gt;&gt; Yes, because anonymous pointers suck, and everybody knows it.
>> 
>> (then I wrote)
>> &gt;&gt; For locate mode I/O, maybe they aren&#39;t so bad, but for many
>> &gt;&gt; pointer uses, yes.
>> 
>> &gt; Locate-mode I/O doesn&#39;t really exist anymore, except in OS/360 (and
>> &gt; DOS/360) legacy features -- unless you count data-in-virtual.
>> 
>> That is pretty much true. Even so, you can remove one level of
>> copying to/from buffers that otherwise is done.
>> 
>> The S/360 I/O hardware and OS/360 access methods were well
>> designed to minimize the memory needed to store and buffer data.
>> 
>> Locate mode I/O allows I/O direct from the actual data to storage.
> 
> It also permits I/O and computation to proceed concurrently.

It is neither necessary nor sufficient.

-- 
John W Kennedy
"...if you had to fall in love with someone who was evil, I can see why 
it was her."
  -- "Alias"

0
jwkenne (1442)
7/18/2012 3:12:03 PM
On 2012-07-18 01:24:14 +0000, robin.vowels@gmail.com said:

> On Wednesday, 18 July 2012 02:08:41 UTC+10, John W Kennedy  wrote:
>> On 2012-07-17 03:36:50 +0000, xxxxxxxx@gmail.com said:
>> 
>> &gt; On Tuesday, 17 July 2012 09:51:56 UTC+10, glen herrmannsfeldt  wrote:
>> &gt;&gt; Peter Flass &amp;lt;Pet......@yahoo.com&amp;gt; wrote:
>> &gt;&gt; &amp;gt; On 7/15/2012 8:36 PM, xxxxxx@gmail.com wrote:
>> &gt;&gt;
>> &gt;&gt; &amp;gt;&amp;gt; PL/I wasn&amp;#39;t an 
>> &amp;quot;experiment&amp;quot;.  It was a huge advance over
>> &gt;&gt; &amp;gt;&amp;gt; anything else at the time, and offered 
>> facilities that
>> &gt;&gt; &amp;gt;&amp;gt; until then had only been available in 
>> individual languages.
>> &gt;&gt;
>> &gt;&gt; All of which doesn&amp;#39;t prove it wasn&amp;#39;t an experiment.
>> &gt;
>> &gt; What proof do you want?
>> &gt;
>> &gt; PL/I was introduced with the S/360.
>> &gt; No manufacturer is going to introduce an &quot;experiment&quot; with
>> &gt; its flagship hardware and flagship compiler.
>> 
>> Bwah-ha-ha-ha-ha-ha-ha!
>> 
>> You really don't know a damn thing about the history of the S/360, do you?
> 
> Sorry to hear that you "don't know a damn thing" about the history of 
> the S/360.
> You can read about it on Wiki.

I was there.

-- 
John W Kennedy
"The blind rulers of Logres
Nourished the land on a fallacy of rational virtue."
  -- Charles Williams.  "Taliessin through Logres: Prelude"

0
jwkenne (1442)
7/18/2012 3:14:09 PM
On 2012-07-18 01:43:24 +0000, robin.vowels@gmail.com said:

> On Wednesday, 18 July 2012 09:16:47 UTC+10, John W Kennedy  wrote:
> 
>> Locate-mode I/O doesn't really exist anymore, except in OS/360 (and
>> DOS/360) legacy features -- unless you count data-in-virtual.
> 
> Locate mode still exists, even on Windows.

No, it doesn't.

-- 
John W Kennedy
"Give up vows and dogmas, and fixed things, and you may grow like That. 
....you may come to think a blow bad, because it hurts, and not because 
it humiliates.  You may come to think murder wrong, because it is 
violent, and not because it is unjust."
  -- G. K. Chesterton.  "The Ball and the Cross"

0
jwkenne (1442)
7/18/2012 3:22:21 PM
robin.vowels@gmail.com wrote:
> On Wednesday, 18 July 2012 09:45:25 UTC+10, John W Kennedy  > On 2012-07-17 21:59:38 +0000, Fritz Wuehler said:

>> Have you ever looked at the object code produced for strcpy, etc., on 
>> /any/ modern architecture? The 370 line had to add some new opcodes. 
>> (Before that was available, it used a TRT loop to scan the source 
>> before staring the actual copy.) And code for Intel is nearly as bad.

> Intel had/has the REP instruction for helping with
> zero-terminated strings.

I thought REP was an instruction prefix, but maybe close enough
to an instruction. 

But yes, it allows for repeating a move instruction as long as
the byte (or, I believe, word) isn't zero.

It might be faster for aligned data, though, to run a loop
of load/store using 32 bit or (in x86_64) 64 bit registers.
(And maybe even for unaligned data.)

-- glen
0
gah (12851)
7/18/2012 5:40:42 PM
John W Kennedy <jwkenne@attglobal.net> wrote:

(snip, someone wrote)
>>>>> Yes, because anonymous pointers suck, and everybody knows it.
 
>> (then I wrote)
>>>> For locate mode I/O, maybe they aren't so bad, but for many
>>>> pointer uses, yes.
 
>>> Locate-mode I/O doesn't really exist anymore, except in OS/360 (and
>>> DOS/360) legacy features -- unless you count data-in-virtual.
 
>> That is pretty much true. Even so, you can remove one level of
>> copying to/from buffers that otherwise is done.
 
(snip) 
>> Locate mode I/O allows I/O direct from the actual data to storage.

> Yes, but even by the time VSAM was being designed, it was seen as a 
> reliability exposure. Locate mode in PL/I for VSAM has to be faked 
> with an extra buffer. (Perhaps not with input-only files -- 
> I don't recall for certain.)

As well as I know it, VSAM, similar to the unix file cache,
uses buffers and fixed length blocks to speed up I/O. 

As processor speeds increases much faster than I/O speed,
for many I/O operations it became faster, assuming that the
cache could actually do something useful. 

(Direct access, with a random enough access pattern over a
large enough file, likely takes no advantage of a cache, and
it may even be a disadvantage.)

(snip)

>> There are certain cases, locate mode being one, where much work
>> is done with the members of one structure. Setting an anonymous
>> pointer and then working with that one is pretty convenient, as
>> long as there is only one. Maybe not so bad for a linked list,
>> but even for a tree it starts to get hard.

> In any case, I can't think of any language where anonymous pointers or 
> pointer casting can't be forced, except for Java and some others that, 
> by their fundamental design goal, have nothing corresponding to a COBOL 
> group, or PL/I or C structure to begin with).

Well, have has this, which has at least some similarity to an
anonymous pointer. (That is, the 'this' object for an instance
method.) If you can consider an object as related to a structure
in other languages, Java also has Object, the super class of
all other classes.

If a procedure/method only references one structure/object, 
then, at least to me, the anonymous pointer/this object seems
to make things more readable. At two it is pretty questionable,
and more than that tends to be less readable.

-- glen

0
gah (12851)
7/18/2012 5:55:36 PM
On 7/17/2012 7:54 PM, glen herrmannsfeldt wrote:
> John W Kennedy <jwkenne@attglobal.net> wrote:
>
> (snip regarding the exception model and ON units)
>
>>> Well, sometimes the global nature is nice, but often it isn't.
>
>>> With try/catch, you can make the try block as small or large as
>>> you like. With ON, it is hard to know what other blocks are doing.
>
>>>>> As for typed pointers I haven't looked too closely, but I believe
>>>>> Enterprise PL/I has typed "handles",
>
>>>> Yes, because anonymous pointers suck, and everybody knows it.
>
> (then I wrote)
>>> For locate mode I/O, maybe they aren't so bad, but for many
>>> pointer uses, yes.
>
>> Locate-mode I/O doesn't really exist anymore, except in OS/360 (and
>> DOS/360) legacy features -- unless you count data-in-virtual.
>
> That is pretty much true. Even so, you can remove one level of
> copying to/from buffers that otherwise is done.
>
> The S/360 I/O hardware and OS/360 access methods were well
> designed to minimize the memory needed to store and buffer data.
>
> Locate mode I/O allows I/O direct from the actual data to storage.
>
> The unix disk I/O model is based on the system buffering disk
> blocks, reading, modifying, and writing as needed. That especially
> works well as memory prices decrease.
>
> Even so, the normal I/O method copies user data to/from a user
> buffer before handing it off to the system. Using locate mode
> allows one to eliminate that one copy. If the system internally
> wants to copy the data one or ten times before it reaches iron
> oxide, that is out of our control. (Note that disks now have
> internal buffers, so count that one, too.)
>
> There are certain cases, locate mode being one, where much work
> is done with the members of one structure. Setting an anonymous
> pointer and then working with that one is pretty convenient, as
> long as there is only one. Maybe not so bad for a linked list,
> but even for a tree it starts to get hard.
>

The loss of locate-mode I/O is tied to the loss of C-K-D disk 
structures.  With CKD you say "give me a record of maximum length <x> 
and put it <here>" and the channel and device do the rest.  Without 
that, you have to read a certain number of disk sectors to find out how 
big your record is, whether OS/360-type variable length records or C 
LF-terminated stuff.  In that case you already have the data in buffers 
somewhere, so you just move it.

FWIW, Iron Spring PL/I still has locate-mode, but largely emulated.


-- 
Pete


0
Peter_Flass (956)
7/18/2012 11:15:31 PM
On 7/17/2012 8:07 PM, glen herrmannsfeldt wrote:
> John W Kennedy <jwkenne@attglobal.net> wrote:
>
> (snip, I wrote)
>>>>> I am not sure by now, if DLM is an OS feature or a JES feature.
>
>>>> JCL, though I daresay the JESs have some awareness.
>
>>> As well as I know, it for OS/360 JES was optional.
>
>>> That is, HASP or ASP were add-ons, but the system could run
>>> without one of them. At least by the later MVS days, as well
>>> as I know, one is required.
>
>> VS1 had JES from the beginning, which superficially emulated QSAM
>> spooling, but internally was more like HASP. SVS, like OS/360, was
>> based on QSAM spooling, but allowed HASP and ASP. MVS dropped QSAM
>> spooling, and required JES2 (based on HASP) or JES3 (based on ASP).
>
>> DLM was introduced on OS/360, with QSAM spooling.
>
> I think that partly answers the question. The OS/360 system I
> used in those days ran HASP for some time, and then ASP.
>
> I didn't remember DLM until late in the ASP years. It may or
> may not have been available on the JESless OS or HASP on
> or before that time.
>
> I don't remember actually using it until MVS.
>

This is off-topic for this group, but since it came into the discussion 
.... I don't think I ever saw an OS system without HASP, but without it 
didn't the system have to run a reader/interpreter job or an output 
writer for every device?  It would seem you'd quickly load up the system 
with lots of often unused jobs.


-- 
Pete


0
Peter_Flass (956)
7/18/2012 11:18:22 PM
In <5005f3ed$0$6065$607ed4bc@cv.net>, on 07/17/2012
   at 07:23 PM, John W Kennedy <jwkenne@attglobal.net> said:

>VS1 had JES from the beginning, which superficially emulated QSAM 
>spooling,

SPOOL was not a QSAM feature; SYSIN and SYSOUT data sets in OS/360
were normal DASD PS data sets, and you could use any of BSAM, EXCP or
QSAM for them. Perhaps you are thinking of the CI and RCI in OS/VS1,
which sat between ACB and DCB interfaces.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
spamtrap16 (3722)
7/18/2012 11:18:28 PM
On 7/18/2012 1:40 PM, glen herrmannsfeldt wrote:
> robin.vowels@gmail.com wrote:
>> On Wednesday, 18 July 2012 09:45:25 UTC+10, John W Kennedy  > On 2012-07-17 21:59:38 +0000, Fritz Wuehler said:
>
>>> Have you ever looked at the object code produced for strcpy, etc., on
>>> /any/ modern architecture? The 370 line had to add some new opcodes.
>>> (Before that was available, it used a TRT loop to scan the source
>>> before staring the actual copy.) And code for Intel is nearly as bad.
>
>> Intel had/has the REP instruction for helping with
>> zero-terminated strings.
>
> I thought REP was an instruction prefix, but maybe close enough
> to an instruction.
>
> But yes, it allows for repeating a move instruction as long as
> the byte (or, I believe, word) isn't zero.
>
> It might be faster for aligned data, though, to run a loop
> of load/store using 32 bit or (in x86_64) 64 bit registers.
> (And maybe even for unaligned data.)
>

That would be great, bit Intel screwed it up so "REP CMPSD" doesn't 
compare correctly for other than equal and not equal.


-- 
Pete


0
Peter_Flass (956)
7/18/2012 11:23:12 PM
On Thursday, 19 July 2012 01:22:21 UTC+10, John W Kennedy  wrote:
> On 2012-07-18 01:43:24 +0000, xxxxxxxxx@gmail.com said:
> 
> &gt; On Wednesday, 18 July 2012 09:16:47 UTC+10, John W Kennedy  wrote:
>
> >> Locate-mode I/O doesn't really exist anymore, except in OS/360 (and
> >> DOS/360) legacy features -- unless you count data-in-virtual.
>
> > Locate mode still exists, even on Windows.
> 
> No, it doesn't.

Have a look at SC14-7285-01 (for AIX, Enterprise, Windows),
and SC26-8003.


0
robin.vowels (428)
7/18/2012 11:30:10 PM
On Thursday, 19 July 2012 09:23:12 UTC+10, Peter Flass  wrote:
> On 7/18/2012 1:40 PM, glen herrmannsfeldt wrote:
> > xxxrxxxxxx@gmail.com wrote:
> &gt;&gt; On Wednesday, 18 July 2012 09:45:25 UTC+10, John W Kennedy  &gt; On 2012-07-17 21:59:38 +0000, Fritz Wuehler said:
>
> &gt;&gt;&gt; Have you ever looked at the object code produced for strcpy, etc., on
> &gt;&gt;&gt; /any/ modern architecture? The 370 line had to add some new opcodes.
> >>> (Before that was available, it used a TRT loop to scan the source
> >>> before staring the actual copy.) And code for Intel is nearly as bad.
>
> > Intel had/has the REP instruction for helping with
> > zero-terminated strings.
>
> > I thought REP was an instruction prefix, but maybe close enough
> > to an instruction.
>
> > But yes, it allows for repeating a move instruction as long as
> > the byte (or, I believe, word) isn't zero.
>
> > It might be faster for aligned data, though, to run a loop
> > of load/store using 32 bit or (in x86_64) 64 bit registers.
> > (And maybe even for unaligned data.)
 
> That would be great, bit Intel screwed it up so "REP CMPSD" doesn't 
> compare correctly for other than equal and not equal.

Isn't that all you need for looking for zero?

0
robin.vowels (428)
7/18/2012 11:34:57 PM
On 2012-07-18 17:55:36 +0000, glen herrmannsfeldt said:

> John W Kennedy <jwkenne@attglobal.net> wrote:
> 
> (snip, someone wrote)
>>>>>> Yes, because anonymous pointers suck, and everybody knows it.
> 
>>> (then I wrote)
>>>>> For locate mode I/O, maybe they aren't so bad, but for many
>>>>> pointer uses, yes.
> 
>>>> Locate-mode I/O doesn't really exist anymore, except in OS/360 (and
>>>> DOS/360) legacy features -- unless you count data-in-virtual.
> 
>>> That is pretty much true. Even so, you can remove one level of
>>> copying to/from buffers that otherwise is done.
> 
> (snip)
>>> Locate mode I/O allows I/O direct from the actual data to storage.
> 
>> Yes, but even by the time VSAM was being designed, it was seen as a
>> reliability exposure. Locate mode in PL/I for VSAM has to be faked
>> with an extra buffer. (Perhaps not with input-only files --
>> I don't recall for certain.)
> 
> As well as I know it, VSAM, similar to the unix file cache,
> uses buffers and fixed length blocks to speed up I/O.
> 
> As processor speeds increases much faster than I/O speed,
> for many I/O operations it became faster, assuming that the
> cache could actually do something useful.
> 
> (Direct access, with a random enough access pattern over a
> large enough file, likely takes no advantage of a cache, and
> it may even be a disadvantage.)
> 
> (snip)
> 
>>> There are certain cases, locate mode being one, where much work
>>> is done with the members of one structure. Setting an anonymous
>>> pointer and then working with that one is pretty convenient, as
>>> long as there is only one. Maybe not so bad for a linked list,
>>> but even for a tree it starts to get hard.
> 
>> In any case, I can't think of any language where anonymous pointers or
>> pointer casting can't be forced, except for Java and some others that,
>> by their fundamental design goal, have nothing corresponding to a COBOL
>> group, or PL/I or C structure to begin with).
> 
> Well, have has this, which has at least some similarity to an
> anonymous pointer. (That is, the 'this' object for an instance
> method.) If you can consider an object as related to a structure
> in other languages, Java also has Object, the super class of
> all other classes.

Yes, but Java absolutely, positively excludes access to objects as byte 
aggregates. I/O, as in traditional Fortran I/O, is element by element, 
even in binary.

> If a procedure/method only references one structure/object,
> then, at least to me, the anonymous pointer/this object seems
> to make things more readable. At two it is pretty questionable,
> and more than that tends to be less readable.

It eliminates all possibility of static checking.

-- 
John W Kennedy
"Information is light. Information, in itself, about anything, is light."
  -- Tom Stoppard. "Night and Day"

0
jwkenne (1442)
7/18/2012 11:48:21 PM
On 2012-07-18 23:30:10 +0000, robin.vowels@gmail.com said:

> On Thursday, 19 July 2012 01:22:21 UTC+10, John W Kennedy  wrote:
>> On 2012-07-18 01:43:24 +0000, xxxxxxxxx@gmail.com said:
>> 
>> &gt; On Wednesday, 18 July 2012 09:16:47 UTC+10, John W Kennedy  wrote:
>> 
>>>> Locate-mode I/O doesn't really exist anymore, except in OS/360 (and
>>>> DOS/360) legacy features -- unless you count data-in-virtual.
>> 
>>> Locate mode still exists, even on Windows.
>> 
>> No, it doesn't.
> 
> Have a look at SC14-7285-01 (for AIX, Enterprise, Windows),
> and SC26-8003.

Those are IBM manuals describing PL/I, not Microsoft manuals describing 
Windows. Windows does not have locate mode, and never did (and neither 
did OS/2).

-- 
John W Kennedy
"The whole modern world has divided itself into Conservatives and 
Progressives. The business of Progressives is to go on making mistakes. 
The business of the Conservatives is to prevent the mistakes from being 
corrected."
  -- G. K. Chesterton

0
jwkenne (1442)
7/18/2012 11:54:46 PM
On 2012-07-18 19:02:35 +0000, Fritz Wuehler said:

> John W Kennedy <jwkenne@attglobal.net> wrote:
> 
>> On 2012-07-17 21:59:38 +0000, Fritz Wuehler said:
>> 
>>> John W Kennedy <jwkenne@attglobal.net> wrote:
>>> 
>>>> On 2012-07-16 11:30:51 +0000, glen herrmannsfeldt said:
>>> 
>>> Which is fine as far as performance goes since Intel (where 99.9% of C
>>> "runs") doesn't have storage/storage moves longer than a quadword (our
>>> fullword).
>> 
>> Have you ever looked at the object code produced for strcpy, etc., on
>> /any/ modern architecture?
> 
> Well no, unless you define Intel as a "modern" architecture. Which one(s)
> were you thinking of?

Pretty much anything more advanced than the Z-80.

>> The 370 line had to add some new opcodes. (Before that was available, it
>> used a TRT loop to scan the source before staring the actual copy.)
> 
> Yes but read what I wrote and ask yourself why you are talking about 370
> when I was talking about Intel. I am fully aware of the implications of null
> terminated strings on IBM.
> 
>> And code for Intel is nearly as bad.
> 
> It is bad but that's because Intel is a mess. All Intel code is bad, but it
> still performs pretty well. The point is as I said, Intel has no storage to
> storage move for more than 4 bytes (SIMD not included) so they have to write
> loops for character moves anyway. A null terminated string is not nearly as
> offensive from an assembly coding standpoint on Intel as it is on IBM.

It is if you really care about performance and your hardware bandwidth 
is more than 8 bits.

-- 
John W Kennedy
"Never try to take over the international economy based on a radical 
feminist agenda if you're not sure your leader isn't a transvestite."
  -- David Misch:  "She-Spies", "While You Were Out"

0
jwkenne (1442)
7/18/2012 11:59:00 PM
On 2012-07-18 23:18:22 +0000, Peter Flass said:

> On 7/17/2012 8:07 PM, glen herrmannsfeldt wrote:
>> John W Kennedy <jwkenne@attglobal.net> wrote:
>> 
>> (snip, I wrote)
>>>>>> I am not sure by now, if DLM is an OS feature or a JES feature.
>> 
>>>>> JCL, though I daresay the JESs have some awareness.
>> 
>>>> As well as I know, it for OS/360 JES was optional.
>> 
>>>> That is, HASP or ASP were add-ons, but the system could run
>>>> without one of them. At least by the later MVS days, as well
>>>> as I know, one is required.
>> 
>>> VS1 had JES from the beginning, which superficially emulated QSAM
>>> spooling, but internally was more like HASP. SVS, like OS/360, was
>>> based on QSAM spooling, but allowed HASP and ASP. MVS dropped QSAM
>>> spooling, and required JES2 (based on HASP) or JES3 (based on ASP).
>> 
>>> DLM was introduced on OS/360, with QSAM spooling.
>> 
>> I think that partly answers the question. The OS/360 system I
>> used in those days ran HASP for some time, and then ASP.
>> 
>> I didn't remember DLM until late in the ASP years. It may or
>> may not have been available on the JESless OS or HASP on
>> or before that time.
>> 
>> I don't remember actually using it until MVS.
>> 
> 
> This is off-topic for this group, but since it came into the discussion 
> ... I don't think I ever saw an OS system without HASP, but without it 
> didn't the system have to run a reader/interpreter job or an output 
> writer for every device?  It would seem you'd quickly load up the 
> system with lots of often unused jobs.

Yes, although they were not exactly "jobs". (They were started by the 
Master Scheduler, and ran in protection key zero.) And they didn't take 
much core, except for the reader/interpreter.

The two biggest problems, really, were competition for SYS1.SYSJOBQE 
and the design of QSAM that meant that, unless you did some fairly 
sophisticated assembler-only runtime twiddling, a hard-coded BLKSIZE 
could not be overridden, and many programs naively specified BLKSIZE=80 
or BLKSIZE=133, which all to horrid performance, especially because of 
the limitation of all CKD devices where it was, no matter how fast your 
code, impossible to read or write block n+1 immediately after reading 
or writing block n unless you chained the operations into a single 
channel program. HASP, ASP, JES, JES2, and JES3 all defeated the 
problem by doing emulated I/O with decent block sizes on the disk.

Still, we stuck with it on our MFT II system, which made it infinitely 
simpler to convert to VS1 and JES, since JES had no JECL and was almost 
entirely compatible (from the user's viewpoint) with QSAM spooling.

-- 
John W Kennedy
"The first effect of not believing in God is to believe in anything...."
  -- Emile Cammaerts, "The Laughing Prophet"

0
jwkenne (1442)
7/19/2012 12:12:24 AM
On Thursday, 19 July 2012 09:54:46 UTC+10, John W Kennedy  wrote:
> On 2012-07-18 23:30:10 +0000, xxxxxxxxxxxx@gmail.com said:
> 
> > On Thursday, 19 July 2012 01:22:21 UTC+10, John W Kennedy  wrote:

> >>>> Locate-mode I/O doesn't really exist anymore, except in OS/360 (and
> >>>> DOS/360) legacy features -- unless you count data-in-virtual.
> &gt;&gt; 
> &gt;&gt;&gt; Locate mode still exists, even on Windows.
> &gt;&gt; 
> >> No, it doesn't.
> 
> > Have a look at SC14-7285-01 (for AIX, Enterprise, Windows),
> > and SC26-8003.
> 
> Those are IBM manuals describing PL/I,

That's what counts.

> not Microsoft manuals describing 
> Windows. Windows does not have locate mode, and never did (and neither 
> did OS/2).

Read the manual.
0
robin.vowels (428)
7/19/2012 12:14:44 AM
On Thursday, 19 July 2012 09:48:21 UTC+10, John W Kennedy  wrote:
> On 2012-07-18 17:55:36 +0000, glen herrmannsfeldt said:

> &gt; If a procedure/method only references one structure/object,
> &gt; then, at least to me, the anonymous pointer/this object seems
> &gt; to make things more readable. At two it is pretty questionable,
> &gt; and more than that tends to be less readable.
> 
> It eliminates all possibility of static checking.

Which is?
0
robin.vowels (428)
7/19/2012 12:19:50 AM
On Thursday, 19 July 2012 09:15:31 UTC+10, Peter Flass  wrote:

> FWIW, Iron Spring PL/I still has locate-mode, but largely emulated.

And so it should [still have it], because it's still in PL/I.

0
robin.vowels (428)
7/19/2012 12:23:57 AM
On Thursday, 19 July 2012 10:12:24 UTC+10, John W Kennedy  wrote:

> The two biggest problems, really, were competition for SYS1.SYSJOBQE 
> and the design of QSAM that meant that, unless you did some fairly 
> sophisticated assembler-only runtime twiddling, a hard-coded BLKSIZE 
> could not be overridden, and many programs naively specified BLKSIZE=80 
> or BLKSIZE=133, which all to horrid performance,

Not when BUFFNO was specified, which we did with the catprocs.

0
robin.vowels (428)
7/19/2012 12:28:49 AM
Peter Flass <Peter_Flass@yahoo.com> wrote:

(snip on locate-mode I/O, I wrote)

>> That is pretty much true. Even so, you can remove one level of
>> copying to/from buffers that otherwise is done.

(snip)
>> Even so, the normal I/O method copies user data to/from a user
>> buffer before handing it off to the system. Using locate mode
>> allows one to eliminate that one copy. If the system internally
>> wants to copy the data one or ten times before it reaches iron
>> oxide, that is out of our control. (Note that disks now have
>> internal buffers, so count that one, too.)

OK, more specifically, the usual C library copies date, such
as from putc/gets or fwrite/fread to a buffer in your program
(part of stdio), which, when full, is sent to the OS.

Many Fortran I/O libraries now are based on an underlying C
library. It wouldn't surprise me if there was an additional
buffer between the user data and stdio buffer, but maybe not.

(snip on structures)

> The loss of locate-mode I/O is tied to the loss of C-K-D disk 
> structures.  With CKD you say "give me a record of maximum length <x> 
> and put it <here>" and the channel and device do the rest.  Without 
> that, you have to read a certain number of disk sectors to find out how 
> big your record is, whether OS/360-type variable length records or C 
> LF-terminated stuff.  In that case you already have the data in buffers 
> somewhere, so you just move it.

Yes. But even so, you can do with one less buffer than the usual
system. For output, pass the structure (address) directly to 
the system. For input, it is harder as, in the usual unix manner,
you don't know how long the record is. 

> FWIW, Iron Spring PL/I still has locate-mode, but largely emulated.

-- glen
0
gah (12851)
7/19/2012 8:39:03 AM
In <ju7g7u$lk7$2@dont-email.me>, on 07/18/2012
   at 07:18 PM, Peter Flass <Peter_Flass@Yahoo.com> said:

>I don't think I ever saw an OS system without HASP, but without it 
>didn't the system have to run a reader/interpreter job or an output 
>writer for every device?

Unless you're running ASP. Note that even with ASP or HASP you still
need the Reader/Interpreter, although the operator doesn't start the
R/I tasks.

>It would seem you'd quickly load up the system 
>with lots of often unused jobs.

The typical shop had only one reader/punch and one or two printers.
The shops with more unit-record equipment usually had more memory and
faster processors.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
spamtrap16 (3722)
7/19/2012 12:40:47 PM
In <500750e8$0$6054$607ed4bc@cv.net>, on 07/18/2012
   at 08:12 PM, John W Kennedy <jwkenne@attglobal.net> said:

>Yes, although they were not exactly "jobs".

Under the covers, START processing involved passing JCL through the
Reader/Interpreter and passing the output to the scheduler. From the
OS perspective it looked like a job.

>QSAM spooling.

The is no such thing. OS/360 SPOOL data sets were normal PS data sets
on DASD and could be processed with BSAM, EXCP or QSAM; the access
method did not do the spooling.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
spamtrap16 (3722)
7/19/2012 12:45:42 PM
In <50074dc4$0$6079$607ed4bc@cv.net>, on 07/18/2012
   at 07:59 PM, John W Kennedy <jwkenne@attglobal.net> said:

>Pretty much anything more advanced than the Z-80.

That would make some 1950's and 1960's machines modern.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
spamtrap16 (3722)
7/19/2012 12:48:27 PM
In <ju8h37$je9$1@speranza.aioe.org>, on 07/19/2012
   at 08:39 AM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:

>Yes. But even so, you can do with one less buffer than the usual
>system.

The Devil is in the details. Consider spanned records in QSAM.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
spamtrap16 (3722)
7/19/2012 12:50:50 PM
On 7/18/2012 7:34 PM, robin.vowels@gmail.com wrote:
> On Thursday, 19 July 2012 09:23:12 UTC+10, Peter Flass  wrote:
>> On 7/18/2012 1:40 PM, glen herrmannsfeldt wrote:
>>> xxxrxxxxxx@gmail.com wrote:
>> &gt;&gt; On Wednesday, 18 July 2012 09:45:25 UTC+10, John W Kennedy  &gt; On 2012-07-17 21:59:38 +0000, Fritz Wuehler said:
>>
>> &gt;&gt;&gt; Have you ever looked at the object code produced for strcpy, etc., on
>> &gt;&gt;&gt; /any/ modern architecture? The 370 line had to add some new opcodes.
>>>>> (Before that was available, it used a TRT loop to scan the source
>>>>> before staring the actual copy.) And code for Intel is nearly as bad.
>>
>>> Intel had/has the REP instruction for helping with
>>> zero-terminated strings.
>>
>>> I thought REP was an instruction prefix, but maybe close enough
>>> to an instruction.
>>
>>> But yes, it allows for repeating a move instruction as long as
>>> the byte (or, I believe, word) isn't zero.
>>
>>> It might be faster for aligned data, though, to run a loop
>>> of load/store using 32 bit or (in x86_64) 64 bit registers.
>>> (And maybe even for unaligned data.)
>
>> That would be great, bit Intel screwed it up so "REP CMPSD" doesn't
>> compare correctly for other than equal and not equal.
>
> Isn't that all you need for looking for zero?
>

Yes, but if you're trying to compare two character strings, CMPSB 
compares a byte at a time, but CMPSD compares a little-endian dword at a 
time, which will not yield the results you expect.

-- 
Pete


0
Peter_Flass (956)
7/19/2012 2:55:26 PM
On 2012-07-19 00:28:49 +0000, robin.vowels@gmail.com said:

> On Thursday, 19 July 2012 10:12:24 UTC+10, John W Kennedy  wrote:
> 
>> The two biggest problems, really, were competition for SYS1.SYSJOBQE
>> and the design of QSAM that meant that, unless you did some fairly
>> sophisticated assembler-only runtime twiddling, a hard-coded BLKSIZE
>> could not be overridden, and many programs naively specified BLKSIZE=80
>> or BLKSIZE=133, which all to horrid performance,
> 
> Not when BUFFNO was specified, which we did with the catprocs.

BUFNO and BLKSIZE are entirely different, although increasing BUFNO 
would provide some partial relief.

-- 
John W Kennedy
"The grand art mastered the thudding hammer of Thor
And the heart of our lord Taliessin determined the war."
  -- Charles Williams.  "Mount Badon"

0
jwkenne (1442)
7/19/2012 4:16:55 PM
On 2012-07-19 12:45:42 +0000, Shmuel (Seymour J.) Metz said:

> In <500750e8$0$6054$607ed4bc@cv.net>, on 07/18/2012
>    at 08:12 PM, John W Kennedy <jwkenne@attglobal.net> said:
> 
>> Yes, although they were not exactly "jobs".
> 
> Under the covers, START processing involved passing JCL through the
> Reader/Interpreter and passing the output to the scheduler. From the
> OS perspective it looked like a job.
> 
>> QSAM spooling.
> 
> The is no such thing. OS/360 SPOOL data sets were normal PS data sets
> on DASD and could be processed with BSAM, EXCP or QSAM; the access
> method did not do the spooling.

Yes, but while that is technically true, virtually all programs /did/ 
use QSAM. (Except for ALGOL 60, which not only used BSAM, but 
NOTE/POINT, so that, in later years, it was necessary to "print" from 
ALGOL 60 programs to a temporary file and then IEBGENER it to SYSOUT.)

-- 
John W Kennedy
If Bill Gates believes in "intelligent design", why can't he apply it 
to Windows?

0
jwkenne (1442)
7/19/2012 4:20:57 PM
On 2012-07-19 00:19:50 +0000, robin.vowels@gmail.com said:

> On Thursday, 19 July 2012 09:48:21 UTC+10, John W Kennedy  wrote:
>> On 2012-07-18 17:55:36 +0000, glen herrmannsfeldt said:
> 
>> &gt; If a procedure/method only references one structure/object,
>> &gt; then, at least to me, the anonymous pointer/this object seems
>> &gt; to make things more readable. At two it is pretty questionable,
>> &gt; and more than that tends to be less readable.
>> 
>> It eliminates all possibility of static checking.
> 
> Which is?

Catching programming errors at compile time instead of at run time, of course.

-- 
John W Kennedy
"Those in the seat of power oft forget their failings and seek only the 
obeisance of others!  Thus is bad government born!  Hold in your heart 
that you and the people are one, human beings all, and good government 
shall arise of its own accord!  Such is the path of virtue!"
  -- Kazuo Koike.  "Lone Wolf and Cub:  Thirteen Strings" (tr. Dana Lewis)

0
jwkenne (1442)
7/19/2012 4:22:33 PM
On 2012-07-19 00:14:44 +0000, robin.vowels@gmail.com said:

> On Thursday, 19 July 2012 09:54:46 UTC+10, John W Kennedy  wrote:
>> On 2012-07-18 23:30:10 +0000, xxxxxxxxxxxx@gmail.com said:
>> 
>>> On Thursday, 19 July 2012 01:22:21 UTC+10, John W Kennedy  wrote:
> 
>>>>>> Locate-mode I/O doesn't really exist anymore, except in OS/360 (and
>>>>>> DOS/360) legacy features -- unless you count data-in-virtual.
>> &gt;&gt;
>> &gt;&gt;&gt; Locate mode still exists, even on Windows.
>> &gt;&gt;
>>>> No, it doesn't.
>> 
>>> Have a look at SC14-7285-01 (for AIX, Enterprise, Windows),
>>> and SC26-8003.
>> 
>> Those are IBM manuals describing PL/I,
> 
> That's what counts.

PL/I is not Windows. Windows is not PL/I. Apparently this is radical 
concept to you, but I assure you, it's true.

>> not Microsoft manuals describing
>> Windows. Windows does not have locate mode, and never did (and neither
>> did OS/2).
> 
> Read the manual.

Since PL/I manuals do not describe Windows, there is no point to that.

-- 
John W Kennedy
Read the remains of Shakespeare's lost play, now annotated!
http://www.SKenSoftware.com/Double%20Falshood

0
jwkenne (1442)
7/19/2012 4:24:01 PM
On 2012-07-19 12:40:47 +0000, Shmuel (Seymour J.) Metz said:

> In <ju7g7u$lk7$2@dont-email.me>, on 07/18/2012
>    at 07:18 PM, Peter Flass <Peter_Flass@Yahoo.com> said:
> 
>> I don't think I ever saw an OS system without HASP, but without it
>> didn't the system have to run a reader/interpreter job or an output
>> writer for every device?
> 
> Unless you're running ASP. Note that even with ASP or HASP you still
> need the Reader/Interpreter, although the operator doesn't start the
> R/I tasks.
> 
>> It would seem you'd quickly load up the system
>> with lots of often unused jobs.
> 
> The typical shop had only one reader/punch and one or two printers.
> The shops with more unit-record equipment usually had more memory and
> faster processors.

I remember, ca. 1970, visiting the AT&T data center where they printed 
dividend checks. A room full of 1403s (in the process of being replaced 
by 3211s) that seemed to stretch to the horizon....

-- 
John W Kennedy
"When a man contemplates forcing his own convictions down another man's 
throat, he is contemplating both an unchristian act and an act of 
treason to the United States."
  -- Joy Davidman, "Smoke on the Mountain"

0
jwkenne (1442)
7/19/2012 4:28:22 PM
On 2012-07-18 00:03:32 +0000, Shmuel (Seymour J.) Metz said:

> In <50048f22$0$26886$607ed4bc@cv.net>, on 07/16/2012
>    at 06:01 PM, John W Kennedy <jwkenne@attglobal.net> said:
> 
>> It remains a fact that OS/360, from the start, used assembler-like
>> constructs for everything from JCL, to utility-program control
>> cards, to PARM values, and IBM then made a consistent shift to
>> PL/I-like constructs for such purposes in new applications
>> starting around 1969.
> 
> It remains a fact that what you call "PL/I-like constructs" had syntax
> grossly at variance with that of PL/I. Nor is "OS/360 command
> languages" a plausible reading of your "command languages".

You are now slipping into outright dishonesty.

>  EXEC is
> every bit as much of a command language as anything in OS/360, and it
> inherits nothing from either assembler syntax or PL/I syntax.

EXEC is from CMS, and is not, historically, IBM software.

-- 
John W Kennedy
Read the remains of Shakespeare's lost play, now annotated!
http://www.SKenSoftware.com/Double%20Falshood

0
jwkenne (1442)
7/19/2012 4:37:00 PM
On 2012-07-19 14:46:04 +0000, Peter Flass said:

> On 7/17/2012 8:03 PM, Shmuel (Seymour J.) Metz wrote:
>> In <ju1r2r$eq4$1@speranza.aioe.org>, on 07/16/2012
>> at 07:46 PM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:
>> 
>>> Well, JCL does have a similar form to S/360 assembler,
>> 
>> Yes, but CLIST does not look like PL/I, despite the support of keyword
>> parameters.
>> 
> 
> I'd like to say CLIST doesn't look like *anything*.  I absolutely hated 
> it, and was very glad to see Rexx.  However, I researched this a bit 
> and it looks like CLIST is descended from CTSS RUNCOM, etc.  but has no 
> relation to PL/I.

In any case, CLIST isn't CL.

-- 
John W Kennedy
"There are those who argue that everything breaks even in this old dump 
of a world of ours. I suppose these ginks who argue that way hold that 
because the rich man gets ice in the summer and the poor man gets it in 
the winter things are breaking even for both. Maybe so, but I'll swear 
I can't see it that way."
  -- The last words of Bat Masterson

0
jwkenne (1442)
7/19/2012 4:38:09 PM
>>Pretty much anything more advanced than the Z-80.
>
>That would make some 1950's and 1960's machines modern.

Other than the address size, the GE 645 was pretty modern.

ObPL/I: nearly all of its system code was written in PL/I

R's,
John
-- 
Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
0
johnl (129)
7/19/2012 5:24:57 PM
>The loss of locate-mode I/O is tied to the loss of C-K-D disk 
>structures.  With CKD you say "give me a record of maximum length <x> 
>and put it <here>" and the channel and device do the rest.  Without 
>that, you have to read a certain number of disk sectors to find out how 
>big your record is, whether OS/360-type variable length records or C 
>LF-terminated stuff.  In that case you already have the data in buffers 
>somewhere, so you just move it.

Not necessarily.  On most modern systems, including Unix, Linux, and
Windows, there is a system call to map a file into the process'
address space so that the file is read and written on demand via page
faults with no copying beyond the disk I/O.  If the data on the disk
is in a format that PL/I can understand, locate mode would so what
it's always been intended to do.

File mapping is heavily used to read executables and shared libraries,
less so for file I/O.  I think the reason we care less about locate
style I/O is that even though processors and disks have both gotten
faster since the 1960s, CPUs have gotten relatively much faster.  

On a 360/30, the MVC to move a 100 character field took 330us, or 355
if it used EX to set the field length.  Do a 20 of those for a 2K disk
block and it's 6ms just to move the data, an appreciable fraction of
the time to do the disk I/O.  These days, moving that much data is
probably under 50us, so who cares?

R's,
John


-- 
Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
0
johnl (129)
7/19/2012 6:03:43 PM
John Levine <johnl@iecc.com> wrote:
(after someone else wrote)
>>The loss of locate-mode I/O is tied to the loss of C-K-D disk 
>>structures.  With CKD you say "give me a record of maximum length <x> 
>>and put it <here>" and the channel and device do the rest.  

(snip)
> Not necessarily.  On most modern systems, including Unix, Linux, and
> Windows, there is a system call to map a file into the process'
> address space so that the file is read and written on demand via page
> faults with no copying beyond the disk I/O.  If the data on the disk
> is in a format that PL/I can understand, locate mode would so what
> it's always been intended to do.

I think I agree. The way the discussion got here was through
anonymous pointers, and me claiming that with locate-mode I/O,
that anonymous pointers weren't so bad. More specifically, if
a routine only has one pointer it isn't hard to keep track of.

Using locate-mode, the one pointer points to a record, you do
all the stuff you need to do to that record, then go on.
No distractions with what points to what.

> File mapping is heavily used to read executables and shared libraries,
> less so for file I/O.  I think the reason we care less about locate
> style I/O is that even though processors and disks have both gotten
> faster since the 1960s, CPUs have gotten relatively much faster.  

Yes, and the reason why many of the optimizations done for S/360
no longer make sense. Well, speed and also the increase in 
memory size. Bigger memories allow for all that buffering
without excessive cost.

> On a 360/30, the MVC to move a 100 character field took 330us, or 355
> if it used EX to set the field length.  Do a 20 of those for a 2K disk
> block and it's 6ms just to move the data, an appreciable fraction of
> the time to do the disk I/O.  These days, moving that much data is
> probably under 50us, so who cares?

Well, 50us, 50us there, and pretty soon it adds up.

Also, as records get bigger, the time to copy them around
increases. 

-- glen
0
gah (12851)
7/19/2012 7:15:53 PM
On Friday, 20 July 2012 02:16:55 UTC+10, John W Kennedy  wrote:
> On 2012-07-19 00:28:49 +0000, yyyyyyyy@gmail.com said:
> 
> &gt; On Thursday, 19 July 2012 10:12:24 UTC+10, John W Kennedy  wrote:
> &gt; 
> &gt;&gt; The two biggest problems, really, were competition for SYS1.SYSJOBQE
> &gt;&gt; and the design of QSAM that meant that, unless you did some fairly
> &gt;&gt; sophisticated assembler-only runtime twiddling, a hard-coded BLKSIZE
> &gt;&gt; could not be overridden, and many programs naively specified BLKSIZE=80
> &gt;&gt; or BLKSIZE=133, which all to horrid performance,
> &gt; 
> &gt; Not when BUFFNO was specified, which we did with the catprocs.
> 
> BUFNO and BLKSIZE are entirely different, although increasing BUFNO 
> would provide some partial relief.

Certainly BUFFNO did (IIRC, we used about BUFFNO=15 for the
reader).
BLKSIZE helped reduce disc accesses (thrashing).

0
robin.vowels (428)
7/20/2012 12:55:13 AM
On Friday, 20 July 2012 02:24:01 UTC+10, John W Kennedy  wrote:
> On 2012-07-19 00:14:44 +0000, zzzzzzzz2@gmail.com said:
> 
> &gt; On Thursday, 19 July 2012 09:54:46 UTC+10, John W Kennedy  wrote:
> &gt;&gt; On 2012-07-18 23:30:10 +0000, xxxxxxxxxxxx@gmail.com said:
> &gt;&gt; 
> &gt;&gt;&gt; On Thursday, 19 July 2012 01:22:21 UTC+10, John W Kennedy  wrote:
> &gt; 
> &gt;&gt;&gt;&gt;&gt;&gt; Locate-mode I/O doesn&#39;t really exist anymore, except in OS/360 (and
> &gt;&gt;&gt;&gt;&gt;&gt; DOS/360) legacy features -- unless you count data-in-virtual.
> &gt;&gt; &amp;gt;&amp;gt;
> &gt;&gt; &amp;gt;&amp;gt;&amp;gt; Locate mode still exists, even on Windows.
> &gt;&gt; &amp;gt;&amp;gt;
> &gt;&gt;&gt;&gt; No, it doesn&#39;t.
> &gt;&gt; 
> &gt;&gt;&gt; Have a look at SC14-7285-01 (for AIX, Enterprise, Windows),
> >>> and SC26-8003.
>
> >> Those are IBM manuals describing PL/I,
> 
> > That's what counts.
> 
> PL/I is not Windows. Windows is not PL/I. Apparently this is radical 
> concept to you, but I assure you, it's true.

Look in any PL/I manual.

> >> not Microsoft manuals describing
> >> Windows. Windows does not have locate mode, and never did (and neither
> >> did OS/2).
>
> > Read the manual.
> 
> Since PL/I manuals do not describe Windows, there is no point to that.

Look in the index of cited PL/I manual for "LOCATE statement".
Then look at the referenced page for an enlightening
description.

0
robin.vowels (428)
7/20/2012 1:25:29 AM
On Friday, 20 July 2012 02:28:22 UTC+10, John W Kennedy  wrote:
> On 2012-07-19 12:40:47 +0000, Shmuel (Seymour J.) Metz said:
> 
> &gt; In &lt;ju7g7u$lk7$2@dont-email.me&gt;, on 07/18/2012
> &gt;    at 07:18 PM, Peter Flass &lt;aaaaaaa@Yahoo.com&gt; said:
> &gt; 
> &gt;&gt; I don&#39;t think I ever saw an OS system without HASP, but without it
> &gt;&gt; didn't the system have to run a reader/interpreter job or an output
> &gt;&gt; writer for every device?
> &gt; 
> &gt; Unless you&#39;re running ASP. Note that even with ASP or HASP you still
> &gt; need the Reader/Interpreter, although the operator doesn&#39;t start the
> &gt; R/I tasks.
> &gt; 
> &gt;&gt; It would seem you&#39;d quickly load up the system
> &gt;&gt; with lots of often unused jobs.
> &gt; 
> &gt; The typical shop had only one reader/punch and one or two printers.
> &gt; The shops with more unit-record equipment usually had more memory and
> &gt; faster processors.
> 
> I remember, ca. 1970, visiting the AT'T data center where they printed 
> dividend checks. A room full of 1403s (in the process of being replaced 
> by 3211s) that seemed to stretch to the horizon....

The 1403 was a tad slow.
For that kind of work, a drum printer would have been better,
typically giving 1150-1250 LPM.
0
robin.vowels (428)
7/20/2012 1:31:59 AM
robin.vowels@gmail.com wrote:

(snip)
> The 1403 was a tad slow.
> For that kind of work, a drum printer would have been better,
> typically giving 1150-1250 LPM.

The drum printers I knew were a lot slower than that, but they
were upper and lower case.

A 1403 with a numeric (and a few other characters) train is
very fast. With QN or PN, reasonably fast, and with TN not
so fast.

-- glen
0
gah (12851)
7/20/2012 4:50:58 AM
On Friday, 20 July 2012 14:50:58 UTC+10, glen herrmannsfeldt  wrote:
> rrrrrrrrr@gmail.com wrote:
> 
> (snip)
> &gt; The 1403 was a tad slow.
> &gt; For that kind of work, a drum printer would have been better,
> &gt; typically giving 1150-1250 LPM.
> 
> The drum printers I knew were a lot slower than that, but they
> were upper and lower case.
> 
> A 1403 with a numeric (and a few other characters) train is
> very fast.

Without alphabetic characters, such a train was for specialized
purposes and was not generally useful.

> With QN or PN, reasonably fast,

but not when many characters per line were printed.
Furthermore, the trains wore out very quickly.

> and with TN not so fast.

Woefully slow, less than 200 lpm.

Admittedly, the different trains could be changed quickly
to give different character sets.  However, one decent drum
would give the complete character set plus high speed printing.
0
robin.vowels (428)
7/20/2012 9:17:03 AM
In <500837f1$0$11515$607ed4bc@cv.net>, on 07/19/2012
   at 12:38 PM, John W Kennedy <jwkenne@attglobal.net> said:

>In any case, CLIST isn't CL.

How is that relevant? Your statement was "But CL is indeed strongly
influenced by PL/I, as were most other IBM  command languages of the
late 60s and 70s, such as TSO and IDCAMS." It's the "most other" part
that is under challenge, not the CL part.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
spamtrap16 (3722)
7/20/2012 2:29:45 PM
In <500833e9$0$11518$607ed4bc@cv.net>, on 07/19/2012
   at 12:20 PM, John W Kennedy <jwkenne@attglobal.net> said:

>Yes, but while that is technically true, virtually all programs /did/
> use QSAM.

I never saw a census of who used what, but didn't the FORTRAN library
make heavy use of BSAM?

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
spamtrap16 (3722)
7/20/2012 2:31:36 PM
In <500837ac$0$11541$607ed4bc@cv.net>, on 07/19/2012
   at 12:37 PM, John W Kennedy <jwkenne@attglobal.net> said:

>You are now slipping into outright dishonesty.

Well, someone is.

>EXEC is from CMS,

Water is what.

>and is not, historically, IBM software.

What are you smoking?

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
spamtrap16 (3722)
7/20/2012 2:41:32 PM
On 2012-07-20 01:25:29 +0000, robin.vowels@gmail.com said:

> On Friday, 20 July 2012 02:24:01 UTC+10, John W Kennedy  wrote:
>> On 2012-07-19 00:14:44 +0000, zzzzzzzz2@gmail.com said:
>> 
>> &gt; On Thursday, 19 July 2012 09:54:46 UTC+10, John W Kennedy  wrote:
>> &gt;&gt; On 2012-07-18 23:30:10 +0000, xxxxxxxxxxxx@gmail.com said:
>> &gt;&gt;
>> &gt;&gt;&gt; On Thursday, 19 July 2012 01:22:21 UTC+10, John W Kennedy  wrote:
>> &gt;
>> &gt;&gt;&gt;&gt;&gt;&gt; Locate-mode I/O doesn&#39;t really exist 
>> anymore, except in OS/360 (and
>> &gt;&gt;&gt;&gt;&gt;&gt; DOS/360) legacy features -- unless you count 
>> data-in-virtual.
>> &gt;&gt; &amp;gt;&amp;gt;
>> &gt;&gt; &amp;gt;&amp;gt;&amp;gt; Locate mode still exists, even on Windows.
>> &gt;&gt; &amp;gt;&amp;gt;
>> &gt;&gt;&gt;&gt; No, it doesn&#39;t.
>> &gt;&gt;
>> &gt;&gt;&gt; Have a look at SC14-7285-01 (for AIX, Enterprise, Windows),
>>>>> and SC26-8003.
>> 
>>>> Those are IBM manuals describing PL/I,
>> 
>>> That's what counts.
>> 
>> PL/I is not Windows. Windows is not PL/I. Apparently this is radical
>> concept to you, but I assure you, it's true.
> 
> Look in any PL/I manual.
> 
>>>> not Microsoft manuals describing
>>>> Windows. Windows does not have locate mode, and never did (and neither
>>>> did OS/2).
>> 
>>> Read the manual.
>> 
>> Since PL/I manuals do not describe Windows, there is no point to that.
> 
> Look in the index of cited PL/I manual for "LOCATE statement".
> Then look at the referenced page for an enlightening
> description.

It says nothing about Windows APIs, because it is not a Windows manual. 
Windows does not have locate mode, and never did.

-- 
John W Kennedy
"Sweet, was Christ crucified to create this chat?"
  -- Charles Williams.  "Judgement at Chelmsford"

0
jwkenne (1442)
7/20/2012 3:31:44 PM
On 2012-07-20 01:31:59 +0000, robin.vowels@gmail.com said:

> On Friday, 20 July 2012 02:28:22 UTC+10, John W Kennedy  wrote:
>> On 2012-07-19 12:40:47 +0000, Shmuel (Seymour J.) Metz said:
>> 
>> &gt; In &lt;ju7g7u$lk7$2@dont-email.me&gt;, on 07/18/2012
>> &gt;    at 07:18 PM, Peter Flass &lt;aaaaaaa@Yahoo.com&gt; said:
>> &gt;
>> &gt;&gt; I don&#39;t think I ever saw an OS system without HASP, but without it
>> &gt;&gt; didn't the system have to run a reader/interpreter job or an output
>> &gt;&gt; writer for every device?
>> &gt;
>> &gt; Unless you&#39;re running ASP. Note that even with ASP or HASP you still
>> &gt; need the Reader/Interpreter, although the operator doesn&#39;t start the
>> &gt; R/I tasks.
>> &gt;
>> &gt;&gt; It would seem you&#39;d quickly load up the system
>> &gt;&gt; with lots of often unused jobs.
>> &gt;
>> &gt; The typical shop had only one reader/punch and one or two printers.
>> &gt; The shops with more unit-record equipment usually had more memory and
>> &gt; faster processors.
>> 
>> I remember, ca. 1970, visiting the AT'T data center where they printed
>> dividend checks. A room full of 1403s (in the process of being replaced
>> by 3211s) that seemed to stretch to the horizon....
> 
> The 1403 was a tad slow.
> For that kind of work, a drum printer would have been better,
> typically giving 1150-1250 LPM.

The 1403-3 and -N1 printed at 1100 LPM with a 48-character set, and 
lacked the vertical-alignment problems of drum printers. (And, of 
course, could be switched to larger character sets when needed.)

-- 
John W Kennedy
"Give up vows and dogmas, and fixed things, and you may grow like That. 
....you may come to think a blow bad, because it hurts, and not because 
it humiliates.  You may come to think murder wrong, because it is 
violent, and not because it is unjust."
  -- G. K. Chesterton.  "The Ball and the Cross"

0
jwkenne (1442)
7/20/2012 3:33:50 PM
On 2012-07-20 04:50:58 +0000, glen herrmannsfeldt said:

> robin.vowels@gmail.com wrote:
> 
> (snip)
>> The 1403 was a tad slow.
>> For that kind of work, a drum printer would have been better,
>> typically giving 1150-1250 LPM.
> 
> The drum printers I knew were a lot slower than that, but they
> were upper and lower case.
> 
> A 1403 with a numeric (and a few other characters) train is
> very fast.

Up to 1400, if I recall aright.

>  With QN or PN, reasonably fast, and with TN not
> so fast.

-- 
John W Kennedy
"The pathetic hope that the White House will turn a Caligula into a 
Marcus Aurelius is as naïve as the fear that ultimate power inevitably 
corrupts."
  -- James D. Barber (1930-2004)


0
jwkenne (1442)
7/20/2012 3:34:45 PM
On 2012-07-20 09:17:03 +0000, robin.vowels@gmail.com said:

> On Friday, 20 July 2012 14:50:58 UTC+10, glen herrmannsfeldt  wrote:
>> rrrrrrrrr@gmail.com wrote:
>> 
>> (snip)
>> &gt; The 1403 was a tad slow.
>> &gt; For that kind of work, a drum printer would have been better,
>> &gt; typically giving 1150-1250 LPM.
>> 
>> The drum printers I knew were a lot slower than that, but they
>> were upper and lower case.
>> 
>> A 1403 with a numeric (and a few other characters) train is
>> very fast.
> 
> Without alphabetic characters, such a train was for specialized
> purposes and was not generally useful.
> 
>> With QN or PN, reasonably fast,
> 
> but not when many characters per line were printed.

Wrong.

> Furthermore, the trains wore out very quickly.

Not even once, in my experience, though I'm sure it happened from time to time.

>> and with TN not so fast.
> 
> Woefully slow, less than 200 lpm.

No, 270 lpm at the worst, and that only on the already obsolescent 
1403-2. The 1403-N1, which was the de-facto standard 360 printer, 
printed the TN train at 552 lpm at the worst.

> Admittedly, the different trains could be changed quickly
> to give different character sets.  However, one decent drum
> would give the complete character set plus high speed printing.

I never heard of a drum printer that could do that /and/ produce 
decently registered printing, though I'm not enough of an engineer to 
categorically pronounce it impossible.

-- 
John W Kennedy
"The whole modern world has divided itself into Conservatives and 
Progressives. The business of Progressives is to go on making mistakes. 
The business of the Conservatives is to prevent the mistakes from being 
corrected."
  -- G. K. Chesterton

0
jwkenne (1442)
7/20/2012 4:07:08 PM
On 2012-07-20 14:29:45 +0000, Shmuel (Seymour J.) Metz said:

> In <500837f1$0$11515$607ed4bc@cv.net>, on 07/19/2012
>    at 12:38 PM, John W Kennedy <jwkenne@attglobal.net> said:
> 
>> In any case, CLIST isn't CL.
> 
> How is that relevant? Your statement was "But CL is indeed strongly
> influenced by PL/I, as were most other IBM  command languages of the
> late 60s and 70s, such as TSO and IDCAMS." It's the "most other" part
> that is under challenge, not the CL part.

If you don't see the obviously organized shift in IBM design standards 
ca. 1969 from:

    command  positional1,positional2,keyword1=value1,keyword2=value2

    command  positional1 positional2 keyword1 (value1) keyword2 (value2)

effecting TSO commands, PARM fields, utility programs, and just about 
everything else involving imperatives, I don't know any way to make it 
plainer.

-- 
John W Kennedy
"When a man contemplates forcing his own convictions down another man's 
throat, he is contemplating both an unchristian act and an act of 
treason to the United States."
  -- Joy Davidman, "Smoke on the Mountain"

0
jwkenne (1442)
7/20/2012 4:27:38 PM
On 2012-07-20 14:31:36 +0000, Shmuel (Seymour J.) Metz said:

> In <500833e9$0$11518$607ed4bc@cv.net>, on 07/19/2012
>    at 12:20 PM, John W Kennedy <jwkenne@attglobal.net> said:
> 
>> Yes, but while that is technically true, virtually all programs /did/
>> use QSAM.
> 
> I never saw a census of who used what, but didn't the FORTRAN library
> make heavy use of BSAM?

In order to implement BACKSPACE and REWIND and jumping between input 
and output, yes, it had to. All sequential files were opened either 
INOUT or OUTIN depending on whether READ or WRITE came first, which 
caused security and other problems later on that had to be fixed by the 
new IN (treat INOUT as INPUT) and OUT (treat OUTIN as OUTPUT) 
suboptions of DD LABEL=. The FORTRAN library also silently implemented 
VS and VBS before they were officially part of the operating system.

-- 
John W Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
  -- Charles Williams.  "Judgement at Chelmsford"

0
jwkenne (1442)
7/20/2012 4:35:50 PM
On Saturday, 21 July 2012 01:33:50 UTC+10, John W Kennedy  wrote:
> On 2012-07-20 01:31:59 +0000, rrrrrrrr@gmail.com said:
> 
> &gt; On Friday, 20 July 2012 02:28:22 UTC+10, John W Kennedy  wrote:
> &gt;&gt; On 2012-07-19 12:40:47 +0000, Shmuel (Seymour J.) Metz said:
> &gt;&gt; 
> &gt;&gt; &amp;gt; In &amp;lt;ju7g7u$lk7$2@dont-email.me&amp;gt;, on 07/18/2012
> &gt;&gt; &amp;gt;    at 07:18 PM, Peter Flass &amp;lt;aaaaaaa@Yahoo.com&amp;gt; said:
> &gt;&gt; &amp;gt;
> &gt;&gt; &amp;gt;&amp;gt; I don&amp;#39;t think I ever saw an OS system without HASP, but without it
> &gt;&gt; &amp;gt;&amp;gt; didn&#39;t the system have to run a reader/interpreter job or an output
> &gt;&gt; &amp;gt;&amp;gt; writer for every device?
> &gt;&gt; &amp;gt;
> &gt;&gt; &amp;gt; Unless you&amp;#39;re running ASP. Note that even with ASP or HASP you still
> &gt;&gt; &amp;gt; need the Reader/Interpreter, although the operator doesn&amp;#39;t start the
> &gt;&gt; &amp;gt; R/I tasks.
> &gt;&gt; &amp;gt;
> &gt;&gt; &amp;gt;&amp;gt; It would seem you&amp;#39;d quickly load up the system
> &gt;&gt; &amp;gt;&amp;gt; with lots of often unused jobs.
> &gt;&gt; &amp;gt;
> &gt;&gt; &amp;gt; The typical shop had only one reader/punch and one or two printers.
> &gt;&gt; &amp;gt; The shops with more unit-record equipment usually had more memory and
> &gt;&gt; &amp;gt; faster processors.
> &gt;&gt; 
> &gt;&gt; I remember, ca. 1970, visiting the AT&#39;T data center where they printed
> &gt;&gt; dividend checks. A room full of 1403s (in the process of being replaced
> &gt;&gt; by 3211s) that seemed to stretch to the horizon....
> &gt; 
> &gt; The 1403 was a tad slow.
> &gt; For that kind of work, a drum printer would have been better,
> &gt; typically giving 1150-1250 LPM.
> 
> The 1403-3 and -N1 printed at 1100 LPM with a 48-character set,

Um, to run with PL/I, the 60-character set was required
as a minimum.

The speed with 60 was significantly less than 1100 lpm, slowed
down considerably with full-ish lines,
and could not keep up with the card reader.

> and 
> lacked the vertical-alignment problems of drum printers.

but introduced its own problems of only half or less of the
character being printed.

And as I said, the print trains wore out rather rapidly.

> (And, of 
> course, could be switched to larger character sets when needed.)

Which why the 48-character set print train wasn't used much.

For the record, the competition (IBM clones) was offering 
drum printers at 1080 LPM with 64 characters (and doesn't slow
down much when full lines are printed on account of there being
one or more characters in *each* print column).  I think that
the maker of those printers was Analine.

Using a reduced character set of 16 characters including the
digits, speed was 2,700 LPM.

Using the 48 character set, speed was 1350 LPM.

The latter two modes were for specialist usage.
0
robin.vowels (428)
7/20/2012 4:45:28 PM
On 2012-07-20 14:41:32 +0000, Shmuel (Seymour J.) Metz said:

> In <500837ac$0$11541$607ed4bc@cv.net>, on 07/19/2012
>    at 12:37 PM, John W Kennedy <jwkenne@attglobal.net> said:
> 
>> You are now slipping into outright dishonesty.
> 
> Well, someone is.
> 
>> EXEC is from CMS,
> 
> Water is what.
> 
>> and is not, historically, IBM software.
> 
> What are you smoking?

It was only when VM/370 came out that it was promoted to equal status 
with the OS and DOS lines. It was developed in the field, and 
distributed as either Type III or Type IV software.

-- 
John W Kennedy
"Sweet, was Christ crucified to create this chat?"
  -- Charles Williams.  "Judgement at Chelmsford"

0
jwkenne (1442)
7/20/2012 4:59:53 PM
On Saturday, 21 July 2012 02:07:08 UTC+10, John W Kennedy  wrote:
> On 2012-07-20 09:17:03 +0000, rrrrrrrr1@gmail.com said:
> 
> &gt; On Friday, 20 July 2012 14:50:58 UTC+10, glen herrmannsfeldt  wrote:
> &gt;&gt; rrrrrrrrr@gmail.com wrote:

> &gt;&gt; &amp;gt; The 1403 was a tad slow.
> &gt;&gt; &amp;gt; For that kind of work, a drum printer would have been better,
> &gt;&gt; &amp;gt; typically giving 1150-1250 LPM.
> &gt;&gt; 
> &gt;&gt; The drum printers I knew were a lot slower than that, but they
> &gt;&gt; were upper and lower case.
> &gt;&gt; 
> &gt;&gt; A 1403 with a numeric (and a few other characters) train is
> &gt;&gt; very fast.
> &gt; 
> &gt; Without alphabetic characters, such a train was for specialized
> &gt; purposes and was not generally useful.
> &gt; 
> &gt;&gt; With QN or PN, reasonably fast,
> 
> > but not when many characters per line were printed.
> 
> Wrong.

> > Furthermore, the trains wore out very quickly.
>
> Not even once, in my experience,

The printer must have had only light usage.

> though I'm sure it happened from time to time.

It happened regularly on our S/360.
And while we were waiting for either a replacement
or a repair (which could last for weeks) we'd have to use the
upper-and-lower-case print train, which was woefully slow.

> >> and with TN not so fast.
> >
> > Woefully slow, less than 200 lpm.
> 
> No, 270 lpm at the worst, and that only on the already obsolescent 
> 1403-2. The 1403-N1, which was the de-facto standard 360 printer, 
> printed the TN train at 552 lpm at the worst.
> 
> > Admittedly, the different trains could be changed quickly
> > to give different character sets.  However, one decent drum
> > would give the complete character set plus high speed printing.
> 
> I never heard of a drum printer that could do that /and/ produce 
> decently registered printing, though I'm not enough of an engineer to 
> categorically pronounce it impossible.

If that was happening, then the paper tension was wrong, or the
sprocket holes in the paper were too large.
0
robin.vowels (428)
7/20/2012 5:07:31 PM
Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> wrote:
> In <500833e9$0$11518$607ed4bc@cv.net>, on 07/19/2012
>   at 12:20 PM, John W Kennedy <jwkenne@attglobal.net> said:

>>Yes, but while that is technically true, virtually all programs /did/
>> use QSAM.

> I never saw a census of who used what, but didn't the 
> FORTRAN library make heavy use of BSAM?

As far as I know, for the OS/360 compilers the Fortran library
for sequential I/O was all BSAM. (BDAM for direct access.)

As far as I know, most utilities used BSAM, though I haven't
looked at them so much.

That might have changed in later years. Rumors are that some 
versions allowed for VB files for formatted I/O, but I only
remember FB. (Unformatted was always VBS.)

-- glen
0
gah (12851)
7/20/2012 7:20:58 PM
John W Kennedy <jwkenne@attglobal.net> wrote:

(snip, someone wrote)
>> Admittedly, the different trains could be changed quickly
>> to give different character sets.  However, one decent drum
>> would give the complete character set plus high speed printing.

> I never heard of a drum printer that could do that /and/ produce 
> decently registered printing, though I'm not enough of an engineer to 
> categorically pronounce it impossible.

I thought I remembered about 600lpm for the DEC printers that I
used to use. Depending on what you mean by decently registered,
the registration might have been about the same, but the eye
is much more sensitive to vertical misregistration.

As I remember, the usual upper case trains have five of most 
common characters, one one of some others.

I was once printing a table using one of the less common characters
as a column separator. (Probably vertical bar.) The print operator
actually came out to explain this to me, and I switched to some
other character, probably '*'.

For chain/train printers, and also as far as I know for drum printers,
the paper moves to the next line soon after all positions have
been printed. Drum printers only have one copy of each character,
so usually a whole revolution. I believe five for the upper
case trains, and two for TN.

-- glen
0
gah (12851)
7/20/2012 7:39:37 PM
robin.vowels@gmail.com wrote:
(snip, someone wrote)
>> The 1403-3 and -N1 printed at 1100 LPM with a 48-character set,

> Um, to run with PL/I, the 60-character set was required
> as a minimum.

Not, at least for (F). There is an option for a 48 character
set and you use various (I believe) reserved words or symbols
in place of the other characters.

> The speed with 60 was significantly less than 1100 lpm, slowed
> down considerably with full-ish lines,
> and could not keep up with the card reader.

If you used all 60, and on most or all lines, then yes.

If you only used the 48 set it was not so much slower.

-- glen
0
gah (12851)
7/20/2012 7:43:09 PM
On Saturday, 21 July 2012 05:39:37 UTC+10, glen herrmannsfeldt  wrote:
> John W Kennedy &lt;jwk@attglobal.net&gt; wrote:
> 
> > Admittedly, the different trains could be changed quickly
> > to give different character sets.  However, one decent drum
> > would give the complete character set plus high speed printing.
> 
> > I never heard of a drum printer that could do that /and/ produce 
> > decently registered printing, though I&#39;m not enough of an engineer to 
> > categorically pronounce it impossible.
> 
> I thought I remembered about 600lpm for the DEC printers that I
> used to use. Depending on what you mean by decently registered,
> the registration might have been about the same, but the eye
> is much more sensitive to vertical misregistration.
> 
> As I remember, the usual upper case trains have five of most 
> common characters, one one of some others.
> 
> I was once printing a table using one of the less common characters
> as a column separator. (Probably vertical bar.) The print operator
> actually came out to explain this to me, and I switched to some
> other character, probably "*".
> 
> For chain/train printers, and also as far as I know for drum printers,
> the paper moves to the next line soon after all positions have
> been printed. Drum printers only have one copy of each character,

Some drums did have only one copy.  But other drums had multiple copies.  Thus, with the Analine(?) printer:
1350 LPM with 48 character set,
1080 LPM with 60 character set, and
2700 LPM with 16 character set.

> so usually a whole revolution.

Definitely not; as soon as all characters in a line were printed,
the paper moved to the next line.
Drums had, in the same position, the same character repeated in
every column.  As the drum rotated, characters from the print
buffer were read out.  If any matched that on the drum row,
the corresponding print hammer was "fired", and any unprinted characters
were returned to the buffer, to await the next position on the drum.
As soon as no characters were returned to the buffer,
printing of the line was complete, and the paper began moving
to the next print line.

In the case where the line contained one or more unprintable
characters, it was necessary to wait for two timing marks
of the print train to pass (for print trains), before moving to
the next line.  And for drum printers, two timing marks of the
drum had to pass before moving to the next line.

> I believe five for the upper
> case trains, and two for TN.
0
robin.vowels (428)
7/21/2012 3:02:11 AM
On Saturday, 21 July 2012 05:43:09 UTC+10, glen herrmannsfeldt  wrote:
> rrrrrrrr@gmail.com wrote:
>
> >> The 1403-3 and -N1 printed at 1100 LPM with a 48-character set,
> 
> > Um, to run with PL/I, the 60-character set was required
> > as a minimum.
> 
> Not, at least for (F). There is an option for a 48 character
> set and you use various (I believe) reserved words or symbols
> in place of the other characters.

No-one used the 48-character set by choice.
That was intended for equipment such as old 026 card key punches
and paper tape equipment that did not have the special characters
required for PL/I.
Using the 48-character set required a special pass by the PL/I
compiler to translate internally to the 60-character set.  That
took extra time.

> > The speed with 60 was significantly less than 1100 lpm, slowed
> > down considerably with full-ish lines,
> > and could not keep up with the card reader.
> 
> If you used all 60, and on most or all lines, then yes.

Indeed.  As was the case for PL/I compiler listings.
Standing next to the line printer, I heard it often enough
(slow down).

> If you only used the 48 set it was not so much slower.

It still slowed down on full-ish lines.

0
robin.vowels (428)
7/21/2012 3:11:20 AM
robin.vowels@gmail.com wrote:

(snip, I wrote)
>> Not, at least for (F). There is an option for a 48 character
>> set and you use various (I believe) reserved words or symbols
>> in place of the other characters.

> No-one used the 48-character set by choice.

Likely true.

> That was intended for equipment such as old 026 card key punches
> and paper tape equipment that did not have the special characters
> required for PL/I.

The 026, like the 029, has multi-punch so you can punch all
the characters that you want. I remember punching ALGOL on
026 punches. There was a big chart on the wall telling how
to punch all the characters needed that weren't on the keyboard.

> Using the 48-character set required a special pass by the PL/I
> compiler to translate internally to the 60-character set.  That
> took extra time.

Yes.

-- glen
0
gah (12851)
7/21/2012 4:35:16 AM
On Saturday, 21 July 2012 14:35:16 UTC+10, glen herrmannsfeldt  wrote:
> rrrrrrrrrr@gmail.com wrote:
> 
> (snip, I wrote)
> &gt;&gt; Not, at least for (F). There is an option for a 48 character
> &gt;&gt; set and you use various (I believe) reserved words or symbols
> &gt;&gt; in place of the other characters.
> 
> &gt; No-one used the 48-character set by choice.
> 
> Likely true.
> 
> > That was intended for equipment such as old 026 card key punches
> > and paper tape equipment that did not have the special characters
> > required for PL/I.
> 
> The 026, like the 029, has multi-punch so you can punch all
> the characters that you want.

Great, except that some (if not all) special characters
shown on the keyboard punched different holes in the cards
from an 029.
No-one in their right mind would use an 026 to prepare 029
codes.  There was no way that the punching of special characters
prepared that way could be checked in some printed form
other than by passing them through the S/360 card reader.
Such mal-punched cards would have caused a read check,
requiring operator intervention and delaying the computer.

> I remember punching ALGOL on
> 026 punches. There was a big chart on the wall telling how
> to punch all the characters needed that weren't on the keyboard.

Some characters on the keyboard put different holes in the cards
from an 029.

> > Using the 48-character set required a special pass by the PL/I
> > compiler to translate internally to the 60-character set.  That
> > took extra time.
> 
> Yes.
0
robin.vowels (428)
7/21/2012 4:53:05 AM
robin.vowels@gmail.com wrote:

(snip, I wrote)
>> The 026, like the 029, has multi-punch so you can punch all
>> the characters that you want.

> Great, except that some (if not all) special characters
> shown on the keyboard punched different holes in the cards
> from an 029.

> No-one in their right mind would use an 026 to prepare 029
> codes.  There was no way that the punching of special characters
> prepared that way could be checked in some printed form
> other than by passing them through the S/360 card reader.
> Such mal-punched cards would have caused a read check,
> requiring operator intervention and delaying the computer.

I don't know if the B5500 has read check.

>> I remember punching ALGOL on
>> 026 punches. There was a big chart on the wall telling how
>> to punch all the characters needed that weren't on the keyboard.

> Some characters on the keyboard put different holes in the cards
> from an 029.

Yes. 

This was just before the 029 appeared. I was told before that
the top two rows were + and -, which was true for 026, not 029.

Actually, it is worse. There are two - characters. Strangely,
Fortran I required the 11 row minus for programs, either for
input data, and generated 8-4 for output data.

ALGOL is older than the 029, so people had to have some
way to punch its characters on cards.

-- glen

0
gah (12851)
7/21/2012 5:34:57 AM
On Saturday, 21 July 2012 15:34:57 UTC+10, glen herrmannsfeldt  wrote:
> rrrrrrrrrrrrrrr@gmail.com wrote:
> 
> (snip, I wrote)
> >> The 026, like the 029, has multi-punch so you can punch all
> >> the characters that you want.

and all the ones that you didn't want.

> > Great, except that some (if not all) special characters
> > shown on the keyboard punched different holes in the cards
> > from an 029.
> 
> > No-one in their right mind would use an 026 to prepare 029
> > codes.  There was no way that the punching of special characters
> > prepared that way could be checked in some printed form
> > other than by passing them through the S/360 card reader.
> > Such mal-punched cards would have caused a read check,
> > requiring operator intervention and delaying the computer.
> 
> I don't know if the B5500 has read check.

??? The B5500 has nothing to do with the S/360.

> >> I remember punching ALGOL on
> >> 026 punches. There was a big chart on the wall telling how
> >> to punch all the characters needed that weren't on the keyboard.
> 
> > Some characters on the keyboard put different holes in the cards
> > from an 029.
> 
> Yes. 

Those were many/most of the non-digits and non-alphabetic characters.
 
> This was just before the 029 appeared. I was told before that
> the top two rows were + and -, which was true for 026, not 029.

The single-hole + and single-hole minus on the top 2 rows were
used by PL/I for over-punched signs (i.e., sign and digit in the
same column).

> Actually, it is worse. There are two - characters. Strangely,
> Fortran I required the 11 row minus for programs, either for
> input data, and generated 8-4 for output data.

Older tabulating equipment used 12-row punch for +,
11-row punch for minus, and 0-1 punch for a slash or period.

> ALGOL is older than the 029, so people had to have some
> way to punch its characters on cards.

They used manual card punches, or electric card punches.
The 026 would have been alright for Algol,
although in the UK and USA, Friden keyboard printers
designed for Algol produced 8-channel paper tape, which was
ideal.

As for cards, the alphabetic codes were sufficient for
generating equivalent combinations for things like > and <,
just as FORTRAN did.
0
robin.vowels (428)
7/21/2012 7:17:49 AM
On Saturday, 21 July 2012 02:07:08 UTC+10, John W Kennedy  wrote:
> On 2012-07-20 09:17:03 +0000, rrrrrrrrrrrr@gmail.com said:
> 
> &gt; On Friday, 20 July 2012 14:50:58 UTC+10, glen herrmannsfeldt  wrote:
> &gt;&gt; rrrrrrrrr@gmail.com wrote:
> &gt;&gt; 
> &gt;&gt; (snip)
> &gt;&gt; &amp;gt; The 1403 was a tad slow.
> &gt;&gt; &amp;gt; For that kind of work, a drum printer would have been better,
> &gt;&gt; &amp;gt; typically giving 1150-1250 LPM.
> &gt;&gt; 
> &gt;&gt; The drum printers I knew were a lot slower than that, but they
> &gt;&gt; were upper and lower case.
> &gt;&gt; 
> &gt;&gt; A 1403 with a numeric (and a few other characters) train is
> &gt;&gt; very fast.
> &gt; 
> &gt; Without alphabetic characters, such a train was for specialized
> &gt; purposes and was not generally useful.
> &gt; 
> &gt;&gt; With QN or PN, reasonably fast,
> &gt; 
> &gt; but not when many characters per line were printed.
> 
> Wrong.

Not wrong.
Now, I wonder how I got that information?; standing in front of
the line printer while it was printing, I suppose.

The time to print a line depended on the number of characters
to be printed on that line.

> &gt; Furthermore, the trains wore out very quickly.
> 
> Not even once, in my experience, though I&#39;m sure it happened from time to time.
> 
> &gt;&gt; and with TN not so fast.
> &gt; 
> &gt; Woefully slow, less than 200 lpm.
> 
> No, 270 lpm at the worst, and that only on the already obsolescent 
> 1403-2. The 1403-N1, which was the de-facto standard 360 printer, 
> printed the TN train at 552 lpm at the worst.
> 
> &gt; Admittedly, the different trains could be changed quickly
> &gt; to give different character sets.  However, one decent drum
> &gt; would give the complete character set plus high speed printing.
> 
> I never heard of a drum printer that could do that /and/ produce 
> decently registered printing, though I'm not enough of an engineer to 
> categorically pronounce it impossible.

You obviously haven't been listening hard enough.

The other advantage of a drum printer is that lines can be
reasonably long.
Ours was 160 characters wide.
The width of a line doesn't affect the speed of printing,
since any given character appears simultaneously in all column positions as the drum rotates.

Finally, the characters printed by a drum printer are precise
and crystal-clear, unlike the print from the 360's train printer,
which tended to be blurred and indistinct.
0
robin.vowels (428)
7/21/2012 7:42:15 AM
 [ note followup to more appropriate group ]

>> &gt; but not when many characters per line were printed.
>> 
>> Wrong.
>
>Not wrong.

I agree.  I wasted too much of my high school spare time waiting for
printouts to come out of Princeton's 1403-N1 printers, and the speed
very obviously varied depending on what was printing.

>Finally, the characters printed by a drum printer are precise
>and crystal-clear, unlike the print from the 360's train printer,
>which tended to be blurred and indistinct.

Not the DEC drum printers I used.  Maybe they were poorly maintained,
but the print quality was awful, both blurry and terrible vertical
registration.  Based on in-house DEC printouts I've seen, everyone had
the vertical registration problem.  

The printouts from 1403s were good enough that they were used to
typeset books, most notably David Gries' classic "Compiler Construction
for Digital Computers".

R's,
John


-- 
Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
0
johnl (129)
7/21/2012 4:05:39 PM
On 7/20/2012 11:02 PM, robin.vowels@gmail.com wrote:
>
> Some drums did have only one copy.  But other drums had multiple copies.  Thus, with the Analine(?) printer:

Analex maybe?

-- 
Pete
0
Peter_Flass (956)
7/21/2012 5:00:27 PM
On 7/21/2012 3:42 AM, robin.vowels@gmail.com wrote:
>
> Finally, the characters printed by a drum printer are precise
> and crystal-clear, unlike the print from the 360's train printer,
> which tended to be blurred and indistinct.
>

Wow, this is exactly the opposite of my experience - I never saw a drum 
printout I'd call even marginally acceptable.  On the other hand, 
printers were touchy beasts, so a lot would depend on the quality of 
maintenance. IBM maintenance was second to none and everyone else was in 
third place.


-- 
Pete
0
Peter_Flass (956)
7/21/2012 5:04:49 PM
robin.vowels@gmail.com wrote:

(snip regarding drum and train printers)

> The time to print a line depended on the number of characters
> to be printed on that line.

(snip)

> You obviously haven't been listening hard enough.

> The other advantage of a drum printer is that lines can be
> reasonably long.   Ours was 160 characters wide.

> The width of a line doesn't affect the speed of printing,
> since any given character appears simultaneously in all column 
> positions as the drum rotates.

That doesn't have much to do with it. It can mostly be 
figured statistically. 

Now, in the rare case that a line contains all the same character,
then it prints the whole line simultaneously. 

A convenience of the 1403 is that the slug spacing and print
spacing aren't equal, such that a large number don't line up
at the same time. That reduces the peak current rating of
the power supply, allows multiplexing the solenoid drivers,
reduces the peak noise, and likely more. That could also be
done on drum printers, but wasn't on the ones I knew.

> Finally, the characters printed by a drum printer are precise
> and crystal-clear, unlike the print from the 360's train printer,
> which tended to be blurred and indistinct.

About the same. Well, 1403's may have had more use, and so worn
more. The solenoid, hammer, paper, ink ribbon, metal type process
is pretty much the same. So are the timing variations that result.

The big advantage of train printers is that the eye is much
less sensitive to horizontal misregistration than vertical.

-- glen
0
gah (12851)
7/21/2012 6:37:22 PM
Peter Flass <Peter_Flass@yahoo.com> wrote:
> On 7/21/2012 3:42 AM, robin.vowels@gmail.com wrote:

>> Finally, the characters printed by a drum printer are precise
>> and crystal-clear, unlike the print from the 360's train printer,
>> which tended to be blurred and indistinct.

> Wow, this is exactly the opposite of my experience - I never saw a drum 
> printout I'd call even marginally acceptable.  On the other hand, 
> printers were touchy beasts, so a lot would depend on the quality of 
> maintenance. IBM maintenance was second to none and everyone else was in 
> third place.

Ribbons wear, which affects print quality. Also, keeping the slugs
clean. 

As I already wrote a few times, though, most important is the
eye sensitivity to vertical misalignment. Looking across a line
of print, it is so easy to see vertical alignment errors, but
not so easy horizontal errors. 

The drum printers I used didn't get a huge amount of use, the 1403's
I knew ran pretty much continuously during the day, and still
looked better.

I don't know how much maintenance was done by IBM and how much
by local operators. (Things like ribbon changes and blowing dust
out of the mechanism.)

-- glen
0
gah (12851)
7/21/2012 6:44:17 PM
On Sunday, 22 July 2012 04:37:22 UTC+10, glen herrmannsfeldt  wrote:
> robin wrote:
> 
> (snip regarding drum and train printers)
> 
> &gt; The time to print a line depended on the number of characters
> &gt; to be printed on that line.
> 
> (snip)
> 
> &gt; You obviously haven&#39;t been listening hard enough.
> 
> &gt; The other advantage of a drum printer is that lines can be
> > reasonably long.   Ours was 160 characters wide.
> 
> > The width of a line doesn't affect the speed of printing,
> > since any given character appears simultaneously in all column 
> > positions as the drum rotates.
> 
> That doesn't have much to do with it. It can mostly be 
> figured statistically. 

Statistics has nothing to do with anything.
It's a plain fact that the width of a line has nothing to do with
print speed.

> Now, in the rare case that a line contains all the same character,
> then it prints the whole line simultaneously.

In the case of a drum printer, true.
Not so in the case of a train printer.

As for "rare case", not rare; in source programs, repeating asterisks
or hyphens or underscore characters were used for highlighting.
Underlining was also common for reports, etc.

> A convenience of the 1403 is that the slug spacing and print
> spacing aren't equal, such that a large number don't line up
> at the same time. That reduces the peak current rating of
> the power supply,

A consequence of the design, not a design feature.

If the spacings were the same, then a solenoid hitting the
paper would impress not only the character that it was
designed to hit, but also the character(s) in the adjacent
column(s).

> allows multiplexing the solenoid drivers,

Ditto.

> reduces the peak noise, and likely more.

Noise abation is achieved with the "coffin".

> That could also be
> done on drum printers, but wasn't on the ones I knew.

That would have slowed down printing, and in any case,
quite unnecessary.

> > Finally, the characters printed by a drum printer are precise
> > and crystal-clear, unlike the print from the 360's train printer,
> > which tended to be blurred and indistinct.
> 
> About the same.

Not in my experience.

> Well, 1403's may have had more use, and so worn more.

Not so.  A drum printer for, say, 132, print columns has
132 of each and every character.
The 1403 train printer has some 5 versions of each character.
It stands to reason that the characters on the train will
wear out some 25 times faster than those on the drum,
because they have much more work to do.

As well as that, the link joins wear and contribute slack,
affecting timing, and accounting for mis-alignment of the
characters on paper.

> The solenoid, hammer, paper, ink ribbon, metal type process
> is pretty much the same. So are the timing variations that result.
> 
> The big advantage of train printers is that the eye is much
> less sensitive to horizontal misregistration than vertical.

The big advantage of train printers is that they slow down
dramatically with long lines and when all or nearly all of the
character set are printed on one line.
0
robin.vowels (428)
7/22/2012 1:26:29 AM
robin.vowels@gmail.com wrote:

(snip)
> Statistics has nothing to do with anything.
> It's a plain fact that the width of a line has nothing to do with
> print speed.

(snip)

> The big advantage of train printers is that they slow down
> dramatically with long lines and when all or nearly all of the
> character set are printed on one line.

Hmmm.

-- glen
0
gah (12851)
7/22/2012 3:34:17 AM
On Sunday, 22 July 2012 13:34:17 UTC+10, glen herrmannsfeldt  wrote:
> rrrrrrrrrrrrrr@gmail.com wrote:
> 
> > Statistics has nothing to do with anything.
> > It's a plain fact that the width of a line has nothing to do with
> > print speed.
> 
> (snip)
> 
> > The big advantage of train printers is that they slow down
> > dramatically with long lines and when all or nearly all of the
> > character set are printed on one line.
> 
> Hmmm.

Yes, a touch of sarcasm in that joke.
0
robin.vowels (428)
7/22/2012 8:28:39 AM
On Sunday, 22 July 2012 03:00:27 UTC+10, Peter Flass  wrote:
> On 7/20/2012 11:02 PM, rrrrrrrr@gmail.com wrote:
>
> > Some drums did have only one copy.  But other drums had multiple copies.  Thus, with the Analine(?) printer:
> 
> Analex maybe?

You could be right.
A web page described a printer thus:

"Therefore we have set up an ANALEX printer (series 5) from 1965. At that time, this printer was the fastest printer on earth, printing 1250 lines per minute."

The print speed agrees closely with the speeds of the models that I quoted.

The models given in the hardware manual are 4000 series, though.

0
robin.vowels (428)
7/22/2012 8:53:27 AM
On Sunday, 22 July 2012 02:05:39 UTC+10, John Levine  wrote:
> [ note followup to more appropriate group ]
> 
> >> &amp;gt; but not when many characters per line were printed.
>
> >> Wrong.
>
> >Not wrong.
> 
> I agree.  I wasted too much of my high school spare time waiting for
> printouts to come out of Princeton's 1403-N1 printers, and the speed
> very obviously varied depending on what was printing.
> 
> >Finally, the characters printed by a drum printer are precise
> >and crystal-clear, unlike the print from the 360's train printer,
> >which tended to be blurred and indistinct.
> 
> Not the DEC drum printers I used.  Maybe they were poorly maintained,
> but the print quality was awful, both blurry and terrible vertical
> registration.  Based on in-house DEC printouts I've seen, everyone had
> the vertical registration problem.  
> 
> The printouts from 1403s were good enough that they were used to
> typeset books, most notably David Gries' classic Compiler Construction
> for Digital Computers".

Quite. I have a copy of that book.
IBM's programming manuals for the S/360 were printed on /360
printers fitted with a special print train (I hold copies
of some of these manuals).  It looks like "Internal Sorting Techniques" by R. P. Rich (which I also have), was printed by
the same kind of printer.

While the print quality of these documents is reasonable,
even good, the mis-printing of characters is evident.
By being reduced to about 50% of normal size for publication,
the defects in formation of characters is reduced.
Nevertheless the quality is significantly less that what the
Analine/Analex printer produced (print-outs in my possession).

Opening  page at randon (p. 110-111) I see:
p. 110:
the letter 'e' is broken in many places -- the right-hand side is missing;
the letter 'b' similarly broken;
the letter 'T' is broken;
the letter 'L' in the word 'LAST' is broken, and looks almost
identical to an 'I'.

p. 111:
In various places, the right-hand side of the letters 'e' and 'o'
is missing.
The letter 'B' in one place looks like an 'E'.
The right-hand side of 'T' is missing in two places.
Various other letters are affected.

These defects and similar ones appear thoughout the book.

I notice that on page 355, on line 3, that an E looks like an F and that it's impossible to tell whether a particular letter is
an 'O' or a 'C'.
0
robin.vowels (428)
7/22/2012 9:37:24 AM
On Sunday, 22 July 2012 02:05:39 UTC+10, John Levine  wrote:
> [ note followup to more appropriate group ]

John, which group was that?
It isn't showing up here.

0
robin.vowels (428)
7/22/2012 9:45:07 AM
In <500986fa$0$6050$607ed4bc@cv.net>, on 07/20/2012
   at 12:27 PM, John W Kennedy <jwkenne@attglobal.net> said:

>If you don't see the obviously organized shift in IBM design
>standards  ca. 1969 from:

>    command  positional1,positional2,keyword1=value1,keyword2=value2

>    command  positional1 positional2 keyword1 (value1) keyword2
>(value2)

Get your red herrings while they're fresh!

 1. No matter how you try to wiggle out of it, you used the word
"most"

 2. Using keyword(value) synatax is not enough to make a language
    "strongly influenced by PL/I"
    

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
spamtrap16 (3722)
7/22/2012 10:44:40 AM
In <50098e89$0$11552$607ed4bc@cv.net>, on 07/20/2012
   at 12:59 PM, John W Kennedy <jwkenne@attglobal.net> said:

>It was only when VM/370 came out that it was promoted to equal status
> with the OS and DOS lines. It was developed in the field,

The same is true of ASP and HASP. Are you also claiming that they were
not IBM software? For that matter, it's dishonest to describe software
developed by the IBM Cambridge Scientific Center as "developed in the
field".

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
spamtrap16 (3722)
7/22/2012 10:52:43 AM
In <jucc5p$ro5$1@speranza.aioe.org>, on 07/20/2012
   at 07:39 PM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:

>I believe five for the upper case trains, and two for TN.

I believe that it's 5[1] for AN and HN, 4 for PN and QN, 2 for TN.
There were a few other trains and chains, but I don't recall the
numbers.

[1] Well, 5 plus some adjustments.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
spamtrap16 (3722)
7/22/2012 11:41:42 AM
In <judf21$10p$1@speranza.aioe.org>, on 07/21/2012
   at 05:34 AM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:

>This was just before the 029 appeared. I was told before that the 
>top two rows were + and -, which was true for 026, not 029.

You're mixing apples and oranges. The 12-zone and 11-zone were plus
and minus signs for both 026 and 029. However, the 026 came in a
commercial version and a scientific version, with different
correspondences between hole combinations and characters. I believe
that a 12-punch with no other punch was a "+" or "&" on the 026,
depending on model, but that has nothing to do with the use of the
12-zone as a plus sign for numeric data.

>Strangely, Fortran I required the 11 row minus for programs, 
>either for input data, and generated 8-4 for output data.

That sounds strange. An isolated 11-puch in EBCDIC is 60 ("-"), but
8-4 would be 7C ("@"). I though maybe you meant underscore, but that's
0-8-5.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
spamtrap16 (3722)
7/22/2012 11:47:19 AM
In <juek0j$1is6$1@leila.iecc.com>, on 07/21/2012
   at 04:05 PM, John Levine <johnl@iecc.com> said:

>>> &gt; but not when many characters per line were printed.
>>> 
>>> Wrong.
>>
>>Not wrong.

>I agree.  I wasted too much of my high school spare time waiting for
>printouts to come out of Princeton's 1403-N1 printers, and the speed
>very obviously varied depending on what was printing.

The Devil is in the details. The print speed on the 1403-N1 depended
on the particular characters printed, not on the number of characters
per line.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
spamtrap16 (3722)
7/22/2012 12:47:20 PM
"Shmuel (Seymour J.) Metz" <spamtrap@library.lspace.org.invalid> wrote:
> John Levine <johnl@iecc.com> said:
>
>>>> &gt; but not when many characters per line were printed.

>>>> Wrong.

>>>Not wrong.

>>I agree.  I wasted too much of my high school spare time waiting for
>>printouts to come out of Princeton's 1403-N1 printers, and the speed
>>very obviously varied depending on what was printing.

> The Devil is in the details. The print speed on the 1403-N1 depended
> on the particular characters printed, not on the number of characters
> per line.

Slight edit: the time required to print a given line was a function of the 
character set on the print train and the set of characters present on that 
line.

The extreme case for the 1403 was the model 3 (with the "Preferred Character 
Set" option) or the N1 (with UCS), which could reach 1400 lines per minute 
when printing lines containing only 0123456789.,-* which appeared eight 
times in the PCAS-AN and PCS-HN trains. The nominal 1100 LPM speed of the N1 
assumes that the train contains five identical glyph sets (for most users, 
meaning the AN or HN train), and that (if UCS is installed) no line contains 
any characters not present in the train.  A character that's not mapped to 
at least one glyph on the train will hold the printer at the current line 
until the train has twice passed its home position.

Shops using PL/I would typically use either the PN or QN train.  Both trains 
contained the same 60 glyphs, but while the PN train had four identical 
glyph sets and ran at the same speed (955 LPM) regardless of the contents of 
the print file (assuming no unknown characters were used - see the above 
paragraph) the QN train had five copies each of 45 characters, plus one copy 
each of 15 additional glyphs.  This meant that a PL/I listing would 
significantly slow the printer (310 LPM), but if the output didn't use any 
of the 15 singleton glyphs you would get the full rated printer speed.

H'mmm...lessee...according to the 1403 SRL the 15 singletons were

_"'$<>:;#?@^&|%

with the caret ^ above meaning the PL/I "not" symbol.

The TN (text) train had 120 characters in its glyph set, with two sets on 
the train.  It (obviously, I hope) slows the printer down, so it was 
typically mounted only when requested by the user.

And, to add to the fun, customers could order "standard" RPQ type slugs for 
a reasonably low cost (or pay a lot for a custom slug) and a create glyph 
set that matched their particular requirements.

Joe 


0
j.c.morris (65)
7/22/2012 2:54:10 PM
>Slight edit: the time required to print a given line was a function of the 
>character set on the print train and the set of characters present on that 
>line.

The 1403-N1 had a Universal Character Set option to support different
print trains.  The printer had a UCS buffer, into which software would
load the characters in each position on the print train.

Princeton had some 360/20's around campus, each with a 1403, MFCM
(card reader-punch-sorter thing) and a bisync modem used as RJE
terminals.  One day while waiting for the /91 to come back up, I hand
punched a little program that loaded the UCS buffer with all the same
character, then printed lines of that character, and booted it.

That turned out to be a bad idea.  The printer printed half a page of
gibberish at very high speed, then the cover raised halfway, then a
fuse blew.  I didn't stick around to see what happened next.

R's,
John
-- 
Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
0
johnl (129)
7/22/2012 5:32:57 PM
Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> wrote:

(snip, I wrote)
>>I believe five for the upper case trains, and two for TN.

> I believe that it's 5[1] for AN and HN, 4 for PN and QN, 2 for TN.
> There were a few other trains and chains, but I don't recall the
> numbers.

Could be. (Some of those save paper by printing 8 lines per inch
on 8.5 by 14 inch paper.) 

TN has 120 different characters, so 2 each would be 240.
(Maybe or maybe not enough to get all the way around.)

So, 240 print positions could be 4 each at 60, or five each at 48.

This was explained to me by an operator in Germany after I tried
to use a less-common character to print a table. Mostly speaking
English, but might have lost a little in translation, and I don't
know the specific print train.

Now, the spacing is slightly more than the spacing of print
positions, but 240 (both ways) is close for a 132 column printer.
(There has to be some room to turn around at each end, and it can't
be too sharp.)

> [1] Well, 5 plus some adjustments.

-- glen
0
gah (12851)
7/22/2012 10:28:17 PM
In comp.lang.pl1 Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> wrote:

(snip on drum and train printers)

> The Devil is in the details. The print speed on the 1403-N1 depended
> on the particular characters printed, not on the number of characters
> per line.

Yes. 

Still, on the average one can say something about how long a
line takes.

For a drum (one copy of each) printer, if you print one character
on a line, (or many of the same character) on the average you
wait one half drum rotation. If you print two different characters,
on the average 3/4 of a rotation, and 7/8 for three. (Assume no
correlation between characters printed and position on the drum.)

For a train printer with N copies of each, on the average the
train moves 1/(2N) of a rotation for one character, 3/(4N) for
two, and 7/(8N) for three.

So, not on the number of print positions per line, but the number 
actually printed. One might expect to print more characters,
on average, on a longer line, though.

-- glen

0
gah (12851)
7/22/2012 10:45:37 PM
In comp.lang.pl1 Joe Morris <j.c.morris@verizon.net> wrote:

(snip of AN and HN trains and print speed)

> Shops using PL/I would typically use either the PN or QN train.  Both trains 
> contained the same 60 glyphs, but while the PN train had four identical 
> glyph sets and ran at the same speed (955 LPM) regardless of the contents of 
> the print file (assuming no unknown characters were used - see the above 
> paragraph) the QN train had five copies each of 45 characters, plus one copy 
> each of 15 additional glyphs.  This meant that a PL/I listing would 
> significantly slow the printer (310 LPM), but if the output didn't use any 
> of the 15 singleton glyphs you would get the full rated printer speed.

OK, I had thought I remembered the difference between PN and QN
as 6 or 8 lines per inch. 

There were also trains allowing 8 lines per inch, usually on 8.5
inch long paper (either 11 or 14 inch wide) to save paper.
(That is, that looked right at 8lpi.)

> H'mmm...lessee...according to the 1403 SRL the 15 singletons were

> _"'$<>:;#?@^&|%

I believe I learned this while trying to use | and instead
switched to *.

> with the caret ^ above meaning the PL/I "not" symbol.

> The TN (text) train had 120 characters in its glyph set, with two sets on 
> the train.  It (obviously, I hope) slows the printer down, so it was 
> typically mounted only when requested by the user.

> And, to add to the fun, customers could order "standard" RPQ type slugs for 
> a reasonably low cost (or pay a lot for a custom slug) and a create glyph 
> set that matched their particular requirements.

> Joe 


0
gah (12851)
7/22/2012 10:54:06 PM
In comp.lang.pl1 John Levine <johnl@iecc.com> wrote:

(snip)
> Princeton had some 360/20's around campus, each with a 1403, MFCM
> (card reader-punch-sorter thing) and a bisync modem used as RJE
> terminals.  One day while waiting for the /91 to come back up, I hand
> punched a little program that loaded the UCS buffer with all the same
> character, then printed lines of that character, and booted it.

> That turned out to be a bad idea.  The printer printed half a page of
> gibberish at very high speed, then the cover raised halfway, then a
> fuse blew.  I didn't stick around to see what happened next.

The print position and slug character spacing aren't equal, so
you can't print all positions at the same time. (Also simplifies
the logic needed to do the compare.) Still, it seems like it
wasn't designed to be even close.

You could always find the spacing and order on the slugs and
print the appropriate line. 

As well as I remember, you can fill the printer with paper
with too many consecutive form feeds. (Or a position with
no hole on the positioning tape.)

For the drum printers I knew, it would be easy to print a
whole line at once. I hope they were designed for it.

-- glen
0
gah (12851)
7/22/2012 11:02:39 PM

glen herrmannsfeldt wrote:

> In comp.lang.pl1 Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> wrote:
>
> (snip on drum and train printers)
>
> > The Devil is in the details. The print speed on the 1403-N1 depended
> > on the particular characters printed, not on the number of characters
> > per line.
>
> Yes.
>
> Still, on the average one can say something about how long a
> line takes.
>
> For a drum (one copy of each) printer, if you print one character
> on a line, (or many of the same character) on the average you
> wait one half drum rotation. If you print two different characters,
> on the average 3/4 of a rotation, and 7/8 for three. (Assume no
> correlation between characters printed and position on the drum.)
>
> For a train printer with N copies of each, on the average the
> train moves 1/(2N) of a rotation for one character, 3/(4N) for
> two, and 7/(8N) for three.
>
> So, not on the number of print positions per line, but the number
> actually printed. One might expect to print more characters,
> on average, on a longer line, though.

There were a number of printer destruction projects around in
the 70's. The trick to causing a chain printer to fail was select a
character sequence on a line that caused maximum stress on
the same point on the print chain. The rest was time until it failed.

Westinghouse was having a pricing disagreement with a TTY
supplier. A TTY was designed for well timed 10cps communication
and was a mechanical monster with a lot of parts. Like the chain
printer it was vunerable to data timing. The data bits needed to be
reasonably well timed but havoc could be had by playing with stop
bits timing. The game was to keep the timing within spec and break
the TTY. Someone wrote a hand timed P250 program that drove
TTY. It was painful to watch. The effective data rate was 7 or 8
characters per second. Mechanically moving parts got stuck, any
loose screw came out and parts became disconnected.

Westinghouse purchasing showed the vendor their "new
incoming inspection test that they would have to pass unless
they reduced the price"  The vendor caved

w..


0
walter20 (887)
7/22/2012 11:09:45 PM
Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> wrote:
> In <judf21$10p$1@speranza.aioe.org>, on 07/21/2012

(I wrote)
>>This was just before the 029 appeared. I was told before that the 
>>top two rows were + and -, which was true for 026, not 029.

> You're mixing apples and oranges. The 12-zone and 11-zone were plus
> and minus signs for both 026 and 029. However, the 026 came in a
> commercial version and a scientific version, with different
> correspondences between hole combinations and characters. 

I only knew scientific ones.

That does explain, though, where the change came from.

> I believe that a 12-punch with no other punch was a "+" or 
> "&" on the 026, depending on model, but that has nothing to 
> do with the use of the 12-zone as a plus sign for numeric data.

From the Fortran I (704) manual, "+" is 12 punch.

They were first explained to me as + row and - row when
I was about 9 years old, in a room full of 026s. Made sense
at the time. Then, one day, one 029 appeared and I punched all
the characters to see the differences.

>>Strangely, Fortran I required the 11 row minus for programs, 
>>either for input data, and generated 8-4 for output data.

> That sounds strange. An isolated 11-puch in EBCDIC is 60 ("-"), 
> but 8-4 would be 7C ("@"). I though maybe you meant underscore, 
> but that's 0-8-5.

There is no @ in BCDIC, at least not the Fortran version of it.
The 8-4 is octal 14, the 11 is octal 40. This is from Appendix A
of the 704 Fortran manual. 
0
gah (12851)
7/22/2012 11:14:50 PM
On Sunday, 22 July 2012 21:47:19 UTC+10, Seymour J. Shmuel Metz  wrote:
> In &lt;judfxxxxxxx@speranza.aioe.org&gt;, on 07/21/2012
>    at 05:34 AM, glen herrmannsfeldt &lt;gxaih@ugcs.caltech.edu&gt; said:
> 
> >This was just before the 029 appeared. I was told before that the 
> >top two rows were + and -, which was true for 026, not 029.
> 
> You're mixing apples and oranges. The 12-zone and 11-zone were plus
> and minus signs for both 026 and 029.

No.  On the 029, plus was 12-6-8, while minus was 11.

For overpunched data, Plus was 12, minus was 11.
Thus, +1 thru +0 was the same as A thru I.
-1 thru -9 was the same as J thru R.

0
robin.vowels (428)
7/23/2012 12:30:23 AM
On Sunday, 22 July 2012 22:47:20 UTC+10, Seymour J. Shmuel Metz  wrote:
> In &lt;juuuuuuuuu@leila.iecc.com&gt;, on 07/21/2012
>    at 04:05 PM, John Levine &lt;jzzzzzzzz@iecc.com&gt; said:
> 
> &gt;&gt;&gt; &amp;gt; but not when many characters per line were printed.
> &gt;&gt;&gt; 
> &gt;&gt;&gt; Wrong.
> &gt;&gt;
> &gt;&gt;Not wrong.
> 
> &gt;I agree.  I wasted too much of my high school spare time waiting for
> >printouts to come out of Princeton's 1403-N1 printers, and the speed
> >very obviously varied depending on what was printing.
> 
> The Devil is in the details. The print speed on the 1403-N1 depended
> on the particular characters printed, not on the number of characters
> per line.

On the number of characters per line.

Print one character only, and as soon as that's done, 
the paper can move.

Print two characters, then unless they can be printed
simultaneously, the paper must wait until the second character
is printed.

Speed also depends on the whether certain characters are not
repeated on the chain as often as the others, and whether those
characters are used as often as other characters.
0
robin.vowels (428)
7/23/2012 12:48:20 AM
On 7/22/2012 10:54 AM, Joe Morris wrote:
> "Shmuel (Seymour J.) Metz" <spamtrap@library.lspace.org.invalid> wrote:
>> John Levine <johnl@iecc.com> said:
>>
>>>>> &gt; but not when many characters per line were printed.
>
>>>>> Wrong.
>
>>>> Not wrong.
>
>>> I agree.  I wasted too much of my high school spare time waiting for
>>> printouts to come out of Princeton's 1403-N1 printers, and the speed
>>> very obviously varied depending on what was printing.
>
>> The Devil is in the details. The print speed on the 1403-N1 depended
>> on the particular characters printed, not on the number of characters
>> per line.
>
> Slight edit: the time required to print a given line was a function of the
> character set on the print train and the set of characters present on that
> line.
>
> The extreme case for the 1403 was the model 3 (with the "Preferred Character
> Set" option) or the N1 (with UCS), which could reach 1400 lines per minute
> when printing lines containing only 0123456789.,-* which appeared eight
> times in the PCAS-AN and PCS-HN trains. The nominal 1100 LPM speed of the N1
> assumes that the train contains five identical glyph sets (for most users,
> meaning the AN or HN train), and that (if UCS is installed) no line contains
> any characters not present in the train.  A character that's not mapped to
> at least one glyph on the train will hold the printer at the current line
> until the train has twice passed its home position.
>
> Shops using PL/I would typically use either the PN or QN train.  Both trains
> contained the same 60 glyphs, but while the PN train had four identical
> glyph sets and ran at the same speed (955 LPM) regardless of the contents of
> the print file (assuming no unknown characters were used - see the above
> paragraph) the QN train had five copies each of 45 characters, plus one copy
> each of 15 additional glyphs.  This meant that a PL/I listing would
> significantly slow the printer (310 LPM), but if the output didn't use any
> of the 15 singleton glyphs you would get the full rated printer speed.
>
> H'mmm...lessee...according to the 1403 SRL the 15 singletons were
>
> _"'$<>:;#?@^&|%
>
> with the caret ^ above meaning the PL/I "not" symbol.
>
> The TN (text) train had 120 characters in its glyph set, with two sets on
> the train.  It (obviously, I hope) slows the printer down, so it was
> typically mounted only when requested by the user.
>
> And, to add to the fun, customers could order "standard" RPQ type slugs for
> a reasonably low cost (or pay a lot for a custom slug) and a create glyph
> set that matched their particular requirements.
>
> Joe
>
>

Of course nearly every line would contain at least a ';', so the 
improvement is not obvious to me.

-- 
Pete
0
Peter_Flass (956)
7/23/2012 12:52:44 AM
On 7/22/2012 6:45 PM, glen herrmannsfeldt wrote:
> In comp.lang.pl1 Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> wrote:
>
> (snip on drum and train printers)
>
>> The Devil is in the details. The print speed on the 1403-N1 depended
>> on the particular characters printed, not on the number of characters
>> per line.
>
> Yes.
>
> Still, on the average one can say something about how long a
> line takes.
>
> For a drum (one copy of each) printer, if you print one character
> on a line, (or many of the same character) on the average you
> wait one half drum rotation. If you print two different characters,
> on the average 3/4 of a rotation, and 7/8 for three. (Assume no
> correlation between characters printed and position on the drum.)

Okay, there's a problem right there.  The 1132 would interrupt as each 
character was coming into position.  The CPU built a buffer with '1' 
bits where that character was to be printed and '0' otherwise, so you'd 
have to wait on average 1/2 rotation at the beginning of a line and up 
to one full rotation to print the data.


-- 
Pete
0
Peter_Flass (956)
7/23/2012 12:56:27 AM
In comp.lang.pl1 Peter Flass <Peter_Flass@yahoo.com> wrote:
> On 7/22/2012 10:54 AM, Joe Morris wrote:

(snip)

>> Shops using PL/I would typically use either the PN or QN train.  Both trains
>> contained the same 60 glyphs, but while the PN train had four identical
>> glyph sets and ran at the same speed (955 LPM) regardless of the contents of
>> the print file (assuming no unknown characters were used - see the above
>> paragraph) the QN train had five copies each of 45 characters, plus one copy
>> each of 15 additional glyphs.  This meant that a PL/I listing would
>> significantly slow the printer (310 LPM), but if the output didn't use any
>> of the 15 singleton glyphs you would get the full rated printer speed.

(snip)

> Of course nearly every line would contain at least a ';', so the 
> improvement is not obvious to me.

Shops running mostly Fortran, but some PL/I, might see the benefit.
Weight based on the fraction using PL/I or other languages using
those characters, and see which is best.

-- glen
0
gah (12851)
7/23/2012 1:37:53 AM
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote:
> In comp.lang.pl1 Joe Morris <j.c.morris@verizon.net> wrote:

> (snip of AN and HN trains and print speed)

> OK, I had thought I remembered the difference between PN and QN
> as 6 or 8 lines per inch.
>
> There were also trains allowing 8 lines per inch, usually on 8.5
> inch long paper (either 11 or 14 inch wide) to save paper.
> (That is, that looked right at 8lpi.)

The vertical spacing was controlled by the clutch knob in the printer; I 
never heard of any standard trains that were designed for a specific 
vertical increment.  The glyph height was (IIRC) enough less than 1/8 inch 
so that you didn't wind up with glyphs on one line merging with ones the 
lines above and below, although readability suffered.

Some shops made 1/8" the standard spacing for their SYSPRINT queues, but 
most concluded that the reduction in the amount of paper consumed wasn't 
worth the reduced readability of dense printouts at 1/8".

That's not to say that some shop might have bought a customized train with a 
smaller-than-standard glyph height, but I would expect that to be 
prohibitively expensive.

Joe 


0
j.c.morris (65)
7/23/2012 2:06:52 AM
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote:

> For the drum printers I knew, it would be easy to print a
> whole line at once. I hope they were designed for it.

Most shops configured their printers to produce a flypage to mark the 
beginning of each job's output, and flypage design usually included rows of 
asterisks:

***********************************************
***********************************************
 JOB:  FUBAR    USER:  ALT.FOLKLORE.COMPUTERS
***********************************************
***********************************************

which, when output on a drum printer, as an unintended (and usually 
unwanted) byproduct gave an aural announcement of the beginning of each 
job's output.

Many IBM shops that had the ability to punch binary cards would punch a lace 
card (all 960 holes) as a separator; that too provided an audio announcement 
of a new job's output.

Joe 


0
j.c.morris (65)
7/23/2012 2:12:54 AM
In <jui0qf$2u7$1@speranza.aioe.org>, on 07/22/2012
   at 11:02 PM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:

>You could always find the spacing and order on the slugs and print
>the appropriate line. 

It was easy to lay out a print line that would generate synch
checks[1] on the original 1403, and I've been told that you could snap
the chain that way if you were unlucky, but I was under the impression
that IBM had re-engineered the newer models to prevent that.

[1] It fired a hammer every 11.5 microseconds in every third print
    positions for three scans.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
spamtrap16 (3722)
7/23/2012 2:27:41 AM
On Monday, 23 July 2012 10:56:27 UTC+10, Peter Flass  wrote:
> On 7/22/2012 6:45 PM, glen herrmannsfeldt wrote:
> &gt; In comp.lang.pl1 Shmuel (Seymour J.) Metz &lt;spamtrap@library.lspace.org.invalid&gt; wrote:
> &gt;
> &gt; (snip on drum and train printers)
> &gt;
> &gt;&gt; The Devil is in the details. The print speed on the 1403-N1 depended
> &gt;&gt; on the particular characters printed, not on the number of characters
> &gt;&gt; per line.
> &gt;
> &gt; Yes.
> &gt;
> &gt; Still, on the average one can say something about how long a
> &gt; line takes.
> &gt;
> &gt; For a drum (one copy of each) printer, if you print one character
> &gt; on a line, (or many of the same character) on the average you
> &gt; wait one half drum rotation. If you print two different characters,
> &gt; on the average 3/4 of a rotation, and 7/8 for three. (Assume no
> &gt; correlation between characters printed and position on the drum.)
> 
> Okay, there's a problem right there.  The 1132

What's an 1132?  Apparently a drum printer?  What computer?

> would interrupt as each 
> character was coming into position.  The CPU built a buffer with '1' 
> bits where that character was to be printed and '0' otherwise, so you'd 
> have to wait on average 1/2 rotation at the beginning of a line and up 
> to one full rotation to print the data.

It is not clear why you'd "have to wait on average 1/2 rotation"
at the beginning of a line.

With a drum printer, printing can commence as soon as the paper has stopped, and can begin with whatever character is about to
come to the printing position.

The printing time for a line is never more than one rotation of
the drum, and can be considerably less.
One exception occurs when a non-printable character is sent to
the printer.  In that case, it is necessary to wait until two timing marks on the drum have been seen, or, until all the
characters have been seen (depends on the printer design).
0
robin.vowels (428)
7/23/2012 2:32:54 AM
In <jui1ha$45u$1@speranza.aioe.org>, on 07/22/2012
   at 11:14 PM, glen herrmannsfeldt <gah@ugcs.caltech.edu> said:

>From the Fortran I (704) manual, "+" is 12 punch.

Whoops! That was well before EBCDIC, so the chart in S/360 PoOps was
irrelevant; the chart in the 7080 PoOps[1] should show the right
characters for that time frame. 

[1] A22-6560-4_7080_PrincOps_Nov64.pdf at bitsavers. 

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
spamtrap16 (3722)
7/23/2012 2:40:04 AM
On Saturday, 21 July 2012 01:31:44 UTC+10, John W Kennedy  wrote:
> On 2012-07-20 01:25:29 +0000, rrrrrrrrss@gmail.com said:
> 
> &gt; On Friday, 20 July 2012 02:24:01 UTC+10, John W Kennedy  wrote:
> &gt;&gt; On 2012-07-19 00:14:44 +0000, zzzzzzzz2@gmail.com said:
> &gt;&gt; 
> &gt;&gt; &amp;gt; On Thursday, 19 July 2012 09:54:46 UTC+10, John W Kennedy  wrote:
> &gt;&gt; &amp;gt;&amp;gt; On 2012-07-18 23:30:10 +0000, xxxxxxxxxxxx@gmail.com said:
> &gt;&gt; &amp;gt;&amp;gt;
> &gt;&gt; &amp;gt;&amp;gt;&amp;gt; On Thursday, 19 July 2012 01:22:21 UTC+10, John W Kennedy  wrote:
> &gt;&gt; &amp;gt;
> &gt;&gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; Locate-mode I/O doesn&amp;#39;t really exist 
> &gt;&gt; anymore, except in OS/360 (and
> &gt;&gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; DOS/360) legacy features -- unless you count 
> &gt;&gt; data-in-virtual.
> &gt;&gt; &amp;gt;&amp;gt; &amp;amp;gt;&amp;amp;gt;
> &gt;&gt; &amp;gt;&amp;gt; &amp;amp;gt;&amp;amp;gt;&amp;amp;gt; Locate mode still exists, even on Windows.
> &gt;&gt; &amp;gt;&amp;gt; &amp;amp;gt;&amp;amp;gt;
> &gt;&gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt; No, it doesn&amp;#39;t.
> &gt;&gt; &amp;gt;&amp;gt;
> &gt;&gt; &amp;gt;&amp;gt;&amp;gt; Have a look at SC14-7285-01 (for AIX, Enterprise, Windows),
> &gt;&gt;&gt;&gt;&gt; and SC26-8003.
> &gt;&gt; 
> &gt;&gt;&gt;&gt; Those are IBM manuals describing PL/I,
> &gt;&gt; 
> &gt;&gt;&gt; That&#39;s what counts.
> &gt;&gt; 
> &gt;&gt; PL/I is not Windows. Windows is not PL/I. Apparently this is radical
> &gt;&gt; concept to you, but I assure you, it&#39;s true.
> &gt; 
> &gt; Look in any PL/I manual.
> &gt; 
> &gt;&gt;&gt;&gt; not Microsoft manuals describing
> &gt;&gt;&gt;&gt; Windows. Windows does not have locate mode, and never did (and neither
> &gt;&gt;&gt;&gt; did OS/2).
> &gt;&gt; 
> &gt;&gt;&gt; Read the manual.
> &gt;&gt; 
> &gt;&gt; Since PL/I manuals do not describe Windows, there is no point to that.
> &gt; 
> &gt; Look in the index of cited PL/I manual for &quot;LOCATE statement&quot;.
> &gt; Then look at the referenced page for an enlightening
> &gt; description.
> 
> It says nothing about Windows APIs, because it is not a Windows manual. 
> Windows does not have locate mode, and never did.

But PL/I does.
0
robin.vowels (428)
7/23/2012 2:46:28 AM
On 2012-07-22 10:52:43 +0000, Shmuel (Seymour J.) Metz said:

> In <50098e89$0$11552$607ed4bc@cv.net>, on 07/20/2012
>    at 12:59 PM, John W Kennedy <jwkenne@attglobal.net> said:
> 
>> It was only when VM/370 came out that it was promoted to equal status
>> with the OS and DOS lines. It was developed in the field,
> 
> The same is true of ASP and HASP.

No, ASP was Type II.

>  Are you also claiming that they were
> not IBM software? For that matter, it's dishonest to describe software
> developed by the IBM Cambridge Scientific Center as "developed in the
> field".

It was "developed in the field" by IBM's own definition. It was not 
developed by IBM's operating-system developers, and was marketed as 
"field-developed software".

-- 
John W Kennedy
"The bright critics assembled in this volume will doubtless show, in 
their sophisticated and ingenious new ways, that, just as /Pooh/ is 
suffused with humanism, our humanism itself, at this late date, has 
become full of /Pooh./"
  -- Frederick Crews.  "Postmodern Pooh", Preface

0
jwkenne (1442)
7/23/2012 3:15:20 AM
On 2012-07-20 16:45:28 +0000, robin.vowels@gmail.com said:

> On Saturday, 21 July 2012 01:33:50 UTC+10, John W Kennedy  wrote:
>> On 2012-07-20 01:31:59 +0000, rrrrrrrr@gmail.com said:
>> 
>> &gt; On Friday, 20 July 2012 02:28:22 UTC+10, John W Kennedy  wrote:
>> &gt;&gt; On 2012-07-19 12:40:47 +0000, Shmuel (Seymour J.) Metz said:
>> &gt;&gt;
>> &gt;&gt; &amp;gt; In &amp;lt;ju7g7u$lk7$2@dont-email.me&amp;gt;, on 07/18/2012
>> &gt;&gt; &amp;gt;    at 07:18 PM, Peter Flass 
>> &amp;lt;aaaaaaa@Yahoo.com&amp;gt; said:
>> &gt;&gt; &amp;gt;
>> &gt;&gt; &amp;gt;&amp;gt; I don&amp;#39;t think I ever saw an OS system 
>> without HASP, but without it
>> &gt;&gt; &amp;gt;&amp;gt; didn&#39;t the system have to run a 
>> reader/interpreter job or an output
>> &gt;&gt; &amp;gt;&amp;gt; writer for every device?
>> &gt;&gt; &amp;gt;
>> &gt;&gt; &amp;gt; Unless you&amp;#39;re running ASP. Note that even 
>> with ASP or HASP you still
>> &gt;&gt; &amp;gt; need the Reader/Interpreter, although the operator 
>> doesn&amp;#39;t start the
>> &gt;&gt; &amp;gt; R/I tasks.
>> &gt;&gt; &amp;gt;
>> &gt;&gt; &amp;gt;&amp;gt; It would seem you&amp;#39;d quickly load up 
>> the system
>> &gt;&gt; &amp;gt;&amp;gt; with lots of often unused jobs.
>> &gt;&gt; &amp;gt;
>> &gt;&gt; &amp;gt; The typical shop had only one reader/punch and one or 
>> two printers.
>> &gt;&gt; &amp;gt; The shops with more unit-record equipment usually had 
>> more memory and
>> &gt;&gt; &amp;gt; faster processors.
>> &gt;&gt;
>> &gt;&gt; I remember, ca. 1970, visiting the AT&#39;T data center where 
>> they printed
>> &gt;&gt; dividend checks. A room full of 1403s (in the process of being 
>> replaced
>> &gt;&gt; by 3211s) that seemed to stretch to the horizon....
>> &gt;
>> &gt; The 1403 was a tad slow.
>> &gt; For that kind of work, a drum printer would have been better,
>> &gt; typically giving 1150-1250 LPM.
>> 
>> The 1403-3 and -N1 printed at 1100 LPM with a 48-character set,
> 
> Um, to run with PL/I, the 60-character set was required
> as a minimum.

No, that's why PL/I had the 48-character set option.


> The speed with 60 was significantly less than 1100 lpm, slowed
> down considerably with full-ish lines,
> and could not keep up with the card reader.
> 
>> and
>> lacked the vertical-alignment problems of drum printers.
> 
> but introduced its own problems of only half or less of the
> character being printed.

Oh for God's sake, the 1403 printer technology (continued in the later 
3203) was actively marketed by IBM for twenty years. It was the most 
successful piece of mainframe hardware ever made, and was the main 
printer at most mainframe shops for most of that period. Carrying on 
like this just makes you look ridiculous.

> And as I said, the print trains wore out rather rapidly.

In about fifteen years, I never saw that happen once.

> 
>> (And, of
>> course, could be switched to larger character sets when needed.)
> 
> Which why the 48-character set print train wasn't used much.

No, it was very common in the field, except for shops sufficiently 
dedicated to PL/I to regard PL/I source listings as a major part of 
their print load.

> For the record, the competition (IBM clones) was offering
> drum printers at 1080 LPM with 64 characters (and doesn't slow
> down much when full lines are printed on account of there being
> one or more characters in *each* print column).  I think that
> the maker of those printers was Analine.
> 
> Using a reduced character set of 16 characters including the
> digits, speed was 2,700 LPM.
> 
> Using the 48 character set, speed was 1350 LPM.
> 
> The latter two modes were for specialist usage.


-- 
John W Kennedy
"The grand art mastered the thudding hammer of Thor
And the heart of our lord Taliessin determined the war."
  -- Charles Williams.  "Mount Badon"

0
jwkenne (1442)
7/23/2012 3:22:48 AM
On Monday, 23 July 2012 00:54:10 UTC+10, Joe Morris  wrote:
> &quot;Shmuel (Seymour J.) Metz&quot; &lt;spamtrap@library.lspace.org.invalid&gt; wrote:
> &gt; John Levine &lt;jjjjjjjjj@iecc.com&gt; said:
> &gt;
> &gt;&gt;&gt;&gt; &amp;gt; but not when many characters per line were printed.
> 
> &gt;&gt;&gt;&gt; Wrong.
> 
> &gt;&gt;&gt;Not wrong.
> 
> &gt;&gt;I agree.  I wasted too much of my high school spare time waiting for
> &gt;&gt;printouts to come out of Princeton&#39;s 1403-N1 printers, and the speed
> &gt;&gt;very obviously varied depending on what was printing.
> 
> &gt; The Devil is in the details. The print speed on the 1403-N1 depended
> &gt; on the particular characters printed, not on the number of characters
> &gt; per line.
> 
> Slight edit: the time required to print a given line was a function of the 
> character set on the print train and the set of characters present on that 
> line.
> 
> The extreme case for the 1403 was the model 3 (with the &quot;Preferred Character 
> Set&quot; option) or the N1 (with UCS), which could reach 1400 lines per minute 
> when printing lines containing only 0123456789.,-* which appeared eight 
> times in the PCAS-AN and PCS-HN trains. The nominal 1100 LPM speed of the N1 
> assumes that the train contains five identical glyph sets (for most users, 
> meaning the AN or HN train), and that (if UCS is installed) no line contains 
> any characters not present in the train.  A character that&#39;s not mapped to 
> at least one glyph on the train will hold the printer at the current line 
> until the train has twice passed its home position.
> 
> Shops using PL/I would typically use either the PN or QN train.  Both trains 
> contained the same 60 glyphs, but while the PN train had four identical 
> glyph sets and ran at the same speed (955 LPM) regardless of the contents of 
> the print file (assuming no unknown characters were used - see the above 
> paragraph) the QN train had five copies each of 45 characters, plus one copy 
> each of 15 additional glyphs.  This meant that a PL/I listing would 
> significantly slow the printer (310 LPM),

' : ; < > were used by other languages also,
although PL/I and Algol used the semicolon regularly.

> but if the output didn't use any 
> of the 15 singleton glyphs you would get the full rated printer speed.

No, because the time to print a line also depended on the number of
characters printed.

> H'mmm...lessee...according to the 1403 SRL the 15 singletons were
> 
> _"'$<>:;#?@^&|%
> 
> with the caret ^ above meaning the PL/I "not" symbol.
> 
> The TN (text) train had 120 characters in its glyph set, with two sets on 
> the train.  It (obviously, I hope) slows the printer down, so it was 
> typically mounted only when requested by the user.
> 
> And, to add to the fun, customers could order "standard" RPQ type slugs for 
> a reasonably low cost (or pay a lot for a custom slug) and a create glyph 
> set that matched their particular requirements.
0
robin.vowels (428)
7/23/2012 3:23:55 AM
In comp.lang.pl1 Joe Morris <j.c.morris@verizon.net> wrote:

(snip, I wrote)
>> For the drum printers I knew, it would be easy to print a
>> whole line at once. I hope they were designed for it.

> Most shops configured their printers to produce a flypage to 
> mark the beginning of each job's output, and flypage design 
> usually included rows of asterisks:

> ***********************************************
> ***********************************************
> JOB:  FUBAR    USER:  ALT.FOLKLORE.COMPUTERS
> ***********************************************
> ***********************************************

> which, when output on a drum printer, as an unintended (and 
> usually unwanted) byproduct gave an aural announcement of 
> the beginning of each job's output.

It wouldn't be hard to stagger them, maybe one per character
position. (That is, the path of the same character on the drum
would be a helix.) I don't remember that the DEC drum printers
I saw did that, though.

> Many IBM shops that had the ability to punch binary cards would 
> punch a lace card (all 960 holes) as a separator; that too 
> provided an audio announcement of a new job's output.

I was always told that the punches weren't designed to
do that. That they were pretty weak, and could rip
when going through the rest of the card path. Even worse,
don't duplicate one in a keypunch.

Now, it isn't hard to get a card with mostly X'00' which
has five or six holes. (Consider the object program of
an initialized (to zero) array.)

-- glen

0
gah (12851)
7/23/2012 3:24:52 AM
In comp.lang.pl1 Joe Morris <j.c.morris@verizon.net> wrote:

(snip, I wrote)
>> There were also trains allowing 8 lines per inch, usually on 8.5
>> inch long paper (either 11 or 14 inch wide) to save paper.
>> (That is, that looked right at 8lpi.)

> The vertical spacing was controlled by the clutch knob in the printer; I 
> never heard of any standard trains that were designed for a specific 
> vertical increment.  The glyph height was (IIRC) enough less than 1/8 inch 
> so that you didn't wind up with glyphs on one line merging with ones the 
> lines above and below, although readability suffered.

I thought I remembered the look, especially of characters like O that
were more square than the usual O. The usual ones wouldn't overlap,
but they would be close enough to be harder to read.

I thought I remembered it as PN, and the 6lpi as QN.

> Some shops made 1/8" the standard spacing for their SYSPRINT queues, but 
> most concluded that the reduction in the amount of paper consumed wasn't 
> worth the reduced readability of dense printouts at 1/8".

> That's not to say that some shop might have bought a customized 
> train with a smaller-than-standard glyph height, but I would 
> expect that to be prohibitively expensive.

Run them 24 hours a day, compute the paper cost savings, then
see if it is worthwhile.

-- glen
0
gah (12851)
7/23/2012 3:28:51 AM
On 2012-07-23 02:06:52 +0000, Joe Morris said:

> "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote:
>> In comp.lang.pl1 Joe Morris <j.c.morris@verizon.net> wrote:
> 
>> (snip of AN and HN trains and print speed)
> 
>> OK, I had thought I remembered the difference between PN and QN
>> as 6 or 8 lines per inch.
>> 
>> There were also trains allowing 8 lines per inch, usually on 8.5
>> inch long paper (either 11 or 14 inch wide) to save paper.
>> (That is, that looked right at 8lpi.)
> 
> The vertical spacing was controlled by the clutch knob in the printer; 
> I never heard of any standard trains that were designed for a specific 
> vertical increment.

Not in that sense, but there were /heights/ customized for the two line sizes.

>   The glyph height was (IIRC) enough less than 1/8 inch so that you 
> didn't wind up with glyphs on one line merging with ones the lines 
> above and below, although readability suffered.
> 
> Some shops made 1/8" the standard spacing for their SYSPRINT queues, 
> but most concluded that the reduction in the amount of paper consumed 
> wasn't worth the reduced readability of dense printouts at 1/8".
> 
> That's not to say that some shop might have bought a customized train 
> with a smaller-than-standard glyph height, but I would expect that to 
> be prohibitively expensive.
> 
> Joe


-- 
John W Kennedy
A proud member of the reality-based community.

0
jwkenne (1442)
7/23/2012 3:32:06 AM
On 2012-07-23 01:37:53 +0000, glen herrmannsfeldt said:

> In comp.lang.pl1 Peter Flass <Peter_Flass@yahoo.com> wrote:
>> On 7/22/2012 10:54 AM, Joe Morris wrote:
> 
> (snip)
> 
>>> Shops using PL/I would typically use either the PN or QN train.  Both trains
>>> contained the same 60 glyphs, but while the PN train had four identical
>>> glyph sets and ran at the same speed (955 LPM) regardless of the contents of
>>> the print file (assuming no unknown characters were used - see the above
>>> paragraph) the QN train had five copies each of 45 characters, plus one copy
>>> each of 15 additional glyphs.  This meant that a PL/I listing would
>>> significantly slow the printer (310 LPM), but if the output didn't use any
>>> of the 15 singleton glyphs you would get the full rated printer speed.
> 
> (snip)
> 
>> Of course nearly every line would contain at least a ';', so the
>> improvement is not obvious to me.
> 
> Shops running mostly Fortran, but some PL/I, might see the benefit.
> Weight based on the fraction using PL/I or other languages using
> those characters, and see which is best.

You could be using all PL/I and still profit from QN (favoring 
scientific) or QNC (favoring commercial), as long as 90% of your 
printing was 48-character reports.

-- 
John W Kennedy
"When a man contemplates forcing his own convictions down another man's 
throat, he is contemplating both an unchristian act and an act of 
treason to the United States."
  -- Joy Davidman, "Smoke on the Mountain"

0
jwkenne (1442)
7/23/2012 3:34:15 AM
On 2012-07-23 00:56:27 +0000, Peter Flass said:

> On 7/22/2012 6:45 PM, glen herrmannsfeldt wrote:
>> In comp.lang.pl1 Shmuel (Seymour J.) Metz 
>> <spamtrap@library.lspace.org.invalid> wrote:
>> 
>> (snip on drum and train printers)
>> 
>>> The Devil is in the details. The print speed on the 1403-N1 depended
>>> on the particular characters printed, not on the number of characters
>>> per line.
>> 
>> Yes.
>> 
>> Still, on the average one can say something about how long a
>> line takes.
>> 
>> For a drum (one copy of each) printer, if you print one character
>> on a line, (or many of the same character) on the average you
>> wait one half drum rotation. If you print two different characters,
>> on the average 3/4 of a rotation, and 7/8 for three. (Assume no
>> correlation between characters printed and position on the drum.)
> 
> Okay, there's a problem right there.  The 1132 would interrupt as each 
> character was coming into position.  The CPU built a buffer with '1' 
> bits where that character was to be printed and '0' otherwise, so you'd 
> have to wait on average 1/2 rotation at the beginning of a line and up 
> to one full rotation to print the data.

The 1132 was based on the 407, and I believe it was not a pure drum 
printer, but a wheel printer, which was more complex and expensive, but 
gave better print quality because the wheel could (slightly) track the 
moving paper during impact.

-- 
John W Kennedy
"Though a Rothschild you may be
In your own capacity,
    As a Company you've come to utter sorrow--
But the Liquidators say,
'Never mind--you needn't pay,'
    So you start another company to-morrow!"
  -- Sir William S. Gilbert.  "Utopia Limited"

0
jwkenne (1442)
7/23/2012 3:38:28 AM
On 2012-07-21 18:44:17 +0000, glen herrmannsfeldt said:

> Peter Flass <Peter_Flass@yahoo.com> wrote:
>> On 7/21/2012 3:42 AM, robin.vowels@gmail.com wrote:
> 
>>> Finally, the characters printed by a drum printer are precise
>>> and crystal-clear, unlike the print from the 360's train printer,
>>> which tended to be blurred and indistinct.
> 
>> Wow, this is exactly the opposite of my experience - I never saw a drum
>> printout I'd call even marginally acceptable.  On the other hand,
>> printers were touchy beasts, so a lot would depend on the quality of
>> maintenance. IBM maintenance was second to none and everyone else was in
>> third place.
> 
> Ribbons wear, which affects print quality. Also, keeping the slugs
> clean.
> 
> As I already wrote a few times, though, most important is the
> eye sensitivity to vertical misalignment. Looking across a line
> of print, it is so easy to see vertical alignment errors, but
> not so easy horizontal errors.
> 
> The drum printers I used didn't get a huge amount of use, the 1403's
> I knew ran pretty much continuously during the day, and still
> looked better.
> 
> I don't know how much maintenance was done by IBM and how much
> by local operators. (Things like ribbon changes and blowing dust
> out of the mechanism.)

And "printing" on pink, sticky, printer-cleaning "paper".

-- 
John W Kennedy
"The grand art mastered the thudding hammer of Thor
And the heart of our lord Taliessin determined the war."
  -- Charles Williams.  "Mount Badon"

0
jwkenne (1442)
7/23/2012 3:39:49 AM
On 2012-07-22 10:44:40 +0000, Shmuel (Seymour J.) Metz said:

> In <500986fa$0$6050$607ed4bc@cv.net>, on 07/20/2012
>    at 12:27 PM, John W Kennedy <jwkenne@attglobal.net> said:
> 
>> If you don't see the obviously organized shift in IBM design
>> standards  ca. 1969 from:
> 
>> command  positional1,positional2,keyword1=value1,keyword2=value2
> 
>> command  positional1 positional2 keyword1 (value1) keyword2
>> (value2)
> 
> Get your red herrings while they're fresh!

What "red herring"? It is exactly the point that I'm making.

>  1. No matter how you try to wiggle out of it, you used the word
> "most"

"Virtually all" would be closer.

>  2. Using keyword(value) synatax is not enough to make a language
>     "strongly influenced by PL/I"

It is if the syntactic scheme is about all the two languages have in 
common to begin with.

-- 
John W Kennedy
"But now is a new thing which is very old--
that the rich make themselves richer and not poorer,
which is the true Gospel, for the poor's sake."
  -- Charles Williams.  "Judgement at Chelmsford"

0
jwkenne (1442)
7/23/2012 3:43:30 AM
>What's an 1132?  Apparently a drum printer?  What computer?

It's the drum printer that came with the IBM 1130 mini.  It was a
modified 407 accounting machine, and printed at 80 lpm on a good day.

The interface was impressively horrible.  As the drum rotated, it
would interrupt the CPU and send it the code of the character about to
come up to the hammers, at which point the CPU had to construct a bit
map of which hammers to fire in time for the printer controller to DMA
it to the transistors that controlled the hammers.  Repeat as each
character comes past the hammers.  When all of the characters on a
line had been printed, the CPU started the paper moving, waited for
the appropriate hole in the carriage control tape to appear, then
stopped the paper.  It was a miracle it worked at all.

You could also attach a 1403, but that cost a lot more and few sites
did.

R's,
John
-- 
Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
0
johnl (129)
7/23/2012 3:43:36 AM
On 2012-07-23 02:46:28 +0000, robin.vowels@gmail.com said:

> On Saturday, 21 July 2012 01:31:44 UTC+10, John W Kennedy  wrote:
>> On 2012-07-20 01:25:29 +0000, rrrrrrrrss@gmail.com said:
>> 
>> &gt; On Friday, 20 July 2012 02:24:01 UTC+10, John W Kennedy  wrote:
>> &gt;&gt; On 2012-07-19 00:14:44 +0000, zzzzzzzz2@gmail.com said:
>> &gt;&gt;
>> &gt;&gt; &amp;gt; On Thursday, 19 July 2012 09:54:46 UTC+10, John W 
>> Kennedy  wrote:
>> &gt;&gt; &amp;gt;&amp;gt; On 2012-07-18 23:30:10 +0000, 
>> xxxxxxxxxxxx@gmail.com said:
>> &gt;&gt; &amp;gt;&amp;gt;
>> &gt;&gt; &amp;gt;&amp;gt;&amp;gt; On Thursday, 19 July 2012 01:22:21 
>> UTC+10, John W Kennedy  wrote:
>> &gt;&gt; &amp;gt;
>> &gt;&gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; Locate-mode 
>> I/O doesn&amp;#39;t really exist
>> &gt;&gt; anymore, except in OS/360 (and
>> &gt;&gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt;&amp;gt; DOS/360) 
>> legacy features -- unless you count
>> &gt;&gt; data-in-virtual.
>> &gt;&gt; &amp;gt;&amp;gt; &amp;amp;gt;&amp;amp;gt;
>> &gt;&gt; &amp;gt;&amp;gt; &amp;amp;gt;&amp;amp;gt;&amp;amp;gt; Locate 
>> mode still exists, even on Windows.
>> &gt;&gt; &amp;gt;&amp;gt; &amp;amp;gt;&amp;amp;gt;
>> &gt;&gt; &amp;gt;&amp;gt;&amp;gt;&amp;gt; No, it doesn&amp;#39;t.
>> &gt;&gt; &amp;gt;&amp;gt;
>> &gt;&gt; &amp;gt;&amp;gt;&amp;gt; Have a look at SC14-7285-01 (for AIX, 
>> Enterprise, Windows),
>> &gt;&gt;&gt;&gt;&gt; and SC26-8003.
>> &gt;&gt;
>> &gt;&gt;&gt;&gt; Those are IBM manuals describing PL/I,
>> &gt;&gt;
>> &gt;&gt;&gt; That&#39;s what counts.
>> &gt;&gt;
>> &gt;&gt; PL/I is not Windows. Windows is not PL/I. Apparently this is radical
>> &gt;&gt; concept to you, but I assure you, it&#39;s true.
>> &gt;
>> &gt; Look in any PL/I manual.
>> &gt;
>> &gt;&gt;&gt;&gt; not Microsoft manuals describing
>> &gt;&gt;&gt;&gt; Windows. Windows does not have locate mode, and never 
>> did (and neither
>> &gt;&gt;&gt;&gt; did OS/2).
>> &gt;&gt;
>> &gt;&gt;&gt; Read the manual.
>> &gt;&gt;
>> &gt;&gt; Since PL/I manuals do not describe Windows, there is no point to that.
>> &gt;
>> &gt; Look in the index of cited PL/I manual for &quot;LOCATE statement&quot;.
>> &gt; Then look at the referenced page for an enlightening
>> &gt; description.
>> 
>> It says nothing about Windows APIs, because it is not a Windows manual.
>> Windows does not have locate mode, and never did.
> 
> But PL/I does.

Which has nothing to do with my original statement that Windows 
doesn't. Windows doesn't have locate mode. And therefore PL/I under 
Windows doesn't really have it, either, since it has to create a dummy 
buffer that is read or written in what OS/360 would call "move mode". 
PL/I for Windows fakes "locate mode"; it doesn't really have it, 
because the underlying system doesn't allow it.

-- 
John W Kennedy
"Those in the seat of power oft forget their failings and seek only the 
obeisance of others!  Thus is bad government born!  Hold in your heart 
that you and the people are one, human beings all, and good government 
shall arise of its own accord!  Such is the path of virtue!"
  -- Kazuo Koike.  "Lone Wolf and Cub:  Thirteen Strings" (tr. Dana Lewis)

0
jwkenne (1442)
7/23/2012 3:52:39 AM
On Monday, 23 July 2012 13:22:48 UTC+10, John W Kennedy  wrote:
> On 2012-07-20 16:45:28 +0000, rrrrrrrrrrr@gmail.com said:
> 
> &gt; On Saturday, 21 July 2012 01:33:50 UTC+10, John W Kennedy  wrote:
> &gt;&gt; On 2012-07-20 01:31:59 +0000, rrrrrrrr@gmail.com said:
> &gt;&gt; 
> &gt;&gt; &amp;gt; On Friday, 20 July 2012 02:28:22 UTC+10, John W Kennedy  wrote:
> &gt;&gt; &amp;gt;&amp;gt; On 2012-07-19 12:40:47 +0000, Shmuel (Seymour J.) Metz said:
> &gt;&gt; &amp;gt;&amp;gt;
> &gt;&gt; &amp;gt;&amp;gt; &amp;amp;gt; In &amp;amp;lt;ju7g7u$lk7$2@dont-email.me&amp;amp;gt;, on 07/18/2012
> &gt;&gt; &amp;gt;&amp;gt; &amp;amp;gt;    at 07:18 PM, Peter Flass 
> &gt;&gt; &amp;amp;lt;aaaaaaa@Yahoo.com&amp;amp;gt; said:
> &gt;&gt; &amp;gt;&amp;gt; &amp;amp;gt;
> &gt;&gt; &amp;gt;&amp;gt; &amp;amp;gt;&amp;amp;gt; I don&amp;amp;#39;t think I ever saw an OS system 
> &gt;&gt; without HASP, but without it
> &gt;&gt; &amp;gt;&amp;gt; &amp;amp;gt;&amp;amp;gt; didn&amp;#39;t the system have to run a 
> &gt;&gt; reader/interpreter job or an output
> &gt;&gt; &amp;gt;&amp;gt; &amp;amp;gt;&amp;amp;gt; writer for every device?
> &gt;&gt; &amp;gt;&amp;gt; &amp;amp;gt;
> &gt;&gt; &amp;gt;&amp;gt; &amp;amp;gt; Unless you&amp;amp;#39;re running ASP. Note that even 
> &gt;&gt; with ASP or HASP you still
> &gt;&gt; &amp;gt;&amp;gt; &amp;amp;gt; need the Reader/Interpreter, although the operator 
> &gt;&gt; doesn&amp;amp;#39;t start the
> &gt;&gt; &amp;gt;&amp;gt; &amp;amp;gt; R/I tasks.
> &gt;&gt; &amp;gt;&amp;gt; &amp;amp;gt;
> &gt;&gt; &amp;gt;&amp;gt; &amp;amp;gt;&amp;amp;gt; It would seem you&amp;amp;#39;d quickly load up 
> &gt;&gt; the system
> &gt;&gt; &amp;gt;&amp;gt; &amp;amp;gt;&amp;amp;gt; with lots of often unused jobs.
> &gt;&gt; &amp;gt;&amp;gt; &amp;amp;gt;
> &gt;&gt; &amp;gt;&amp;gt; &amp;amp;gt; The typical shop had only one reader/punch and one or 
> &gt;&gt; two printers.
> &gt;&gt; &amp;gt;&amp;gt; &amp;amp;gt; The shops with more unit-record equipment usually had 
> &gt;&gt; more memory and
> &gt;&gt; &amp;gt;&amp;gt; &amp;amp;gt; faster processors.
> &gt;&gt; &amp;gt;&amp;gt;
> &gt;&gt; &amp;gt;&amp;gt; I remember, ca. 1970, visiting the AT&amp;#39;T data center where 
> &gt;&gt; they printed
> &gt;&gt; &amp;gt;&amp;gt; dividend checks. A room full of 1403s (in the process of being 
> &gt;&gt; replaced
> &gt;&gt; &amp;gt;&amp;gt; by 3211s) that seemed to stretch to the horizon....
> &gt;&gt; &amp;gt;
> &gt;&gt; &amp;gt; The 1403 was a tad slow.
> &gt;&gt; &amp;gt; For that kind of work, a drum printer would have been better,
> &gt;&gt; &amp;gt; typically giving 1150-1250 LPM.
> &gt;&gt; 
> &gt;&gt; The 1403-3 and -N1 printed at 1100 LPM with a 48-character set,
> &gt; 
> &gt; Um, to run with PL/I, the 60-character set was required
> &gt; as a minimum.
> 
> No, that's why PL/I had the 48-character set option.

Eh?  That's not the reason.  The 48-character set was available
because older card preparation equipment and some paper tape
preparation equipment lacked the special characters.

Using the 48-character set required a separate compiler pass to
translate 48-character set stuff to 60-character set, before the
actual compilation could take place.

That took extra time.

> &gt; The speed with 60 was significantly less than 1100 lpm, slowed
> &gt; down considerably with full-ish lines,
> &gt; and could not keep up with the card reader.
> &gt; 
> &gt;&gt; and
> &gt;&gt; lacked the vertical-alignment problems of drum printers.
> &gt; 
> &gt; but introduced its own problems of only half or less of the
> &gt; character being printed.

> Oh for God's sake, the 1403 printer technology (continued in the later 
> 3203) was actively marketed by IBM for twenty years.

It doesn't change the fact that there were better printers
on the market.

Elsewhere in this thread or n.g. I documented instances in a
published book of malformed characters produced by IBM printer
fitted with the special print train (upper and lower case and many special characters).

In all the cases, the right-hand side of the character was missing.
In a few cases, the malformed character was impossible or difficult
to determine.

> It was the most 
> successful piece of mainframe hardware ever made, and was the main 
> printer at most mainframe shops for most of that period.

Only indicative of aggressive marketing.

We had a SPC-16 made by GA.  It was an RJE, and had a
drum printer. Not a specially fast one, but more than adequate.
Note that it was *not* a chain printer.

> Carrying on like this just makes you look ridiculous.

You look ridiculous by carrying on as you do
with denigrating remarks.

> > And as I said, the print trains wore out rather rapidly.
> 
> In about fifteen years, I never saw that happen once.

Obviously infrequently-used printers at your site(s), or
you were absent when they did wear out, and/or the site had a
spare train and you didn't notice the change.

> &gt;&gt; (And, of
> &gt;&gt; course, could be switched to larger character sets when needed.)
> 
> > Which why the 48-character set print train wasn't used much.
> 
> No, it was very common in the field, except for shops sufficiently 
> dedicated to PL/I to regard PL/I source listings as a major part of 
> their print load.

COBOL wasn't used?  Algol wasn't used?

> > For the record, the competition (IBM clones) was offering
> > drum printers at 1080 LPM with 64 characters (and doesn't slow
> > down much when full lines are printed on account of there being
> > one or more characters in *each* print column).  I think that
> > the maker of those printers was Analine.
> 
> > Using a reduced character set of 16 characters including the
> &gt; digits, speed was 2,700 LPM.
> &gt; 
> &gt; Using the 48 character set, speed was 1350 LPM.
0
robin.vowels (428)
7/23/2012 3:55:42 AM
>Which has nothing to do with my original statement that Windows 
>doesn't. Windows doesn't have locate mode.

Windows has memory mapped files.  They could implement locate mode I/O
if they wanted, although I doubt the performance benefit would be
noticable on modern PCs.

R's,
John


-- 
Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
0
johnl (129)
7/23/2012 4:58:48 AM
On 7/22/2012 10:06 PM, Joe Morris wrote:
> "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote:
>> In comp.lang.pl1 Joe Morris <j.c.morris@verizon.net> wrote:
>
>> (snip of AN and HN trains and print speed)
>
>> OK, I had thought I remembered the difference between PN and QN
>> as 6 or 8 lines per inch.
>>
>> There were also trains allowing 8 lines per inch, usually on 8.5
>> inch long paper (either 11 or 14 inch wide) to save paper.
>> (That is, that looked right at 8lpi.)
>
> The vertical spacing was controlled by the clutch knob in the printer; I
> never heard of any standard trains that were designed for a specific
> vertical increment.  The glyph height was (IIRC) enough less than 1/8 inch
> so that you didn't wind up with glyphs on one line merging with ones the
> lines above and below, although readability suffered.

You had to change the carriage control tape though, later the FCB.

-- 
Pete
0
Peter_Flass (956)
7/23/2012 9:26:06 AM
"John Levine" <johnl@iecc.com> wrote in message 
news:juih97$2ejt$2@leila.iecc.com...
> >What's an 1132?  Apparently a drum printer?  What computer?
>
> It's the drum printer that came with the IBM 1130 mini.  It was a
> modified 407 accounting machine, and printed at 80 lpm on a good day.
>
> The interface was impressively horrible.  As the drum rotated, it
> would interrupt the CPU and send it the code of the character about to
> come up to the hammers, at which point the CPU had to construct a bit
> map of which hammers to fire in time for the printer controller to DMA
> it to the transistors that controlled the hammers.  Repeat as each
> character comes past the hammers.  When all of the characters on a
> line had been printed, the CPU started the paper moving, waited for
> the appropriate hole in the carriage control tape to appear, then
> stopped the paper.  It was a miracle it worked at all.
>

This sounds like an *excellent* design... if you had a microprocessor CPU to 
run the thing.  But certainly you are talking about a printer that pre-dated 
microprocessors by many years.

--

numerist at aquaporin4 dot com

0
numerist (84)
7/23/2012 11:49:16 AM
"Joe Morris" <j.c.morris@verizon.net> wrote in message 
news:juibv701kjc@news6.newsguy.com...
> "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote:
>
>> For the drum printers I knew, it would be easy to print a
>> whole line at once. I hope they were designed for it.
>
> Most shops configured their printers to produce a flypage to mark the 
> beginning of each job's output, and flypage design usually included rows 
> of asterisks:
>
> ***********************************************
> ***********************************************
> JOB:  FUBAR    USER:  ALT.FOLKLORE.COMPUTERS
> ***********************************************
> ***********************************************
>
> which, when output on a drum printer, as an unintended (and usually 
> unwanted) byproduct gave an aural announcement of the beginning of each 
> job's output.
>

So do we know how the characters were apportioned on the drum printer??? Was 
each line of the drum a single character... like all A's, or all *'s???  Or 
did each line have the alphabet but skewed so that the rows might look 
something like:

ABCDEFGHIJKLMNOPQRSTUVWXYZ
BCDEFGHIJKLMNOPQRSTUVWXYZA
CDEFGHIJKLMNOPQRSTUVWXYZAB

etc.     etc.    etc.

Or perhaps the letters were apportioned based on the frequency in English or 
German or such...

If the rows of asterisks made a big "bang!" when they were typed, I guess 
all the characters on each line of the drum were the same character.  But 
even if this was true, there could be more rows of E's than other 
characters.

--

numerist at aquaporin4 dot com

0
numerist (84)
7/23/2012 11:56:42 AM
Charles Richmond wrote:
> "John Levine" <johnl@iecc.com> wrote in message
> news:juih97$2ejt$2@leila.iecc.com...
>> >What's an 1132?  Apparently a drum printer?  What computer?
>>
>> It's the drum printer that came with the IBM 1130 mini.  It was a
>> modified 407 accounting machine, and printed at 80 lpm on a good day.
>>
>> The interface was impressively horrible.  As the drum rotated, it
>> would interrupt the CPU and send it the code of the character about to
>> come up to the hammers, at which point the CPU had to construct a bit
>> map of which hammers to fire in time for the printer controller to DMA
>> it to the transistors that controlled the hammers.  Repeat as each
>> character comes past the hammers.  When all of the characters on a
>> line had been printed, the CPU started the paper moving, waited for
>> the appropriate hole in the carriage control tape to appear, then
>> stopped the paper.  It was a miracle it worked at all.
>>
>
> This sounds like an *excellent* design... if you had a microprocessor CPU to
> run the thing.  But certainly you are talking about a printer that pre-dated
> microprocessors by many years.

Or a PDP-8.


/BAH
0
See.above (172)
7/23/2012 1:21:17 PM
In <500cc1c8$0$11505$607ed4bc@cv.net>, on 07/22/2012
   at 11:15 PM, John W Kennedy <jwkenne@attglobal.net> said:

>No, ASP was Type II.

Which is not equal status with OS/360.

>It was "developed in the field" by IBM's own definition. It was not 
>developed by IBM's operating-system developers, and was marketed as 
>"field-developed software".

The User's Guide refers to it as Type III Class A Program. Class A
means full support.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
spamtrap16 (3722)
7/23/2012 1:40:33 PM
In <500cc862$0$11550$607ed4bc@cv.net>, on 07/22/2012
   at 11:43 PM, John W Kennedy <jwkenne@attglobal.net> said:

>What "red herring"?

Pretending that the dispute is over the use of keyword(value)
notation.

>"Virtually all" would be closer.

That would be even more off base.

>It is if the syntactic scheme is about all the two languages have in
> common to begin with.

If your grandmother had wheels she'd be a wagon. The syntactic schemes
of CLIST and PL/I are radically different.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
spamtrap16 (3722)
7/23/2012 1:40:38 PM
In <jujdo3$prr$1@dont-email.me>, on 07/23/2012
   at 06:49 AM, "Charles Richmond" <numerist@aquaporin4.com> said:

>This sounds like an *excellent* design... if you had a microprocessor
>CPU to  run the thing.  But certainly you are talking about a printer
>that pre-dated  microprocessors by many years.

The design predated microprocessors by decades.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
spamtrap16 (3722)
7/23/2012 1:45:02 PM
In article <juje62$sbg$1@dont-email.me>,
Charles Richmond <numerist@aquaporin4.com> wrote:
>"Joe Morris" <j.c.morris@verizon.net> wrote in message 
>news:juibv701kjc@news6.newsguy.com...
>> "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote:
>>
>>> For the drum printers I knew, it would be easy to print a
>>> whole line at once. I hope they were designed for it.
>>
>> Most shops configured their printers to produce a flypage to mark the 
>> beginning of each job's output, and flypage design usually included rows 
>> of asterisks:
>>
>> ***********************************************
>> ***********************************************
>> JOB:  FUBAR    USER:  ALT.FOLKLORE.COMPUTERS
>> ***********************************************
>> ***********************************************
>>
>> which, when output on a drum printer, as an unintended (and usually 
>> unwanted) byproduct gave an aural announcement of the beginning of each 
>> job's output.
>>
>
>So do we know how the characters were apportioned on the drum printer??? Was 
>each line of the drum a single character... like all A's, or all *'s???  Or 
>did each line have the alphabet but skewed so that the rows might look 
>something like:
>
>ABCDEFGHIJKLMNOPQRSTUVWXYZ
>BCDEFGHIJKLMNOPQRSTUVWXYZA
>CDEFGHIJKLMNOPQRSTUVWXYZAB

Not necessarily IBM-specific, but from the service I have done on drum printers
(quite a number of smaller manufacturers) I remember staggered lines like the
ones above.

Some also had the numbers, most common punctuation and the 10-16 most common 
characters repeated, up to a count of 128 positions, like 

etaoinshrd0123456789.,-+:/*abcdefghijklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ!$#%,.;:-+*...
taoinshrd0123456789.,-+:/*abcdefghijklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ!$#%,.;:-+*...
aoinshrd0123456789.,-+:/*abcdefghijklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ!$#%,.;:-+*...
oinshrd0123456789.,-+:/*abcdefghijklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ!$#%,.;:-+*...
inshrd0123456789.,-+:/*abcdefghijklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ!$#%,.;:-+*...

>etc.     etc.    etc.

The lines of * (or other common character) made a characteristic singing sound as the
characters rippled along. 

>Or perhaps the letters were apportioned based on the frequency in English or 
>German or such...
>
>If the rows of asterisks made a big "bang!" when they were typed, I guess 
>all the characters on each line of the drum were the same character.  But 
>even if this was true, there could be more rows of E's than other 
>characters.

I never remember hearing such "kad-thud" sounds, rather that the random noise
suddely made a chirping steady tone.

-- mrr
0
first (184)
7/23/2012 2:27:05 PM
"Joe Morris" <j.c.morris@verizon.net> writes:
> The vertical spacing was controlled by the clutch knob in the printer; I 
> never heard of any standard trains that were designed for a specific 
> vertical increment.  The glyph height was (IIRC) enough less than 1/8 inch 
> so that you didn't wind up with glyphs on one line merging with ones the 
> lines above and below, although readability suffered.
>
> Some shops made 1/8" the standard spacing for their SYSPRINT queues, but 
> most concluded that the reduction in the amount of paper consumed wasn't 
> worth the reduced readability of dense printouts at 1/8".
>
> That's not to say that some shop might have bought a customized train with a 
> smaller-than-standard glyph height, but I would expect that to be 
> prohibitively expensive.

Los Gatos VLSI lab had special train for printing logic diagrams
sideways (& "dense" printing) on 1403n1 ... needed characters so that
boxes and lines appeared continuous. application could be used with
standard print train ... but lines wouldn't be solid/continuous.
Application was also sometimes used to print internal network diagram
.... i.e. nodes were boxes and lines were the links that connected nodes.
I may still have such a copy printed at hone approx. 300(?) or so nodes
.... I would have to find it to double check ... I may even have archived
post mentioning it) ... found archived post (references 4/15/77 print
.... but not number of nodes)
http://www.garlic.com/~lynn/2002j.html#4

early on mainframe principles of operation was moved to cms script file.
actually it was the architecture "redbook" (for the red 3-ring binder it
was distributed in). There were conditional controls in the file that
printed either the full architecture redbook ... lots of engineering
notes, feature justification, discussion of alternatives, etc ... or the
principles of operation subset (version selection with command line
parameter, whether redbook or POP). when printed on 1403n1 ... some of
this can be seen in principles of operation ... where the diagram boxes
didn't have solid/continuous lines.

science center developed an application that traced instruction and
storage fetch/store addresses. "plotting" was done on 1403 with address
vertical and time horizontal ... addresses were scaled to about 7ft
length of 1403 output and time scaled could be 20-30ft. The paper
assembled on some of the interior hallways of the science center.

One of the uses was looking at how to redo apl storage management.
science center had ported apl\360 to cp67/cms for cms\apl. standard apl
storage management allocated new storage location on every assignment.
when all storage (in workspace) was exhausted, it would do garbage
collection (compacting inuse storage) and start all over again.  apl\360
with 16kbyte workspace that was completely swapped as single entity
.... didn't make any difference. Moved to multiple megabyte virtual
storage, demand paged environment ... resulted in severe page thrashing.
plot along the hallways was strong sawtooth pattern ... relatively rapid
rise from low storage to high followed by sharp "tooth blade" edge (as
garbage collected) ... repeated numerous times as moved down the hall.

application also did semi-automated program reorganization as aid in
improving preformance in virtual memory, demand paged environment. It
was used by lots of internal development group (like IMS) for moving
from real-storage (os/360) to virtual memory environment (as well as
identifying execution "hot-spots"). It was eventually released to
customers as VS/Repack in spring of 1976.

misc recent posts mentioning architecture redbook, vs/repack, and/or
cms\apl:
http://www.garlic.com/~lynn/2012.html#14 HONE
http://www.garlic.com/~lynn/2012.html#50 Can any one tell about what is APL language
http://www.garlic.com/~lynn/2012.html#64 Has anyone successfully migrated off mainframes?
http://www.garlic.com/~lynn/2012b.html#6 Cloud apps placed well in the economic cycle
http://www.garlic.com/~lynn/2012d.html#38 Invention of Email
http://www.garlic.com/~lynn/2012d.html#73 Execution Velocity
http://www.garlic.com/~lynn/2012e.html#59 Word Length
http://www.garlic.com/~lynn/2012j.html#20 Operating System, what is it?

-- 
virtualization experience starting Jan1968, online at home since Mar1970
0
lynn13 (400)
7/23/2012 2:53:02 PM
>> The interface was impressively horrible. ...
>
>This sounds like an *excellent* design... if you had a microprocessor CPU to 
>run the thing.  But certainly you are talking about a printer that pre-dated 
>microprocessors by many years.

Well, yes, but the microprocessor was also the CPU of the computer.
It couldn't do anything else while printing, which meant that the
printer often ran slower than its modest nominal speed due to delays
to compute what to print on the next line.

The 1130 had a lot of other cost reduced stuff.  The keyboard was a
keypunch keyboard that provided 12-bit card column code, and the card
reader read 12 bit binary columns.  Software had to translate those to
EBCDIC.  The console printer was a Selectric mechanism, programmed by
sending it the tilt and rotate location of the character, so it had
to translate to those codes, too.

The disk arm was run by a stepper motor, so you could hear the buzzing
as it ground its way from the outside of the disk toward the center
and back.

It's amazing the 1130 could get any actual computing done at all.

R's,
John
-- 
Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
0
johnl (129)
7/23/2012 4:44:51 PM
On Jul 22, 10:54=A0am, "Joe Morris" <j.c.mor...@verizon.net> wrote:

> The extreme case for the 1403 was the model 3 (with the "Preferred Charac=
ter
> Set" option) or the N1 (with UCS), which could reach 1400 lines per minut=
e
> when printing lines containing only 0123456789.,-* which appeared eight
> times in the PCAS-AN and PCS-HN trains. The nominal 1100 LPM speed of the=
 N1
> assumes that the train contains five identical glyph sets (for most users=
,
> meaning the AN or HN train), and that (if UCS is installed) no line conta=
ins
> any characters not present in the train. =A0A character that's not mapped=
 to
> at least one glyph on the train will hold the printer at the current line
> until the train has twice passed its home position.

We had a 1403 printer with our S/360-40; and the printer had a 48
character chain.  For COBOL this was an annoyance since certain
characters like parenthesis and the <> signs didn't get printed or got
a substitute.

Through some gross misinformation from IBM, the manager was told
upgrading to a 64 character chain would seriously degrade printing
speed, and also require expensive hardware add-ons and installations.
With that, the shop manager who was an old autocoder hand, who saw no
reason to upgrade.

But then the accounting department wanted to have parenthesis around
negative numbers in reports instead of a mere - sign, so as to make
negative values stand out.  It turned out a new chain would not
noticeably affect printing speed, no hardware was required, and the
chain itself and installation was free.  A simple change was required
to UCS controls.

The new chain did make it easier to go over complex program listings.
0
hancock4 (224)
7/23/2012 4:54:16 PM
On Jul 22, 7:09=A0pm, Walter Banks <wal...@bytecraft.com> wrote:

[teletype failure from timing signals]
> Westinghouse purchasing showed the vendor their "new
> incoming inspection test that they would have to pass unless
> they reduced the price" =A0The vendor caved

Was this a Teletype brand Model 33 or 35?  The 33 was a light duty
machine and probably more susceptible to failure; the 35 was robust.
Other brand machines varied greatly.

http://massis.lcs.mit.edu/telecom-archives/archives/technical/western-union=
-tech-review/19-1/p022.htm

0
hancock4 (224)
7/23/2012 5:04:21 PM
On Jul 22, 8:56=A0pm, Peter Flass <Peter_Fl...@Yahoo.com> wrote:

> Okay, there's a problem right there. =A0The 1132 would interrupt as each
> character was coming into position. =A0The CPU built a buffer with '1'
> bits where that character was to be printed and '0' otherwise, so you'd
> have to wait on average 1/2 rotation at the beginning of a line and up
> to one full rotation to print the data.

Did the 1132 use recycled parts out of surplus 407s?

I wish I had saved some 1132 printouts but they were tossed in a move
long ago, along with other stuff I wish I had now.  Of course, that
was long before the Internet where this material could be shared with
others.

0
hancock4 (224)
7/23/2012 5:06:14 PM
On Jul 22, 10:06=A0pm, "Joe Morris" <j.c.mor...@verizon.net> wrote:
> > There were also trains allowing 8 lines per inch, usually on 8.5
> > inch long paper (either 11 or 14 inch wide) to save paper.
> > (That is, that looked right at 8lpi.)
>
> The vertical spacing was controlled by the clutch knob in the printer; I
> never heard of any standard trains that were designed for a specific
> vertical increment. =A0The glyph height was (IIRC) enough less than 1/8 i=
nch
> so that you didn't wind up with glyphs on one line merging with ones the
> lines above and below, although readability suffered.
> Some shops made 1/8" the standard spacing for their SYSPRINT queues, but
> most concluded that the reduction in the amount of paper consumed wasn't
> worth the reduced readability of dense printouts at 1/8".
> That's not to say that some shop might have bought a customized train wit=
h a
> smaller-than-standard glyph height, but I would expect that to be
> prohibitively expensive.

Running the common 1403 font at 8 lines per inch produced a very
crowded appearance that was difficult to read.  Many shops
experimented, once, with high density printing to save space on
archival reports but didn't bother putting it into practice.

I think they made a 'lower' font for use at 8 lines per inch; I recall
some utility bills printed that way.

Sometimes 8 lines was used at double space which produced an
attractive output.  However, this wasn't popular in practice since it
required a setup change to the printer, which was often forgotten for
the next job (and would foul it); generally shops didn't like messing
with those controls.




0
hancock4 (224)
7/23/2012 5:11:05 PM
On Jul 22, 10:12=A0pm, "Joe Morris" <j.c.mor...@verizon.net> wrote:

> Many IBM shops that had the ability to punch binary cards would punch a l=
ace
> card (all 960 holes) as a separator; that too provided an audio announcem=
ent
> of a new job's output.

If your job abended, the printing of the coredump made a distinctive
different sound that alerted all to your screwup.
0
hancock4 (224)
7/23/2012 5:12:38 PM
On Jul 23, 12:44=A0pm, John Levine <jo...@iecc.com> wrote:

> The disk arm was run by a stepper motor, so you could hear the buzzing
> as it ground its way from the outside of the disk toward the center
> and back.

One time our system hung.  The manager opened the disk drive door,
then slammed it close.  The machine restarted.

If the 1130 had buffering, it wasn't enough.  Running a simple program
with reading a card, a simple calculation, and printout, took
forever.  I didn't have a stop watch, but I think the throughput speed
was only 40 lines a minute.  I suspect one only got the 'rated' 80
lines per minute if one specially programmed the machine in its
assembler to expedite and optimized the printing I/O.  (Undoubtedly
many users did just that if that had high volume reports.)


> It's amazing the 1130 could get any actual computing done at all.

The 1130 was a cheap successor to the 1620 and was a popular machine
for science/engineering applications, and even small businesses.  In
its day, there wasn't much competition.  It also had S/360
compatibility, a useful feature for units of larger organizations.  It
had disk for offline storage.  I believe IBM offered a series of
common programs for it, just as IBM did for S/360.

People who have used the 1130 for number crunching problems report it
was a fast machine.  Yes, the I/O was terrible, but science/
engineering machines weren't designed for I/O.  If you had a problem
where you loaded a bunch of numbers then did extensive calculations on
them, the machine gave good performance.

I suspect the competition later on (about five years after
introduction) from more sophisticated DEC, DataGeneral, Nova, and
other mini computer makers made the 1130 obsolete.

0
hancock4 (224)
7/23/2012 5:24:03 PM

hancock4@bbs.cpcn.com wrote:

> On Jul 22, 7:09 pm, Walter Banks <wal...@bytecraft.com> wrote:
>
> [teletype failure from timing signals]
> > Westinghouse purchasing showed the vendor their "new
> > incoming inspection test that they would have to pass unless
> > they reduced the price"  The vendor caved
>
> Was this a Teletype brand Model 33 or 35?  The 33 was a light duty
> machine and probably more susceptible to failure; the 35 was robust.
> Other brand machines varied greatly.
>
> http://massis.lcs.mit.edu/telecom-archives/archives/technical/western-union-tech-review/19-1/p022.htm

I believe it was teletype model 35 mechanics. It was packaged in a
 small console supplied by teletype. I remember that it had a different
teletype model number, a quick check on the internet didn't find it.
It was a console keyboard/printer only.

The PROdac 250 was a Scientific Data Systems  (later Zerox Data Systems)
SDS sigma 2 repackaged by Westinghouse to be used for process control.

This happened in 1969 or early 1970.

w..



0
walter20 (887)
7/23/2012 5:34:50 PM
>Did the 1132 use recycled parts out of surplus 407s?

It definitely used 407 parts.  Nothing I've read says whether they
were refurbished used ones or built to be 1132s.

R's,
John
-- 
Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
0
johnl (129)
7/23/2012 10:25:19 PM
In comp.lang.pl1 John Levine <johnl@iecc.com> wrote:

>>Did the 1132 use recycled parts out of surplus 407s?

> It definitely used 407 parts.  Nothing I've read says whether they
> were refurbished used ones or built to be 1132s.

IBM has been well known for building new products out of parts
of old ones. Since many products were leased, they had to find
something to do with them when they came back.

-- glen
0
gah (12851)
7/23/2012 10:33:57 PM
>If the 1130 had buffering, it wasn't enough.

It didn't.  The card reader buffered one column, the printer had
extremely tight timing constraints to set up the bit map for each
character.

>> It's amazing the 1130 could get any actual computing done at all.
>
>The 1130 was a cheap successor to the 1620 and was a popular machine
>for science/engineering applications, and even small businesses.  In
>its day, there wasn't much competition.  It also had S/360
>compatibility, ...

Not really.  You could attac some 360 type peripherals to it, such as
the 1442 and 2501 card readers and 1403 printer, but the internal
organization was entirely different and none of the peripherals other
than the 1132 spoke EBCDIC.  There was a modest operating system that
could run stacked Fortran and assembler jobs, and a program library.

>People who have used the 1130 for number crunching problems report it
>was a fast machine.

They were mistaken, or they had extremely low expectations.  A 16 bit
add with an indexed address took 12us, multiply took 32us, divide
83us, store took 11us.

>I suspect the competition later on (about five years after
>introduction) from more sophisticated DEC, DataGeneral, Nova, and
>other mini computer makers made the 1130 obsolete.

Right.  IBM came out with the System 7 and Series 1, but by then it
was too late other than for true blue shops.

R's,
John



-- 
Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
0
johnl (129)
7/23/2012 10:44:47 PM
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote 
> John Levine <johnl@iecc.com> wrote

>>> Did the 1132 use recycled parts out of surplus 407s?
 
>> It definitely used 407 parts.  Nothing I've read says whether 
>> they were refurbished used ones or built to be 1132s.
 
> IBM has been well known for building new products out of parts
> of old ones. Since many products were leased, they had to find
> something to do with them when they came back.

Yeah, we bought an 029 card punch and there was one hell of
a stink when it turned out to be have been made from used parts.  
0
rod.speed.aaa (1275)
7/23/2012 11:02:17 PM
On 7/23/2012 7:49 AM, Charles Richmond wrote:
> "John Levine" <johnl@iecc.com> wrote in message
> news:juih97$2ejt$2@leila.iecc.com...
>> >What's an 1132?  Apparently a drum printer?  What computer?
>>
>> It's the drum printer that came with the IBM 1130 mini.  It was a
>> modified 407 accounting machine, and printed at 80 lpm on a good day.
>>
>> The interface was impressively horrible.  As the drum rotated, it
>> would interrupt the CPU and send it the code of the character about to
>> come up to the hammers, at which point the CPU had to construct a bit
>> map of which hammers to fire in time for the printer controller to DMA
>> it to the transistors that controlled the hammers.  Repeat as each
>> character comes past the hammers.  When all of the characters on a
>> line had been printed, the CPU started the paper moving, waited for
>> the appropriate hole in the carriage control tape to appear, then
>> stopped the paper.  It was a miracle it worked at all.
>>
>
> This sounds like an *excellent* design... if you had a microprocessor
> CPU to run the thing.  But certainly you are talking about a printer
> that pre-dated microprocessors by many years.
>


The 1130 was the microprocessor of its day.  It was kept inexpensive by 
having rather dumb peripherals and having the CPU do most of the work. 
It was an EBCDIC machine, but each peripheral communicated using its own 
code, except for the printer as previously described.  For example the 
console typewriter accepted Selectric "tilt and rotate" code.

Nevertheless it didn't compare unfavorably to a 360/20.  I thought it 
was a wonderful machine.


-- 
Pete
0
Peter_Flass (956)
7/23/2012 11:49:52 PM
On 7/23/2012 7:49 AM, Charles Richmond wrote:
> "John Levine" <johnl@iecc.com> wrote in message
> news:juih97$2ejt$2@leila.iecc.com...
>> >What's an 1132?  Apparently a drum printer?  What computer?
>>
>> It's the drum printer that came with the IBM 1130 mini.  It was a
>> modified 407 accounting machine, and printed at 80 lpm on a good day.
>>
>> The interface was impressively horrible.  As the drum rotated, it
>> would interrupt the CPU and send it the code of the character about to
>> come up to the hammers, at which point the CPU had to construct a bit
>> map of which hammers to fire in time for the printer controller to DMA
>> it to the transistors that controlled the hammers.  Repeat as each
>> character comes past the hammers.  When all of the characters on a
>> line had been printed, the CPU started the paper moving, waited for
>> the appropriate hole in the carriage control tape to appear, then
>> stopped the paper.  It was a miracle it worked at all.
>>
>
> This sounds like an *excellent* design... if you had a microprocessor
> CPU to run the thing.  But certainly you are talking about a printer
> that pre-dated microprocessors by many years.
>

Oh, by the way, to bring this thread back to a semblance of relevance, 
there was a PL/I interpreter for it - SL/I (Student Language/I) that was 
a more complete PL/I than PL/I(D).  I'm still searching for a copy, by 
the way...


-- 
Pete
0
Peter_Flass (956)
7/23/2012 11:51:53 PM
On 7/23/2012 7:56 AM, Charles Richmond wrote:
> "Joe Morris" <j.c.morris@verizon.net> wrote in message
> news:juibv701kjc@news6.newsguy.com...
>> "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote:
>>
>>> For the drum printers I knew, it would be easy to print a
>>> whole line at once. I hope they were designed for it.
>>
>> Most shops configured their printers to produce a flypage to mark the
>> beginning of each job's output, and flypage design usually included
>> rows of asterisks:
>>
>> ***********************************************
>> ***********************************************
>> JOB:  FUBAR    USER:  ALT.FOLKLORE.COMPUTERS
>> ***********************************************
>> ***********************************************
>>
>> which, when output on a drum printer, as an unintended (and usually
>> unwanted) byproduct gave an aural announcement of the beginning of
>> each job's output.
>>
>
> So do we know how the characters were apportioned on the drum printer???
> Was each line of the drum a single character... like all A's, or all
> *'s???  Or did each line have the alphabet but skewed so that the rows
> might look something like:
>
> ABCDEFGHIJKLMNOPQRSTUVWXYZ
> BCDEFGHIJKLMNOPQRSTUVWXYZA
> CDEFGHIJKLMNOPQRSTUVWXYZAB
>
> etc.     etc.    etc.
>
> Or perhaps the letters were apportioned based on the frequency in
> English or German or such...
>
> If the rows of asterisks made a big "bang!" when they were typed, I
> guess all the characters on each line of the drum were the same
> character.  But even if this was true, there could be more rows of E's
> than other characters.
>

The 1132 had rows all the same.  A line of all '*' mace quite a 
satisfying bang! and rocked the printer.


-- 
Pete
0
Peter_Flass (956)
7/23/2012 11:53:05 PM
In article <jukk4v$2tcp$1@leila.iecc.com>, John Levine <johnl@iecc.com> 
wrote:

> Not really.  You could attac some 360 type peripherals to it, such as
> the 1442 and 2501 card readers and 1403 printer, but the internal
> organization was entirely different and none of the peripherals other
> than the 1132 spoke EBCDIC.  There was a modest operating system that
> could run stacked Fortran and assembler jobs, and a program library.

It was compatible with the 360 in that the same programs would run on 
it, within limitations.  Also, it could communicate with the 360 using 
the SCA <http://www.ibm1130.net/functional/Introduction.html#SCA>.  At 
the time, this was pretty significant, as I understand it.  
Communications between TWO computers?!?  Whoa.  The ARPANET wouldn't 
exist for some years after this machine was introduced.


> They were mistaken, or they had extremely low expectations.  A 16 bit
> add with an indexed address took 12us, multiply took 32us, divide
> 83us, store took 11us.

Consider what they were comparing it to.  Older machines like the 1401 
from 1959?  The 1620, Can't Add, Doesn't Even Try?  I don't think they 
were comparing it with Xeon-based boxen, or even 8080s.  I agree that it 
wasn't fast compared to many 360-based boxes, or more recent systems.  
Its main selling point was that it was CHEAP and physically SMALL, only 
the size of a desk.  You couldn't say that about IBM 360 installations.  
Then again, you really couldn't say it about the IBM 1130 either, since 
if you add in the peripherals, it got quite a bit larger.  The 1132 was 
about the size of many line printers which followed it, which isn't tiny.


> >I suspect the competition later on (about five years after
> >introduction) from more sophisticated DEC, DataGeneral, Nova, and
> >other mini computer makers made the 1130 obsolete.
> 
> Right.  IBM came out with the System 7 and Series 1, but by then it
> was too late other than for true blue shops.

The DEC PDP-8 was comparable in capacity and age to the IBM 1130.

-- 
May joy be yours all the days of your life! - Phina
We are but a moment's sunlight, fading in the grass. - The Youngbloods
Those who eat natural foods die of natural causes. - Kperspective
0
howard578 (2138)
7/23/2012 11:58:29 PM
On 7/23/2012 1:24 PM, hancock4@bbs.cpcn.com wrote:
>
> The 1130 was a cheap successor to the 1620 and was a popular machine
> for science/engineering applications, and even small businesses.  In
> its day, there wasn't much competition.  It also had S/360
> compatibility

Not really, except for EBCDIC.  It *could* attach to an S/360 channel, 
and was often equipped with a 2250-4 to offload some of the CPU cycles 
from the mainframe.
....
>
> I suspect the competition later on (about five years after
> introduction) from more sophisticated DEC, DataGeneral, Nova, and
> other mini computer makers made the 1130 obsolete.
>

I think it became obsolete because IBM wanted an "all 360" solution.  It 
was limited to a 32K address space, but this could have been extended by 
bank switching or memory map registers if anyone had wanted to bother. 
The peripherals could also have been upgraded.


-- 
Pete
0
Peter_Flass (956)
7/24/2012 12:02:13 AM
On 7/23/2012 6:44 PM, John Levine wrote:
>> If the 1130 had buffering, it wasn't enough.
>
> It didn't.  The card reader buffered one column, the printer had
> extremely tight timing constraints to set up the bit map for each
> character.
>
>>> It's amazing the 1130 could get any actual computing done at all.
>>
>> The 1130 was a cheap successor to the 1620 and was a popular machine
>> for science/engineering applications, and even small businesses.  In
>> its day, there wasn't much competition.  It also had S/360
>> compatibility, ...
>
> Not really.  You could attac some 360 type peripherals to it, such as
> the 1442 and 2501 card readers and 1403 printer, but the internal
> organization was entirely different and none of the peripherals other
> than the 1132 spoke EBCDIC.  There was a modest operating system that
> could run stacked Fortran and assembler jobs, and a program library.
>
>> People who have used the 1130 for number crunching problems report it
>> was a fast machine.
>
> They were mistaken, or they had extremely low expectations.  A 16 bit
> add with an indexed address took 12us, multiply took 32us, divide
> 83us, store took 11us.

The index registers were memory locations.  The 1800 (1130 upgrade) used 
real registers.


-- 
Pete
0
Peter_Flass (956)
7/24/2012 12:04:21 AM
"John Levine" <johnl@iecc.com> wrote:

> The 1130 had a lot of other cost reduced stuff.  The keyboard was a
> keypunch keyboard that provided 12-bit card column code, and the card
> reader read 12 bit binary columns.  Software had to translate those to
> EBCDIC.

C'm on...where's your sense of history?  The online card reader, card punch, 
and printer for the IBM 7090 all used row-binary data transmission (none of 
this wimpy new-fangled "column-binary" stuff".

What that meant was that (for example) to punch the character "I" in card 
column 72 (did I mention that the card reader and punch could handle only 72 
columns?) you had to send 24 words of data with a 1 in the low-order bit of 
the second and 24th words...in other words (pun!) a 12-row and 9-row punch.

* ROW  12- 11- -0- -1- -2- -3-
  OCT  0,1,0,0,0,0,0,0,0,0,0,0

*      -4- -5- -6- -7- -8- -9-
  OCT  0,0,0,0,0,0,0,0,0,0,0,1

And, of course, you had to shoehorn the code to translate between card codes 
and BCD into the humongous memory - 32768 words of 36 bits each if the 
machine was maxed out.  (One side effect of this was that I have the value 
of 2^15 hardwired in fast-access memory...)

Joe 


0
j.c.morris (65)
7/24/2012 12:47:20 AM
"Peter Flass" <Peter_Flass@Yahoo.com> wrote:
> On 7/22/2012 10:06 PM, Joe Morris wrote:

>> The vertical spacing was controlled by the clutch knob in the printer; I
>> never heard of any standard trains that were designed for a specific
>> vertical increment.  The glyph height was (IIRC) enough less than 1/8 
>> inch
>> so that you didn't wind up with glyphs on one line merging with ones the
>> lines above and below, although readability suffered.

> You had to change the carriage control tape though, later the FCB.

Minor edit: you *hope* that someone changed the carriage control tape, and 
that ehen they didn't the jobs printed before someone corrected the mistake 
were those submitted by peons (aka "undergraduates") and not the Big-Name 
Professor.

Joe 


0
j.c.morris (65)
7/24/2012 12:54:34 AM
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote:
> In comp.lang.pl1 Joe Morris <j.c.morris@verizon.net> wrote:

>> Some shops made 1/8" the standard spacing for their SYSPRINT queues, but
>> most concluded that the reduction in the amount of paper consumed wasn't
>> worth the reduced readability of dense printouts at 1/8".

>> That's not to say that some shop might have bought a customized
>> train with a smaller-than-standard glyph height, but I would
>> expect that to be prohibitively expensive.

> Run them 24 hours a day, compute the paper cost savings, then
> see if it is worthwhile.

I'll admit that my perspective was from an academic shop.  I'll agree with 
you that in a business shop - especially given the stability of the workload 
and the power of the bean counters - the balance between legibility and cost 
has a different location.  Just look at the credit card statements or 
similar business printouts from that era.

Joe 


0
j.c.morris (65)
7/24/2012 12:58:05 AM
In comp.lang.pl1 Joe Morris <j.c.morris@verizon.net> wrote:
> "John Levine" <johnl@iecc.com> wrote:

>> The 1130 had a lot of other cost reduced stuff.  The keyboard was a
>> keypunch keyboard that provided 12-bit card column code, and the card
>> reader read 12 bit binary columns.  Software had to translate those to
>> EBCDIC.

> C'm on...where's your sense of history?  The online card reader, card punch, 
> and printer for the IBM 7090 all used row-binary data transmission (none of 
> this wimpy new-fangled "column-binary" stuff".

> What that meant was that (for example) to punch the character "I" in card 
> column 72 (did I mention that the card reader and punch could handle only 72 
> columns?) 

Same as the 704? As a result, Fortran got the column 72 limitation, 
still in the standard for Fixed Form. 

-- glen
0
gah (12851)
7/24/2012 1:30:17 AM
In <howard-914DA3.17582923072012@news.giganews.com>, on 07/23/2012
   at 05:58 PM, Howard S Shubs <howard@shubs.net> said:

>Communications between TWO computers?!?  Whoa.  The ARPANET 
>wouldn't  exist for some years after this machine was introduced.

Every generation thinks that it invented sex. Communication between
computers is older than the 1130.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
spamtrap16 (3722)
7/24/2012 2:13:58 AM
In article <howard-914DA3.17582923072012@news.giganews.com>,
 Howard S Shubs <howard@shubs.net> wrote:

> In article <jukk4v$2tcp$1@leila.iecc.com>, John Levine <johnl@iecc.com> 
> wrote:
> 
> > Not really.  You could attac some 360 type peripherals to it, such as
> > the 1442 and 2501 card readers and 1403 printer, but the internal
> > organization was entirely different and none of the peripherals other
> > than the 1132 spoke EBCDIC.  There was a modest operating system that
> > could run stacked Fortran and assembler jobs, and a program library.
> 
> It was compatible with the 360 in that the same programs would run on 
> it, within limitations.  Also, it could communicate with the 360 using 
> the SCA <http://www.ibm1130.net/functional/Introduction.html#SCA>.  At 
> the time, this was pretty significant, as I understand it.  
> Communications between TWO computers?!?  Whoa.  The ARPANET wouldn't 
> exist for some years after this machine was introduced.
> 
> 
> > They were mistaken, or they had extremely low expectations.  A 16 bit
> > add with an indexed address took 12us, multiply took 32us, divide
> > 83us, store took 11us.
> 
> Consider what they were comparing it to.  Older machines like the 1401 
> from 1959?  The 1620, Can't Add, Doesn't Even Try?  I don't think they 
> were comparing it with Xeon-based boxen, or even 8080s.  I agree that it 
> wasn't fast compared to many 360-based boxes, or more recent systems.  
> Its main selling point was that it was CHEAP and physically SMALL, only 
> the size of a desk.  You couldn't say that about IBM 360 installations.  
> Then again, you really couldn't say it about the IBM 1130 either, since 
> if you add in the peripherals, it got quite a bit larger.  The 1132 was 
> about the size of many line printers which followed it, which isn't tiny.
> 
> 
> > >I suspect the competition later on (about five years after
> > >introduction) from more sophisticated DEC, DataGeneral, Nova, and
> > >other mini computer makers made the 1130 obsolete.
> > 
> > Right.  IBM came out with the System 7 and Series 1, but by then it
> > was too late other than for true blue shops.
> 
> The DEC PDP-8 was comparable in capacity and age to the IBM 1130.

I got into computers because of the 1130. We had one at Brooklyn Tech 
circa 1970 (probably one of the few high schools in America to have a 
computer at that time!). I knew zero about computers, but once I did use 
it, I was hooked and made computers my life's work.

Later I found it could be used as an RJE station to system/360. I've 
seen pictures of a center in England where they used an 1130 as such 
(with a 2501 card reader and 1403-N1 printer). From the looks of things 
there, a totally self-service operation.

I wonder how fast it could operate the peripherals because the 1130 only 
had a 512K (yes 512 thousand bytes!) single platter disk drive for 
storage and buffering). A second one could be added, if I remember right.

--LG
0
7/24/2012 2:16:31 AM
On Tuesday, 24 July 2012 08:44:47 UTC+10, John Levine  wrote:

> >People who have used the 1130 for number crunching problems report it
> >was a fast machine.
> 
> They were mistaken, or they had extremely low expectations.  A 16 bit
> add with an indexed address took 12us, multiply took 32us, divide
> 83us, store took 11us.

Probably fast for the time.
The figures are not horribly slow,
and compare favorably with earlier and later machines.
Earlier machines had 33 to 64 uS for a 32-bit add,
and 2ms for multiply / divide.
The EE System 4-50 (=RCA Spectra) 32-bit add was 7.92uS,
multiply 62.52uS, divide 90.81uS
0
robin.vowels (428)
7/24/2012 2:25:52 AM
>> There was a modest operating system that
>> could run stacked Fortran and assembler jobs, and a program library.
>
>It was compatible with the 360 in that the same programs would run on 
>it, within limitations.

So long as the limitation was that the programs were rewritten from
scratch to work on the entirely incompatible 1130, I suppose so.
Internally the 1130 was a 16 bit word addressed machine which was
nothing like a 360.  Are you sure you don't have it confused with the
360/20?

> Also, it could communicate with the 360 using 
>the SCA <http://www.ibm1130.net/functional/Introduction.html#SCA>.  At 
>the time, this was pretty significant, as I understand it.  
>Communications between TWO computers?!?  Whoa.

Yawn.  Back in the early 1970s a friend at Princeton did a little
hardware hackery to attach a bisync line to a PDP-11 in his lab and do
RJE to the 360/91 a couple of blocks away.  I helped him write some of
the front end user code.

>> They were mistaken, or they had extremely low expectations.  A 16 bit
>> add with an indexed address took 12us, multiply took 32us, divide
>> 83us, store took 11us.
>
>Consider what they were comparing it to.  Older machines like the 1401 
>from 1959?  The 1620, Can't Add, Doesn't Even Try?  I don't think they 
>were comparing it with Xeon-based boxen, or even 8080s.  I agree that it 
>wasn't fast compared to many 360-based boxes, or more recent systems.  
>Its main selling point was that it was CHEAP and physically SMALL

If you were only aware of IBM equipment, I suppose.  On a PDP-8, a 12
bit add took 3us, 24 bit add would be about 18us (CLR, TAD, TAD, DCA,
RAL, TAD, TAD)

>The DEC PDP-8 was comparable in capacity and age to the IBM 1130.

Kind of.  It was only 12 bits and multiply/divide was an expensive
option.  But it was under $20K, was small enough that one person could
move it, and was way more fun to program from the switches.  I'd say a
PDP-7 or PDP-9 was more comparable to an 1130, but I never programmed
either of those.
-- 
Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
0
johnl (129)
7/24/2012 3:49:15 AM
>> They were mistaken, or they had extremely low expectations.  A 16 bit
>> add with an indexed address took 12us, multiply took 32us, divide
>> 83us, store took 11us.
>
>The index registers were memory locations.  The 1800 (1130 upgrade) used 
>real registers.

The 1800 was a lot faster, but also a lot more expensive.  It was
aimed at a different market, realtime process control, rather than the
1130s low end data processing.

R's,
John
-- 
Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
0
johnl (129)
7/24/2012 3:50:38 AM
In article 
<lawrence.greenwald-83DC29.19163123072012@5ad64b5e.bb.sky.com>,
 Lawrence Greenwald <lawrence.greenwald@sbcglobal.net> wrote:

> I wonder how fast it could operate the peripherals because the 1130 only 
> had a 512K (yes 512 thousand bytes!) single platter disk drive for 
> storage and buffering). A second one could be added, if I remember right.

Almost.  The IBM 1130 measured memory in 16-bit words, so that disk was 
roughly 1MB.

-- 
May joy be yours all the days of your life! - Phina
We are but a moment's sunlight, fading in the grass. - The Youngbloods
Those who eat natural foods die of natural causes. - Kperspective
0
howard578 (2138)
7/24/2012 3:54:53 AM
>> They were mistaken, or they had extremely low expectations.  A 16 bit
>> add with an indexed address took 12us, multiply took 32us, divide
>> 83us, store took 11us.
>
>Probably fast for the time.

The PDP-7 was introduced in 1965 and cost about the same as an 1130.

Its core memory cycled at 1.75us, rather than 2.2us or 3.6us for the
1130.  An 18 bit add with an indirect address (typical because the -7
had no index registers) took 5.25us.  You get the idea.  The 1130 had
its charms, but blinding speed was not one of them.

R's,
John
-- 
Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
0
johnl (129)
7/24/2012 4:02:29 AM
>Nevertheless it didn't compare unfavorably to a 360/20.  I thought it 
>was a wonderful machine.

The 360/20 was WAY more fun to program from the switches.  And you could
punch some interesting programs onto a single self-booting card.

R's,
John
-- 
Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
0
johnl (129)
7/24/2012 4:04:09 AM
>> The 1130 had a lot of other cost reduced stuff.  The keyboard was a
>> keypunch keyboard that provided 12-bit card column code, and the card
>> reader read 12 bit binary columns.  Software had to translate those to
>> EBCDIC.
>
>C'm on...where's your sense of history?

Well, yeah.  I was spoiled by the 360/20 where the code conversion was
all hidden in the microcode.

R's,
John
-- 
Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
0
johnl (129)
7/24/2012 4:12:21 AM
In article <jul5vr$1e5o$1@leila.iecc.com>, John Levine <johnl@iecc.com> 
wrote:

> >> There was a modest operating system that
> >> could run stacked Fortran and assembler jobs, and a program library.
> >
> >It was compatible with the 360 in that the same programs would run on 
> >it, within limitations.
> 
> So long as the limitation was that the programs were rewritten from
> scratch to work on the entirely incompatible 1130, I suppose so.
> Internally the 1130 was a 16 bit word addressed machine which was
> nothing like a 360.  Are you sure you don't have it confused with the
> 360/20?

I seem to recall some language in one of the two manuals I put on the 
web that said it was compatible in some way in source, but I'm not 
finding it now.  You're probably right.


> > Also, it could communicate with the 360 using 
> >the SCA <http://www.ibm1130.net/functional/Introduction.html#SCA>.  At 
> >the time, this was pretty significant, as I understand it.  
> >Communications between TWO computers?!?  Whoa.
> 
> Yawn.  Back in the early 1970s a friend at Princeton did a little
> hardware hackery to attach a bisync line to a PDP-11 in his lab and do
> RJE to the 360/91 a couple of blocks away.  I helped him write some of
> the front end user code.

But the 1130 was released in the mid-1960s, not 1970s.


> >Consider what they were comparing it to.  Older machines like the 1401 
> >from 1959?  The 1620, Can't Add, Doesn't Even Try?  I don't think they 
> >were comparing it with Xeon-based boxen, or even 8080s.  I agree that it 
> >wasn't fast compared to many 360-based boxes, or more recent systems.  
> >Its main selling point was that it was CHEAP and physically SMALL
> 
> If you were only aware of IBM equipment, I suppose.  On a PDP-8, a 12
> bit add took 3us, 24 bit add would be about 18us (CLR, TAD, TAD, DCA,
> RAL, TAD, TAD)
> 
> >The DEC PDP-8 was comparable in capacity and age to the IBM 1130.
> 
> Kind of.  It was only 12 bits and multiply/divide was an expensive
> option.  But it was under $20K, was small enough that one person could
> move it, and was way more fun to program from the switches.  I'd say a
> PDP-7 or PDP-9 was more comparable to an 1130, but I never programmed
> either of those.

Yeah, I can't claim those either.

-- 
May joy be yours all the days of your life! - Phina
We are but a moment's sunlight, fading in the grass. - The Youngbloods
Those who eat natural foods die of natural causes. - Kperspective
0
howard578 (2138)
7/24/2012 5:00:18 AM
In article <howard-1800A4.21545323072012@news.giganews.com>,
 Howard S Shubs <howard@shubs.net> wrote:

> In article 
> <lawrence.greenwald-83DC29.19163123072012@5ad64b5e.bb.sky.com>,
>  Lawrence Greenwald <lawrence.greenwald@sbcglobal.net> wrote:
> 
> > I wonder how fast it could operate the peripherals because the 1130 only 
> > had a 512K (yes 512 thousand bytes!) single platter disk drive for 
> > storage and buffering). A second one could be added, if I remember right.
> 
> Almost.  The IBM 1130 measured memory in 16-bit words, so that disk was 
> roughly 1MB.

There were giants on the Earth in those days, who did mighty deeds 
with almost no resources.

Hail!

I wonder how long it would have taken that machine to do Kepler's 
computation establishing the motion of the planets.

-- 
This space unintentionally left blank.
0
proto (1924)
7/24/2012 10:20:04 AM
In <howard-914DA3.17582923072012@news.giganews.com>, on 07/23/2012
   at 05:58 PM, Howard S Shubs <howard@shubs.net> said:

>Consider what they were comparing it to.

I believe that John's point was that they were only comparing it to
other slow machines. There were faster machines on the market long
before the 1130.

>The 1620, Can't Add, Doesn't Even Try?

The RCA 301 used the same trick. I wonder whether anybody ever diddled
the add tables for octal arithmetic?

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
spamtrap16 (3722)
7/24/2012 10:50:59 AM

Walter Bushell wrote:

> In article <howard-1800A4.21545323072012@news.giganews.com>,
>  Howard S Shubs <howard@shubs.net> wrote:
>
> > Almost.  The IBM 1130 measured memory in 16-bit words, so that disk was
> > roughly 1MB.
>
> There were giants on the Earth in those days, who did mighty deeds
> with almost no resources.
>
> Hail!
>
> I wonder how long it would have taken that machine to do Kepler's
> computation establishing the motion of the planets.
>

Good question.

The 1130 couldn't think and talk at the same time. If stopped talking (printing)
then it had enough time to think.  It beat doing planet motion by hand which
made it fast.

Forty + years have not only made computers  fast but the algorithms for
implementing a problem on computers have had equally dramatic performance
improvements.

w..



0
walter20 (887)
7/24/2012 11:53:27 AM

"Shmuel (Seymour J.) Metz" wrote:

> In <howard-914DA3.17582923072012@news.giganews.com>, on 07/23/2012
>    at 05:58 PM, Howard S Shubs <howard@shubs.net> said:
>
> >Consider what they were comparing it to.
>
> I believe that John's point was that they were only comparing it to
> other slow machines. There were faster machines on the market long
> before the 1130.
>
> >The 1620, Can't Add, Doesn't Even Try?
>
> The RCA 301 used the same trick. I wonder whether anybody ever diddled
> the add tables for octal arithmetic?

Guilty.. I worked just fine. Actually almost anyone with access to the
original  IBM1620 found some use for changing the math tables.

The time it took to reload the tables would kill the advantage. Besides
add of various bases the tables were sometimes used to create logic
operators. It was almost always a midnight to morning experiment that
had no real use beyond the curiosity factor.

w..

0
walter20 (887)
7/24/2012 12:18:47 PM
On Mon, 23 Jul 2012 19:16:31 -0700
Lawrence Greenwald <lawrence.greenwald@sbcglobal.net> wrote:


> I got into computers because of the 1130. We had one at Brooklyn Tech 
> circa 1970 (probably one of the few high schools in America to have a 
> computer at that time!). I knew zero about computers, but once I did use 
> it, I was hooked and made computers my life's work.

	That makes (at least) two of us, although the 1130 was at the local
technical college, at school we only had an ASR33 and an acoustic coupler.

> Later I found it could be used as an RJE station to system/360. I've 
> seen pictures of a center in England where they used an 1130 as such 
> (with a 2501 card reader and 1403-N1 printer). From the looks of things 
> there, a totally self-service operation.

	Ours had a 1442 and a 1403 (not N1), for an hour a day anyone could
walk in and drop a job onto the card reader. Trusted people could even book
the machine to themselves for an hour at a time. I lost my privilege by
playing moon lander for most of an hour one time.

> I wonder how fast it could operate the peripherals because the 1130 only 
> had a 512K (yes 512 thousand bytes!) single platter disk drive for 
> storage and buffering). A second one could be added, if I remember right.

	I rather thought ours was a 1.5MB single platter drive, it also had
a cabinet with two more drives in it, a pretty much essential peripheral
for copying discs.

-- 
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:>WIN                                      | A better way to focus the sun
The computer obeys and wins.                |    licences available see
You lose and Bill collects.                 |    http://www.sohara.org/
0
steveo (475)
7/24/2012 12:39:20 PM
On Jul 23, 6:33=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> In comp.lang.pl1 John Levine <jo...@iecc.com> wrote:
>
> >>Did the 1132 use recycled parts out of surplus 407s?
> > It definitely used 407 parts. =A0Nothing I've read says whether they
> > were refurbished used ones or built to be 1132s.
>
> IBM has been well known for building new products out of parts
> of old ones. Since many products were leased, they had to find
> something to do with them when they came back.

What other IBM _new_ products used parts of old ones?

They re-used the 2314 disk drive in S/370, but I don't think they gave
it a new model number.

Because new equipment generally was faster and smaller-sized than the
stuff it replaced, I'm not sure how old parts could be utilized to any
great extent.  The 1132 printer is a notable exception since it was a
very slow printer.  (The 407 ran faster at 150 lines per minute).

I've been told that they resold turned-in 1401 to schools and
hospitals at a good price after S/360 came out, but it was still sold
as a 1401, not incorporated into anything else.

IBM utilized its 1950s "SMS" circuit card technology in peripheral
units for S/360, but I don't think they physically re-used old circuit
cards.
0
hancock4 (224)
7/24/2012 3:18:05 PM
On Jul 23, 6:44=A0pm, John Levine <jo...@iecc.com> wrote:

> >It also had S/360
> >compatibility, ...
>
> Not really. =A0You could attac some 360 type peripherals to it, such as
> the 1442 and 2501 card readers and 1403 printer, but the internal
> organization was entirely different and none of the peripherals other
> than the 1132 spoke EBCDIC. =A0There was a modest operating system that
> could run stacked Fortran and assembler jobs, and a program library.

It could be used as a terminal to connect to  S/360.



> >People who have used the 1130 for number crunching problems report it
> >was a fast machine.
>
> They were mistaken, or they had extremely low expectations. =A0A 16 bit
> add with an indexed address took 12us, multiply took 32us, divide
> 83us, store took 11us.

What were arithmetic processing speeds of other low-end computers of
that time-frame?



> >I suspect the competition later on (about five years after
> >introduction) from more sophisticated DEC, DataGeneral, Nova, and
> >other mini computer makers made the 1130 obsolete.
>
> Right. =A0IBM came out with the System 7 and Series 1, but by then it
> was too late other than for true blue shops.

I believe the S/7 was more of a process control computer, to replace
the 1130's cousin, the 1800.  Interestingly, one of the few times the
Bell System went 'outside' to get hardware, was to use S/7's to
supplement AMA toll recording equipment.  Bell later went to PDP
machines and was a big purchaser of DEC gear.




0
hancock4 (224)
7/24/2012 3:23:34 PM
On Monday, 23 July 2012 12:40:04 UTC+10, Seymour J. Shmuel Metz  wrote:
> In &lt;jjjjjj@speranza.aioe.org&gt;, on 07/22/2012
>    at 11:14 PM, glen herrmannsfeldt <ggggggg@gcs.caltech.edu> said:
> 
> >From the Fortran I (704) manual, "+" is 12 punch.
> 
> Whoops! That was well before EBCDIC,

The codes used in the 1950s probably derived from unit record
equipment from the late 1800s.

Mechanical tabulating equipment used in business in the 1950s
(and probably decades before) employed those codes.
Hollerith in the UK and IBM in the USA made such tabulators
(or, if you prefer, card to printed page).

Certainly, in 1955, + was a 12-row punch and - was an 11-row punch.
This was part of the so-called 3-zone code -- the top three rows
of a punch card being the zone code.
The IBM 421 tabulator was one such device for producing listings.
0
robin.vowels (428)
7/24/2012 3:31:43 PM
On Jul 23, 8:02=A0pm, Peter Flass <Peter_Fl...@Yahoo.com> wrote:

> > I suspect the competition later on (about five years after
> > introduction) from more sophisticated DEC, DataGeneral, Nova, and
> > other mini computer makers made the 1130 obsolete.
>
> I think it became obsolete because IBM wanted an "all 360" solution. =A0I=
t
> was limited to a 32K address space, but this could have been extended by
> bank switching or memory map registers if anyone had wanted to bother.
> The peripherals could also have been upgraded.


IBM might have 'wanted' an all S/360 solution, but even a very low end
S/360 was not cost competitive with tab machines in small
installations.  I don't know the costs, but I suspect a low end S/360-
model 30 would've cost more to both buy and operate than a good 1130.

Anyway, IBM ended up developing System/3 for small business needs.  It
used modern technology and new ways of thinking to hold down costs.
The tiny punched card meant the card reader and punch could be
physically smaller which saved money.  The S/3 begat its own line of
mini-computers (S/34, 36, 38, AS/400, i series) which remains
successful to this day.

While the IBM history touches on System/3, a separate history should
be written of life of the development of low-end business machines,
software, and the world of low-end business users.  Much has been
written about the high end world (we just got the reference "The
Computer Boys"), but the low end world had a very different culture.


0
hancock4 (224)
7/24/2012 3:32:57 PM
On Jul 23, 8:54=A0pm, "Joe Morris" <j.c.mor...@verizon.net> wrote:
> "Peter Flass" <Peter_Fl...@Yahoo.com> wrote:
> > On 7/22/2012 10:06 PM, Joe Morris wrote:
> >> The vertical spacing was controlled by the clutch knob in the printer;=
 I
> >> never heard of any standard trains that were designed for a specific
> >> vertical increment. =A0The glyph height was (IIRC) enough less than 1/=
8
> >> inch


[8 lines per inch]
> >> so that you didn't wind up with glyphs on one line merging with ones t=
he
> >> lines above and below, although readability suffered.
> > You had to change the carriage control tape though, later the FCB.
>
> Minor edit: you *hope* that someone changed the carriage control tape, an=
d
> that ehen they didn't the jobs printed before someone corrected the mista=
ke
> were those submitted by peons (aka "undergraduates") and not the Big-Name
> Professor.

Often they forgot to change the tape, and the subsequent run was
botched.  A key reason 8 lines per inch was discouraged except in very
special cases.



0
hancock4 (224)
7/24/2012 3:34:44 PM
In comp.lang.pl1 hancock4@bbs.cpcn.com wrote:

(snip, I wrote)
>> IBM has been well known for building new products out of parts
>> of old ones. Since many products were leased, they had to find
>> something to do with them when they came back.

> What other IBM _new_ products used parts of old ones?

> They re-used the 2314 disk drive in S/370, but I don't think 
> they gave it a new model number.

The 2319 IFA (integrated file adaptor). As I understand it,
they reuse 2314 parts, but without the traditional controller.
It seems to use special microcode on some S/370 models to replace
the logic that normally would be in a separate controller box.

> Because new equipment generally was faster and smaller-sized than the
> stuff it replaced, I'm not sure how old parts could be utilized to any
> great extent.  The 1132 printer is a notable exception since it was a
> very slow printer.  (The 407 ran faster at 150 lines per minute).

Also, as I understand, 370/158s were reused inside the 3032 
and 3033 for I/O. As a 370/158, it had microcode for both CPU 
and channel operations. Running the channels for the 303x, it
only needed (probably new) channel microcode, to offload that
function from the CPU.

-- glen
0
gah (12851)
7/24/2012 4:29:01 PM
On Jul 23, 8:58=A0pm, "Joe Morris" <j.c.mor...@verizon.net> wrote:

> > Run them 24 hours a day, compute the paper cost savings, then
> > see if it is worthwhile.
>
> I'll admit that my perspective was from an academic shop. =A0I'll agree w=
ith
> you that in a business shop - especially given the stability of the workl=
oad
> and the power of the bean counters - the balance between legibility and c=
ost
> has a different location. =A0Just look at the credit card statements or
> similar business printouts from that era.

Since the 'bean counters' were the readers of computer generated
reports, they tended to not encourage hard-to-read formats.

Back then, computers and labor to run them were so expensive that
paper costs just got buried in the overall costs.  Computer centers
and programmers used to waste tremendous amounts of paper.  Efforts to
conserve (eg reuse of reports for printing on the back side* and
crowded 8 lines per inch) were limited to avoid confusion.

Of course, invoices and notices back then tended to be smaller than
what is printed today.  Our phone bill in that era was a single slip
of paper, service & equipment on the left side, toll calls on the
right side.  Our electric bill was a postcard, name/address on the
right, KWHrs and amount due on the left.

For whatever reason, electric and telephone bills are much more
complex.  (Mine runs many pages even _without_ call itemization.)

Later on xeroxography printing came out (we had high speed mediocre
quality Xerox printers in 1979), which saved some paper costs.

When personal computers hit the office, paper consumption went way up
for a number of years.


* If there was a messsage to go out with the payroll checks, we reran
the checks printing the message on the backside of the pay stub.   We
did tend to completely wear out a printer ribbon and used generic ones
to save money, except when printing checks.
  Also, many business reports were on special forms, and the cost was
more in one-time set up (typesetting and design) than in subsequent
copies.

0
hancock4 (224)
7/24/2012 5:19:34 PM
On Jul 23, 11:49=A0pm, John Levine <jo...@iecc.com> wrote:

> >> There was a modest operating system that
> >> could run stacked Fortran and assembler jobs, and a program library.
>
> >It was compatible with the 360 in that the same programs would run on
> >it, within limitations.
>
> So long as the limitation was that the programs were rewritten from
> scratch to work on the entirely incompatible 1130, I suppose so.
> Internally the 1130 was a 16 bit word addressed machine which was
> nothing like a 360. =A0Are you sure you don't have it confused with the
> 360/20?

The 1130 Fortran had a few limitations, such as not allowing logical
IF statements.  But otherwise a modest sized Fortran program could be
recompiled and run on the 1130 without change, and the reverse.


> >Consider what they were comparing it to. =A0Older machines like the 1401
> >from 1959? =A0The 1620, Can't Add, Doesn't Even Try? =A0I don't think th=
ey
> >were comparing it with Xeon-based boxen, or even 8080s. =A0I agree that =
it
> >wasn't fast compared to many 360-based boxes, or more recent systems.
> >Its main selling point was that it was CHEAP and physically SMALL

> If you were only aware of IBM equipment, I suppose. =A0On a PDP-8, a 12
> bit add took 3us, 24 bit add would be about 18us (CLR, TAD, TAD, DCA,
> RAL, TAD, TAD)

Did the PDP-8 support a wide line printer, disk storage and punched
card input?





> >The DEC PDP-8 was comparable in capacity and age to the IBM 1130.
>
> Kind of. =A0It was only 12 bits and multiply/divide was an expensive
> option. =A0But it was under $20K, was small enough that one person could
> move it, and was way more fun to program from the switches. =A0I'd say a
> PDP-7 or PDP-9 was more comparable to an 1130, but I never programmed
> either of those.

If someone outgrew their PDP, were the next upward models compatible,
that is, could programs and compiled for say the PDP-7 run without
change on the PDP-8 or PDP-9, etc.?


0
hancock4 (224)
7/24/2012 5:24:13 PM
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Also, as I understand, 370/158s were reused inside the 3032 
> and 3033 for I/O. As a 370/158, it had microcode for both CPU 
> and channel operations. Running the channels for the 303x, it
> only needed (probably new) channel microcode, to offload that
> function from the CPU.

370/158 had "integrated channels" ... 158 engine was shared running
"integrated channel" microcode and 370 microcode.

303x was a quick&dirty effort to get something out quick ... after
future system effort had failed ... during the FS period lots of 370
efforts were suspended and/or killed off (and is credited with allowing
clone processors to get market foothold). some past posts mentioning
FS
http://www.garlic.com/~lynn/submain.html#futuresys

303x channel director was 370/158 engine with only the integrated
channel microcode (and no 370 microcode)

3031 was two 370/158 engines, one dedicated to "channel director"
running just the integrated channel microcode and another engine running
just the 370 microcode (a 3031 multiprocessor being four 370/158
engines, two channel directors and two 370 processor).

3032 was 370/168 reconfigured to use channel director as its
external channels

3033 started out being 370/168 logic remapped to 20% faster chips that
also had 10times circuits/chip ... extra circuits originally gone
unused. during development there was some remapping of logic to
consolidate more onchip operations ... eventually getting 3033 up to
nearly 50% faster than 168. 3033 also used the channel director for its
i/o.

370/158 integrated channel microcode supported 6 channels. for 3032 and
3033 configurations with more than 6 channels required multiple "channel
directors"

some other details of future system, 3033, and 3081 (also quick&dirty
effort, reusing some FS technology)
http://www.jfsowa.com/computer/memo125.htm

this post has old 4341, 3031, & 158 benchmark shows 3031 increased
processing compared to 158 (since the engine was now dedicated to 370
processing) 
http://www.garlic.com/~lynn/2000d.html#0

as an aside ... 4341 also had integrated channel ... but the 4341
processor engine was so much faster ... that with slight tweaks the 4341
supports 3380 3mbyte channel speeds ... something that the 370/158
engine was incapable of.

-- 
virtualization experience starting Jan1968, online at home since Mar1970
0
lynn13 (400)
7/24/2012 6:23:33 PM

<hancock4@bbs.cpcn.com> wrote in message 
news:96711db9-9ea1-4534-ac6a-68f4ddd0f3f7@e7g2000yqh.googlegroups.com...
> On Jul 23, 11:49 pm, John Levine <jo...@iecc.com> wrote:
>
>> >> There was a modest operating system that
>> >> could run stacked Fortran and assembler jobs, and a program library.
>>
>> >It was compatible with the 360 in that the same programs would run on
>> >it, within limitations.
>>
>> So long as the limitation was that the programs were rewritten from
>> scratch to work on the entirely incompatible 1130, I suppose so.
>> Internally the 1130 was a 16 bit word addressed machine which was
>> nothing like a 360.  Are you sure you don't have it confused with the
>> 360/20?
>
> The 1130 Fortran had a few limitations, such as not allowing logical
> IF statements.  But otherwise a modest sized Fortran program could be
> recompiled and run on the 1130 without change, and the reverse.
>
>
>> >Consider what they were comparing it to.  Older machines like the 1401
>> >from 1959?  The 1620, Can't Add, Doesn't Even Try?  I don't think they
>> >were comparing it with Xeon-based boxen, or even 8080s.  I agree that it
>> >wasn't fast compared to many 360-based boxes, or more recent systems.
>> >Its main selling point was that it was CHEAP and physically SMALL
>
>> If you were only aware of IBM equipment, I suppose.  On a PDP-8, a 12
>> bit add took 3us, 24 bit add would be about 18us (CLR, TAD, TAD, DCA,
>> RAL, TAD, TAD)
>
> Did the PDP-8 support a wide line printer, disk storage and punched
> card input?
>
>
>
>
>
>> >The DEC PDP-8 was comparable in capacity and age to the IBM 1130.
>>
>> Kind of.  It was only 12 bits and multiply/divide was an expensive
>> option.  But it was under $20K, was small enough that one person could
>> move it, and was way more fun to program from the switches.  I'd say a
>> PDP-7 or PDP-9 was more comparable to an 1130, but I never programmed
>> either of those.

> If someone outgrew their PDP, were the next upward models compatible,
> that is, could programs and compiled for say the PDP-7 run without
> change on the PDP-8 or PDP-9, etc.?

The 7 and 9 were just different technology with the same instruction set.

The 8 was very different to the 7 on stuff like word size.

The way text was packed into the 12 and 18 bit words respectively was quite 
different. 

0
rod.speed.aaa (1275)
7/24/2012 7:15:16 PM
>The 1130 Fortran had a few limitations, such as not allowing logical
>IF statements.  But otherwise a modest sized Fortran program could be
>recompiled and run on the 1130 without change, and the reverse.

Yes, I know, the first program I ever wrote was a quadratic equation
solver on an 1130.

But you could say that about any computer.  You could recompile your
360 Fortran programs on a PDP-6 with minimal changes (its compiler had
a lot in common with Fortran G) but nobody would say a PDP-6 was in
any way compatible with a 360.

>> If you were only aware of IBM equipment, I suppose. �On a PDP-8, a 12
>> bit add took 3us, 24 bit add would be about 18us (CLR, TAD, TAD, DCA,
>> RAL, TAD, TAD)
>
>Did the PDP-8 support a wide line printer, disk storage and punched
>card input?

If you had enough money, sure, but most people didn't.  DEC had enough
sense not to compete head-on with IBM, and their main markets were
scientific, process control and education.  They made a half hearted
attempt at the commercial market with an RPG-ish language called Dibol
which wasn't very popular/

>If someone outgrew their PDP, were the next upward models compatible,
>that is, could programs and compiled for say the PDP-7 run without
>change on the PDP-8 or PDP-9, etc.?

There were multiple product lines.  The 18 bit PDP-4, -7, -9, and -15
were largely instruction set compatible, as were the 12 bit PDP-5 and -8
and the 36 bit PDP-6, -10, and DEC 20.

R's,
John



-- 
Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
0
johnl (129)
7/24/2012 7:20:10 PM
>The codes used in the 1950s probably derived from unit record
>equipment from the late 1800s.

Not that far back.  Hole arrangements in the 1800s were quite ad-hoc
and the familiar 80 column card with rectangular holes wasn't
developed until 1928.

-- 
Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
0
johnl (129)
7/24/2012 7:29:25 PM
On Jul 24, 2:23=A0pm, Anne & Lynn Wheeler <l...@garlic.com> wrote:

> 3031 was two 370/158 engines, one dedicated to "channel director"
> running just the integrated channel microcode and another engine running
> just the 370 microcode (a 3031 multiprocessor being four 370/158
> engines, two channel directors and two 370 processor).

Did the 3031 actually use recycled circuits out of old 158's, or was
it new gear merely manufactured per 158 design and incorporated in a
bigger box?

From the description on the IBM website, it seems that the 3031 was
new technology given the improved storage and execution techinques.
http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP3031.html


> 3033 started out being 370/168 logic remapped to 20% faster chips that
> also had 10times circuits/chip ... extra circuits originally gone
> unused. during development there was some remapping of logic to
> consolidate more onchip operations ... eventually getting 3033 up to
> nearly 50% faster than 168. 3033 also used the channel director for its
> i/o.

It sounds like 3033 was all new hardware, even if some of it use an
older design.



0
hancock4 (224)
7/24/2012 7:38:13 PM
In comp.lang.pl1 hancock4@bbs.cpcn.com wrote:

(snip on printers)

> Back then, computers and labor to run them were so expensive that
> paper costs just got buried in the overall costs.  Computer centers
> and programmers used to waste tremendous amounts of paper.  Efforts to
> conserve (eg reuse of reports for printing on the back side* and
> crowded 8 lines per inch) were limited to avoid confusion.

I do remember 1403 printouts being reused as paper for 2714s.

For debugging, it was usual to print out the whole source
listing with each compilation, along with the storage map
and such. 

With WYLBUR, it was usual to fetch the output, and look it
over before printing, or purge it if not needed.

> Of course, invoices and notices back then tended to be smaller than
> what is printed today.  Our phone bill in that era was a single slip
> of paper, service & equipment on the left side, toll calls on the
> right side.  Our electric bill was a postcard, name/address on the
> right, KWHrs and amount due on the left.

Many were on IBM punched cards!

> For whatever reason, electric and telephone bills are much more
> complex.  (Mine runs many pages even _without_ call itemization.)

Most likely, change in regulations.

> Later on xeroxography printing came out (we had high speed mediocre
> quality Xerox printers in 1979), which saved some paper costs.

> When personal computers hit the office, paper consumption went way up
> for a number of years.

I remember 5000 line (default) print limits, and at least some
that printed more than they were supposed to, until the limit
was reached.

-- glen
0
gah (12851)
7/24/2012 7:58:53 PM
hancock4@bbs.cpcn.com writes:
> Did the 3031 actually use recycled circuits out of old 158's, or was
> it new gear merely manufactured per 158 design and incorporated in a
> bigger box?
>
> From the description on the IBM website, it seems that the 3031 was
> new technology given the improved storage and execution techinques.
> http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP3031.html

re:
http://www.garlic.com/~lynn/2012j.html#91 printer history Languages influenced by PL/1

the 370/158 engine manufacturing line had achieved an astonishing level
of efficiency ... incremental cost of every additional 370/158 of the
line was unbelievably small (imagine some of the old numbers for
incremental cost of building additional automobile).

note 370/168-1 to 370/168-3 was similar doubling of cache size also
.... but resulted in significant problems. the bit chosen for indexing
additional cache lines was the 2k bit ... and therefor when 370/168-3
was running in 2k-byte page mode (dos/vs, vs1) ... it only used half the
cache (because the 2k bit was now part of the virtual address ... all
the othere cache index bits were low-order bits which were the same in
both virtual and real address). As a result for dos/vs & vs1, 168-3 had
the same performance as 168-1. The problem was even worse for vm370
running either dos/vs &/or vs1 in virtual machine. vm370 normally used
4k-byte page mode logic ... which used the full 32kbyte cache. However,
when switching to dos/vs or vs1 virtual machine running with 2k-byte
pages ... it used 2k-byte "shadow" tables. In the switch between 4k-byte
and 2k-byte virtual page mode ... there would be full cache flush
because of the different mapping ... with dos/vs & vs1 running under
vm370 ... this would be happening at very high frequency ... some number
of vm370 customers (running dos/vs &/or vs1) complained upgrading from
168-1 to 168-3 ... performance degrading to worse than 168-1.

something similar would happen for doubling cache for 158-3 to 3031.

the remapping of 168-3 logic to newer/faster chips started out 20%
faster than 168-3 for 3033 .... but eventually some logic tuning got it
up to 50% faster ... 168-3 was approx. 3mip machine and 3033 was
approx. 4.5mip machine (depending on typical application cache hit
ratios).

as sowa's references 3081 was kludged FS machine using the FS machine
370 emulator (enormous increase in number of circuits compared to all
other 370 machine implementations regardless of the vendor).
http://www.jfsowa.com/computer/memo125.htm

First 3081 out the door was 3081-D with supposedly two five-mip
processors ... but lots of benchmarks had 3081-d processors running
slower than 3033. Then similar to 168-1 to 168-3, amount of cache was
doubled for 3081-K which supposedly resulting in two 7mip processors
(i.e. larger cache, results in lower cache miss / higher cache hit
ratios ... increasing the effective instruction execution rate ...  aka
fewer instruction stall from cache miss waiting for storage). However,
some number of benchmarks had 3081-K processor about the same or ownly
slightly faster than 3033 processor.

-- 
virtualization experience starting Jan1968, online at home since Mar1970
0
lynn13 (400)
7/24/2012 8:46:32 PM
On 7/23/2012 7:58 PM, Howard S Shubs wrote:
> In article <jukk4v$2tcp$1@leila.iecc.com>, John Levine <johnl@iecc.com>
> wrote:
>
>> Not really.  You could attac some 360 type peripherals to it, such as
>> the 1442 and 2501 card readers and 1403 printer, but the internal
>> organization was entirely different and none of the peripherals other
>> than the 1132 spoke EBCDIC.  There was a modest operating system that
>> could run stacked Fortran and assembler jobs, and a program library.
>
> It was compatible with the 360 in that the same programs would run on
> it, within limitations.

Impossible.  It had a totally incompatible architecture, an accumulator, 
and three index registers instead of GPRs.  It was (16-bit) 
word-addressed instead of byte addressed.  Probably APL programs could 
run unchanged, and the FORTRAN was somewhat similar, but that's it.

-- 
Pete
0
Peter_Flass (956)
7/24/2012 11:10:54 PM
On 7/24/2012 6:50 AM, Shmuel (Seymour J.) Metz wrote:
> In <howard-914DA3.17582923072012@news.giganews.com>, on 07/23/2012
>     at 05:58 PM, Howard S Shubs <howard@shubs.net> said:
>
>> Consider what they were comparing it to.
>
> I believe that John's point was that they were only comparing it to
> other slow machines. There were faster machines on the market long
> before the 1130.

How did the prices compare.  I seem to recall that the 1130 leased for 
$1000/mo when it was introduced.  If this is right, at $12,000 a year it 
was a very affordable machine.


-- 
Pete
0
Peter_Flass (956)
7/24/2012 11:18:03 PM
On 7/24/2012 3:20 PM, John Levine wrote:
>> The 1130 Fortran had a few limitations, such as not allowing logical
>> IF statements.  But otherwise a modest sized Fortran program could be
>> recompiled and run on the 1130 without change, and the reverse.
>
> Yes, I know, the first program I ever wrote was a quadratic equation
> solver on an 1130.
>
> But you could say that about any computer.  You could recompile your
> 360 Fortran programs on a PDP-6 with minimal changes (its compiler had
> a lot in common with Fortran G) but nobody would say a PDP-6 was in
> any way compatible with a 360.

Before C, FORTRAN was the universal language.  If you wanted to write a 
portable program, you used FORTRAN.


-- 
Pete
0
Peter_Flass (956)
7/24/2012 11:24:17 PM
"glen herrmannsfeldt" wrote:

> I do remember 1403 printouts being reused as paper for 2714s.

I'm assuming a typo there...the popular terminal was the 2741, which was 
essentially a remote Selectric.  I've still got some typeballs I grabbed as 
the last one went out the door...some still in a sealed box, others with the 
infamous "chipped tooth" disease.

Joe 


0
j.c.morris (65)
7/25/2012 12:40:44 AM
On Jul 24, 4:46=A0pm, Anne & Lynn Wheeler <l...@garlic.com> wrote:

> the 370/158 engine manufacturing line had achieved an astonishing level
> of efficiency ... incremental cost of every additional 370/158 of the
> line was unbelievably small (imagine some of the old numbers for
> incremental cost of building additional automobile).

So, if I understand this correctly, they just merely kept building
more CPU units since it was cheap to do so, rather than re-using old
ones.

The workings of the cache and virtual addressing was amazingly
complex.  How they could write an operating system and micro code to
track all the stuff is beyond me.  I once got a book explaining the
internals of modern Z series and the complexity is beyond belief.
Kind of downer when you're running an old simple program against a
small file.

0
hancock4 (224)
7/25/2012 1:52:31 AM
On Jul 24, 7:18=A0pm, Peter Flass <Peter_Fl...@Yahoo.com> wrote:

> How did the prices compare. =A0I seem to recall that the 1130 leased for
> $1000/mo when it was introduced. =A0If this is right, at $12,000 a year i=
t
> was a very affordable machine.

It's weird that one could probably get--for a small fraction of
$1,000--an old second-hand PC, a copy of QuickBasic, and a cheap
printer, and yet have more processing power and easier use than the
1130.  Heck, you might even get someone's cast off machine for free.

(I remember the first time I saw a PC in the trash--it was an OMG
moment.  I took it home--it was a 386 that more or less worked.  Now I
see scrap PCs and peripherals all the time and just ignore them.)
0
hancock4 (224)
7/25/2012 1:58:00 AM
On Jul 24, 7:24=A0pm, Peter Flass <Peter_Fl...@Yahoo.com> wrote:

> Before C, FORTRAN was the universal language. =A0If you wanted to write a
> portable program, you used FORTRAN.

Fortran was common for science and engineering applications; but COBOL
was the standard for business applications.

In the early days machine horsepower was limited, and even with
efficient compilers many users preferred to write in native assembler
language for a given machine.  Skilled assembler programmers could
take advantage of machine timing to maximize efficiency by overlap and
other tricks.  I think a good programmer on the IBM 1130 could
maximize I/O throughput by careful timing controls over I/O commands
so that each command was issued at the most opportune moment.  This
also could be done on the 1401.


What language(s) were most commonly used to program PDP machines,
especially in the early days?
0
hancock4 (224)
7/25/2012 2:04:29 AM
On Jul 24, 8:40=A0pm, "Joe Morris" <j.c.mor...@verizon.net> wrote:

> I'm assuming a typo there...the popular terminal was the 2741, which was
> essentially a remote Selectric. =A0I've still got some typeballs I grabbe=
d as
> the last one went out the door...some still in a sealed box, others with =
the
> infamous "chipped tooth" disease.

A business had a corporate 'yard sale' to get rid of old office
furniture and appliances.  I picked up a dual pitch Correcting
Selectric II typewriter for $1.00  It worked ok, a bit sluggish.  I
think it was $1,000 new.

I was thrilled to get it, but admittedly it soon fell into disuse--it
was just easier to use a word processor.  I haven't used it in a long
time.

0
hancock4 (224)
7/25/2012 2:08:22 AM
>What language(s) were most commonly used to program PDP machines,
>especially in the early days?

Depends on what machine and where.  There was a lot of assembler on the lower
end machines, and now forgotten languages like FOCAL which was sort of a stripped
down JOSS.

At Yale in 1970 on our PDP-10 there was a mix of assembler, Fortran,
Algol, BLISS (DEC's system programming language) and some locally
written stuff.

R's,
John


-- 
Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
0
johnl (129)
7/25/2012 2:15:09 AM
>> I believe that John's point was that they were only comparing it to
>> other slow machines. There were faster machines on the market long
>> before the 1130.
>
>How did the prices compare.  I seem to recall that the 1130 leased for 
>$1000/mo when it was introduced.  If this is right, at $12,000 a year it 
>was a very affordable machine.

It's hard to compare, since other vendors tended to sell their
computers rather than leasing them, but the purchase price for a PDP-7
was similar to that for an 1130.  The PDP-8 was famous for being the
first computer you could buy for under $20,000.

R's,
John
-- 
Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
0
johnl (129)
7/25/2012 2:17:05 AM
<hancock4@bbs.cpcn.com> wrote 
> Peter Flass <Peter_Fl...@Yahoo.com> wrote

>> Before C, FORTRAN was the universal language.  If you 
>> wanted to write a portable program, you used FORTRAN.

> Fortran was common for science and engineering applications; 
> but COBOL was the standard for business applications.
 
> In the early days machine horsepower was limited, and even with
> efficient compilers many users preferred to write in native assembler
> language for a given machine.  Skilled assembler programmers could
> take advantage of machine timing to maximize efficiency by overlap and
> other tricks.  I think a good programmer on the IBM 1130 could
> maximize I/O throughput by careful timing controls over I/O commands
> so that each command was issued at the most opportune moment.  This
> also could be done on the 1401.

> What language(s) were most commonly used to 
> program PDP machines, especially in the early days?

Mostly assembler. Some use of Focal, similar to Basic. Basic later. 

Lots of Fortran later.  
0
rod.speed.aaa (1275)
7/25/2012 3:31:15 AM
On Jul 20, 2:22=A0am, John W Kennedy <jwke...@attglobal.net> wrote:
> On 2012-07-19 00:19:50 +0000, rrrrrrr...@gmail.com said:
>
> > On Thursday, 19 July 2012 09:48:21 UTC+10, John W Kennedy =A0wrote:
> >> On 2012-07-18 17:55:36 +0000, glen herrmannsfeldt said:
>
> >> > If a procedure/method only references one structure/object,
> >> > then, at least to me, the anonymous pointer/this object seems
> >> > to make things more readable. At two it is pretty questionable,
> >> > and more than that tends to be less readable.
>
> >> It eliminates all possibility of static checking.
>
> > Which is?
>
> Catching programming errors at compile time instead of at run time, of co=
urse.

Which is what the compiler does with any pointer code.
0
robin.vowels (428)
7/25/2012 5:20:37 AM
On Jul 21, 1:31=A0am, John W Kennedy <jwke...@attglobal.net> wrote:
> On 2012-07-20 01:25:29 +0000, robin.vow...@gmail.com said:
>
>
>
>
>
>
>
>
>
> > On Friday, 20 July 2012 02:24:01 UTC+10, John W Kennedy =A0wrote:
> >> On 2012-07-19 00:14:44 +0000, zzzzzz...@gmail.com said:
>
> >> &gt; On Thursday, 19 July 2012 09:54:46 UTC+10, John W Kennedy =A0wrot=
e:
> >> &gt;&gt; On 2012-07-18 23:30:10 +0000, xxxxxxxxx...@gmail.com said:
> >> &gt;&gt;
> >> &gt;&gt;&gt; On Thursday, 19 July 2012 01:22:21 UTC+10, John W Kennedy=
 =A0wrote:
> >> &gt;
> >> &gt;&gt;&gt;&gt;&gt;&gt; Locate-mode I/O doesn&#39;t really exist
> >> anymore, except in OS/360 (and
> >> &gt;&gt;&gt;&gt;&gt;&gt; DOS/360) legacy features -- unless you count
> >> data-in-virtual.
> >> &gt;&gt; &amp;gt;&amp;gt;
> >> &gt;&gt; &amp;gt;&amp;gt;&amp;gt; Locate mode still exists, even on Wi=
ndows.
> >> &gt;&gt; &amp;gt;&amp;gt;
> >> &gt;&gt;&gt;&gt; No, it doesn&#39;t.
> >> &gt;&gt;
> >> &gt;&gt;&gt; Have a look at SC14-7285-01 (for AIX, Enterprise, Windows=
),
> >>>>> and SC26-8003.
>
> >>>> Those are IBM manuals describing PL/I,
>
> >>> That's what counts.
>
> >> PL/I is not Windows. Windows is not PL/I. Apparently this is radical
> >> concept to you, but I assure you, it's true.
>
> > Look in any PL/I manual.
>
> >>>> not Microsoft manuals describing
> >>>> Windows. Windows does not have locate mode, and never did (and neith=
er
> >>>> did OS/2).
>
> >>> Read the manual.
>
> >> Since PL/I manuals do not describe Windows, there is no point to that.
>
> > Look in the index of cited PL/I manual for "LOCATE statement".
> > Then look at the referenced page for an enlightening
> > description.
>
> It says nothing about Windows APIs,

API's now?  I'm speaking about LOCATE mode in PL/I,
where the LOCATE statement is provided.

> because it is not a Windows manual.
> Windows does not have locate mode, and never did.

I never said it did.
Windows PL/I does.
0
robin.vowels (428)
7/25/2012 5:25:18 AM
On Jul 21, 2:07=A0am, John W Kennedy <jwke...@attglobal.net> wrote:
> On 2012-07-20 09:17:03 +0000, robin.vow...@gmail.com said:
>
>
>
>
>
>
>
>
>
> > On Friday, 20 July 2012 14:50:58 UTC+10, glen herrmannsfeldt =A0wrote:
> >> rrrrrr...@gmail.com wrote:
>
> >> (snip)
> >> &gt; The 1403 was a tad slow.
> >> &gt; For that kind of work, a drum printer would have been better,
> >> &gt; typically giving 1150-1250 LPM.
>
> >> The drum printers I knew were a lot slower than that, but they
> >> were upper and lower case.
>
> >> A 1403 with a numeric (and a few other characters) train is
> >> very fast.
>
> > Without alphabetic characters, such a train was for specialized
> > purposes and was not generally useful.
>
> >> With QN or PN, reasonably fast,
>
> > but not when many characters per line were printed.
>
> Wrong.
>
> > Furthermore, the trains wore out very quickly.
>
> Not even once, in my experience, though I'm sure it happened from time to=
 time.
>
> >> and with TN not so fast.
>
> > Woefully slow, less than 200 lpm.
>
> No, 270 lpm at the worst, and that only on the already obsolescent
> 1403-2. The 1403-N1, which was the de-facto standard 360 printer,
> printed the TN train at 552 lpm at the worst.

Definitely not.
That might be a theoretical maximum (one character per line printing
'A's or some such).

You only needed to watch (hear) the /360 printer labor though
output with the text train.

0
robin.vowels (428)
7/25/2012 5:30:18 AM
On Jul 25, 9:24=A0am, Peter Flass <Peter_Fl...@Yahoo.com> wrote:
> On 7/24/2012 3:20 PM, John Levine wrote:
>
> >> The 1130 Fortran had a few limitations, such as not allowing logical
> >> IF statements. =A0But otherwise a modest sized Fortran program could b=
e
> >> recompiled and run on the 1130 without change, and the reverse.
>
> > Yes, I know, the first program I ever wrote was a quadratic equation
> > solver on an 1130.
>
> > But you could say that about any computer. =A0You could recompile your
> > 360 Fortran programs on a PDP-6 with minimal changes (its compiler had
> > a lot in common with Fortran G) but nobody would say a PDP-6 was in
> > any way compatible with a 360.
>
> Before C, FORTRAN was the universal language. =A0If you wanted to write a
> portable program, you used FORTRAN.

That's debateable, as there were many flavours of FORTRAN.
Some might argue that COBOL was.

0
robin.vowels (428)
7/25/2012 5:51:16 AM
Robin Vowels <robin.vowels@gmail.com> wrote 
> Peter Flass <Peter_Fl...@Yahoo.com> wrote
>> John Levine wrote

>>>> The 1130 Fortran had a few limitations, such as not allowing logical
>>>> IF statements.  But otherwise a modest sized Fortran program could 
>>>> be recompiled and run on the 1130 without change, and the reverse.

>>> Yes, I know, the first program I ever wrote was a quadratic equation
>>> solver on an 1130.

>>> But you could say that about any computer.  You could recompile your
>>> 360 Fortran programs on a PDP-6 with minimal changes (its compiler had
>>> a lot in common with Fortran G) but nobody would say a PDP-6 was in
>>> any way compatible with a 360.

>> Before C, FORTRAN was the universal language.  If you wanted to write a
>> portable program, you used FORTRAN.
 
> That's debateable, as there were many flavours of FORTRAN.

Not that many at a particular time, and if you wanted a portable
program, you could always just use the portable subset that was
common to all the common ones. 

> Some might argue that COBOL was.

Sure, particularly for business stuff. But it was 
never that commonly used on DEC hardware.  
0
rod.speed.aaa (1275)
7/25/2012 7:09:46 AM
In article <juna1v$ftk$1@dont-email.me>,
 Peter Flass <Peter_Flass@Yahoo.com> wrote:

> On 7/23/2012 7:58 PM, Howard S Shubs wrote:
> > In article <jukk4v$2tcp$1@leila.iecc.com>, John Levine <johnl@iecc.com>
> > wrote:
> >
> >> Not really.  You could attac some 360 type peripherals to it, such as
> >> the 1442 and 2501 card readers and 1403 printer, but the internal
> >> organization was entirely different and none of the peripherals other
> >> than the 1132 spoke EBCDIC.  There was a modest operating system that
> >> could run stacked Fortran and assembler jobs, and a program library.
> >
> > It was compatible with the 360 in that the same programs would run on
> > it, within limitations.
> 
> Impossible.  It had a totally incompatible architecture, an accumulator, 
> and three index registers instead of GPRs.  It was (16-bit) 
> word-addressed instead of byte addressed.  Probably APL programs could 
> run unchanged, and the FORTRAN was somewhat similar, but that's it.

Compiled or interpreted languages could be portable, within capacity 
limits, I suppose. One could write a Forth system that could run on 
both for example.

Is there a generally available Forth for the 360 et. al. systems?

-- 
This space unintentionally left blank.
0
proto (1924)
7/25/2012 10:32:31 AM
In article <junar1$ftk$3@dont-email.me>,
 Peter Flass <Peter_Flass@Yahoo.com> wrote:

> On 7/24/2012 3:20 PM, John Levine wrote:
> >> The 1130 Fortran had a few limitations, such as not allowing logical
> >> IF statements.  But otherwise a modest sized Fortran program could be
> >> recompiled and run on the 1130 without change, and the reverse.
> >
> > Yes, I know, the first program I ever wrote was a quadratic equation
> > solver on an 1130.
> >
> > But you could say that about any computer.  You could recompile your
> > 360 Fortran programs on a PDP-6 with minimal changes (its compiler had
> > a lot in common with Fortran G) but nobody would say a PDP-6 was in
> > any way compatible with a 360.
> 
> Before C, FORTRAN was the universal language.  If you wanted to write a 
> portable program, you used FORTRAN.

Or COBOL, if you need more capabilities. :)

-- 
This space unintentionally left blank.
0
proto (1924)
7/25/2012 10:35:14 AM
In article 
<7084d8a0-c34a-4e45-a107-5e909e8db5b5@v7g2000yqn.googlegroups.com>,
 hancock4@bbs.cpcn.com wrote:

> On Jul 24, 8:40�pm, "Joe Morris" <j.c.mor...@verizon.net> wrote:
> 
> > I'm assuming a typo there...the popular terminal was the 2741, which was
> > essentially a remote Selectric. �I've still got some typeballs I grabbed as
> > the last one went out the door...some still in a sealed box, others with the
> > infamous "chipped tooth" disease.
> 
> A business had a corporate 'yard sale' to get rid of old office
> furniture and appliances.  I picked up a dual pitch Correcting
> Selectric II typewriter for $1.00  It worked ok, a bit sluggish.  I
> think it was $1,000 new.
> 
> I was thrilled to get it, but admittedly it soon fell into disuse--it
> was just easier to use a word processor.  I haven't used it in a long
> time.

There were Selectrics with computer ports, IIRC RS 232 or compatible. 
We used them at a major NYC bank for writing form letters to 
presidents of foreign banks (driven by Trash 80s). It would have been 
unthinkable to use dot matrix print of the day for such correspondence.

And of course, writing technical documentation as sending it to the 
typing puddle just produced gibberish.

-- 
This space unintentionally left blank.
0
proto (1924)
7/25/2012 10:46:21 AM
In comp.lang.pl1 Anne & Lynn Wheeler <lynn@garlic.com> wrote:

(snip)
> note 370/168-1 to 370/168-3 was similar doubling of cache size also
> ... but resulted in significant problems. the bit chosen for indexing
> additional cache lines was the 2k bit ... and therefor when 370/168-3
> was running in 2k-byte page mode (dos/vs, vs1) ... it only used half the
> cache (because the 2k bit was now part of the virtual address ... all
> the othere cache index bits were low-order bits which were the same in
> both virtual and real address). 

I have had VM/370 running on the P/370, with the 4K key 
feature (sic).  That likely fails if it ever tries to run
with 2K byte pages. (To do that, you have to set bit 7 in all
the values to be loaded into CR0.)

-- glen
0
gah (12851)
7/25/2012 10:51:17 AM
In <junafb$ftk$2@dont-email.me>, on 07/24/2012
   at 07:18 PM, Peter Flass <Peter_Flass@Yahoo.com> said:

>How did the prices compare.

I'm not sure; some of the alternative vendors were gone. Does anybody
have prices on the small machines from, e.g., DEC, PB, SDS, TRW? For
that matter, wasn't the UNIVAC 490[1] fairly inexpensive?

[1] And renumbered versions thereof.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
spamtrap16 (3722)
7/25/2012 12:12:27 PM
In <junar1$ftk$3@dont-email.me>, on 07/24/2012
   at 07:24 PM, Peter Flass <Peter_Flass@Yahoo.com> said:

>Before C, FORTRAN was the universal language.

Algol is divided in three parts. For that matter, so were COBOL and
Pascal.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
spamtrap16 (3722)
7/25/2012 12:14:33 PM
In <proto-D57745.06462125072012@news.panix.com>, on 07/25/2012
   at 06:46 AM, Walter Bushell <proto@panix.com> said:

>There were Selectrics with computer ports, IIRC RS 232 or compatible.

The unbuffered IBM 2741 and its clones were fairly common for use with
time-sharing systems, but I'd wait for a 3270 rather than endure the
available 2741; it was just too slow. The buffered 2740 and 1050 may
have been more common in business applications.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
spamtrap16 (3722)
7/25/2012 12:27:53 PM
Robin Vowels wrote:
> On Jul 25, 9:24 am, Peter Flass <Peter_Fl...@Yahoo.com> wrote:
>> On 7/24/2012 3:20 PM, John Levine wrote:
>>
>> >> The 1130 Fortran had a few limitations, such as not allowing logical
>> >> IF statements.  But otherwise a modest sized Fortran program could be
>> >> recompiled and run on the 1130 without change, and the reverse.
>>
>> > Yes, I know, the first program I ever wrote was a quadratic equation
>> > solver on an 1130.
>>
>> > But you could say that about any computer.  You could recompile your
>> > 360 Fortran programs on a PDP-6 with minimal changes (its compiler had
>> > a lot in common with Fortran G) but nobody would say a PDP-6 was in
>> > any way compatible with a 360.
>>
>> Before C, FORTRAN was the universal language.  If you wanted to write a
>> portable program, you used FORTRAN.
>
> That's debateable, as there were many flavours of FORTRAN.

No.  FORTRAN had a standard and, if a company wanted to sell anything
to the Federal government, they had to pass the Navy tests.  Each
manufacturer may have had extensions to the standard but those were not
used if you wanted to move the program to another platform.

> Some might argue that COBOL was.
>
Until DATE became a reserved word.

/BAH
0
See.above (172)
7/25/2012 12:33:43 PM
Rod Speed wrote:
> Robin Vowels <robin.vowels@gmail.com> wrote
>> Peter Flass <Peter_Fl...@Yahoo.com> wrote
>>> John Levine wrote
>
>>>>> The 1130 Fortran had a few limitations, such as not allowing logical
>>>>> IF statements.  But otherwise a modest sized Fortran program could
>>>>> be recompiled and run on the 1130 without change, and the reverse.
>
>>>> Yes, I know, the first program I ever wrote was a quadratic equation
>>>> solver on an 1130.
>
>>>> But you could say that about any computer.  You could recompile your
>>>> 360 Fortran programs on a PDP-6 with minimal changes (its compiler had
>>>> a lot in common with Fortran G) but nobody would say a PDP-6 was in
>>>> any way compatible with a 360.
>
>>> Before C, FORTRAN was the universal language.  If you wanted to write a
>>> portable program, you used FORTRAN.
>
>> That's debateable, as there were many flavours of FORTRAN.
>
> Not that many at a particular time, and if you wanted a portable
> program, you could always just use the portable subset that was
> common to all the common ones.
>
>> Some might argue that COBOL was.
>
> Sure, particularly for business stuff. But it was
> never that commonly used on DEC hardware.

STrange.  We made money selling COBOL compilers.

/BAH
0
See.above (172)
7/25/2012 12:33:44 PM
Peter Flass wrote:
> On 7/24/2012 3:20 PM, John Levine wrote:
>>> The 1130 Fortran had a few limitations, such as not allowing logical
>>> IF statements.  But otherwise a modest sized Fortran program could be
>>> recompiled and run on the 1130 without change, and the reverse.
>>
>> Yes, I know, the first program I ever wrote was a quadratic equation
>> solver on an 1130.
>>
>> But you could say that about any computer.  You could recompile your
>> 360 Fortran programs on a PDP-6 with minimal changes (its compiler had
>> a lot in common with Fortran G) but nobody would say a PDP-6 was in
>> any way compatible with a 360.
>
> Before C, FORTRAN was the universal language.  If you wanted to write a
> portable program, you used FORTRAN.

Yes.  If you wanted to write a compatible FORTRAN program, say between
the PDP-10 and IBM, you did not use the extensions which were documented
in the FORTRAN manual in blue.

But you did have to recompile.  EXEs were not portable between
manufacturers.

/BAH
0
See.above (172)
7/25/2012 12:33:48 PM
hancock4@bbs.cpcn.com writes:
> So, if I understand this correctly, they just merely kept building
> more CPU units since it was cheap to do so, rather than re-using old
> ones.
>
> The workings of the cache and virtual addressing was amazingly
> complex.  How they could write an operating system and micro code to
> track all the stuff is beyond me.  I once got a book explaining the
> internals of modern Z series and the complexity is beyond belief.
> Kind of downer when you're running an old simple program against a
> small file.

re:
http://www.garlic.com/~lynn/2012j.html#91 printer history Languages influenced by PL/1
http://www.garlic.com/~lynn/2012j.html#92 printer history Languages influenced by PL/1

redoing manufacturing line can be major expense ... and the first one
off the line is really costly ... if you expense the whole line on the
price of that first unit. however, every incremental unit off the line
approaches the cost of the raw materials.

manual costs to refurbish an old unit can be greater than just running
automated line for new one.

modern day computer chips can have billions of circuits and enormously
complex and the upfront design cost to design such a new chip can be
significant. also, building new fab for latest smaller circuits can be
over billion dollars for each newer generation. then things are setup to
turn out billions of such chips ... once the intial investment is
recovered ... then incremental cost for each additional chip is
relatively small.

current generation, maximum configured z196 with 80 processor goes for
$28M and is rated at 50BIPS. by comparison, e5-2600 ($560,000/BIPS) is
rated at 527BIPS and IBM lists base price at $1815 for e5-2600 blade
(i.e. e5-2600 server blade has over ten times the processing power of
fully configured z196 and $3.44/BIPS).

I would claim that z196 and e5 chips are relatively equivalent
complexity and (incremental) manufacturing cost. Recent annual
"mainframe" revenue seems to about the equivalent of 130-140 fully
configured z196 systems.

The big cloud mega-datacenters are doing hundreds of thousands
of server blades ... each.

misc. past posts mentioning z196 &/or e5-2600
http://www.garlic.com/~lynn/2012.html#20 21st Century Migrates Mainframe with Clerity
http://www.garlic.com/~lynn/2012.html#23 21st Century Migrates Mainframe with Clerity
http://www.garlic.com/~lynn/2012.html#24 21st Century Migrates Mainframe with Clerity
http://www.garlic.com/~lynn/2012.html#56 IBM researchers make 12-atom magnetic memory bit
http://www.garlic.com/~lynn/2012.html#59 IBM's z196 Article at RWT
http://www.garlic.com/~lynn/2012.html#78 Has anyone successfully migrated off mainframes?
http://www.garlic.com/~lynn/2012.html#80 Article on IBM's z196 Mainframe Architecture
http://www.garlic.com/~lynn/2012.html#90 Has anyone successfully migrated off mainframes?
http://www.garlic.com/~lynn/2012.html#91 Has anyone successfully migrated off mainframes?
http://www.garlic.com/~lynn/2012b.html#28 New IBM mainframe instructions
http://www.garlic.com/~lynn/2012b.html#30 New IBM mainframe instructions
http://www.garlic.com/~lynn/2012b.html#41 Are rotating register files still a bad idea?
http://www.garlic.com/~lynn/2012b.html#57 Has anyone successfully migrated off mainframes?
http://www.garlic.com/~lynn/2012d.html#2 NASA unplugs their last mainframe
http://www.garlic.com/~lynn/2012d.html#35 Layer 8: NASA unplugs last mainframe
http://www.garlic.com/~lynn/2012d.html#41 Layer 8: NASA unplugs last mainframe
http://www.garlic.com/~lynn/2012d.html#50 Layer 8: NASA unplugs last mainframe
http://www.garlic.com/~lynn/2012d.html#64 Layer 8: NASA unplugs last mainframe
http://www.garlic.com/~lynn/2012e.html#3 NASA unplugs their last mainframe
http://www.garlic.com/~lynn/2012e.html#4 Memory versus processor speed
http://www.garlic.com/~lynn/2012e.html#94 Can Mainframes Be Part Of Cloud Computing?
http://www.garlic.com/~lynn/2012e.html#99 Can Mainframes Be Part Of Cloud Computing?
http://www.garlic.com/~lynn/2012e.html#105 Burroughs B5000, B5500, B6500 videos
http://www.garlic.com/~lynn/2012f.html#0 Burroughs B5000, B5500, B6500 videos
http://www.garlic.com/~lynn/2012f.html#4 Can Mainframes Be Part Of Cloud Computing?
http://www.garlic.com/~lynn/2012f.html#7 Burroughs B5000, B5500, B6500 videos
http://www.garlic.com/~lynn/2012f.html#19 Can Mainframes Be Part Of Cloud Computing?
http://www.garlic.com/~lynn/2012g.html#36 Should IBM allow the use of Hercules as z system emulator?
http://www.garlic.com/~lynn/2012g.html#38 Should IBM allow the use of Hercules as z system emulator?
http://www.garlic.com/~lynn/2012h.html#4 Think You Know The Mainframe?
http://www.garlic.com/~lynn/2012h.html#20 Mainframes Warming Up to the Cloud
http://www.garlic.com/~lynn/2012h.html#35 Monopoly/ Cartons of Punch Cards
http://www.garlic.com/~lynn/2012h.html#52 How will mainframers retiring be different from Y2K?
http://www.garlic.com/~lynn/2012h.html#62 What are your experiences with Amdahl Computers and Plug-Compatibles?
http://www.garlic.com/~lynn/2012h.html#70 How many cost a cpu second?
http://www.garlic.com/~lynn/2012i.html#11 Can anybody give me a clear idea about Cloud Computing in MAINFRAME ?
http://www.garlic.com/~lynn/2012i.html#15 Can anybody give me a clear idea about Cloud Computing in MAINFRAME ?
http://www.garlic.com/~lynn/2012i.html#16 Think You Know The Mainframe?
http://www.garlic.com/~lynn/2012i.html#84 Can anybody give me a clear idea about Cloud Computing in MAINFRAME ?
http://www.garlic.com/~lynn/2012i.html#88 Can anybody give me a clear idea about Cloud Computing in MAINFRAME ?
http://www.garlic.com/~lynn/2012i.html#89 Can anybody give me a clear idea about Cloud Computing in MAINFRAME ?
http://www.garlic.com/~lynn/2012i.html#95 Can anybody give me a clear idea about Cloud Computing in MAINFRAME ?
http://www.garlic.com/~lynn/2012j.html#1 Can anybody give me a clear idea about Cloud Computing in MAINFRAME ?
http://www.garlic.com/~lynn/2012j.html#9 Can anybody give me a clear idea about Cloud Computing in MAINFRAME ?
http://www.garlic.com/~lynn/2012j.html#34 Can anybody give me a clear idea about Cloud Computing in MAINFRAME ?
http://www.garlic.com/~lynn/2012j.html#46 Word Length
http://www.garlic.com/~lynn/2012j.html#66 Monopoly/ Cartons of Punch Cards
http://www.garlic.com/~lynn/2012j.html#69 Monopoly/ Cartons of Punch Cards
http://www.garlic.com/~lynn/2012j.html#70 Monopoly/ Cartons of Punch Cards

-- 
virtualization experience starting Jan1968, online at home since Mar1970
0
lynn13 (400)
7/25/2012 1:18:50 PM
On 7/24/2012 9:52 PM, hancock4@bbs.cpcn.com wrote:
> On Jul 24, 4:46 pm, Anne & Lynn Wheeler <l...@garlic.com> wrote:
>
>> the 370/158 engine manufacturing line had achieved an astonishing level
>> of efficiency ... incremental cost of every additional 370/158 of the
>> line was unbelievably small (imagine some of the old numbers for
>> incremental cost of building additional automobile).
>
> So, if I understand this correctly, they just merely kept building
> more CPU units since it was cheap to do so, rather than re-using old
> ones.

I think there were legal restrictions involved, and probably tax 
implications.  You couldn't sell something as a "new" machine if it 
contained used parts.


-- 
Pete
0
Peter_Flass (956)
7/25/2012 2:13:25 PM
On Jul 25, 6:46=A0am, Walter Bushell <pr...@panix.com> wrote:

> There were Selectrics with computer ports, IIRC RS 232 or compatible.
> We used them at a major NYC bank for writing form letters to
> presidents of foreign banks (driven by Trash 80s). It would have been
> unthinkable to use dot matrix print of the day for such correspondence.

For many years IBM had Selectric-based word processors.  One used
magnetic tape (MTST 1964), the other used magnetic plastic cards (Mag
card 1969).  One application was the above.

http://www-03.ibm.com/press/us/en/pressrelease/35140.wss

http://www-03.ibm.com/ibm/history/ibm100/us/en/icons/selectric/
0
hancock4 (224)
7/25/2012 2:19:20 PM
On 7/25/2012 1:51 AM, Robin Vowels wrote:
> On Jul 25, 9:24 am, Peter Flass <Peter_Fl...@Yahoo.com> wrote:
>>
>> Before C, FORTRAN was the universal language.  If you wanted to write a
>> portable program, you used FORTRAN.
>
> That's debateable, as there were many flavours of FORTRAN.
> Some might argue that COBOL was.
>

If you were careful with either COBOL or FORTRAN you could have a fairly 
portable program, maybe needing only a few tweaks.  Of course I came 
from an academic environment, but I believe "shareware" COBOL programs 
were rarer than kangaroo wings.  Most portable compilers were written in 
FORTRAN, for example PL/M.

-- 
Pete
0
Peter_Flass (956)
7/25/2012 2:21:06 PM
On Jul 25, 10:21=A0am, Peter Flass <Peter_Fl...@Yahoo.com> wrote:

> If you were careful with either COBOL or FORTRAN you could have a fairly
> portable program, maybe needing only a few tweaks. =A0Of course I came
> from an academic environment, but I believe "shareware" COBOL programs
> were rarer than kangaroo wings. =A0Most portable compilers were written i=
n
> FORTRAN, for example PL/M.

IBM maintained a huge library of contributed application programs for
a business environment; this tradition goes way back.  It also had
science and engineering applications, too.  I think it was free to
anyone in those days*.

Whether it was better to modify someone else's system to fit your own
needs or to write it yourself was debatable.  The hospital I worked
for used IBM's hospital-oriented accounting systems (in-patient
billing, out-patient billing, general ledger, accounts payable) but
had its own payroll system.  They told me almost everyone used IBM's
hospital accounting systems.


*IBM software pricing back then was explained here once before, but I
forgot.  Our machine was leased from a third-party vendor so we were
not a formal full service "IBM Customer".  However, IBM provided
physical maintenance of the machine for a fee.  Some systems software
was free, some was rented at a modest charge.  For instance, the plain
simple COBOL D compiler was free, but we had to pay for the better
COBOL F compiler.
0
hancock4 (224)
7/25/2012 2:37:14 PM
On Jul 24, 7:18=A0pm, Peter Flass <Peter_Fl...@Yahoo.com> wrote:

> > I believe that John's point was that they were only comparing it to
> > other slow machines. There were faster machines on the market long
> > before the 1130.
>
> How did the prices compare. =A0I seem to recall that the 1130 leased for
> $1000/mo when it was introduced. =A0If this is right, at $12,000 a year i=
t
> was a very affordable machine.

FWIW, bitsavers has a 1971 mini-computer industry profile:
http://www.bitsavers.org/pdf/auerbach/Auerbach_Minicomputers_Mar71.pdf

0
hancock4 (224)
7/25/2012 3:12:47 PM

Peter Flass wrote:

> On 7/24/2012 9:52 PM, hancock4@bbs.cpcn.com wrote:
> > On Jul 24, 4:46 pm, Anne & Lynn Wheeler <l...@garlic.com> wrote:
> >
> >> the 370/158 engine manufacturing line had achieved an astonishing level
> >> of efficiency ... incremental cost of every additional 370/158 of the
> >> line was unbelievably small (imagine some of the old numbers for
> >> incremental cost of building additional automobile).
> >
> > So, if I understand this correctly, they just merely kept building
> > more CPU units since it was cheap to do so, rather than re-using old
> > ones.
>
> I think there were legal restrictions involved, and probably tax
> implications.  You couldn't sell something as a "new" machine if it
> contained used parts.

It got a lot more complex if they (IBM and others) leased a
product with an option to buy. They could put a product out on lease
that had recycled parts, the customer they would be purchasing
a product that may have re-cycled parts that was being maintained
up to the date of sale.

There were all sorts of business model implications in the early days
of computers. Lease costs could be written off against taxes, capital
purchases were depreciated and the annual depreciation could be
written off.

Software was leased for a while for the same reason.

I remember being in several tax battles because with rapid changes
in technology capital costs less depreciation left a capital asset that
was worth far less than its book value. Companies leased computers
because it made tax sense to do so. IBM and others provided leases
because they could control how customers used third party add ons
as well as need for that business model.

w..



0
walter20 (887)
7/25/2012 4:18:18 PM
["Followup-To:" header set to alt.folklore.computers.]
On 2012-07-24, hancock4@bbs.cpcn.com <hancock4@bbs.cpcn.com> wrote:
>
> Anyway, IBM ended up developing System/3 for small business needs.  It
> used modern technology and new ways of thinking to hold down costs.
> The tiny punched card meant the card reader and punch could be
> physically smaller which saved money.  The S/3 begat its own line of
> mini-computers (S/34, 36, 38, AS/400, i series) which remains
> successful to this day.

The new smaller card had 96 columns, which led to a great one-liner in
Datamation, something like "A new breakthrough in social equality - junk
mail for the Polish".

0
jhaynes (11)
7/25/2012 5:13:34 PM
jmfbahciv <See.above@aol.com> wrote
> Rod Speed wrote
>> Robin Vowels <robin.vowels@gmail.com> wrote
>>> Peter Flass <Peter_Fl...@Yahoo.com> wrote
>>>> John Levine wrote

>>>>>> The 1130 Fortran had a few limitations, such as not allowing logical
>>>>>> IF statements.  But otherwise a modest sized Fortran program could
>>>>>> be recompiled and run on the 1130 without change, and the reverse.

>>>>> Yes, I know, the first program I ever wrote was a quadratic equation
>>>>> solver on an 1130.

>>>>> But you could say that about any computer.  You could recompile your
>>>>> 360 Fortran programs on a PDP-6 with minimal changes (its compiler had
>>>>> a lot in common with Fortran G) but nobody would say a PDP-6 was in
>>>>> any way compatible with a 360.

>>>> Before C, FORTRAN was the universal language.  If you
>>>> wanted to write a portable program, you used FORTRAN.

>>> That's debateable, as there were many flavours of FORTRAN.

>> Not that many at a particular time, and if you wanted a
>> portable program, you could always just use the portable
>> subset that was common to all the common ones.

>>> Some might argue that COBOL was.

>> Sure, particularly for business stuff. But it was
>> never that commonly used on DEC hardware.

> STrange.

Nope.

> We made money selling COBOL compilers.

DEC made money selling Dibol. So what ?  It was never that common. 

0
rod.speed.aaa (1275)
7/25/2012 5:18:37 PM
In article <PM0004C5A694C4D8E1@ac8103f6.ipt.aol.com>,
jmfbahciv  <See.above@aol.com> wrote:
> Peter Flass wrote:
> > On 7/24/2012 3:20 PM, John Levine wrote:
> >>> The 1130 Fortran had a few limitations, such as not allowing logical
> >>> IF statements.  But otherwise a modest sized Fortran program could be
> >>> recompiled and run on the 1130 without change, and the reverse.
> >>
> >> Yes, I know, the first program I ever wrote was a quadratic equation
> >> solver on an 1130.
> >>
> >> But you could say that about any computer.  You could recompile your
> >> 360 Fortran programs on a PDP-6 with minimal changes (its compiler had
> >> a lot in common with Fortran G) but nobody would say a PDP-6 was in
> >> any way compatible with a 360.
> >
> > Before C, FORTRAN was the universal language.  If you wanted to write a
> > portable program, you used FORTRAN.
> 
> Yes.  If you wanted to write a compatible FORTRAN program, say between
> the PDP-10 and IBM, you did not use the extensions which were documented
> in the FORTRAN manual in blue.


Huh.  I wonder if the "in blue" was somehow standard -- I *think*
I remember finding the same convention used in IBM's documentation of
*its* FORTRAN compiler(s).


> But you did have to recompile.  EXEs were not portable between
> manufacturers.

-- 
B. L. Massingill
ObDisclaimer:  I don't speak for my employers; they return the favor.
0
blmblm (1302)
7/25/2012 7:18:37 PM
In comp.lang.pl1 jmfbahciv <See.above@aol.com> wrote:

(snip, someone wrote)
>> Before C, FORTRAN was the universal language.  If you wanted to write a
>> portable program, you used FORTRAN.

> Yes.  If you wanted to write a compatible FORTRAN program, say between
> the PDP-10 and IBM, you did not use the extensions which were documented
> in the FORTRAN manual in blue.

Well, DEC implemented many of the extensions from IBM Fortran IV.

While there was a Fortran 66 standard, IBM Fortran IV was more
often used as a de-facto standard.

The only reasonably large program I know claiming Fortran 66
compliance is the MORTRAN 2 processor. (It makes some assumptions
about what you can do with data read and written with A1 format,
but otherwise should work.)

-- glen
0
gah (12851)
7/25/2012 7:51:32 PM
In comp.lang.pl1 blmblm@myrealbox.com <blmblm.myrealbox@gmail.com> wrote:

(snip, someone wrote)
>> Yes.  If you wanted to write a compatible FORTRAN program, say between
>> the PDP-10 and IBM, you did not use the extensions which were documented
>> in the FORTRAN manual in blue.

> Huh.  I wonder if the "in blue" was somehow standard -- I *think*
> I remember finding the same convention used in IBM's documentation of
> *its* FORTRAN compiler(s).

IBM used gray shading over non-standard features.

Most often the shading survives scanning, though sometimes making
the underlying text hard to read. 

The DEC blue ink most often looks indistinguishable from black in
a scan, but in some cases might disappear. (In a blue only sensitive
scanner.)

(I have written to bitsavers about the bits being lost from this.)

-- glen
0
gah (12851)
7/25/2012 7:54:39 PM
On Jul 25, 12:18=A0pm, Walter Banks <wal...@bytecraft.com> wrote:

> I remember being in several tax battles because with rapid changes
> in technology capital costs less depreciation left a capital asset that
> was worth far less than its book value. Companies leased computers
> because it made tax sense to do so. IBM and others provided leases
> because they could control how customers used third party add ons
> as well as need for that business model.

In the old days, customers didn't merely lease a piece of hardware
from IBM, they leased IBM support and service which was bundled in,
which was a significant component of the cost.  After anti-trust
pressures arose, IBM changed its policy to be a la carte.

IBM liked leasing because it gave them a steady and solid revenue
stream.

A disadvantage to some customers was that they were paying for service
and support they might not have needed, whether they wanted it or
not.  As time went, some sophisticated customers may have been able to
do certain tasks for themselves at less cost than depending on IBM to
do it (or purchase services or software from other companies.)  The
change in policy caused a big growth in independent software
development houses.

This likewise applied to the old Bell System policy of leasing all
equipment.  Independent equipment makers, like Automatic Electric,
sold telephone equipment and many companies bought such gear for
internal intercom use.  Large customers wanted to buy their own
equipment, and entrapreneurs wanted to sell it to them, these factors
led first to Carterphone and then Divesture.  Of course, after
Divesture many companies had to hire telecom specialists to do what
the Bell System used to do for them, sometimes they hired their former
Bell System representative.  So, the net savings after Divesture were
fleeting.





0
hancock4 (224)
7/25/2012 7:59:53 PM
>There were Selectrics with computer ports, IIRC RS 232 or compatible. 

I once saw a thing that was sort of a Selectric sandwich.  To install
it, you'd unscrew the base of the typewriter, and this thing fit
between the base and the upper part.  It let you use the typewriter as
a computer printer, bur I don't think it sent the typewriter
keystrokes to the computer.

R's,
John
-- 
Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
0
johnl (129)
7/25/2012 8:19:42 PM
>No.  FORTRAN had a standard and, if a company wanted to sell anything
>to the Federal government, they had to pass the Navy tests.

I wrote a Fortran compiler that passed the Navy tests.  It wasn't very
hard.

Carefully written Fortran could be quite portable, but most Fortran
wasn't carefully written.

R's,
John
-- 
Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
0
johnl (129)
7/25/2012 8:21:44 PM
John Levine <johnl@iecc.com> writes:

> Carefully written Fortran could be quite portable, but most Fortran
> wasn't carefully written.

Sounds just like modern C.
0
blp (3955)
7/25/2012 8:36:02 PM
In comp.lang.pl1 Ben Pfaff <blp@cs.stanford.edu> wrote:
> John Levine <johnl@iecc.com> writes:

>> Carefully written Fortran could be quite portable, but most 
>> Fortran wasn't carefully written.

Because it was hard (tedious) to do.

I believe one of the more common extensions was to allow general
expressions in subscripts instead of the very limited form allowed
by the Fortran 66 standard.

Also, the H format descriptor was error prone if you weren't 
good at counting.

In Fortran 66 there is no way to detect end-of-file. You have to
have some indication in your input data that there isn't any more.

And always my favorite restriction lifted with Fortran 77, the
ability to put expressions in I/O lists and DO statements. 
(Avoids many temporary variables.)

> Sounds just like modern C.

It is true for C, but for different reasons.

It is so easy to assume twos complement, and files of 8 bit bytes.

Endianness also complicates writing portable C.

But with Fortran 66, you keep asking yourself why they didn't
make it easier, though the compiler will catch many of the mistakes
that you might be tempted to make.

-- glen

0
gah (12851)
7/25/2012 10:38:58 PM
Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> writes:
> The unbuffered IBM 2741 and its clones were fairly common for use with
> time-sharing systems, but I'd wait for a 3270 rather than endure the
> available 2741; it was just too slow. The buffered 2740 and 1050 may
> have been more common in business applications.

depends what you got use to ... all was half-duplex and one of the human
factors problems with the 3270 was that the keyboard was normally locked
.... so if you were trying to do interactive computing ... and happened
to be typing at the instant that the system decided to update the screen
....  things would lock up and would have to hit the reset button
.... destroying interactive computing rhythm. For 3272/3277 with the
electronics in the head ... it was possible to do some hacks ... one was
a FIFO box that fit inside the head, unplug the keyboard, plug in the
box and plug the keyboard into the box ... it would queue keystrokes it
the system wasn't ready to accept them at the particular moment ... it
was also possible to hack the keyboard to change the repeat key delay
and the repeat key rate.

3274/3278 move lots of electronics back into the (shared) controller
.... significantly slowing down things and eliminating possibility of
fixing the more annoying human factors (part of significantly reducing
the manufacturing cost of the terminal). we complained a lot to kingston
(communication group before they moved to raleigh) ... and eventually
got a responses that 3274/3278 wasn't designed for interactive computing
.... but for data-entry. much later PC terminal emulation with emalated
3277 card could do 3-4 times the upload/download speed of emulated 3278
card (significantly larger amount of coax protocol chatter between 3274
& 3278 because so much electronics had been moved back into the
controller).

early 80s comparison of 3272/3277 and 3274/3278 in this post
http://www.garlic.com/~lynn/2001m.html#19 3270 protocol

of course all of this was local channel attached controllers.

once accustomed to local channel attach 3272/3277 ... remote 3274 could
become unbearable. This came up when STL development lab was becoming
exceedingly croweded ... and they decided to move 300 people from the
IMS group to offsite building ... with remote access back to STL
datacenter. The IMS people was use to local vm370/cms channel attached
human factors and found the remote 3270 tests totally intolerable. I got
sucked into doing software for supporting channel extender (running over
microwave, collins digital radio) ... local channel simulation and local
channel attached controllers at the offsite building.

-- 
virtualization experience starting Jan1968, online at home since Mar1970
0
lynn13 (400)
7/25/2012 10:45:30 PM
On 7/25/2012 10:37 AM, hancock4@bbs.cpcn.com wrote:
> On Jul 25, 10:21 am, Peter Flass <Peter_Fl...@Yahoo.com> wrote:
>
>> If you were careful with either COBOL or FORTRAN you could have a fairly
>> portable program, maybe needing only a few tweaks.  Of course I came
>> from an academic environment, but I believe "shareware" COBOL programs
>> were rarer than kangaroo wings.  Most portable compilers were written in
>> FORTRAN, for example PL/M.
>
> IBM maintained a huge library of contributed application programs for
> a business environment; this tradition goes way back.  It also had
> science and engineering applications, too.  I think it was free to
> anyone in those days*.
>
> Whether it was better to modify someone else's system to fit your own
> needs or to write it yourself was debatable.  The hospital I worked
> for used IBM's hospital-oriented accounting systems (in-patient
> billing, out-patient billing, general ledger, accounts payable) but
> had its own payroll system.  They told me almost everyone used IBM's
> hospital accounting systems.

Probably not the 1130 programs, but my first job was working on the 1130 
"FDP" Hospital Patient Billing and Payroll systems,

-- 
Pete
0
Peter_Flass (956)
7/25/2012 10:55:35 PM
In article <proto-5F4E9A.06323125072012@news.panix.com>,
 Walter Bushell <proto@panix.com> wrote:

> In article <juna1v$ftk$1@dont-email.me>,
>  Peter Flass <Peter_Flass@Yahoo.com> wrote:
> 
> > On 7/23/2012 7:58 PM, Howard S Shubs wrote:
> > > In article <jukk4v$2tcp$1@leila.iecc.com>, John Levine <johnl@iecc.com>
> > > wrote:
> > >
> > >> Not really.  You could attac some 360 type peripherals to it, such as
> > >> the 1442 and 2501 card readers and 1403 printer, but the internal
> > >> organization was entirely different and none of the peripherals other
> > >> than the 1132 spoke EBCDIC.  There was a modest operating system that
> > >> could run stacked Fortran and assembler jobs, and a program library.
> > >
> > > It was compatible with the 360 in that the same programs would run on
> > > it, within limitations.
> > 
> > Impossible.  It had a totally incompatible architecture, an accumulator, 
> > and three index registers instead of GPRs.  It was (16-bit) 
> > word-addressed instead of byte addressed.  Probably APL programs could 
> > run unchanged, and the FORTRAN was somewhat similar, but that's it.
> 
> Compiled or interpreted languages could be portable, within capacity 
> limits, I suppose. One could write a Forth system that could run on 
> both for example.
> 
> Is there a generally available Forth for the 360 et. al. systems?

BTW Peter, I didn't say it was binary compatible.  I'm pretty sure I 
specified that it was kinda source compatible.

-- 
May joy be yours all the days of your life! - Phina
We are but a moment's sunlight, fading in the grass. - The Youngbloods
Those who eat natural foods die of natural causes. - Kperspective
0
howard578 (2138)
7/26/2012 3:23:16 AM
"John Levine" <johnl@iecc.com> wrote in message 
news:jupkgo$160n$3@leila.iecc.com...
> >No.  FORTRAN had a standard and, if a company wanted to sell anything
>>to the Federal government, they had to pass the Navy tests.
>
> I wrote a Fortran compiler that passed the Navy tests.  It wasn't very
> hard.
>
> Carefully written Fortran could be quite portable, but most Fortran
> wasn't carefully written.
>

ISTM that FORTRAN through the FORTRAN IV comilers... had *no* standard way 
to handle character data.  The character data was "fudged in" using 
different methods on different machines... and that lead to non-standard, 
incompatible programs.

--

numerist at aquaporin4 dot com

0
numerist (84)
7/26/2012 11:11:19 AM
In article <50101C4A.917133D2@bytecraft.com>,
 Walter Banks <walter@bytecraft.com> wrote:

> There were all sorts of business model implications in the early days
> of computers. Lease costs could be written off against taxes, capital
> purchases were depreciated and the annual depreciation could be
> written off.

And probably depreciation was far too slow.

-- 
This space unintentionally left blank.
0
proto (1924)
7/26/2012 11:13:49 AM
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message 
news:jupsi2$7ls$1@speranza.aioe.org...
> In comp.lang.pl1 Ben Pfaff <blp@cs.stanford.edu> wrote:
>> John Levine <johnl@iecc.com> writes:
>
>>> Carefully written Fortran could be quite portable, but most
>>> Fortran wasn't carefully written.
>
> Because it was hard (tedious) to do.
>
> I believe one of the more common extensions was to allow general
> expressions in subscripts instead of the very limited form allowed
> by the Fortran 66 standard.
>
> Also, the H format descriptor was error prone if you weren't
> good at counting.
>
> In Fortran 66 there is no way to detect end-of-file. You have to
> have some indication in your input data that there isn't any more.
>

So you just end your data with a "sentinel" value that could *not* occur in 
the data. The read loop checked for the sentinel and stopped reading data 
when the sentinel was found.

--

numerist at aquaporin4 dot com


0
numerist (84)
7/26/2012 11:15:09 AM
"jmfbahciv" <See.above@aol.com> wrote in message 
news:PM0004C5A694C4D8E1@ac8103f6.ipt.aol.com...
> Peter Flass wrote:
>> On 7/24/2012 3:20 PM, John Levine wrote:
>>>> The 1130 Fortran had a few limitations, such as not allowing logical
>>>> IF statements.  But otherwise a modest sized Fortran program could be
>>>> recompiled and run on the 1130 without change, and the reverse.
>>>
>>> Yes, I know, the first program I ever wrote was a quadratic equation
>>> solver on an 1130.
>>>
>>> But you could say that about any computer.  You could recompile your
>>> 360 Fortran programs on a PDP-6 with minimal changes (its compiler had
>>> a lot in common with Fortran G) but nobody would say a PDP-6 was in
>>> any way compatible with a 360.
>>
>> Before C, FORTRAN was the universal language.  If you wanted to write a
>> portable program, you used FORTRAN.
>
> Yes.  If you wanted to write a compatible FORTRAN program, say between
> the PDP-10 and IBM, you did not use the extensions which were documented
> in the FORTRAN manual in blue.
>
> But you did have to recompile.  EXEs were not portable between
> manufacturers.
>

The EXE's were *sometimes* portable... like between IBM 370's and Amdahl 
clones.  I guess that does *not* really count, though.

--

numerist at aquaporin4 dot com

0
numerist (84)
7/26/2012 11:16:58 AM
In comp.lang.pl1 Charles Richmond <numerist@aquaporin4.com> wrote:

(snip, someone wrote)
>> Carefully written Fortran could be quite portable, but most Fortran
>> wasn't carefully written.

> ISTM that FORTRAN through the FORTRAN IV comilers... had *no* standard way 
> to handle character data.  The character data was "fudged in" using 
> different methods on different machines... and that lead to non-standard, 
> incompatible programs.

Well, it is part of the standard, both Fortran 66 and the (different
versions of) IBM Fortran IV.

As well as I know it, the standard pretty much allows for reading
in alphanumeric data, and then writing it back out again.

It isn't so obvious that you can copy from one variable to another.
(REAL variables with unnormalized floating point values for one.
Integer values where not all bits in a word are significant, for
another.)

If you get past those, and then stretch to being able to compare
characters read in A1 format, it usually works.

-- glen
0
gah (12851)
7/26/2012 11:17:12 AM
In article 
<f8063d99-07fb-4a3f-82ae-e913767be5a5@q2g2000vbv.googlegroups.com>,
 hancock4@bbs.cpcn.com wrote:

> This likewise applied to the old Bell System policy of leasing all
> equipment.  Independent equipment makers, like Automatic Electric,
> sold telephone equipment and many companies bought such gear for
> internal intercom use.  Large customers wanted to buy their own
> equipment, and entrapreneurs wanted to sell it to them, these factors
> led first to Carterphone and then Divesture.  Of course, after
> Divesture many companies had to hire telecom specialists to do what
> the Bell System used to do for them, sometimes they hired their former
> Bell System representative.  So, the net savings after Divesture were
> fleeting.

Certainly not for home customers. I remember buying a phone and the 
amortization over renting it was amortized in months or was it much 
less? It was anyway a no brainer. And those rulings allowed us to 
connect directly to the phone line rather than using a acoustic 
coupler.

-- 
This space unintentionally left blank.
0
proto (1924)
7/26/2012 11:18:01 AM
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message 
news:jupio4$gm5$1@speranza.aioe.org...
> In comp.lang.pl1 jmfbahciv <See.above@aol.com> wrote:
>
> (snip, someone wrote)
>>> Before C, FORTRAN was the universal language.  If you wanted to write a
>>> portable program, you used FORTRAN.
>
>> Yes.  If you wanted to write a compatible FORTRAN program, say between
>> the PDP-10 and IBM, you did not use the extensions which were documented
>> in the FORTRAN manual in blue.
>
> Well, DEC implemented many of the extensions from IBM Fortran IV.
>
> While there was a Fortran 66 standard, IBM Fortran IV was more
> often used as a de-facto standard.
>
> The only reasonably large program I know claiming Fortran 66
> compliance is the MORTRAN 2 processor. (It makes some assumptions
> about what you can do with data read and written with A1 format,
> but otherwise should work.)
>

The FORTRAN compiler needs to be able to *compile* the MORTRAN 2 
processor... and also be able to compile the FORTRAN code that the MORTRAN 2 
processor produces.

Like the old TV and Radio show:  "Believe It... or Just Don't Think About 
It!"  ;-)  I mean this:  at a PPoE I worked on a military contract (we were 
actually sub-contractors... *not* at all unusual for military contracts) and 
we actually used MORTRAN 2 as the development language.  The FORTRAN 
compiler (it was a CDC compiler for a CDC machine) was actually a *subset* 
of FORTRAN IV... but the MORTRAN 2 worked with it.

One day I intend to *understand* the translation macros used by MORTRAN 2. 
ISTM that the SLAC documentation for MORTRAN 2 is on bitsavers.  If anyone 
here can explain the macros to me, I will be happy to post some of the 
macros here on <a.f.c.>.

--

numerist at aquaporin4 dot com

0
numerist (84)
7/26/2012 11:27:31 AM
John Levine wrote:
>>No.  FORTRAN had a standard and, if a company wanted to sell anything
>>to the Federal government, they had to pass the Navy tests.
>
> I wrote a Fortran compiler that passed the Navy tests.  It wasn't very
> hard.
>
> Carefully written Fortran could be quite portable, but most Fortran
> wasn't carefully written.


I remember that DEC's PDP-10 FORTRAN in 1969 could do disk I/O.
the compiler didn't "support" disk I/O as a standard...only cards.
So the way to fake card I/O was to issue the monitor commands:

ASSIGN DSK 5
ASSIGN DSK [my fingers have failed me; I can't remmeber the
            number IBM used for READ --1?]

Your FORTRAN program read a "card" from a file called FOR01.DAT
and wrote a "card" to a disk file called FOR05.DAT

/BAH
0
See.above (172)
7/26/2012 12:27:36 PM
Rod Speed wrote:
> jmfbahciv <See.above@aol.com> wrote
>> Rod Speed wrote
>>> Robin Vowels <robin.vowels@gmail.com> wrote
>>>> Peter Flass <Peter_Fl...@Yahoo.com> wrote
>>>>> John Levine wrote
>
>>>>>>> The 1130 Fortran had a few limitations, such as not allowing logical
>>>>>>> IF statements.  But otherwise a modest sized Fortran program could
>>>>>>> be recompiled and run on the 1130 without change, and the reverse.
>
>>>>>> Yes, I know, the first program I ever wrote was a quadratic equation
>>>>>> solver on an 1130.
>
>>>>>> But you could say that about any computer.  You could recompile your
>>>>>> 360 Fortran programs on a PDP-6 with minimal changes (its compiler had
>>>>>> a lot in common with Fortran G) but nobody would say a PDP-6 was in
>>>>>> any way compatible with a 360.
>
>>>>> Before C, FORTRAN was the universal language.  If you
>>>>> wanted to write a portable program, you used FORTRAN.
>
>>>> That's debateable, as there were many flavours of FORTRAN.
>
>>> Not that many at a particular time, and if you wanted a
>>> portable program, you could always just use the portable
>>> subset that was common to all the common ones.
>
>>>> Some might argue that COBOL was.
>
>>> Sure, particularly for business stuff. But it was
>>> never that commonly used on DEC hardware.
>
>> STrange.
>
> Nope.
>
>> We made money selling COBOL compilers.
>
> DEC made money selling Dibol. So what ?  It was never that common.

If it wasn't common, then there would not be many buying it.  If
not many bought it, DEC would not have been able to justify
developing it.

/BAH
0
See.above (172)
7/26/2012 12:27:42 PM
John Levine wrote:
>>No.  FORTRAN had a standard and, if a company wanted to sell anything
>>to the Federal government, they had to pass the Navy tests.
>
> I wrote a Fortran compiler that passed the Navy tests.  It wasn't very
> hard.

As long as you stayed with the standard, it shouldn't be very hard.
The operating time system (FOROTS) was harder.  Arithmetic, I/O and
other less-used aspects had to conform.

>
> Carefully written Fortran could be quite portable, but most Fortran
> wasn't carefully written.

AFAIK, not doing any of the blue-documented extensions would be OK.
I never tested it.

/BAH
0
See.above (172)
7/26/2012 12:27:44 PM
jmfbahciv <See.above@aol.com> writes:

> John Levine wrote:
>>>No.  FORTRAN had a standard and, if a company wanted to sell anything
>>>to the Federal government, they had to pass the Navy tests.
>>
>> I wrote a Fortran compiler that passed the Navy tests.  It wasn't very
>> hard.
>>
>> Carefully written Fortran could be quite portable, but most Fortran
>> wasn't carefully written.
>
>
> I remember that DEC's PDP-10 FORTRAN in 1969 could do disk I/O.
> the compiler didn't "support" disk I/O as a standard...only cards.
> So the way to fake card I/O was to issue the monitor commands:
>
> ASSIGN DSK 5
> ASSIGN DSK [my fingers have failed me; I can't remmeber the
>             number IBM used for READ --1?]

It was a "1" on IBN 1401 but a 1 is a Write command in a S/360
channel program.


-- 
Dan Espen
0
despen2 (232)
7/26/2012 12:37:27 PM
In <slrnk10a9u.2o7.jhaynes@Frances.localdomain>, on 07/25/2012
   at 12:13 PM, Jim Haynes <jhaynes@alumni.uark.edu> said:

>The new smaller card had 96 columns,

While it was marketed a 96-column, it was actually only 96-character.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
spamtrap16 (3722)
7/26/2012 1:00:29 PM
In <PM0004C5A6A0A8A2D9@ac8103f6.ipt.aol.com>, on 07/25/2012
   at 12:33 PM, jmfbahciv <See.above@aol.com> said:

>No.  FORTRAN had a standard

Not until late in the game.

>Federal government

Universal refers to more than the Federal Government.

>but those were not used if you wanted to move the program to 
>another platform.

So in some alternate universe where management told programmers to
write only portable code, it was portable. But in the real world
people used the extensions with gay abandon, in many cases not even
aware that they were using extensions.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
spamtrap16 (3722)
7/26/2012 1:04:57 PM
In <m3pq7jtq7p.fsf@garlic.com>, on 07/25/2012
   at 06:45 PM, Anne & Lynn Wheeler <lynn@garlic.com> said:

>depends what you got use to ... all was half-duplex

Including the 2741.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
spamtrap16 (3722)
7/26/2012 1:19:55 PM
On Jul 26, 7:18=A0am, Walter Bushell <pr...@panix.com> wrote:


[owning phones]
> Certainly not for home customers. I remember buying a phone and the
> amortization over renting it was amortized in months or was it much
> less? It was anyway a no brainer. And those rulings allowed us to
> connect directly to the phone line rather than using a acoustic
> coupler.

At the time of Divesture, the Bell System allowed customers to buy
their existing telephone sets at a very good price, much less than the
cost to manufacture them.  So yes, the amortization was pretty quick,
about a year.

There was no rental fee on the first telephone set that came with the
line; it was only on extension sets.

It should be noted that since those old Western Electric telephone
sets were intended for rental and company-provided maintenance, they
were carefully designed and manufacturered to be long-lasting and
maintenance free.  If repairs were needed, parts were modular and easy
to replace.  Indeed, many people still have such sets in use to this
day.  (Using rotary today with ten digit dialing and automated menus
and PBXs is cumbersome, and many users want fancy features that a
plain Touch Tone phone doesn't offer, like cordless, speed dialing,
speakerphone).

It also should be noted that the rental policy was desired by
regulators (applied to Independent Companies, too).  The profits from
rentals were used to offset the price of basic phone service--which
back then could be as low as $3/month for bare bones service.

After Divesture, other companies came out with telephone sets.  They
built much cheaper, sounded like crap, and were basically disposable.
If they fell off the table they were ruined.

The old Bell System provided phone-to-phone service and maintenance.
If there was a problem with your house wiring, they came out and fixed
it free.  Admittedly, this was rare, but it does occur from time to
time.  Today, if a subscriber has a problem, the legacy companies
aren't very helpful, and the newcomer companies are even less
helpful.  But apparently people prefer the present system to paying
the rentals every month.



0
hancock4 (224)
7/26/2012 2:49:46 PM

hancock4@bbs.cpcn.com wrote:

> (Using rotary today with ten digit dialing and automated menus
> and PBXs is cumbersome, and many users want fancy features that a
> plain Touch Tone phone doesn't offer, like cordless, speed dialing,
> speakerphone).

Bell Canada charges extra per month for touch tone phone support.
I have a friend whose home phone has a dial simply to make a point.
As long as he has to may more for touch tome phones the Bell switches
are going to need to decode pulse dialing. :)

w..


0
walter20 (887)
7/26/2012 3:10:41 PM
On Jul 26, 11:10=A0am, Walter Banks <wal...@bytecraft.com> wrote:
> hanco...@bbs.cpcn.com wrote:
> > (Using rotary today with ten digit dialing and automated menus
> > and PBXs is cumbersome, and many users want fancy features that a
> > plain Touch Tone phone doesn't offer, like cordless, speed dialing,
> > speakerphone).
>
> Bell Canada charges extra per month for touch tone phone support.
> I have a friend whose home phone has a dial simply to make a point.
> As long as he has to may more for touch tome phones the Bell switches
> are going to need to decode pulse dialing. :)

That is weird that Bell Canada still does that.  Does Canada have
competing local phone companies with their own switches that charge
differently?

Regular landline telephones still use the old DC hookswitch signalling
protocol*, so every central office requires a means to react to change
in hookswitch status.  The very same circuitry is used to detect dial
pulses which are just rapid hookswitch changes**.    Some modern PBX
switches are Touch Tone only.  VOIP is a whole other world.


* Also known as "common battery".

** People with skilled fingers can 'dial' by rapidly flashing the
hookswitch at the proper timing.  This was popular back in the days
when dials were locked to prevent unauthorized use.
0
hancock4 (224)
7/26/2012 5:09:37 PM
jmfbahciv <See.above@aol.com> wrote
> Rod Speed wrote
>> jmfbahciv <See.above@aol.com> wrote
>>> Rod Speed wrote
>>>> Robin Vowels <robin.vowels@gmail.com> wrote
>>>>> Peter Flass <Peter_Fl...@Yahoo.com> wrote
>>>>>> John Levine wrote

>>>>>>>> The 1130 Fortran had a few limitations, such as not allowing 
>>>>>>>> logical
>>>>>>>> IF statements.  But otherwise a modest sized Fortran program could
>>>>>>>> be recompiled and run on the 1130 without change, and the reverse.

>>>>>>> Yes, I know, the first program I ever wrote was a quadratic equation
>>>>>>> solver on an 1130.

>>>>>>> But you could say that about any computer.  You could recompile your
>>>>>>> 360 Fortran programs on a PDP-6 with minimal changes (its compiler 
>>>>>>> had
>>>>>>> a lot in common with Fortran G) but nobody would say a PDP-6 was in
>>>>>>> any way compatible with a 360.

>>>>>> Before C, FORTRAN was the universal language.  If you
>>>>>> wanted to write a portable program, you used FORTRAN.

>>>>> That's debateable, as there were many flavours of FORTRAN.

>>>> Not that many at a particular time, and if you wanted a
>>>> portable program, you could always just use the portable
>>>> subset that was common to all the common ones.

>>>>> Some might argue that COBOL was.

>>>> Sure, particularly for business stuff. But it was
>>>> never that commonly used on DEC hardware.

>>> STrange.

>> Nope.

>>> We made money selling COBOL compilers.

>> DEC made money selling Dibol. So what ?  It was never that common.

> If it wasn't common, then there would not be many buying it.

There werent. The costs werent that high, so it was possible to
make money even when it wasn’t.

Fortran was MUCH more common. Even Focal left both
for dead as far as how many bought it was concerned.

> If not many bought it, DEC would not
> have been able to justify developing it.

ALL they had to do was cover their costs and start making money on it.

It didn’t need to be common to do that. 

0
rod.speed.aaa (1275)
7/26/2012 5:29:16 PM
Walter Banks <walter@bytecraft.com> writes:
> Bell Canada charges extra per month for touch tone phone support.
> I have a friend whose home phone has a dial simply to make a point.
> As long as he has to may more for touch tome phones the Bell switches
> are going to need to decode pulse dialing. :)
>

Entertainingly enough, becuase register holding time for DP calls is
much, much longer than for TT calls, from an engineering perspective -
it costs MORE to offer DP ...

Not that the capital cost of registers is even a microscopic blip on the
radar of the cost model for a modern (post 1985) switch ... 

--L

0
7/26/2012 5:52:19 PM
On 26/07/2012 13:27, jmfbahciv wrote:
> Rod Speed wrote:
>> jmfbahciv <See.above@aol.com> wrote
>>> Rod Speed wrote
>>>> Robin Vowels <robin.vowels@gmail.com> wrote
>>>>> Peter Flass <Peter_Fl...@Yahoo.com> wrote
>>>>>> John Levine wrote
>>
>>>>>>>> The 1130 Fortran had a few limitations, such as not allowing logical
>>>>>>>> IF statements.  But otherwise a modest sized Fortran program could
>>>>>>>> be recompiled and run on the 1130 without change, and the reverse.
>>
>>>>>>> Yes, I know, the first program I ever wrote was a quadratic equation
>>>>>>> solver on an 1130.
>>
>>>>>>> But you could say that about any computer.  You could recompile your
>>>>>>> 360 Fortran programs on a PDP-6 with minimal changes (its compiler had
>>>>>>> a lot in common with Fortran G) but nobody would say a PDP-6 was in
>>>>>>> any way compatible with a 360.
>>
>>>>>> Before C, FORTRAN was the universal language.  If you
>>>>>> wanted to write a portable program, you used FORTRAN.
>>
>>>>> That's debateable, as there were many flavours of FORTRAN.
>>
>>>> Not that many at a particular time, and if you wanted a
>>>> portable program, you could always just use the portable
>>>> subset that was common to all the common ones.
>>
>>>>> Some might argue that COBOL was.
>>
>>>> Sure, particularly for business stuff. But it was
>>>> never that commonly used on DEC hardware.
>>
>>> STrange.
>>
>> Nope.
>>
>>> We made money selling COBOL compilers.
>>
>> DEC made money selling Dibol. So what ?  It was never that common.
>
> If it wasn't common, then there would not be many buying it.  If
> not many bought it, DEC would not have been able to justify
> developing it.
>
> /BAH
>

COBOL was a requirement for sales to the US Government.  That rule would 
have justified the writing of a COBOL compiler by DEC.

Andrew Swallow
0
7/26/2012 6:07:37 PM
In comp.lang.pl1 jmfbahciv <See.above@aol.com> wrote:

(snip, someone wrote)
>> Carefully written Fortran could be quite portable, but most Fortran
>> wasn't carefully written.

> I remember that DEC's PDP-10 FORTRAN in 1969 could do disk I/O.
> the compiler didn't "support" disk I/O as a standard...only cards.
> So the way to fake card I/O was to issue the monitor commands:

> ASSIGN DSK 5
> ASSIGN DSK [my fingers have failed me; I can't remmeber the
>            number IBM used for READ --1?]

> Your FORTRAN program read a "card" from a file called FOR01.DAT
> and wrote a "card" to a disk file called FOR05.DAT

Usual is 5 for card input, 6 for printer output, 7 for card output.

In some early system 1 through 4 were tape drives.

-- glen
0
gah (12851)
7/26/2012 6:24:55 PM
In comp.lang.pl1 Charles Richmond <numerist@aquaporin4.com> wrote:

(snip, I wrote)
>> The only reasonably large program I know claiming Fortran 66
>> compliance is the MORTRAN 2 processor. (It makes some assumptions
>> about what you can do with data read and written with A1 format,
>> but otherwise should work.)
>>

> The FORTRAN compiler needs to be able to *compile* the MORTRAN 2 
> processor... and also be able to compile the FORTRAN code that 
> the MORTRAN 2 processor produces.

Yes. The latter depends on what you write. Among others, though,
MORTRAN2 outputs H format descriptor for quoted strings in input.

> Like the old TV and Radio show:  "Believe It... or Just Don't Think 
> About It!"  ;-)  I mean this:  at a PPoE I worked on a military 
> contract (we were actually sub-contractors... *not* at all unusual 
> for military contracts) and we actually used MORTRAN 2 as the 
> development language.  The FORTRAN compiler (it was a CDC 
> compiler for a CDC machine) was actually a *subset* of 
> FORTRAN IV... but the MORTRAN 2 worked with it.

The claim is Fortran 66 standard. 

> One day I intend to *understand* the translation macros used by MORTRAN 2. 
> ISTM that the SLAC documentation for MORTRAN 2 is on bitsavers.  If anyone 
> here can explain the macros to me, I will be happy to post some of the 
> macros here on <a.f.c.>.

I once understood them enough to write macros to generate Fortran 90
constructs.

Among others, MORTRAN2 has a FOR loop that generates IF/GOTO such
that one can do floating point loops, ones that decrement, or have
a starting value less than one. All those can be done by DO in
Fortran 90, but not in Fortran 66.

I have both the users manual and the explanation for how to
write macros.  Somewhere.

-- glen
0
gah (12851)
7/26/2012 6:31:10 PM
In comp.lang.pl1 hancock4@bbs.cpcn.com wrote:

(snip on lease vs. buy)
> At the time of Divesture, the Bell System allowed customers to buy
> their existing telephone sets at a very good price, much less than the
> cost to manufacture them.  So yes, the amortization was pretty quick,
> about a year.

> There was no rental fee on the first telephone set that came with the
> line; it was only on extension sets.

Well, more likely was included in the monthly rate.

> It should be noted that since those old Western Electric telephone
> sets were intended for rental and company-provided maintenance, they
> were carefully designed and manufacturered to be long-lasting and
> maintenance free.  

The original touch-tone phone was designed to need only one 
transistor. That was the least reliable part at the time, and 
they wanted to minimize the number. Note that it has to
generate two tones for each number.

(snip)

> It also should be noted that the rental policy was desired by
> regulators (applied to Independent Companies, too).  The profits from
> rentals were used to offset the price of basic phone service--which
> back then could be as low as $3/month for bare bones service.

Yes. And even more, was subsidized by higher long-distance rates.

> After Divesture, other companies came out with telephone sets.  They
> built much cheaper, sounded like crap, and were basically disposable.
> If they fell off the table they were ruined.

> The old Bell System provided phone-to-phone service and maintenance.
> If there was a problem with your house wiring, they came out and fixed
> it free.  Admittedly, this was rare, but it does occur from time to
> time.  Today, if a subscriber has a problem, the legacy companies
> aren't very helpful, and the newcomer companies are even less
> helpful.  But apparently people prefer the present system to paying
> the rentals every month.

Last I knew, you could pay a monthly charger for inside wiring
maintenance. The change happened while I was living in a dorm in
Urbana, IL, where the phones were provided by the phone company.
One month they sent out a note asking if we wanted to do our
own inside wiring maintenance, and I returned it saying "yes."
(Which, of course, doesn't really apply in a dorm room.)

I did have a modem hard wired into the line, though.

-- glen

0
gah (12851)
7/26/2012 6:40:03 PM
In comp.lang.pl1 Walter Banks <walter@bytecraft.com> wrote:

(snip)

> Bell Canada charges extra per month for touch tone phone support.
> I have a friend whose home phone has a dial simply to make a point.
> As long as he has to may more for touch tome phones the Bell switches
> are going to need to decode pulse dialing. :)

US companies did that for many years, but most (that I know of)
don't anymore. All that I knew, for many years now, accepted 
tones, but only some lines supported pulse dialing.

-- glen
0
gah (12851)
7/26/2012 6:42:37 PM
In article <jur8l0$icd$1@dont-email.me>,
 "Charles Richmond" <numerist@aquaporin4.com> wrote:

> "John Levine" <johnl@iecc.com> wrote in message 
> news:jupkgo$160n$3@leila.iecc.com...
> > >No.  FORTRAN had a standard and, if a company wanted to sell anything
> >>to the Federal government, they had to pass the Navy tests.
> >
> > I wrote a Fortran compiler that passed the Navy tests.  It wasn't very
> > hard.
> >
> > Carefully written Fortran could be quite portable, but most Fortran
> > wasn't carefully written.
> >
> 
> ISTM that FORTRAN through the FORTRAN IV comilers... had *no* standard way 
> to handle character data.  The character data was "fudged in" using 
> different methods on different machines... and that lead to non-standard, 
> incompatible programs.
> 
> --
> 
> numerist at aquaporin4 dot com

And Fortran used no precision control for floating point; it just used 
the native value of the hardware.

-- 
This space unintentionally left blank.
0
proto (1924)
7/26/2012 6:52:50 PM

hancock4@bbs.cpcn.com wrote:

> On Jul 26, 11:10 am, Walter Banks <wal...@bytecraft.com> wrote:
>
> >
> > Bell Canada charges extra per month for touch tone phone support.
> > I have a friend whose home phone has a dial simply to make a point.
> > As long as he has to pay more for touch tone phones the Bell switches
> > are going to need to decode pulse dialing. :)
>
> That is weird that Bell Canada still does that.  Does Canada have
> competing local phone companies with their own switches that charge
> differently?

Communication rates are part of communication providers license
agreements with the federal government. The rates are subject to
periodic review by the CRTC.

As touch tone dialing was introduced Bell was granted a service rate
for providing customer support. They still have it even though it
would be less expensive to eliminate pulse dialing completely.

There are about a dozen canadian landline phone companies
very few have overlapping service area's. Toronto is one example
where there is two significant landline competitors. (Bell and Rogers)

w..



0
walter20 (887)
7/26/2012 6:59:56 PM
On Jul 22, 8:54=A0am, "Joe Morris" <j.c.mor...@verizon.net> wrote:

> Slight edit: the time required to print a given line was a function of th=
e
> character set on the print train and the set of characters present on tha=
t
> line.

Some IBM print trains were designed so that characters in a preferred
character set repeated more often on the print train than certain
additional characters which were also available.

It was only if one of those print trans were used that this phenomenon
would take place; many installations of 1403 or similar printers did
not use these relatively specialized print trains, which was why your
earlier posting engendered doubt.

I am aware of their existence, and discuss the principle on my page at
http://www.quadibloc.com/comp/lineint.htm

John Savard
0
jsavard (654)
7/26/2012 7:04:17 PM
In article <50115DF1.68B9F1CC@bytecraft.com>,
 Walter Banks <walter@bytecraft.com> wrote:

> Bell Canada charges extra per month for touch tone phone support.
> I have a friend whose home phone has a dial simply to make a point.
> As long as he has to may more for touch tome phones the Bell switches
> are going to need to decode pulse dialing. :)

I had a phone that would switch from pulse to tone by a switch, and I 
assume they are still available somewhere, so he needn't actually dial 
the numbers.

-- 
This space unintentionally left blank.
0
proto (1924)
7/26/2012 7:06:26 PM
On Jul 23, 5:49=A0am, "Charles Richmond" <numer...@aquaporin4.com>
wrote:
> "John Levine" <jo...@iecc.com> wrote in message

> > The interface was impressively horrible. =A0As the drum rotated, it
> > would interrupt the CPU and send it the code of the character about to
> > come up to the hammers, at which point the CPU had to construct a bit
> > map of which hammers to fire in time for the printer controller to DMA
> > it to the transistors that controlled the hammers. =A0Repeat as each
> > character comes past the hammers. =A0When all of the characters on a
> > line had been printed, the CPU started the paper moving, waited for
> > the appropriate hole in the carriage control tape to appear, then
> > stopped the paper. =A0It was a miracle it worked at all.
>
> This sounds like an *excellent* design... if you had a microprocessor CPU=
 to
> run the thing. =A0But certainly you are talking about a printer that pre-=
dated
> microprocessors by many years.

Excellent or horrible, you _did_ have a CPU to run the thing: the IBM
1130 processor to which the printer was attached, as the post to which
you replied noted.

So instead of the 1130 transmitting the characters to the printer,
which took care of the business of getting them printed, here the CPU
itself did a significant part of the work of printing.

Since the 1130 was a small-scale computer system, and thus time on it
didn't cost hundreds of dollars an hour, this was a reasonable design
compromise to allow 1130 owners to purchase an inexpensive printer for
it.

However, I would assume that one would first have all one's bit maps
ready, and then start printing, so as to just fire off a bit map in
response to an interrupt, rather than construct one as part of an
interrupt service routine. For obvious reasons, one endeavors to keep
to an absolute minimum the amount of processing done during interrupt
service.

The primary obvious reason is to avoid the possibility of, with
several peripherals running, the amount of time required to service
all interrupt requests on time turning out to be more than 100% of the
time available. Interrupt processing is real-time, so you want the
interrupt service routine to be in and out right away after, with as
much of the computational work being done at one's leisure outside of
interrupt service.

John Savard
0
jsavard (654)
7/26/2012 7:14:49 PM
On Jul 23, 9:49=A0pm, John Levine <jo...@iecc.com> wrote:
(quoting someone)

> >It was compatible with the 360 in that the same programs would run on
> >it, within limitations.
>
> So long as the limitation was that the programs were rewritten from
> scratch to work on the entirely incompatible 1130, I suppose so.
> Internally the 1130 was a 16 bit word addressed machine which was
> nothing like a 360. =A0Are you sure you don't have it confused with the
> 360/20?

You're quite correct that the IBM 1130 is not System/360 compatible in
the sense in which we would use that term today.

However, while the poster to whom you are replying understands that,
he is using "compatible" in a different sense. Because it still uses
an 8-bit byte, and EBCDIC, and the compilers written for it were also
IBM products, it had some partial compatibility at the higher-level
language level.

Partial is right, though - the double-precision floating-point format
was different in precision, the languages for the 1130 usually had
limitations and restrictions those for the 360 did not - and so I'm
not at all sure one would *really* have found it _that_ much easier to
port FORTRAN or COBOL to an 1130 from a 360 than to port such programs
to, say, a PDP-10.

On the other hand, if one is porting from the 1130 to the 360, then
the view of the systems as having some degree of compatibility is
considerably more justified.

John Savard
0
jsavard (654)
7/26/2012 7:21:20 PM
On Jul 24, 11:24=A0am, hanco...@bbs.cpcn.com wrote:

> If someone outgrew their PDP, were the next upward models compatible,
> that is, could programs and compiled for say the PDP-7 run without
> change on the PDP-8 or PDP-9, etc.?

Not really.

Higher-level language programs for the PDP-8 could often be easily
ported upwards to the somewhat similar, although incompatible,
PDP-4/7/9/15 architecture with limited changes, and this could
continue with the PDP-6/10 architecture, simply because the same
company wrote the compilers for all the machines.

It was really only with the PDP-11 that one finally had machines with
the same architecture and a range of performance, comparable to the
System/360 or the SDS-9xx series.

John Savard
0
jsavard (654)
7/26/2012 7:25:10 PM
On Jul 24, 11:24=A0am, hanco...@bbs.cpcn.com wrote:

> Did the PDP-8 support a wide line printer, disk storage and punched
> card input?

Yes, it did. And nine-track tape too.

You could outfit a PDP-8/I... and, in fact, even the PDP-5... as
though it were a tiny mainframe.

John Savard
0
jsavard (654)
7/26/2012 7:26:19 PM
On Jul 26, 12:52=A0pm, Walter Bushell <pr...@panix.com> wrote:

> And Fortran used no precision control for floating point; it just used
> the native value of the hardware.

You chose one of the native values offered by the hardware for any
given variable. In PL/I, one could specify the number of digits you
wanted, and the compiler would pick an available format that would
provide that precision - FORTRAN definitely did not do that.

What FORTRAN did do, though, that present day C does not, was that it
had separate libraries for every precision. So if you had a program
that worked with single-precision numbers, you did not waste time
calculating sines and logarithms to double precision - which is what
the standard C math library inflicts on you.

Although, given the design of Intel floating-point hardware from the
8087 onwards, that's less of a fault than it might sound like. On old-
style 360-era hardware, it would have been insanity.

John Savard
0
jsavard (654)
7/26/2012 7:32:56 PM
On Jul 26, 6:27=A0am, jmfbahciv <See.ab...@aol.com> wrote:

> ASSIGN DSK 5
> ASSIGN DSK [my fingers have failed me; I can't remmeber the
> =A0 =A0 =A0 =A0 =A0 =A0 number IBM used for READ --1?]

Huh?

Do you mean things like

 READ (5,10) X,Y,Z
 WRITE (6,11) A,B,C

where 5 is the standard number used for the card reader as a device
and 6 the standard number used for the line printer as a device?

(10 and 11 are the line numbers of FORMAT statements.)

John Savard
0
jsavard (654)
7/26/2012 7:35:05 PM
On Jul 26, 12:24=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu>
wrote:

> In some early system 1 through 4 were tape drives.

And I know that under MTS the convention was to assign lower numbers
like that to disk files in the RUN command:

RUN MYPROG 2=3DMYFILE

would be similar to

myprog 2<myfile

or

myprog 2>myfile

these days.

John Savard
0
jsavard (654)
7/26/2012 7:37:28 PM
On Jul 24, 10:29=A0am, glen herrmannsfeldt <g...@ugcs.caltech.edu>
wrote:

> Also, as I understand, 370/158s were reused inside the 3032
> and 3033 for I/O. As a 370/158, it had microcode for both CPU
> and channel operations. Running the channels for the 303x, it
> only needed (probably new) channel microcode, to offload that
> function from the CPU.

I don't know anything about that, but the 3033, the 370/165 and 168,
and the Model 85 used essentially the same microcode format; they were
improved versions of the same underlying microarchitecture.

John Savard
0
jsavard (654)
7/26/2012 7:39:52 PM
On Jul 24, 7:52=A0pm, hanco...@bbs.cpcn.com wrote:

> The workings of the cache and virtual addressing was amazingly
> complex. =A0How they could write an operating system and micro code to
> track all the stuff is beyond me.

Still, though, cache memory and virtual memory were very important in
improving performance and maintaining compatibility. So it was worth
the effort for IBM.

John Savard
0
jsavard (654)
7/26/2012 7:43:27 PM
In comp.lang.pl1 Quadibloc <jsavard@ecn.ab.ca> wrote:
> On Jul 26, 12:52�pm, Walter Bushell <pr...@panix.com> wrote:

>> And Fortran used no precision control for floating point; 
>> it just used the native value of the hardware.

> You chose one of the native values offered by the hardware for any
> given variable. In PL/I, one could specify the number of digits you
> wanted, and the compiler would pick an available format that would
> provide that precision - FORTRAN definitely did not do that.

Most PL/I programs that I knew chose the number to match the
hardware. FLOAT BINARY(53) was very common.

> What FORTRAN did do, though, that present day C does not, was that it
> had separate libraries for every precision. So if you had a program
> that worked with single-precision numbers, you did not waste time
> calculating sines and logarithms to double precision - which is what
> the standard C math library inflicts on you.

Actually, present day C does supply both float and double
library routines, along with complex routines. It didn't used
to, but does now. (I believe from C01, maybe C11.)

> Although, given the design of Intel floating-point hardware from the
> 8087 onwards, that's less of a fault than it might sound like. On old-
> style 360-era hardware, it would have been insanity.

Yes, much hardware now does full precision even if you don't
need it. And often at about the same speed.

I remember from the OS/360 days, I had times for Fortran and PL/I
library routines on different S/360 processors. On the 360/91,
DSQRT was faster than SQRT. SQRT used a more complicated fixed
point first approximation than DSQRT, which was slower on the 91.

-- glen
0
gah (12851)
7/26/2012 7:48:32 PM
In comp.lang.pl1 Quadibloc <jsavard@ecn.ab.ca> wrote:
> On Jul 26, 12:24�pm, glen herrmannsfeldt <g...@ugcs.caltech.edu>
> wrote:

>> In some early system 1 through 4 were tape drives.

> And I know that under MTS the convention was to assign lower numbers
> like that to disk files in the RUN command:

In Fortran I and Fortran II there were separate I/O statements:

      READ INPUT TAPE

      WRITE OUTPUT TAPE

(for character input and output to tape). Fortran IV introduced
unit numbers, such that program could be written device independent.

> RUN MYPROG 2=MYFILE

> would be similar to

> myprog 2<myfile

> or

> myprog 2>myfile

> these days.

From OS/360 days:

//FT01F001 DD DSN=MYFILE,DISP=SHR

OS/360 used DD names where unix uses file descriptors.

-- glen
0
gah (12851)
7/26/2012 7:54:42 PM
On Jul 26, 3:06=A0pm, Walter Bushell <pr...@panix.com> wrote:
> In article <50115DF1.68B9F...@bytecraft.com>,
> =A0Walter Banks <wal...@bytecraft.com> wrote:
>
> > Bell Canada charges extra per month for touch tone phone support.
> > I have a friend whose home phone has a dial simply to make a point.
> > As long as he has to may more for touch tome phones the Bell switches
> > are going to need to decode pulse dialing. :)
>
> I had a phone that would switch from pulse to tone by a switch, and I
> assume they are still available somewhere, so he needn't actually dial
> the numbers.

Lots of phones had that capability.

Going back years, many local exchanges were dial pulse only, but
subscribers (such as banks) had to call into computers.  They had a
Touch Tone pad with their telephone.  AE made a dual mode phone with
both a TT pad and a dial.

Regarding the issue of register hold, it doesn't matter in ESS.  But
in crossbar and panel TT did reduce register hold time.  In SxS TT had
to be converted into pulses, and could result in excessive switchtrain
wear.  In any event, TT was seen as a premium service so they charged
more for it.

As an aside, Western Union had a private line phone system using push
button phones, but they didn't use tones, but various electric
signals.
0
hancock4 (224)
7/26/2012 8:02:36 PM
On Jul 26, 3:48=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

> I remember from the OS/360 days, I had times for Fortran and PL/I
> library routines on different S/360 processors. On the 360/91,
> DSQRT was faster than SQRT. SQRT used a more complicated fixed
> point first approximation than DSQRT, which was slower on the 91.

It appears that square root is now a hardware command on the IBM Z
series.  Given how common this function is used, I'm surprised it was
not made into hardware years ago.  (Likewise with certain relatively
new COBOL functions.)
0
hancock4 (224)
7/26/2012 8:08:30 PM
On Jul 26, 1:04=A0pm, Quadibloc <jsav...@ecn.ab.ca> wrote:

> Some IBM print trains

such as the QN print train which you mentioned; my point was only that
many people wouldn't even know such print trains existed because many
installations never used them.

John Savard
0
jsavard (654)
7/26/2012 9:41:03 PM
In article 
<ab3070a4-adba-41ff-be96-c834f90d8697@j9g2000vbk.googlegroups.com>,
 hancock4@bbs.cpcn.com wrote:

> 
> It appears that square root is now a hardware command on the IBM Z
> series.  Given how common this function is used, I'm surprised it was
> not made into hardware years ago.  (Likewise with certain relatively
> new COBOL functions.)

But the square root loop is a small function and easily cached. Mayhap 
it's micro coded.

-- 
This space unintentionally left blank.
0
proto (1924)
7/26/2012 10:19:55 PM
On Jul 26, 4:19=A0pm, Walter Bushell <pr...@panix.com> wrote:
> In article
> <ab3070a4-adba-41ff-be96-c834f90d8...@j9g2000vbk.googlegroups.com>,
> =A0hanco...@bbs.cpcn.com wrote:
>
> > It appears that square root is now a hardware command on the IBM Z
> > series. =A0Given how common this function is used, I'm surprised it was
> > not made into hardware years ago. =A0(Likewise with certain relatively
> > new COBOL functions.)
>
> But the square root loop is a small function and easily cached. Mayhap
> it's micro coded.

Actually, it's not particularly unusual (oh, what the heck, why not
throw in an irrelevant link)

http://www.youtube.com/watch?v=3DvfaNCRAFuek

that square root is a hardware command on the Z series mainframes; on
x86 chips, even the log and trig functions are hardware commands these
days.

John Savard
0
jsavard (654)
7/26/2012 10:50:47 PM
In <icehnyg0l4.fsf@home.home>, on 07/26/2012
   at 08:37 AM, Dan Espen <despen@verizon.net> said:

>It was a "1" on IBN 1401 but a 1 is a Write command in a S/360
>channel program.

Don't confuse the encoding of devices numbers with the encoding of I/O
commands. Also, mmmmmm01 is a write opcode for any value of the mmmmmm
bits.

-- 
Shmuel (Seymour J.) Metz, SysProg and JOAT  <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action.  I reserve the
right to publicly post or ridicule any abusive E-mail.  Reply to
domain Patriot dot net user shmuel+news to contact me.  Do not
reply to spamtrap@library.lspace.org

0
spamtrap16 (3722)
7/26/2012 11:05:14 PM
On 7/26/2012 7:17 AM, glen herrmannsfeldt wrote:
> In comp.lang.pl1 Charles Richmond <numerist@aquaporin4.com> wrote:
>
> (snip, someone wrote)
>>> Carefully written Fortran could be quite portable, but most Fortran
>>> wasn't carefully written.
>
>> ISTM that FORTRAN through the FORTRAN IV comilers... had *no* standard way
>> to handle character data.  The character data was "fudged in" using
>> different methods on different machines... and that lead to non-standard,
>> incompatible programs.
>
> Well, it is part of the standard, both Fortran 66 and the (different
> versions of) IBM Fortran IV.
>
> As well as I know it, the standard pretty much allows for reading
> in alphanumeric data, and then writing it back out again.

I think it's A1 or whatever the correct syntax is.  You'd get one 
character per "word", so it was fairly wasteful, especially in the days 
of small memories, but if you needed to be portable it worked.  Othre 
formats like A4 (again IIRC) would pack four characters to a "word" 
assuming you had a 32-bit or larger word, but made it harder to manipulate.
>


-- 
Pete
0
Peter_Flass (956)
7/26/2012 11:16:15 PM
On 7/26/2012 8:37 AM, Dan Espen wrote:
> jmfbahciv <See.above@aol.com> writes:
>
>> John Levine wrote:
>>>> No.  FORTRAN had a standard and, if a company wanted to sell anything
>>>> to the Federal government, they had to pass the Navy tests.
>>>
>>> I wrote a Fortran compiler that passed the Navy tests.  It wasn't very
>>> hard.
>>>
>>> Carefully written Fortran could be quite portable, but most Fortran
>>> wasn't carefully written.
>>
>>
>> I remember that DEC's PDP-10 FORTRAN in 1969 could do disk I/O.
>> the compiler didn't "support" disk I/O as a standard...only cards.
>> So the way to fake card I/O was to issue the monitor commands:
>>
>> ASSIGN DSK 5
>> ASSIGN DSK [my fingers have failed me; I can't remmeber the
>>              number IBM used for READ --1?]
>
> It was a "1" on IBN 1401 but a 1 is a Write command in a S/360
> channel program.
>
>

Huh?

-- 
Pete
0
Peter_Flass (956)
7/26/2012 11:18:53 PM
On 7/26/2012 2:07 PM, Andrew Swallow wrote:
>
> COBOL was a requirement for sales to the US Government.  That rule would
> have justified the writing of a COBOL compiler by DEC.
>

I'm sure people used it.  Colleges that had a -10 as their main machine 
may have been induced to write COBOL programs for usage accounting or 
even administrative use.  I doubt anyone would have bought a -10 
primarily as a platform for writing apps in COBOL.

-- 
Pete
0
Peter_Flass (956)
7/26/2012 11:22:58 PM
On 7/26/2012 3:14 PM, Quadibloc wrote:
>
> So instead of the 1130 transmitting the characters to the printer,
> which took care of the business of getting them printed, here the CPU
> itself did a significant part of the work of printing.
>
> Since the 1130 was a small-scale computer system, and thus time on it
> didn't cost hundreds of dollars an hour, this was a reasonable design
> compromise to allow 1130 owners to purchase an inexpensive printer for
> it.
>
> However, I would assume that one would first have all one's bit maps
> ready, and then start printing, so as to just fire off a bit map in
> response to an interrupt, rather than construct one as part of an
> interrupt service routine. For obvious reasons, one endeavors to keep
> to an absolute minimum the amount of processing done during interrupt
> service.
>
> The primary obvious reason is to avoid the possibility of, with
> several peripherals running, the amount of time required to service
> all interrupt requests on time turning out to be more than 100% of the
> time available. Interrupt processing is real-time, so you want the
> interrupt service routine to be in and out right away after, with as
> much of the computational work being done at one's leisure outside of
> interrupt service.
>

I think it built the bitmaps on the fly, though I'm sure there are 
people in the 1130 groups that would know for sure.  Memory was an 
expensive resource in those days, and I think the printer was slow 
enough and the CPU fast enough that it took negligible time.

Actually, the code is available.  I suppose I could check it out.  The 
1130 Disk Monitor developers did an outstanding job getting the most out 
of the machine using the least amount of memory.  I could probably learn 
a lot.


-- 
Pete
0
Peter_Flass (956)
7/26/2012 11:29:31 PM
In comp.lang.pl1 Peter Flass <Peter_Flass@yahoo.com> wrote:

(snip regarding character data in Fortran 66, then I wrote)

>> Well, it is part of the standard, both Fortran 66 and the 
>> (different versions of) IBM Fortran IV.

>> As well as I know it, the standard pretty much allows for reading
>> in alphanumeric data, and then writing it back out again.

> I think it's A1 or whatever the correct syntax is.  You'd get one 
> character per "word", so it was fairly wasteful, especially in the days 
> of small memories, but if you needed to be portable it worked.  

Yes. But on word oriented machines, it worked pretty well.

> Other  formats like A4 (again IIRC) would pack four 
> characters to a "word" assuming you had a 32-bit or larger 
> word, but made it harder to manipulate.

In portable code, you don't know the word size of the machine.

The 704 and such have 36 bit words and six bit characters,
so six per word. Four characters per word for S/360.
Many 16 bit machines used a 16 bit integer type, so only two.

That worked if you just want to read in and write out, but one
character per word to do anything more (and be anywhere close
to standard).

-- glen
0
gah (12851)
7/26/2012 11:34:51 PM
>However, I would assume that one would first have all one's bit maps
>ready, and then start printing, so as to just fire off a bit map in
>response to an interrupt, rather than construct one as part of an
>interrupt service routine. For obvious reasons, one endeavors to keep
>to an absolute minimum the amount of processing done during interrupt
>service.

I'm fairly sure they didn't.  The 1130 didn't come with much memory,
4K words in a basic model, and 48 bit maps would take a fair amount
of space.

>The primary obvious reason is to avoid the possibility of, with
>several peripherals running, the amount of time required to service
>all interrupt requests on time turning out to be more than 100% of the
>time available.

No kidding.  For the printer, that wasn't a disaster.  There was a
flag bit the program set to tell the printer the bitmap was ready, and
an error condition if the printer didn't see the flag.  In that case
the program just waited for the same character to come around on the
drum and tried again.

Remember that the 1130 most definitely did not try to do more than one
thing at a time.  The 1130 came in a variety of models of differing
performance, and it was widely known that the slower models were the
same as the faster ones with delays added.  For the card reader, there
was apparently a relay you disabled and remembered to recoonect when
the IBM guy was there.  The slowest CPU had 5.6us cycle time rather
than 3.6us on the other models, and I am reliably informed that when
there was a printer interrupt, the CPU sped up to 3.6us so it would
be able to build the bitmap in time.  Needless to say, at academic
installations people figured out how to run all the time with the
printer interrupt on.

R's,
John
-- 
Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
0
johnl (129)
7/26/2012 11:37:55 PM
In comp.lang.pl1 Walter Bushell <proto@panix.com> wrote:

(snip on speed of math functions)

> But the square root loop is a small function and easily cached. 
> Mayhap it's micro coded.

The software routines I know of don't use a loop for sqrt.

First divide the exponent by two, remembering if it was odd.
Generate a starting guess using a simple formula, then
two Newton-Raphson cycles (sequentially coded) for single
precision, four for double.

There is an extra trick for the last one to avoid precision
loss on the divide by two for floating point base other
than two.

I would guess similar non-loop structure in microcode.

-- glen
0
gah (12851)
7/26/2012 11:41:13 PM
In article <proto-7A728B.07180126072012@news.panix.com>,
Walter Bushell  <proto@panix.com> wrote:
>In article 
><f8063d99-07fb-4a3f-82ae-e913767be5a5@q2g2000vbv.googlegroups.com>,
> hancock4@bbs.cpcn.com wrote:
>
>> This likewise applied to the old Bell System policy of leasing all
>> equipment. ...

>Certainly not for home customers. I remember buying a phone and the 
>amortization over renting it was amortized in months or was it much 
>less?

That was later.  I bought a Mickey Mouse phone, which I still have,
from SNET in the 1970s.  They explained to me that I had only bought
the attractive plastic case, and I was still renting the working
parts.  I asked what would happen when I moved, and they said with a
straight face that they'd sell the guts to my new telco so they could
continue renting it to me.  Needless to say that didn't happen, but I
did pay the monthly rental to SNET for a couple of years until I
moved.

R's,
John
-- 
Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
0
johnl (129)
7/26/2012 11:41:28 PM
>It appears that square root is now a hardware command on the IBM Z
>series.  Given how common this function is used, I'm surprised it was
>not made into hardware years ago.

According to my ESA/390 Principals of Operation, those instructions
were added in ESA/390, which was shipped in 1990.

Does 22 years count as years ago?

R's,
John

-- 
Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
0
johnl (129)
7/26/2012 11:49:19 PM
Peter Flass <Peter_Flass@Yahoo.com> wrote
> Andrew Swallow wrote

>> COBOL was a requirement for sales to the US Government.  That rule would 
>> have justified the writing of a COBOL compiler by DEC.

> I'm sure people used it.

Few did.

> Colleges that had a -10 as their main machine may have been induced to 
> write COBOL programs for usage accounting or even administrative use.

Most would just use Fortran instead.

I saw that happen with CDC mainframes.

They basically used the language they were fluent in for obvious reasons.

> I doubt anyone would have bought a -10 primarily as a platform for writing 
> apps in COBOL.

I doubt too many would have actually used COBOL either. 

0
rod.speed.aaa (1275)
7/26/2012 11:50:21 PM
In comp.lang.pl1 John Levine <johnl@iecc.com> wrote:

(snip on 1130 printing)

> Remember that the 1130 most definitely did not try to do more than one
> thing at a time.  The 1130 came in a variety of models of differing
> performance, and it was widely known that the slower models were the
> same as the faster ones with delays added.  

I remember the story about System/3 having two memory sizes
(I believe 32K and 64K, but could be wrong), the difference 
being a switch position. Once someone found the switch, keep
it in the large memory position, but don't forget to switch
it back before the IBM guy comes in.

At that point, memory was cheap enough that it was easier to
install it all, instead of make two different versions.

> For the card reader, there
> was apparently a relay you disabled and remembered to recoonect when
> the IBM guy was there.  The slowest CPU had 5.6us cycle time rather
> than 3.6us on the other models, and I am reliably informed that when
> there was a printer interrupt, the CPU sped up to 3.6us so it would
> be able to build the bitmap in time.  Needless to say, at academic
> installations people figured out how to run all the time with the
> printer interrupt on.

Seems the idea wasn't new with System/3.

-- glen
0
gah (12851)
7/26/2012 11:50:32 PM
>> I wrote a Fortran compiler that passed the Navy tests.  It wasn't very
>> hard.
>
>As long as you stayed with the standard, it shouldn't be very hard.
>The operating time system (FOROTS) was harder.  Arithmetic, I/O and
>other less-used aspects had to conform.

I wrote the runtime system, too.  I was young and foolish and didn't
realize that it was an impossible amount of work for one person.  It
ran on PDP-11 Unix, using the back end of the Ritchie C compiler for
code generation, and the existing C math libraries which were quite
good.

The NBS also had a test suite which I recall as being harder to pass.
I never finished writing a few of the more exotic F77 I/O library bits.

R's,
John
-- 
Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
0
johnl (129)
7/26/2012 11:57:00