Languages influenced by PL/1

[john_m...@hotmail.com]

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.

[robin....@gmail.com]

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?

[John W Kennedy]

On 2012-07-14 09:44:14 +0000, john_m...@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"

[John W Kennedy]

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"

[glen herrmannsfeldt]

John W Kennedy <jwk...@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

[John W Kennedy]

I am not an expert on Fortran past Fortran IV, but what you say here
makes no sense. If SAVE means static, and otherwise means automatic,
then automatic is the default, on accounta that's what "default" means.
Now, if I recall aright, in 77, non-SAVE /could/ be static, and maybe
that's still true today, but that's not what you're saying.


--
John W Kennedy
Having switched to a Mac in disgust at Microsoft's combination of
incompetence and criminality.

[glen herrmannsfeldt]

John W Kennedy <jwk...@attglobal.net> wrote:

(snip, I wrote)

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

> I am not an expert on Fortran past Fortran IV, but what you say here
> makes no sense. If SAVE means static, and otherwise means automatic,
> then automatic is the default, on accounta that's what "default" means.
> Now, if I recall aright, in 77, non-SAVE /could/ be static, and maybe
> that's still true today, but that's not what you're saying.

That is what I was trying to say.

A Fortran 90 or later compiler, when compiling a routine without
the RECURSIVE option, is allowed to use either static or automatic
storage for local variables. (SAVE is the word used in the Fortran
standard for what everyone else calls static.) There is no keyword
for automatic. (Not that anyone uses auto in C, and rarely AUTOMATIC
in PL/I.)

-- glen

[Shmuel Metz]

In <50020d5e$0$1223$607e...@cv.net>, on 07/14/2012

at 08:22 PM, John W Kennedy <jwk...@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 spam...@library.lspace.org

[John W Kennedy]

On 2012-07-15 01:33:42 +0000, Shmuel (Seymour J.) Metz said:

> In <50020d5e$0$1223$607e...@cv.net>, on 07/14/2012
> at 08:22 PM, John W Kennedy <jwk...@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.

Not "late 60s and 70s".

> The only IBM command
> language that looked vaguely like PL/I was REXX, and even there their
> were more differences than similarities.

You're neglecting the general schema of:

command [pos-arg...] [keyword(operand [, operand]...)]

Early 360-era command languages looked like assembler. Later ones
looked like PL/I

--
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"

[glen herrmannsfeldt]

Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> wrote:
> In <50020d5e$0$1223$607e...@cv.net>, on 07/14/2012
> at 08:22 PM, John W Kennedy <jwk...@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

[robin....@gmail.com]

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?

[robin....@gmail.com]

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.

[John W Kennedy]

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

[glen herrmannsfeldt]

robin....@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

[glen herrmannsfeldt]

John W Kennedy <jwk...@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

[robin....@gmail.com]

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.

[robin....@gmail.com]

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.

[glen herrmannsfeldt]

robin....@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

[glen herrmannsfeldt]

robin....@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

[John W Kennedy]

On 2012-07-16 02:11:42 +0000, glen herrmannsfeldt said:

> John W Kennedy <jwk...@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)

[John W Kennedy]

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"

[Tim C.]

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.

[Shmuel Metz]

In <ju0u1b$vg3$1...@speranza.aioe.org>, on 07/16/2012

at 11:30 AM, glen herrmannsfeldt <g...@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 Metz]

In <jtvt8u$phc$1...@speranza.aioe.org>, on 07/16/2012

at 02:11 AM, glen herrmannsfeldt <g...@ugcs.caltech.edu> said:

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

>was added,

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

[Shmuel Metz]

In <5002edd2$0$11531$607e...@cv.net>, on 07/15/2012

at 12:20 PM, John W Kennedy <jwk...@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."

[glen herrmannsfeldt]

Shmuel (Seymour J.) Metz <spam...@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

[glen herrmannsfeldt]

Shmuel (Seymour J.) Metz <spam...@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.

-- glen

[John W Kennedy]

On 2012-07-16 14:17:07 +0000, Shmuel (Seymour J.) Metz said:

> In <5002edd2$0$11531$607e...@cv.net>, on 07/15/2012
> at 12:20 PM, John W Kennedy <jwk...@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"

[John W Kennedy]

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"

[Peter Flass]

On 7/14/2012 8:32 PM, John W Kennedy wrote:
> On 2012-07-14 23:49:49 +0000, robin....@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

[Peter Flass]

//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

[Peter Flass]

On 7/15/2012 8:36 PM, robin....@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

[Peter Flass]

On 7/15/2012 10:11 PM, glen herrmannsfeldt wrote:
> John W Kennedy <jwk...@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

[glen herrmannsfeldt]

Peter Flass <Peter...@yahoo.com> wrote:
> On 7/15/2012 8:36 PM, robin....@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

[glen herrmannsfeldt]

Peter Flass <Peter...@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

[robin....@gmail.com]

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.

[robin....@gmail.com]

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.

[robin....@gmail.com]

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.

[robin....@gmail.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.

[robin....@gmail.com]

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.

[robin....@gmail.com]

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.

[robin....@gmail.com]

On Tuesday, 17 July 2012 09:43:52 UTC+10, Peter Flass wrote:
> On 7/15/2012 8:36 PM, xxx...@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.

[robin....@gmail.com]

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, xxx...@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.

[glen herrmannsfeldt]

robin....@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

[robin....@gmail.com]

On Tuesday, 17 July 2012 13:57:53 UTC+10, glen herrmannsfeldt wrote:

> xxx...@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.

[Peter Flass]

On 7/16/2012 7:58 PM, glen herrmannsfeldt wrote:
> Peter Flass <Peter...@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

[John W Kennedy]

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"

[John W Kennedy]

On 2012-07-16 23:58:13 +0000, glen herrmannsfeldt said:

> Peter Flass <Peter...@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"

[John W Kennedy]

On 2012-07-17 03:36:50 +0000, robin....@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, xxx...@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)

[John W Kennedy]

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"

[John W Kennedy]

Just like every other language from Plankalkül on.

[glen herrmannsfeldt]

John W Kennedy <jwk...@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

[glen herrmannsfeldt]

John W Kennedy <jwk...@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

[Fritz Wuehler]

John W Kennedy <jwk...@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). 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.

[John W Kennedy]

On 2012-07-17 19:49:43 +0000, glen herrmannsfeldt said:

> John W Kennedy <jwk...@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

[John W Kennedy]

On 2012-07-17 19:56:43 +0000, glen herrmannsfeldt said:

> John W Kennedy <jwk...@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"

[glen herrmannsfeldt]

Fritz Wuehler <fr...@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.

-- glen

[John W Kennedy]

On 2012-07-17 21:59:38 +0000, Fritz Wuehler said:

> John W Kennedy <jwk...@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"

[glen herrmannsfeldt]

John W Kennedy <jwk...@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

[glen herrmannsfeldt]

John W Kennedy <jwk...@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

[robin....@gmail.com]

On Wednesday, 18 July 2012 02:08:41 UTC+10, John W Kennedy wrote:
> On 2012-07-17 03:36:50 +0000, xxxx...@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, xxx...@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.

[robin....@gmail.com]

On Wednesday, 18 July 2012 02:12:10 UTC+10, John W Kennedy wrote:

> On 2012-07-17 02:45:33 +0000, rxxx...@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.

[robin....@gmail.com]

On Wednesday, 18 July 2012 02:14:19 UTC+10, John W Kennedy wrote:
> On 2012-07-17 02:51:13 +0000, oxxx...@gmail.com said:
>
> &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;
> &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;
> &gt;&gt; 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.

But in C you can do it without even trying.

[robin....@gmail.com]

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.

[robin....@gmail.com]

On Wednesday, 18 July 2012 09:54:42 UTC+10, glen herrmannsfeldt wrote:

> John W Kennedy &lt;jxxx...@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.

[glen herrmannsfeldt]

robin....@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

[Tim C.]

On Mon, 16 Jul 2012 19:55:09 -0700 (PDT), robin....@gmail.com wrote in
post : <news:f1d70be6-685a-4e29...@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.

[Shmuel Metz]

In <ju4g1q$om4$1...@speranza.aioe.org>, on 07/17/2012

at 07:56 PM, glen herrmannsfeldt <g...@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 spam...@library.lspace.org

[robin....@gmail.com]

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.

[John W Kennedy]

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

--
John W Kennedy

[John W Kennedy]

On 2012-07-17 23:54:42 +0000, glen herrmannsfeldt said:

> John W Kennedy <jwk...@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."

[John W Kennedy]

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"

[John W Kennedy]

I was there.

--
John W Kennedy

[John W Kennedy]

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"

[glen herrmannsfeldt]

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

[glen herrmannsfeldt]

John W Kennedy <jwk...@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

[Fritz Wuehler]

John W Kennedy <jwk...@attglobal.net> wrote:

> On 2012-07-17 21:59:38 +0000, Fritz Wuehler said:
>
> > John W Kennedy <jwk...@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?

> 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.

[glen herrmannsfeldt]

Fritz Wuehler <fr...@spamexpire-201207.rodent.frell.theremailer.net> wrote:

(snip)

> 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.

Well, I believe REP is an instruction prefix, sort of similar
to an extended opcode. For the 8086, it may have refetched
the instruction, or maybe not. By now, I am pretty sure that
it doesn't. A little ugly, but I believe it counts as
one instruction. Still, interruptable like MVCL.

> A null terminated string is not nearly as offensive from
> an assembly coding standpoint on Intel as it is on IBM.

-- glen

[Peter Flass]

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

[Peter Flass]

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

[Peter Flass]

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


--
Pete

[robin....@gmail.com]

On Thursday, 19 July 2012 01:22:21 UTC+10, John W Kennedy wrote:
> On 2012-07-18 01:43:24 +0000, xxxx...@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.

[robin....@gmail.com]

On Thursday, 19 July 2012 09:23:12 UTC+10, Peter Flass wrote:
> On 7/18/2012 1:40 PM, glen herrmannsfeldt wrote:

> > xxxrx...@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?

[John W Kennedy]

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"

[John W Kennedy]

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

[robin....@gmail.com]

On Thursday, 19 July 2012 05:26:05 UTC+10, glen herrmannsfeldt wrote:

> Fritz Wuehler &lt;x...@spamexpire-201207.rodent.frell.theremailer.net&gt; wrote:

> Well, I believe REP is an instruction prefix,

Strictly speaking, yes, that's what Intel calls it.
However, it can be virtually be regarded as an in instruction
when coupled with the relevant string instruction.

> sort of similar
> to an extended opcode. For the 8086, it may have refetched
> the instruction, or maybe not. By now, I am pretty sure that

> it doesn&#39;t. A little ugly, but I believe it counts as

[John W Kennedy]

On 2012-07-18 19:02:35 +0000, Fritz Wuehler said:

> John W Kennedy <jwk...@attglobal.net> wrote:
>
>> On 2012-07-17 21:59:38 +0000, Fritz Wuehler said:
>>
>>> John W Kennedy <jwk...@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"

[John W Kennedy]

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"

[robin....@gmail.com]

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?

[robin....@gmail.com]

On Thursday, 19 July 2012 09:54:46 UTC+10, John W Kennedy wrote:

> On 2012-07-18 23:30:10 +0000, xxxxxx...@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.

[robin....@gmail.com]

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.

[robin....@gmail.com]

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.

[robin....@gmail.com]

On Thursday, 19 July 2012 09:18:22 UTC+10, Peter Flass wrote:

> 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.

With PCP, only one (user) job ran at a time.

[glen herrmannsfeldt]

Peter Flass <Peter...@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

[Shmuel Metz]

In <5005f3ed$0$6065$607e...@cv.net>, on 07/17/2012

at 07:23 PM, John W Kennedy <jwk...@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 spam...@library.lspace.org

[Shmuel Metz]

In <ju8h37$je9$1...@speranza.aioe.org>, on 07/19/2012

at 08:39 AM, glen herrmannsfeldt <g...@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 Metz]

In <50074dc4$0$6079$607e...@cv.net>, on 07/18/2012

at 07:59 PM, John W Kennedy <jwk...@attglobal.net> said:

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

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

[Shmuel Metz]

In <500750e8$0$6054$607e...@cv.net>, on 07/18/2012

at 08:12 PM, John W Kennedy <jwk...@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 Metz]

In <ju7g7u$lk7$2...@dont-email.me>, on 07/18/2012

at 07:18 PM, Peter Flass <Peter...@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 Metz]

In <ju29ql$kk2$1...@speranza.aioe.org>, on 07/16/2012

at 11:58 PM, glen herrmannsfeldt <g...@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.