Re: PL/I question

[Robin Vowels]

On 2023-11-18 03:38, Bernd Oppolzer wrote:

Sorry for jumping in VERY late.

If you have something like

    DCL X CHAR (6);

    X = DATE;

then you will get strange results, because DATE is not recognized as 
the

well-known builtin function DATE which returns the
current date. But instead it is a DECIMAL FLOAT(6) variable


Not when you specify explicit declarations.
In his case, the identifier is marked as not declared, and it is treated
as a compile-time ERROR.

The default in PL/I (F) days for undeclared identifiers whose initial
letter was A-H and O-Z was FLOAT BINARY.


with an undefined value (given the "normal" default rules, inherited
from FORTRAN, which defines an undefined variable depending on its 
first letter ... and, of course, if you don't have the more
modern compiler options which prevent you from using undefined 
variables etc.).


Now, if you want the compiler to use the builtin function DATE instead 
of this undefined variable, you have two choices:


- declare DATE as a BUILTIN function

   DCL DATE BUILTIN;
   X = DATE;

- put parantheses after DATE; that is:

   X = DATE ();

   this way, DATE is known to be the BUILTIN function "by context".

Both variants will do.

Same goes for all other builtin functions without arguments.

HTH,
kind regards

Bernd


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Bernd Oppolzer]

Sorry for jumping in VERY late.

If you have something like

    DCL X CHAR (6);

    X = DATE;

then you will get strange results, because DATE is not recognized as the 
well-known builtin function DATE which returns the
current date. But instead it is a DECIMAL FLOAT(6) variable with an 
undefined value (given the "normal" default rules, inherited
from FORTRAN, which defines an undefined variable depending on its first 
letter ... and, of course, if you don't have the more
modern compiler options which prevent you from using undefined variables 
etc.).


Now, if you want the compiler to use the builtin function DATE instead 
of this undefined variable, you have two choices:


- declare DATE as a BUILTIN function

   DCL DATE BUILTIN;
   X = DATE;

- put parantheses after DATE; that is:

   X = DATE ();

   this way, DATE is known to be the BUILTIN function "by context".

Both variants will do.

Same goes for all other builtin functions without arguments.

HTH,
kind regards

Bernd
(PL/1 teacher since 1991 - and many other stuff, ASSEMBLER, C, DB2, ...)



Am 15.11.2023 um 18:34 schrieb Binyamin Dissen:

A PL/I source code member has

DCL foobar BUILTIN

and must be compiled with RULES(LAXDCL)

I see no reference to FOOBAR as a function call.

My question is if FOOBAR was invoked, what does the BUILTIN clause do? A
different calling sequence? Looking for an internal label?

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Robin Vowels]

The attribute BUILTIN can be used only for a name that is a built-in 
function.
It overrides any prior declaration if the name as a variable or label 
etc

in an outer block.

On 2023-11-16 05:33, Steve Beaver wrote:
BUILTIN is a way to tell the compiler that what ever something like 
SUBSTR doesn’t need to be resolved outside of the object


Sent from my iPhone

No one said I could type with one thumb

On Nov 15, 2023, at 11:33, Binyamin Dissen 
 wrote:


A PL/I source code member has

  DCL foobar BUILTIN

and must be compiled with RULES(LAXDCL)

I see no reference to FOOBAR as a function call.

My question is if FOOBAR was invoked, what does the BUILTIN clause do? 
A

different calling sequence? Looking for an internal label?

--
Binyamin Dissen 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Robin Vowels]

BUILTIN is used when, for example, an identifier that is the same
as the name of a BUILT-IN function has been used as a variable.

Suppose that you want to use that built-in function in an inner block.
Then you declare it as BUILTIN.

E.G. declare sqrt builtin;

This overrides the declaration in the outer block.


On 2023-11-16 04:34, Binyamin Dissen wrote:

A PL/I source code member has

   DCL foobar BUILTIN

and must be compiled with RULES(LAXDCL)

I see no reference to FOOBAR as a function call.

My question is if FOOBAR was invoked, what does the BUILTIN clause do? 
A

different calling sequence? Looking for an internal label?

--
Binyamin Dissen 


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Steve Beaver]

BUILTIN is a way to tell the compiler that what ever something like SUBSTR 
doesn’t need to be resolved outside of the object 

Sent from my iPhone

No one said I could type with one thumb 

> On Nov 15, 2023, at 11:33, Binyamin Dissen  wrote:
> 
> A PL/I source code member has 
> 
>   DCL foobar BUILTIN
> 
> and must be compiled with RULES(LAXDCL)
> 
> I see no reference to FOOBAR as a function call. 
> 
> My question is if FOOBAR was invoked, what does the BUILTIN clause do? A
> different calling sequence? Looking for an internal label?
> 
> --
> Binyamin Dissen 
> http://www.dissensoftware.com
> 
> Director, Dissen Software, Bar & Grill - Israel
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

PL/I question

[Binyamin Dissen]

A PL/I source code member has 

   DCL foobar BUILTIN

and must be compiled with RULES(LAXDCL)

I see no reference to FOOBAR as a function call. 

My question is if FOOBAR was invoked, what does the BUILTIN clause do? A
different calling sequence? Looking for an internal label?

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[zMan]

Kids, kids...take it outside. Or at least to a thread that can be ignored.
Some of us are interested in the original question.

On Wed, Mar 30, 2022 at 12:58 PM Seymour J Metz  wrote:

> Whoosh!
>
> In this case it walks like a dog, purrs like a cat and is definitely not a
> duck.
>
> Don't try to teach your grandmother to suck eggs.
>
> You seem to be willfully ignoring what I actually wrote as well. I made
> specific claims and specific contexts and you seem to be criticizing claims
> that I never made, yet again.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Robin Vowels [robi...@dodo.com.au]
> Sent: Wednesday, March 30, 2022 12:31 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PL/I question
>
> On 2022-03-31 02:38, Seymour J Metz wrote:
> >> Who does that leave?
> >
> > The obvious; your claim is untrue and it is you.
>
> Looks like you have egg on your face again.
>
> >> Put up or shut up.
> >
> > PL/I does not have computed GO TO.
>
> If it looks like a duck, quacks like a duck, it probably is a duck.
>
> Try:
>GO TO X(I);
>
> X(1): A = B;
> ...
> X(2): A = C;
> ...
> X(3): A = D;
> ...
>
> and try:
>
> GOTO (1, 2, 3), K
>
> 1 A = B
>...
> 2 A = B
>...
> 3 A = C
>...
>
> Guess which one is FORTRAN and which is PL/I.
>
> > It has LABEL arrays, which are more
> > useful. There may be cases where a computed GO TO would be clearer if
> > it exiasted, but good or bad, PL/I doesn't have it.
>
> >> Read what I wrote.
> >
> > I did; it's BS.
>
> More egg on your face.
>
> >>  White space has noting to do with it.
> >
> > That's a perfect example of BS. In FORTRAN, DO 500 I=1.10 is an
> > assignment statement because the blanks are not significant. In PL/I,
> > DO I=1.10; is still a DO statement, because spaces are not allowed
> > inside a variable name.
>
> That is irrelevant to whether the DO statement in PL/I was taken
> from FORTRAN.
>
>
> > 
> > From: IBM Mainframe Discussion List  on
> > behalf of Robin Vowels 
> > Sent: Tuesday, March 29, 2022 9:51 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: PL/I question
> >
> > On 2022-03-30 00:06, Seymour J Metz wrote:
> >> It's obvious that one of us doesn't know what he's talking about,
> >
> > And it's not me.  Who does that leave?
> >
> >> especially as you cited things that don't even exist in PL/I as being
> >> derived from FORTRAN.
> >
> > Put up or shut up.
> >
> >> And you still haven't answered whether you
> >> seriouslyu believe thaat the FORTRAN DO resembles the PL/I DO more
> >> than the ALGOL FOR statement does.
> >
> > Read what I wrote.
> >
> >> Your purported explanation of the difference in DO between FORTRAN and
> >> PL/I is ludicrous, because the rules for "white spacew" in FORTRAN and
> >> PL/I are very different.
> >
> > White space has noting to do with it.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Seymour J Metz]

Whoosh!

In this case it walks like a dog, purrs like a cat and is definitely not a duck.

Don't try to teach your grandmother to suck eggs.

You seem to be willfully ignoring what I actually wrote as well. I made 
specific claims and specific contexts and you seem to be criticizing claims 
that I never made, yet again. 


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Robin Vowels [robi...@dodo.com.au]
Sent: Wednesday, March 30, 2022 12:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

On 2022-03-31 02:38, Seymour J Metz wrote:
>> Who does that leave?
>
> The obvious; your claim is untrue and it is you.

Looks like you have egg on your face again.

>> Put up or shut up.
>
> PL/I does not have computed GO TO.

If it looks like a duck, quacks like a duck, it probably is a duck.

Try:
   GO TO X(I);

X(1): A = B;
...
X(2): A = C;
...
X(3): A = D;
...

and try:

GOTO (1, 2, 3), K

1 A = B
   ...
2 A = B
   ...
3 A = C
   ...

Guess which one is FORTRAN and which is PL/I.

> It has LABEL arrays, which are more
> useful. There may be cases where a computed GO TO would be clearer if
> it exiasted, but good or bad, PL/I doesn't have it.

>> Read what I wrote.
>
> I did; it's BS.

More egg on your face.

>>  White space has noting to do with it.
>
> That's a perfect example of BS. In FORTRAN, DO 500 I=1.10 is an
> assignment statement because the blanks are not significant. In PL/I,
> DO I=1.10; is still a DO statement, because spaces are not allowed
> inside a variable name.

That is irrelevant to whether the DO statement in PL/I was taken
from FORTRAN.


> 
> From: IBM Mainframe Discussion List  on
> behalf of Robin Vowels 
> Sent: Tuesday, March 29, 2022 9:51 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PL/I question
>
> On 2022-03-30 00:06, Seymour J Metz wrote:
>> It's obvious that one of us doesn't know what he's talking about,
>
> And it's not me.  Who does that leave?
>
>> especially as you cited things that don't even exist in PL/I as being
>> derived from FORTRAN.
>
> Put up or shut up.
>
>> And you still haven't answered whether you
>> seriouslyu believe thaat the FORTRAN DO resembles the PL/I DO more
>> than the ALGOL FOR statement does.
>
> Read what I wrote.
>
>> Your purported explanation of the difference in DO between FORTRAN and
>> PL/I is ludicrous, because the rules for "white spacew" in FORTRAN and
>> PL/I are very different.
>
> White space has noting to do with it.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Robin Vowels]

On 2022-03-31 02:38, Seymour J Metz wrote:

Who does that leave?


The obvious; your claim is untrue and it is you.


Looks like you have egg on your face again.


Put up or shut up.


PL/I does not have computed GO TO.


If it looks like a duck, quacks like a duck, it probably is a duck.

Try:
  GO TO X(I);

X(1): A = B;
...
X(2): A = C;
...
X(3): A = D;
...

and try:

GOTO (1, 2, 3), K

1 A = B
  ...
2 A = B
  ...
3 A = C
  ...

Guess which one is FORTRAN and which is PL/I.


It has LABEL arrays, which are more
useful. There may be cases where a computed GO TO would be clearer if
it exiasted, but good or bad, PL/I doesn't have it.



Read what I wrote.


I did; it's BS.


More egg on your face.


 White space has noting to do with it.


That's a perfect example of BS. In FORTRAN, DO 500 I=1.10 is an
assignment statement because the blanks are not significant. In PL/I,
DO I=1.10; is still a DO statement, because spaces are not allowed
inside a variable name.


That is irrelevant to whether the DO statement in PL/I was taken
from FORTRAN.




From: IBM Mainframe Discussion List  on
behalf of Robin Vowels 
Sent: Tuesday, March 29, 2022 9:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

On 2022-03-30 00:06, Seymour J Metz wrote:

It's obvious that one of us doesn't know what he's talking about,


And it's not me.  Who does that leave?


especially as you cited things that don't even exist in PL/I as being
derived from FORTRAN.


Put up or shut up.


And you still haven't answered whether you
seriouslyu believe thaat the FORTRAN DO resembles the PL/I DO more
than the ALGOL FOR statement does.


Read what I wrote.


Your purported explanation of the difference in DO between FORTRAN and
PL/I is ludicrous, because the rules for "white spacew" in FORTRAN and
PL/I are very different.


White space has noting to do with it.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Seymour J Metz]

> Who does that leave?

The obvious; your claim is untrue and it is you.

> Put up or shut up.

PL/I does not have computed GO TO. It has LABEL arrays, which are more useful. 
There may be cases where a computed GO TO would be clearer if it exiasted, but 
good or bad, PL/I doesn't have it.

> Read what I wrote.

I did; it's BS.

>  White space has noting to do with it. 

That's a perfect example of BS. In FORTRAN, DO 500 I=1.10 is an assignment 
statement because the blanks are not significant. In PL/I, DO I=1.10; is still 
a DO statement, because spaces are not allowed inside a variable name.




From: IBM Mainframe Discussion List  on behalf of 
Robin Vowels 
Sent: Tuesday, March 29, 2022 9:51 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

On 2022-03-30 00:06, Seymour J Metz wrote:
> It's obvious that one of us doesn't know what he's talking about,

And it's not me.  Who does that leave?

> especially as you cited things that don't even exist in PL/I as being
> derived from FORTRAN.

Put up or shut up.

> And you still haven't answered whether you
> seriouslyu believe thaat the FORTRAN DO resembles the PL/I DO more
> than the ALGOL FOR statement does.

Read what I wrote.

> Your purported explanation of the difference in DO between FORTRAN and
> PL/I is ludicrous, because the rules for "white spacew" in FORTRAN and
> PL/I are very different.

White space has noting to do with it.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Seymour J Metz]

A pedantic compiler would not flag code that violated no rules. Paranoid 
compilers might flag the FORTRAN "DO 500 I=1.10" and the PL/I "DO I=1.10" as 
possibly unintended, but pedantic compilers would quietly accept both. Note 
that only the FORTRAN is an assignment statement.


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, March 29, 2022 10:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

On Tue, 29 Mar 2022 09:22:10 -0400, David Spiegel wrote:
>
>You said: "... BTW, the change in format of the DO was essential
>in preventing the flaw in FORTRAN (which still exists)
>by which a period instead of the first comma
>changes the DO statement into an assignment statement.  ..."
>
Do pedantic compilers warn of that?  But it might be inicidental
to warning of unused variables.

Most languages have such pitfalls.  A favorite is the ALGOL-60
implied comment.  Pedantic compilers warn of that.

>Have you ever read the Datamation article regarding the comma which cost
>$15,00,000 (in the '60s)?
>
Did you just supply  an example ("$15,00.000")?  If not, cite.

In IT or in law?

--
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Seymour J Metz]

> REXX ==? Unix shell script.

Not what I wrote.  "IBM does support ANSI REXX stream I/O within a Unix shell 
script." does not mean *every* shell script, only those written in REXX.


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Wednesday, March 30, 2022 10:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

On Wed, 30 Mar 2022 14:13:56 +, Seymour J Metz  wrote:

>To be fair, IBM does support ANSI REXX stream I/O within a Unix shell script.
>
To be fair, it lacks SIGNAL ON NOTREADY.

Yes, I know it's an external function package.

REXX ==? Unix shell script.

--
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Paul Gilmartin]

On Wed, 30 Mar 2022 14:13:56 +, Seymour J Metz  wrote:

>To be fair, IBM does support ANSI REXX stream I/O within a Unix shell script.
>
To be fair, it lacks SIGNAL ON NOTREADY.

Yes, I know it's an external function package.

REXX ==? Unix shell script.

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Seymour J Metz]

However, buffer overruns are characteristic of languages with no range 
checking. Of course, you can write C in PL/I with, e.g, (NOSTRINGRANGE) 
prefixes.


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Wednesday, March 30, 2022 10:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

On Wed, 30 Mar 2022 14:53:57 +0100, Rupert Reynolds wrote:

>That's a common problem, certainly, but if we include the wider world of
>micros and minis, I'd bet that buffer overuns related to null-teminated
>strings (BLEAH!) are in the lead :-)
>
Buffer overruns are hardly peculiar to null-temniated strinigs.  Rather,
they result from indolent programmers' neglecting to check the length
before the move or the status after; using strcat() and sprinitf()
instead of strncat and snprintf(); etc.

What should be done in HLASM?  Use unprotected MVCL, or define
data types with explicit lengths and rely on macros to move data with
protection?

Should an attempted buffer overrun throw an exception?

--
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Seymour J Metz]

> although FORTRAN is very special,
because it allows spaces even in the middle of identifiers

Exactly. Were "DO I=1,10" a valid PL/I DO statement, typing a period 
instead of a comma might make it the wrong DO statement, but could not make it 
an assignment statement.

>  IF 9 < ZZ < 20 THEN DO;

Yes, there are languages that allow what was intended.



From: IBM Mainframe Discussion List  on behalf of 
Bernd Oppolzer 
Sent: Tuesday, March 29, 2022 4:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

As it seems from other posts, the story is not completely true;
there was indeed such an error somewhere sometime with NASA,
but the error that destroyed the Mariner spacecraft was different (a
missing hyphen on
a hand-written variable specification, which had not been translated
correctly to computer code).

I believe that there are similar pitfalls in other languages, too,
although FORTRAN is very special,
because it allows spaces even in the middle of identifiers (and
numbers), such as

DO  3  I=   1 . 10

which in every other programming language would disqualify as an
assignment statement
because of the spaces around the DO symbol.

My favorite PL/1 example from a real world program is this:

IF 9 < ZZ < 20 THEN DO; ...

someone with a math background obviously coded this :-)
the expectation was, that the statement be executed if ZZ is in the
range 10 to 19.

Unfortunately, this is translated by PL/1 as follows:

IF (9 < ZZ) < 20 THEN DO;

9 < ZZ is a result of type BIT(1) and yields '0'B or '1'B, depending on ZZ;
this result is converted to decimal, so that it can be compared to the
decimal constant 20
and the result therefore is ALWAYS FALSE.

This is clearly not what the coder had intended.

We detected this luckily, using a site-written PL/1 diagnosing tool,
which complained because of the
implied type conversion (BIT(1) to decimal). About 2 percent of the
total PL/1 code base
had similar logic errors, which were undetected before we scanned all
the source codes with our
new tool in 2007. After that, we changed the deployment processes, so
that the new tool
runs with every software deployment.

Kind regards

Bernd


Am 29.03.2022 um 17:03 schrieb David Spiegel:
> Hi gil,
> I remember reading the article approximately 40 years ago.
> It was in Datamation, which was an IT magazine.
> You've never heard of Datamation before? ... How many years have you
> been in this business?
>
> The story was related to an unmanned spaceship (i.e. Venus Probe)
> whose trajectory was calculated by a FORTRAN program
> with the following statements:
> DO 3  I=1.3
> .
> .
> 3
>
> Since there was a period between "1" and "3" (instead of a comma), the
> loop ran precisely once
> and assigned 1.3 to DO3I (FORTRAN removes blanks before compile) a
> variable which is automatically declared REAL, because its first letter
> is outside the INTEGER Range I-N.
>
> Here is another reference (not Datamation) (which does not mention the
> financial loss)
> Please see:
> IEEE Xplore Full-Text PDF:
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fieeexplore.ieee.org%2Fstamp%2Fstamp.jsp%3Farnumber%3D4392951data=04%7C01%7Csmetz3%40gmu.edu%7C4616b9f6e98748b02adf08da11c6c267%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C637841842622249901%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=2%2BCvgzY6DMp%2BZO1%2F4m%2F%2BKYzJ0CHWTlZZs4FCIRYUW2k%3Dreserved=0>
> Page 58
>
> Regards,
> David
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Paul Gilmartin]

On Wed, 30 Mar 2022 14:53:57 +0100, Rupert Reynolds wrote:

>That's a common problem, certainly, but if we include the wider world of
>micros and minis, I'd bet that buffer overuns related to null-teminated
>strings (BLEAH!) are in the lead :-)
> 
Buffer overruns are hardly peculiar to null-temniated strinigs.  Rather,
they result from indolent programmers' neglecting to check the length
before the move or the status after; using strcat() and sprinitf()
instead of strncat and snprintf(); etc.

What should be done in HLASM?  Use unprotected MVCL, or define
data types with explicit lengths and rely on macros to move data with
protection?

Should an attempted buffer overrun throw an exception?

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Seymour J Metz]

Yes, the original PL/I inherited the original I-N rule as a default, and IBM 
later changed that.

Yes, Algol 58, 60 and 68 were all stronger in Europe than in US, although there 
were two Algol 58 based languages developed in the US. 


From: IBM Mainframe Discussion List  on behalf of 
Bernd Oppolzer 
Sent: Tuesday, March 29, 2022 5:20 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

In the context of the error mentioned in this thread with the FORTRAN
variable DO3I etc.,
(a statement looks like a loop control statement, but is in fact a
simple assignment,
because of a period instead of a comma),
it is important to notice that PL/1 indeed inherited some
significant "bad habits" from FORTRAN, for example the idea of implicit
definitions
of variables depending on the first letter of the name ... the DEFAULT,
AFAIK,
for PL/1 was that variables starting with I to N have the BIN FIXED(15)
attribute etc.,
all others are FLOAT. This was done for FORTRAN compatibility;
IIRC, when IBM introduced PL/1, there was indeed the idea that the
scientific community which used heavily FORTRAN at that time should
convert to PL/1.
So IBM tried to make the migration as easy as possible.

Other languages, like Pascal for example, requested that all variables
be declared;
this is common today (and the error mentioned above could not occur).
The FORTRAN-PL/1-approach turned out to be an error. Later versions of PL/1
tried to resolve this.

Algol was an European effort, and it took some time for IBM to accept
(some of)
the ideas and concepts of Algol for their new language.

Kind regards

Bernd


Am 29.03.2022 um 23:05 schrieb CM Poncelet:
> +1
>
> ... and the GUIDE group then insisted that the new PL/I language should
> also support COBOL's I/O processing as well as Fortran, at a 1962-64
> conference (whenever it was.)
>
>
> On 28/03/2022 10:43, Seymour J Metz wrote:
>> I'm fully aware of the initial name; the fact remains that IBM and SHARE 
>> looked at three languages, and that FORTRAN had the least influence of the 
>> three. Most of the language derives from Algol 60 and COBOL, and the most 
>> obvious feature from FORTRAN has gone by the wayside.
>>
>>
>> --
>> Shmuel (Seymour J.) Metz
>> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmason.gmu.edu%2F~smetz3data=04%7C01%7Csmetz3%40gmu.edu%7C085a100ae1a647ad927a08da11ca1a78%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C637841856970331813%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=TzkDFWU87cTIP2E%2BeIKGdIWLjOIYJKU0dcOCymUjCCM%3Dreserved=0
>>
>> 
>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
>> Robin Vowels [robi...@dodo.com.au]
>> Sent: Monday, March 28, 2022 4:53 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: PL/I question
>>
>> On 2022-03-28 19:10, Seymour J Metz wrote:
>>> Exaclly, especially since Algol 60 was one of the three languages
>>> folded into PL/I.
>> FORTRAN, not Algol, was the starting-point for PL/I.
>> It was even called FORTRAN VI.
>> Features of both Algol and COBOL were incorporated into
>> the language.
>>
>>> 
>>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
>>> behalf of David Spiegel [dspiegel...@hotmail.com]
>>> Sent: Sunday, March 27, 2022 11:38 PM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: PL/I question
>>>
>>> Hi R'Shmuel AMV"SH,
>>> Like ALGOL and Pascal?
>>>
>>> Regards,
>>> David
>>>
>>> On 2022-03-27 22:52, Seymour J Metz wrote:
>>>> Personally, I wish that IBM had chosen ":=" for assignment.
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> .
>>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Seymour J Metz]

To be fair, IBM does support ANSI REXX stream I/O within a Unix shell script.


From: IBM Mainframe Discussion List  on behalf of 
Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sent: Tuesday, March 29, 2022 7:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

On Tue, 29 Mar 2022 15:41:14 -0700, Charles Mills  wrote:

>I wrote a commercial product in Borland Turbo Pascal somewhere around 1988. We 
>ended up re-writing it in C. Some combination of the greater availability of 
>developers and/or an inability to do certain things* in Pascal that we could 
>do in C. I don't recall exactly.
>
I once wrote an RTF to Script translator in Apple Pascal.  A co-worker
asked fora copy, then diiscovered Borland couldn't deal with it.
II had used IEEE standard I/O which Borland shunned.

Kinida like IBM Rexx vs. ANSI standard Rexx I/O.

I/O may be hard, but vendors are too eager to shirk it.

--
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Seymour J Metz]

It is easy to recognize that "if (foo=constant)" is probably meant to be "if 
(foo == constant)", but "if (foo = expression)" might actually be what was 
meant.


From: IBM Mainframe Discussion List  on behalf of 
Charles Mills 
Sent: Tuesday, March 29, 2022 6:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

Well, while we are digressing ...

There was discussion earlier of the use of the equal sign for assignment versus 
comparison.

I am going to guess that THE most common cause of C/C++ program errors is the 
mis-use of = for comparison. (The comparison operator in C and C++ is ==.) In C 
if you code

if (foo = 3) bar = 5;

Then the compiler generates code to assign 3 to foo, test the result (3) for 
truth (not 0) and then execute the conditional statement. The above has the 
same effect as

foo = 3;
bar = 5;

If I am recalling the story correctly, a malicious programmer *almost* 
succeeded in inserting code into the Linux kernel of the form

if (uid = 0) ...

The code appears to be testing the uid for 0, but in reality is making the uid 
0. Someone who know how to get to the code path could make themselves into 
superuser.

I like := for assignment, but I believe C eliminated the ambiguity of = by 
choosing == for comparison, by analogy to all of the other 2-character 
comparison operators (>=, !=, etc.).=

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bernd Oppolzer
Sent: Tuesday, March 29, 2022 1:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

As it seems from other posts, the story is not completely true;
there was indeed such an error somewhere sometime with NASA,
but the error that destroyed the Mariner spacecraft was different (a
missing hyphen on
a hand-written variable specification, which had not been translated
correctly to computer code).

I believe that there are similar pitfalls in other languages, too,
although FORTRAN is very special,
because it allows spaces even in the middle of identifiers (and
numbers), such as

DO  3  I=   1 . 10

which in every other programming language would disqualify as an
assignment statement
because of the spaces around the DO symbol.

My favorite PL/1 example from a real world program is this:

IF 9 < ZZ < 20 THEN DO; ...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Charles Mills]

I would certainly suspect that for *security* problems buffer overruns are far 
and away the biggest problem. You see it all the time: the programmer declares 
a 50-byte buffer for reading-in an 8 byte value, and then just assumes that is 
"big enough" and does not limit or check the read.

For problems as a whole, I'm still going with =. 

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Rupert Reynolds
Sent: Wednesday, March 30, 2022 6:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

That's a common problem, certainly, but if we include the wider world of
micros and minis, I'd bet that buffer overuns related to null-teminated
strings (BLEAH!) are in the lead :-)

I once saw a report quoting Microsoft that half of all vulnerabilities were
buffer overruns.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Rupert Reynolds]

That's a common problem, certainly, but if we include the wider world of
micros and minis, I'd bet that buffer overuns related to null-teminated
strings (BLEAH!) are in the lead :-)

I once saw a report quoting Microsoft that half of all vulnerabilities were
buffer overruns.

I also saw a Dave Plummer YT (Dave's Garage) video recently, in which he
said that MS programmers tended to coypu pasty code, rather than reuse.

Do I spot a pattern? :-)

On Tue., Mar. 29, 2022, 23:10 Charles Mills,  wrote:

> Well, while we are digressing ...
>
> There was discussion earlier of the use of the equal sign for assignment
> versus comparison.
>
> I am going to guess that THE most common cause of C/C++ program errors is
> the mis-use of = for comparison. (The comparison operator in C and C++ is
> ==.) In C if you code
>
> if (foo = 3) bar = 5;
>
> Then the compiler generates code to assign 3 to foo, test the result (3)
> for truth (not 0) and then execute the conditional statement. The above has
> the same effect as
>
> foo = 3;
> bar = 5;
>
> If I am recalling the story correctly, a malicious programmer *almost*
> succeeded in inserting code into the Linux kernel of the form
>
> if (uid = 0) ...
>
> The code appears to be testing the uid for 0, but in reality is making the
> uid 0. Someone who know how to get to the code path could make themselves
> into superuser.
>
> I like := for assignment, but I believe C eliminated the ambiguity of = by
> choosing == for comparison, by analogy to all of the other 2-character
> comparison operators (>=, !=, etc.).=
>
> Charles
>
>
>
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

ASCII was RE: PL/I question

[Seymour J Metz]

An early version of ASCII had some code points with dual assignments of 
characters, and included left and up arrows.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Paul Gilmartin [000433f07816-dmarc-requ...@listserv.ua.edu]
Sent: Wednesday, March 30, 2022 8:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

On Wed, 30 Mar 2022 19:50:12 +0800, David Crayford wrote:
>>
>> That may well be. I stand by my claim that it is a common source of errors.
>
>I agree. Which is why a lot of C programmers used to used to code if 
>statements with no lvalues:
>
>if (3 = foo) ...
>
A similar practice applies to Shell test.  Code:
if [ 3 = $foo ] ...
rather than:
if [ $foo = 3 ] ...
lest $foo evaluate to a unary operator.  The habit of writing the constant on 
the
right may come from natural languages where "is" can denote either identity
or set membership.

I favor ":=", a typographically asymmetric operator for a semantically
asymmetric operation.

It's unfortunate that ASCII doesn't contain "←".  Some languages assign
rightward -- "GIVING or "→".

--
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Paul Gilmartin]

On Wed, 30 Mar 2022 19:50:12 +0800, David Crayford wrote:
>>
>> That may well be. I stand by my claim that it is a common source of errors.
>
>I agree. Which is why a lot of C programmers used to used to code if 
>statements with no lvalues:
>
>if (3 = foo) ...
>
A similar practice applies to Shell test.  Code:
if [ 3 = $foo ] ...
rather than:
if [ $foo = 3 ] ...
lest $foo evaluate to a unary operator.  The habit of writing the constant on 
the
right may come from natural languages where "is" can denote either identity
or set membership.

I favor ":=", a typographically asymmetric operator for a semantically
asymmetric operation.

It's unfortunate that ASCII doesn't contain "←".  Some languages assign
rightward -- "GIVING or "→".

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[David Crayford]

On Tue, 2022-03-29 at 20:35 -0700, Charles Mills wrote:
> > Almost all modern C/C++ compilers will flag that as a warning
> 
> That may well be. I stand by my claim that it is a common source of errors.

I agree. Which is why a lot of C programmers used to used to code if statements 
with no lvalues:

if (3 = foo) ...

> 
> I am not sure if z/OS XLC flags it. I am also not sure whether z/OS XLC is a 
> modern C/C++ compiler. 

xlclang does. In fact it goes further and will validate that printf() arguments 
match the format specifiers and will also check for buffer overflows. But it's 
64bit only so can can't be used with
legacy code without jumping through AMODE switching hoops. The new LLVM/clang 
compiler currently in beta solves those problems and is bang up to date as IBM 
have joined the LLVM open source commnunity
and are committing z/OS patches. It supports 31bit and C++20 with all the nice 
stuff like modules and concepts. We're hanging out for it to GA!

> 
> The intentional use of = in a condition is a favorite of old-style "how few 
> keystrokes can I use" C programmers, for example in the formulation
> 
> if (myfile = fopen(...)) ...  // executes code if fopen is successful
> 
> Charles
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of David Crayford
> Sent: Tuesday, March 29, 2022 7:49 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PL/I question
> 
> On Tue, 2022-03-29 at 15:10 -0700, Charles Mills wrote:
> > Well, while we are digressing ...
> > 
> > There was discussion earlier of the use of the equal sign for assignment 
> > versus comparison.
> > 
> > I am going to guess that THE most common cause of C/C++ program errors is 
> > the mis-use of = for comparison. (The comparison operator in C and C++ is 
> > ==.) In C if you code
> > 
> > if (foo = 3) bar = 5;
> > 
> > Then the compiler generates code to assign 3 to foo, test the result (3) 
> > for truth (not 0) and then execute the conditional statement. The above has 
> > the same effect as
> 
> Almost all modern C/C++ compilers will flag that as a warning. And there are 
> options to promote warnings to errors. For example:
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Charles Mills]

> Almost all modern C/C++ compilers will flag that as a warning

That may well be. I stand by my claim that it is a common source of errors.

I am not sure if z/OS XLC flags it. I am also not sure whether z/OS XLC is a 
modern C/C++ compiler. 

The intentional use of = in a condition is a favorite of old-style "how few 
keystrokes can I use" C programmers, for example in the formulation

if (myfile = fopen(...)) ...  // executes code if fopen is successful

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David Crayford
Sent: Tuesday, March 29, 2022 7:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

On Tue, 2022-03-29 at 15:10 -0700, Charles Mills wrote:
> Well, while we are digressing ...
> 
> There was discussion earlier of the use of the equal sign for assignment 
> versus comparison.
> 
> I am going to guess that THE most common cause of C/C++ program errors is the 
> mis-use of = for comparison. (The comparison operator in C and C++ is ==.) In 
> C if you code
> 
> if (foo = 3) bar = 5;
> 
> Then the compiler generates code to assign 3 to foo, test the result (3) for 
> truth (not 0) and then execute the conditional statement. The above has the 
> same effect as

Almost all modern C/C++ compilers will flag that as a warning. And there are 
options to promote warnings to errors. For example:

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[David Crayford]

On Tue, 2022-03-29 at 15:10 -0700, Charles Mills wrote:
> Well, while we are digressing ...
> 
> There was discussion earlier of the use of the equal sign for assignment 
> versus comparison.
> 
> I am going to guess that THE most common cause of C/C++ program errors is the 
> mis-use of = for comparison. (The comparison operator in C and C++ is ==.) In 
> C if you code
> 
> if (foo = 3) bar = 5;
> 
> Then the compiler generates code to assign 3 to foo, test the result (3) for 
> truth (not 0) and then execute the conditional statement. The above has the 
> same effect as

Almost all modern C/C++ compilers will flag that as a warning. And there are 
options to promote warnings to errors. For example:

❯ clang -Werror -o a a.c
a.c:6:11: error: using the result of an assignment as a condition without 
parentheses [-Werror,-Wparentheses]
if (a = 2) puts("bugger");
~~^~~
a.c:6:11: note: place parentheses around the assignment to silence this warning
if (a = 2) puts("bugger");
  ^
()
a.c:6:11: note: use '==' to turn this assignment into an equality comparison
if (a = 2) puts("bugger");
  ^
  ==
1 error generated.

I use the CLion IDE which uses clang-tidy to check for errors while I type. 
Most editors such as Vim, VS Code etc support clang integration including 
Visual Studio.

> 
> foo = 3;
> bar = 5;  
> 
> If I am recalling the story correctly, a malicious programmer *almost* 
> succeeded in inserting code into the Linux kernel of the form
> 
> if (uid = 0) ...
> 
> The code appears to be testing the uid for 0, but in reality is making the 
> uid 0. Someone who know how to get to the code path could make themselves 
> into superuser.
> 
> I like := for assignment, but I believe C eliminated the ambiguity of = by 
> choosing == for comparison, by analogy to all of the other 2-character 
> comparison operators (>=, !=, etc.).=
> 
> Charles
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Bernd Oppolzer
> Sent: Tuesday, March 29, 2022 1:57 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PL/I question
> 
> As it seems from other posts, the story is not completely true;
> there was indeed such an error somewhere sometime with NASA,
> but the error that destroyed the Mariner spacecraft was different (a 
> missing hyphen on
> a hand-written variable specification, which had not been translated 
> correctly to computer code).
> 
> I believe that there are similar pitfalls in other languages, too, 
> although FORTRAN is very special,
> because it allows spaces even in the middle of identifiers (and 
> numbers), such as
> 
> DO  3  I=   1 . 10
> 
> which in every other programming language would disqualify as an 
> assignment statement
> because of the spaces around the DO symbol.
> 
> My favorite PL/1 example from a real world program is this:
> 
> IF 9 < ZZ < 20 THEN DO; ...
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Charles Mills]

I thought Turbo Pascal was awesome. I came from a background where I thought 
normal program development was punch your program into cards, hand it to the 
operators, come back tomorrow for the listing. The Turbo Pascal was an IDE. If 
you had a compile error the source code popped up on your screen with the 
cursor at the error. I thought I had died and gone to heaven.

But it was what it was. Not sure if you could call out to assembler. The 
product needed to hook two or three DOS interrupts.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, March 29, 2022 4:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

On Tue, 29 Mar 2022 15:41:14 -0700, Charles Mills  wrote:

>I wrote a commercial product in Borland Turbo Pascal somewhere around 1988. We 
>ended up re-writing it in C. Some combination of the greater availability of 
>developers and/or an inability to do certain things* in Pascal that we could 
>do in C. I don't recall exactly.
>
I once wrote an RTF to Script translator in Apple Pascal.  A co-worker
asked fora copy, then diiscovered Borland couldn't deal with it.
II had used IEEE standard I/O which Borland shunned.

Kinida like IBM Rexx vs. ANSI standard Rexx I/O.

I/O may be hard, but vendors are too eager to shirk it.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Paul Gilmartin]

On Tue, 29 Mar 2022 15:41:14 -0700, Charles Mills  wrote:

>I wrote a commercial product in Borland Turbo Pascal somewhere around 1988. We 
>ended up re-writing it in C. Some combination of the greater availability of 
>developers and/or an inability to do certain things* in Pascal that we could 
>do in C. I don't recall exactly.
>
I once wrote an RTF to Script translator in Apple Pascal.  A co-worker
asked fora copy, then diiscovered Borland couldn't deal with it.
II had used IEEE standard I/O which Borland shunned.

Kinida like IBM Rexx vs. ANSI standard Rexx I/O.

I/O may be hard, but vendors are too eager to shirk it.

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Charles Mills]

I wrote a commercial product in Borland Turbo Pascal somewhere around 1988. We 
ended up re-writing it in C. Some combination of the greater availability of 
developers and/or an inability to do certain things* in Pascal that we could do 
in C. I don't recall exactly.

*DOS interrupt handlers.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bob Bridges
Sent: Tuesday, March 29, 2022 3:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

I'm curious:  How much ALGOL is in use in the US?  I learned it while working 
at a university (on a PDP-10), and used it quite a bit for those two years.  
Occasionally I've seen it mentioned in job postings, but not very much; I've 
been told it's bigger in Europe.  How many of you have used it in your jobs, 
and how much?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Bob Bridges]

I'm curious:  How much ALGOL is in use in the US?  I learned it while working 
at a university (on a PDP-10), and used it quite a bit for those two years.  
Occasionally I've seen it mentioned in job postings, but not very much; I've 
been told it's bigger in Europe.  How many of you have used it in your jobs, 
and how much?

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* We keep forgetting that God is a person.  We don't learn to love someone 
without it changing us.  That is just the nature of love that reflects the 
heart of God.  Because God's love is unchanging, the second person of the 
Trinity, Jesus of Nazareth, now has a scarred body.  The Trinity is different 
because of love.  -from "A Praying Life" by Paul E Miller */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Bernd Oppolzer
Sent: Tuesday, March 29, 2022 17:21

Algol was an European effort, and it took some time for IBM to accept (some of) 
the ideas and concepts of Algol for their new language.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Charles Mills]

Well, while we are digressing ...

There was discussion earlier of the use of the equal sign for assignment versus 
comparison.

I am going to guess that THE most common cause of C/C++ program errors is the 
mis-use of = for comparison. (The comparison operator in C and C++ is ==.) In C 
if you code

if (foo = 3) bar = 5;

Then the compiler generates code to assign 3 to foo, test the result (3) for 
truth (not 0) and then execute the conditional statement. The above has the 
same effect as

foo = 3;
bar = 5;  

If I am recalling the story correctly, a malicious programmer *almost* 
succeeded in inserting code into the Linux kernel of the form

if (uid = 0) ...

The code appears to be testing the uid for 0, but in reality is making the uid 
0. Someone who know how to get to the code path could make themselves into 
superuser.

I like := for assignment, but I believe C eliminated the ambiguity of = by 
choosing == for comparison, by analogy to all of the other 2-character 
comparison operators (>=, !=, etc.).=

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bernd Oppolzer
Sent: Tuesday, March 29, 2022 1:57 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

As it seems from other posts, the story is not completely true;
there was indeed such an error somewhere sometime with NASA,
but the error that destroyed the Mariner spacecraft was different (a 
missing hyphen on
a hand-written variable specification, which had not been translated 
correctly to computer code).

I believe that there are similar pitfalls in other languages, too, 
although FORTRAN is very special,
because it allows spaces even in the middle of identifiers (and 
numbers), such as

DO  3  I=   1 . 10

which in every other programming language would disqualify as an 
assignment statement
because of the spaces around the DO symbol.

My favorite PL/1 example from a real world program is this:

IF 9 < ZZ < 20 THEN DO; ...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Bernd Oppolzer]

In the context of the error mentioned in this thread with the FORTRAN 
variable DO3I etc.,
(a statement looks like a loop control statement, but is in fact a 
simple assignment,

because of a period instead of a comma),
it is important to notice that PL/1 indeed inherited some
significant "bad habits" from FORTRAN, for example the idea of implicit 
definitions
of variables depending on the first letter of the name ... the DEFAULT, 
AFAIK,
for PL/1 was that variables starting with I to N have the BIN FIXED(15) 
attribute etc.,

all others are FLOAT. This was done for FORTRAN compatibility;
IIRC, when IBM introduced PL/1, there was indeed the idea that the
scientific community which used heavily FORTRAN at that time should 
convert to PL/1.

So IBM tried to make the migration as easy as possible.

Other languages, like Pascal for example, requested that all variables 
be declared;

this is common today (and the error mentioned above could not occur).
The FORTRAN-PL/1-approach turned out to be an error. Later versions of PL/1
tried to resolve this.

Algol was an European effort, and it took some time for IBM to accept 
(some of)

the ideas and concepts of Algol for their new language.

Kind regards

Bernd


Am 29.03.2022 um 23:05 schrieb CM Poncelet:

+1
  
... and the GUIDE group then insisted that the new PL/I language should

also support COBOL's I/O processing as well as Fortran, at a 1962-64
conference (whenever it was.)


On 28/03/2022 10:43, Seymour J Metz wrote:

I'm fully aware of the initial name; the fact remains that IBM and SHARE looked 
at three languages, and that FORTRAN had the least influence of the three. Most 
of the language derives from Algol 60 and COBOL, and the most obvious feature 
from FORTRAN has gone by the wayside.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Robin Vowels [robi...@dodo.com.au]
Sent: Monday, March 28, 2022 4:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

On 2022-03-28 19:10, Seymour J Metz wrote:

Exaclly, especially since Algol 60 was one of the three languages
folded into PL/I.

FORTRAN, not Algol, was the starting-point for PL/I.
It was even called FORTRAN VI.
Features of both Algol and COBOL were incorporated into
the language.



From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
behalf of David Spiegel [dspiegel...@hotmail.com]
Sent: Sunday, March 27, 2022 11:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

Hi R'Shmuel AMV"SH,
Like ALGOL and Pascal?

Regards,
David

On 2022-03-27 22:52, Seymour J Metz wrote:

Personally, I wish that IBM had chosen ":=" for assignment.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[CM Poncelet]

+1
 
... and the GUIDE group then insisted that the new PL/I language should
also support COBOL's I/O processing as well as Fortran, at a 1962-64
conference (whenever it was.)  


On 28/03/2022 10:43, Seymour J Metz wrote:
> I'm fully aware of the initial name; the fact remains that IBM and SHARE 
> looked at three languages, and that FORTRAN had the least influence of the 
> three. Most of the language derives from Algol 60 and COBOL, and the most 
> obvious feature from FORTRAN has gone by the wayside.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> Robin Vowels [robi...@dodo.com.au]
> Sent: Monday, March 28, 2022 4:53 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PL/I question
>
> On 2022-03-28 19:10, Seymour J Metz wrote:
>> Exaclly, especially since Algol 60 was one of the three languages
>> folded into PL/I.
> FORTRAN, not Algol, was the starting-point for PL/I.
> It was even called FORTRAN VI.
> Features of both Algol and COBOL were incorporated into
> the language.
>
>> 
>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
>> behalf of David Spiegel [dspiegel...@hotmail.com]
>> Sent: Sunday, March 27, 2022 11:38 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: PL/I question
>>
>> Hi R'Shmuel AMV"SH,
>> Like ALGOL and Pascal?
>>
>> Regards,
>> David
>>
>> On 2022-03-27 22:52, Seymour J Metz wrote:
>>> Personally, I wish that IBM had chosen ":=" for assignment.
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> .
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Bernd Oppolzer]

As it seems from other posts, the story is not completely true;
there was indeed such an error somewhere sometime with NASA,
but the error that destroyed the Mariner spacecraft was different (a 
missing hyphen on
a hand-written variable specification, which had not been translated 
correctly to computer code).


I believe that there are similar pitfalls in other languages, too, 
although FORTRAN is very special,
because it allows spaces even in the middle of identifiers (and 
numbers), such as


   DO  3  I    =   1 . 10

which in every other programming language would disqualify as an 
assignment statement

because of the spaces around the DO symbol.

My favorite PL/1 example from a real world program is this:

   IF 9 < ZZ < 20 THEN DO; ...

someone with a math background obviously coded this :-)
the expectation was, that the statement be executed if ZZ is in the 
range 10 to 19.


Unfortunately, this is translated by PL/1 as follows:

   IF (9 < ZZ) < 20 THEN DO;

9 < ZZ is a result of type BIT(1) and yields '0'B or '1'B, depending on ZZ;
this result is converted to decimal, so that it can be compared to the 
decimal constant 20

and the result therefore is ALWAYS FALSE.

This is clearly not what the coder had intended.

We detected this luckily, using a site-written PL/1 diagnosing tool, 
which complained because of the
implied type conversion (BIT(1) to decimal). About 2 percent of the 
total PL/1 code base
had similar logic errors, which were undetected before we scanned all 
the source codes with our
new tool in 2007. After that, we changed the deployment processes, so 
that the new tool

runs with every software deployment.

Kind regards

Bernd


Am 29.03.2022 um 17:03 schrieb David Spiegel:

Hi gil,
I remember reading the article approximately 40 years ago.
It was in Datamation, which was an IT magazine.
You've never heard of Datamation before? ... How many years have you 
been in this business?


The story was related to an unmanned spaceship (i.e. Venus Probe) 
whose trajectory was calculated by a FORTRAN program

with the following statements:
DO 3  I=1.3
.
.
3

Since there was a period between "1" and "3" (instead of a comma), the 
loop ran precisely once
and assigned 1.3 to DO3I (FORTRAN removes blanks before compile) a 
variable which is automatically declared REAL, because its first letter

is outside the INTEGER Range I-N.

Here is another reference (not Datamation) (which does not mention the 
financial loss)

Please see:
IEEE Xplore Full-Text PDF: 


Page 58

Regards,
David



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[David Spiegel]

Hi gil,
I remember reading the article approximately 40 years ago.
It was in Datamation, which was an IT magazine.
You've never heard of Datamation before? ... How many years have you 
been in this business?


The story was related to an unmanned spaceship (i.e. Venus Probe) whose 
trajectory was calculated by a FORTRAN program

with the following statements:
DO 3  I=1.3
.
.
3

Since there was a period between "1" and "3" (instead of a comma), the 
loop ran precisely once
and assigned 1.3 to DO3I (FORTRAN removes blanks before compile) a 
variable which is automatically declared REAL, because its first letter

is outside the INTEGER Range I-N.

Here is another reference (not Datamation) (which does not mention the 
financial loss)

Please see:
IEEE Xplore Full-Text PDF: 


Page 58

Regards,
David

On 2022-03-29 10:37, Paul Gilmartin wrote:

On Tue, 29 Mar 2022 09:22:10 -0400, David Spiegel wrote:

You said: "... BTW, the change in format of the DO was essential
in preventing the flaw in FORTRAN (which still exists)
by which a period instead of the first comma
changes the DO statement into an assignment statement.  ..."


Do pedantic compilers warn of that?  But it might be inicidental
to warning of unused variables.

Most languages have such pitfalls.  A favorite is the ALGOL-60
implied comment.  Pedantic compilers warn of that.


Have you ever read the Datamation article regarding the comma which cost
$15,00,000 (in the '60s)?


Did you just supply  an example ("$15,00.000")?  If not, cite.

In IT or in law?



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Paul Gilmartin]

On Tue, 29 Mar 2022 09:22:10 -0400, David Spiegel wrote:
>
>You said: "... BTW, the change in format of the DO was essential
>in preventing the flaw in FORTRAN (which still exists)
>by which a period instead of the first comma
>changes the DO statement into an assignment statement.  ..."
> 
Do pedantic compilers warn of that?  But it might be inicidental
to warning of unused variables.

Most languages have such pitfalls.  A favorite is the ALGOL-60
implied comment.  Pedantic compilers warn of that.

>Have you ever read the Datamation article regarding the comma which cost
>$15,00,000 (in the '60s)?
>
Did you just supply  an example ("$15,00.000")?  If not, cite.

In IT or in law?

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Scott Barry]

And some wonder why IBM-MAIN subscribers go with options:  NOMAIL NODIGEST - 
considering the "noise to value ratio" specifically, at times.

Scott Barry
SBBTech LLC

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Robin Vowels]

On 2022-03-30 00:06, Seymour J Metz wrote:

It's obvious that one of us doesn't know what he's talking about,


And it's not me.  Who does that leave?


especially as you cited things that don't even exist in PL/I as being
derived from FORTRAN.


Put up or shut up.


And you still haven't answered whether you
seriouslyu believe thaat the FORTRAN DO resembles the PL/I DO more
than the ALGOL FOR statement does.


Read what I wrote.


Your purported explanation of the difference in DO between FORTRAN and
PL/I is ludicrous, because the rules for "white spacew" in FORTRAN and
PL/I are very different.


White space has noting to do with it.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[David Crayford]

Me too

> On 29 Mar 2022, at 19:48, Jay Maynard  wrote:
> 
> I'm not going to speak for Robin, but to me, yes, it does.
> 
>> On Tue, Mar 29, 2022 at 6:46 AM Seymour J Metz  wrote:
>> 
>> I'm not going to mention all of them, but you obviously noticed that I
>> mentioned DO.
>> 
>> Are you seriously claiming that "DO K = 1 TO 10 BY 2;" looks more like "DO
>> 10 K = 1, 10, 2 " than it does like "for K := 1 step 2 until 10 do"?
>> 
> 
> -- 
> Jay Maynard
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[David Spiegel]

Hi Robin
You said: "... BTW, the change in format of the DO was essential
in preventing the flaw in FORTRAN (which still exists)
by which a period instead of the first comma
changes the DO statement into an assignment statement.  ..."

Have you ever read the Datamation article regarding the comma which cost 
$15,00,000 (in the '60s)?


Regards,
David


On 2022-03-29 08:08, Robin Vowels wrote:

On 2022-03-29 22:46, Seymour J Metz wrote:

I'm not going to mention all of them, but you obviously noticed that I
mentioned DO.


Then, it's obvious that you don't know what you are talking about.


Are you seriously claiming that "DO K = 1 TO 10 BY 2;" looks more like
"DO 10 K = 1, 10, 2 " than it does like "for K := 1 step 2 until 10
do"?


Given that the PL/I language was derived from FORTRAN IV,
and that the name of the language was FORTRAN VI,
it is reasonable to assert that the PL/I version was
derived from FORTRAN IV, and that the keyword 'TO'
was only required to be added to the short form,
and 'TO' and 'BY' to be added to the long form.

PL/I went a lot further than FORTRAN IV:
for example, multiple iterations were added, and,
for example, the 'TO' component could be omitted.

BTW, the change in format of the DO was essential
in preventing the flaw in FORTRAN (which still exists)
by which a period instead of the first comma
changes the DO statement into an assignment statement.



From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
behalf of Robin Vowels [robi...@dodo.com.au]
Sent: Monday, March 28, 2022 8:45 PM
Subject: Re: PL/I question

- Original Message -
From: "Seymour J Metz" 
Newsgroups: bit.listserv.ibm-main
To: 
Sent: Tuesday, March 29, 2022 10:47 AM
Subject: Re: PL/I question


You claimed that a lot of things came from FORTRAN that don'r look 
remotely like FORTRAN syntax,


Name them.


some of which look like Algol 60. A good example is the DO statement,
which looks a lot more like an Algol for statement than a FORTRAN DO.


Try
DO 10 K = 1, 10   ->    DO K = 1 TO 10;
DO 10 K = 1, 10, 2    ->    DO K = 1 TO 10 BY 2;


Some of what you claimed came from FORTRAN doesn't even exist in PL/I.


Name them.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Seymour J Metz]

It's obvious that one of us doesn't know what he's talking about, especially as 
you cited things that don't even exist in PL/I as being derived from FORTRAN. 
And you still haven't answered whether you seriouslyu believe thaat the FORTRAN 
DO resembles the PL/I DO more than the ALGOL FOR statement does.

Your purported explanation of the difference in DO between FORTRAN and PL/I is 
ludicrous, because the rules for "white spacew" in FORTRAN and PL/I are very 
different.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Robin Vowels [robi...@dodo.com.au]
Sent: Tuesday, March 29, 2022 8:08 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

On 2022-03-29 22:46, Seymour J Metz wrote:
> I'm not going to mention all of them, but you obviously noticed that I
> mentioned DO.

Then, it's obvious that you don't know what you are talking about.

> Are you seriously claiming that "DO K = 1 TO 10 BY 2;" looks more like
> "DO 10 K = 1, 10, 2 " than it does like "for K := 1 step 2 until 10
> do"?

Given that the PL/I language was derived from FORTRAN IV,
and that the name of the language was FORTRAN VI,
it is reasonable to assert that the PL/I version was
derived from FORTRAN IV, and that the keyword 'TO'
was only required to be added to the short form,
and 'TO' and 'BY' to be added to the long form.

PL/I went a lot further than FORTRAN IV:
for example, multiple iterations were added, and,
for example, the 'TO' component could be omitted.

BTW, the change in format of the DO was essential
in preventing the flaw in FORTRAN (which still exists)
by which a period instead of the first comma
changes the DO statement into an assignment statement.

> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> behalf of Robin Vowels [robi...@dodo.com.au]
> Sent: Monday, March 28, 2022 8:45 PM
> Subject: Re: PL/I question
>
> - Original Message -
> From: "Seymour J Metz" 
> Newsgroups: bit.listserv.ibm-main
> To: 
> Sent: Tuesday, March 29, 2022 10:47 AM
> Subject: Re: PL/I question
>
>
>> You claimed that a lot of things came from FORTRAN that don'r look
>> remotely like FORTRAN syntax,
>
> Name them.
>
>> some of which look like Algol 60. A good example is the DO statement,
>> which looks a lot more like an Algol for statement than a FORTRAN DO.
>
> Try
> DO 10 K = 1, 10   ->DO K = 1 TO 10;
> DO 10 K = 1, 10, 2->DO K = 1 TO 10 BY 2;
>
>> Some of what you claimed came from FORTRAN doesn't even exist in PL/I.
>
> Name them.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Robin Vowels]

On 2022-03-29 17:42, Michael Stein wrote:

On Fri, Mar 25, 2022 at 11:20:10AM +, Rupert Reynolds wrote:

Vaguely related, can anyone comment on the assertions that PL/I was
considered "too slow" back in the old days, and that it was "too 
verbose
for writing system code"? Excuse me? MVS system macros are stuffed 
with its

close relative, PL/S!


I used PL/1 back in the MVT days, F level.  My memory says that it
did a getmain/freemain for each PL1 procedure call.


That's correct. It was to obtain storage for non-static variables
and to set up stuff for procedure entry.  The storage was given up
at procedure termination.


So reading a file
of students (30k+) you couldn't afford a procedure call in the path.
It was ok to use them during init and term (which only happened once).

This was a 360/91KK and 2314 disks...


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Robin Vowels]

On 2022-03-29 22:46, Seymour J Metz wrote:

I'm not going to mention all of them, but you obviously noticed that I
mentioned DO.


Then, it's obvious that you don't know what you are talking about.


Are you seriously claiming that "DO K = 1 TO 10 BY 2;" looks more like
"DO 10 K = 1, 10, 2 " than it does like "for K := 1 step 2 until 10
do"?


Given that the PL/I language was derived from FORTRAN IV,
and that the name of the language was FORTRAN VI,
it is reasonable to assert that the PL/I version was
derived from FORTRAN IV, and that the keyword 'TO'
was only required to be added to the short form,
and 'TO' and 'BY' to be added to the long form.

PL/I went a lot further than FORTRAN IV:
for example, multiple iterations were added, and,
for example, the 'TO' component could be omitted.

BTW, the change in format of the DO was essential
in preventing the flaw in FORTRAN (which still exists)
by which a period instead of the first comma
changes the DO statement into an assignment statement.



From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
behalf of Robin Vowels [robi...@dodo.com.au]
Sent: Monday, March 28, 2022 8:45 PM
Subject: Re: PL/I question

- Original Message -
From: "Seymour J Metz" 
Newsgroups: bit.listserv.ibm-main
To: 
Sent: Tuesday, March 29, 2022 10:47 AM
Subject: Re: PL/I question


You claimed that a lot of things came from FORTRAN that don'r look 
remotely like FORTRAN syntax,


Name them.


some of which look like Algol 60. A good example is the DO statement,
which looks a lot more like an Algol for statement than a FORTRAN DO.


Try
DO 10 K = 1, 10   ->DO K = 1 TO 10;
DO 10 K = 1, 10, 2->DO K = 1 TO 10 BY 2;


Some of what you claimed came from FORTRAN doesn't even exist in PL/I.


Name them.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Jay Maynard]

I'm not going to speak for Robin, but to me, yes, it does.

On Tue, Mar 29, 2022 at 6:46 AM Seymour J Metz  wrote:

> I'm not going to mention all of them, but you obviously noticed that I
> mentioned DO.
>
> Are you seriously claiming that "DO K = 1 TO 10 BY 2;" looks more like "DO
> 10 K = 1, 10, 2 " than it does like "for K := 1 step 2 until 10 do"?
>

-- 
Jay Maynard

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Seymour J Metz]

I'm not going to mention all of them, but you obviously noticed that I 
mentioned DO.

Are you seriously claiming that "DO K = 1 TO 10 BY 2;" looks more like "DO 10 K 
= 1, 10, 2 " than it does like "for K := 1 step 2 until 10 do"?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Robin Vowels [robi...@dodo.com.au]
Sent: Monday, March 28, 2022 8:45 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

- Original Message -
From: "Seymour J Metz" 
Newsgroups: bit.listserv.ibm-main
To: 
Sent: Tuesday, March 29, 2022 10:47 AM
Subject: Re: PL/I question


> You claimed that a lot of things came from FORTRAN that don'r look remotely 
> like FORTRAN syntax,

Name them.

> some of which look like Algol 60. A good example is the DO statement,
> which looks a lot more like an Algol for statement than a FORTRAN DO.

Try
DO 10 K = 1, 10->DO K = 1 TO 10;
DO 10 K = 1, 10, 2->DO K = 1 TO 10 BY 2;

> Some of what you claimed came from FORTRAN doesn't even exist in PL/I.

Name them.

---
This email has been checked for viruses by Avast antivirus software.
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.avast.com%2Fantivirusdata=04%7C01%7Csmetz3%40gmu.edu%7C8bfbe5e390994dbbf76608da111d69c6%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C637841115292073877%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=GbJRwuudlJjyfHA2afrnyQs5AwmZPoIpN%2BZeesulU54%3Dreserved=0

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question (slow?)

[Seymour J Metz]

Yes, one of the changes between PL/I (F) and the "Optimizing" Compiler was 
using fewer GETMAINs for stack management. However, I found the performance of 
F to be adequate as long as I didn't do much with unaligned bit strings.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Michael Stein [m...@zlvfc.com]
Sent: Tuesday, March 29, 2022 2:42 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question (slow?)

On Fri, Mar 25, 2022 at 11:20:10AM +, Rupert Reynolds wrote:
> Vaguely related, can anyone comment on the assertions that PL/I was
> considered "too slow" back in the old days, and that it was "too verbose
> for writing system code"? Excuse me? MVS system macros are stuffed with its
> close relative, PL/S!

I used PL/1 back in the MVT days, F level.  My memory says that it
did a getmain/freemain for each PL1 procedure call.  So reading a file
of students (30k+) you couldn't afford a procedure call in the path.
It was ok to use them during init and term (which only happened once).

This was a 360/91KK and 2314 disks...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question (slow?)

[Michael Stein]

On Fri, Mar 25, 2022 at 11:20:10AM +, Rupert Reynolds wrote:
> Vaguely related, can anyone comment on the assertions that PL/I was
> considered "too slow" back in the old days, and that it was "too verbose
> for writing system code"? Excuse me? MVS system macros are stuffed with its
> close relative, PL/S!

I used PL/1 back in the MVT days, F level.  My memory says that it
did a getmain/freemain for each PL1 procedure call.  So reading a file
of students (30k+) you couldn't afford a procedure call in the path.
It was ok to use them during init and term (which only happened once).

This was a 360/91KK and 2314 disks...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Robin Vowels]

- Original Message - 
From: "Seymour J Metz" 

Newsgroups: bit.listserv.ibm-main
To: 
Sent: Tuesday, March 29, 2022 10:47 AM
Subject: Re: PL/I question



You claimed that a lot of things came from FORTRAN that don'r look remotely 
like FORTRAN syntax,


Name them.


some of which look like Algol 60. A good example is the DO statement,
which looks a lot more like an Algol for statement than a FORTRAN DO.


Try
DO 10 K = 1, 10->DO K = 1 TO 10;
DO 10 K = 1, 10, 2->DO K = 1 TO 10 BY 2;


Some of what you claimed came from FORTRAN doesn't even exist in PL/I.


Name them.

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Robin Vowels]

From: "Phil Smith III" 
Sent: Tuesday, March 29, 2022 5:56 AM


My dad once told me that he'd seen a PL/I program in South America somewhere
in which the language itself was Spanish-the keywords etc. So "si" for "if"
(not to be confused with "yes"!) and "más hacer" for "else do", etc. I'm now
suspecting this was done using the preprocessor.


That is definitely done with the preprocessor.
It was part of IBM's course in 1966.

The keywords can be substituted with local language words. 



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Seymour J Metz]

You claimed that a lot of things came from FORTRAN that don'r look remotely 
like FORTRAN syntax, some of which look like Algol 60. A good example is the DO 
statement, which looks a lot more like an Algol for statement than a FORTRAN 
DO. Some of what you claimed came from FORTRAN doesn't even exist in PL/I.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Robin Vowels [robi...@dodo.com.au]
Sent: Monday, March 28, 2022 8:32 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

On 2022-03-28 22:38, Seymour J Metz wrote:
> Oddly enough, you listed lots of  bogus claims

There are no bogus claims.

> but forgot one that is
> legitimate: the default attributes depending on variable names. Of
> course, in FORTRAN it's wired in, but the original PL/I defaults
> matched FORTRAN.

I don't claim to have itemised every possible feature
that came from various languages. They are OTOMH.
The main point was that you are wrong in claiming that
"FORTRAN had the least influence of the three",
which is patently and demonstrably false.

Yes, the I to N default for integers, and the rest real,
came from FORTRAN, and while we're here, so did PL/I's
DEFAULT statement (from FORTRAN's IMPLICIT).

> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> behalf of Robin Vowels [robi...@dodo.com.au]
> Sent: Monday, March 28, 2022 6:26 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PL/I question
>
> On 2022-03-28 20:43, Seymour J Metz wrote:
>> I'm fully aware of the initial name; the fact remains that IBM and
>> SHARE looked at three languages, and that FORTRAN had the least
>> influence of the three.
>
> Static storage came from FORTRAN.
> Edited input-output (format lists) came from FORTRAN.
> EXTERNAL came from FORTRAN.
> Function references came from FORTRAN.
> CALL statements came from FORTRAN.
> Computed GO TO came from FORTRAN.
> Remote formats came from FORTRAN
> Label parameters came from FORTRAN.
> Assignment statements came from FORTRAN.
> Implied DO came from FORTRAN.
> Data-directed I/O came from FORTRAN.
> FORMAT statements came from FORTRAN.
> DO statements came from FORTRAN.
>
>> Most of the language derives from Algol 60
>
> Dynamic arrays and scalars came from ALGOL.
> Block structure came from ALGOL.
> Explicitly allocated arrays did not come from ALGOL.
> Free source form came from Algol.
> Conditional statements came from Algol.
>
> No I/O came from Algol.
> Generic functions did not come from Algol.
>
>> and COBOL,
>
> Data structures came from COBOL.
> Picture came from COBOL.
> Decimal came from COBOL.
>
>> and the most obvious feature from FORTRAN has gone by the
>> wayside.
>
> These new features were introduced in PL/I:
> BIT strings.
> scaled fixed binary.
> Varying-length strings.
> ALLOCATE-able variables.
> The means of detecting and intercepting run-time errors.
> integer overflow detection.
> subscript bounds checking.
> string range checking.
> preprocessor.
>
>
>> ________
>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
>> behalf of Robin Vowels [robi...@dodo.com.au]
>> Sent: Monday, March 28, 2022 4:53 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: PL/I question
>>
>> On 2022-03-28 19:10, Seymour J Metz wrote:
>>> Exaclly, especially since Algol 60 was one of the three languages
>>> folded into PL/I.
>>
>> FORTRAN, not Algol, was the starting-point for PL/I.
>> It was even called FORTRAN VI.
>> Features of both Algol and COBOL were incorporated into
>> the language.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Phil Smith III]

Thanks for the hints folks suggested. It turns out that the PL/I
preprocessor does make this easy, via something like:

%Dcl Forn Char;

%if Uppercase(Dyn) = 'YES' %then %do ;

%Forn = ', fetchable';

%end;

%else %do;

%Forn = '';

%end;

 

Then you just include the Forn variable in the function prototypes, where it
appears as null or “, fetchable”.

 

I had some problems with this because I was using a preprocessor variable
named DYN and my test program was also DYN. That meant that the “end dyn;”
statement at the end of the program became “end yes;”, which the compiler
didn’t much like. So yes, I used much longer variable names that nobody
should ever trip over!

 

While it’s a neat facility, I don’t see any way to override it. If you think
of CLIST or CMS EXEC/EXEC 2, variables were indicated by an &. Rexx variable
use is more “natural”, but you can override it by quoting, and it doesn’t
interpret keywords as variables. I tried, and “end 'dyn';” does NOT
work—PL/I doesn’t like the quotes (plus you couldn’t really quote every
keyword and still read the program).

 

This seem potentially nasty: if you set a variable named DECLARE, all your
DECLARE statements are now…something else. That feels like a huge security
issue: you %include some member and hilarity ensues (“PL/I injection”??). Or
just as a joke, back when we printed listings) defining SKIP as PAGE and
watching someone use a box of greenline for a short program...

 

My dad once told me that he’d seen a PL/I program in South America somewhere
in which the language itself was Spanish—the keywords etc. So “si” for “if”
(not to be confused with “yes”!) and “más hacer” for “else do”, etc. I’m now
suspecting this was done using the preprocessor.

 

I suppose it’s a bit late to APAR this.

 

(Thanks to a list-mate here whom I won’t name, who did the real work on
this—he’s welcome to out himself if desired [yes I just indicated gender])

 

...phsiii


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Robin Vowels]

On 2022-03-28 22:38, Seymour J Metz wrote:

Oddly enough, you listed lots of  bogus claims


There are no bogus claims.


but forgot one that is
legitimate: the default attributes depending on variable names. Of
course, in FORTRAN it's wired in, but the original PL/I defaults
matched FORTRAN.


I don't claim to have itemised every possible feature
that came from various languages. They are OTOMH.
The main point was that you are wrong in claiming that
"FORTRAN had the least influence of the three",
which is patently and demonstrably false.

Yes, the I to N default for integers, and the rest real,
came from FORTRAN, and while we're here, so did PL/I's
DEFAULT statement (from FORTRAN's IMPLICIT).



From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
behalf of Robin Vowels [robi...@dodo.com.au]
Sent: Monday, March 28, 2022 6:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

On 2022-03-28 20:43, Seymour J Metz wrote:

I'm fully aware of the initial name; the fact remains that IBM and
SHARE looked at three languages, and that FORTRAN had the least
influence of the three.


Static storage came from FORTRAN.
Edited input-output (format lists) came from FORTRAN.
EXTERNAL came from FORTRAN.
Function references came from FORTRAN.
CALL statements came from FORTRAN.
Computed GO TO came from FORTRAN.
Remote formats came from FORTRAN
Label parameters came from FORTRAN.
Assignment statements came from FORTRAN.
Implied DO came from FORTRAN.
Data-directed I/O came from FORTRAN.
FORMAT statements came from FORTRAN.
DO statements came from FORTRAN.


Most of the language derives from Algol 60


Dynamic arrays and scalars came from ALGOL.
Block structure came from ALGOL.
Explicitly allocated arrays did not come from ALGOL.
Free source form came from Algol.
Conditional statements came from Algol.

No I/O came from Algol.
Generic functions did not come from Algol.


and COBOL,


Data structures came from COBOL.
Picture came from COBOL.
Decimal came from COBOL.


and the most obvious feature from FORTRAN has gone by the
wayside.


These new features were introduced in PL/I:
BIT strings.
scaled fixed binary.
Varying-length strings.
ALLOCATE-able variables.
The means of detecting and intercepting run-time errors.
integer overflow detection.
subscript bounds checking.
string range checking.
preprocessor.




From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
behalf of Robin Vowels [robi...@dodo.com.au]
Sent: Monday, March 28, 2022 4:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

On 2022-03-28 19:10, Seymour J Metz wrote:

Exaclly, especially since Algol 60 was one of the three languages
folded into PL/I.


FORTRAN, not Algol, was the starting-point for PL/I.
It was even called FORTRAN VI.
Features of both Algol and COBOL were incorporated into
the language.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Seymour J Metz]

Oddly enough, you listed lots of  bogus claims but forgot one that is 
legitimate: the default attributes depending on variable names. Of course, in 
FORTRAN it's wired in, but the original PL/I defaults matched FORTRAN.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Robin Vowels [robi...@dodo.com.au]
Sent: Monday, March 28, 2022 6:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

On 2022-03-28 20:43, Seymour J Metz wrote:
> I'm fully aware of the initial name; the fact remains that IBM and
> SHARE looked at three languages, and that FORTRAN had the least
> influence of the three.

Static storage came from FORTRAN.
Edited input-output (format lists) came from FORTRAN.
EXTERNAL came from FORTRAN.
Function references came from FORTRAN.
CALL statements came from FORTRAN.
Computed GO TO came from FORTRAN.
Remote formats came from FORTRAN
Label parameters came from FORTRAN.
Assignment statements came from FORTRAN.
Implied DO came from FORTRAN.
Data-directed I/O came from FORTRAN.
FORMAT statements came from FORTRAN.
DO statements came from FORTRAN.

> Most of the language derives from Algol 60

Dynamic arrays and scalars came from ALGOL.
Block structure came from ALGOL.
Explicitly allocated arrays did not come from ALGOL.
Free source form came from Algol.
Conditional statements came from Algol.

No I/O came from Algol.
Generic functions did not come from Algol.

> and COBOL,

Data structures came from COBOL.
Picture came from COBOL.
Decimal came from COBOL.

> and the most obvious feature from FORTRAN has gone by the
> wayside.

These new features were introduced in PL/I:
BIT strings.
scaled fixed binary.
Varying-length strings.
ALLOCATE-able variables.
The means of detecting and intercepting run-time errors.
integer overflow detection.
subscript bounds checking.
string range checking.
preprocessor.


> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> behalf of Robin Vowels [robi...@dodo.com.au]
> Sent: Monday, March 28, 2022 4:53 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PL/I question
>
> On 2022-03-28 19:10, Seymour J Metz wrote:
>> Exaclly, especially since Algol 60 was one of the three languages
>> folded into PL/I.
>
> FORTRAN, not Algol, was the starting-point for PL/I.
> It was even called FORTRAN VI.
> Features of both Algol and COBOL were incorporated into
> the language.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[David Spiegel]

Hi Robin,
You said: "... These new features were introduced in PL/I: ..."
Pseudo-variables (i.e. SUBSTR, UNSPEC), Source Margins (not exactly the 
language itself).


Regards,
David

On 2022-03-28 06:26, Robin Vowels wrote:

On 2022-03-28 20:43, Seymour J Metz wrote:

I'm fully aware of the initial name; the fact remains that IBM and
SHARE looked at three languages, and that FORTRAN had the least
influence of the three.


Static storage came from FORTRAN.
Edited input-output (format lists) came from FORTRAN.
EXTERNAL came from FORTRAN.
Function references came from FORTRAN.
CALL statements came from FORTRAN.
Computed GO TO came from FORTRAN.
Remote formats came from FORTRAN
Label parameters came from FORTRAN.
Assignment statements came from FORTRAN.
Implied DO came from FORTRAN.
Data-directed I/O came from FORTRAN.
FORMAT statements came from FORTRAN.
DO statements came from FORTRAN.


Most of the language derives from Algol 60


Dynamic arrays and scalars came from ALGOL.
Block structure came from ALGOL.
Explicitly allocated arrays did not come from ALGOL.
Free source form came from Algol.
Conditional statements came from Algol.

No I/O came from Algol.
Generic functions did not come from Algol.


and COBOL,


Data structures came from COBOL.
Picture came from COBOL.
Decimal came from COBOL.


and the most obvious feature from FORTRAN has gone by the
wayside.


These new features were introduced in PL/I:
BIT strings.
scaled fixed binary.
Varying-length strings.
ALLOCATE-able variables.
The means of detecting and intercepting run-time errors.
integer overflow detection.
subscript bounds checking.
string range checking.
preprocessor.




From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
behalf of Robin Vowels [robi...@dodo.com.au]
Sent: Monday, March 28, 2022 4:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

On 2022-03-28 19:10, Seymour J Metz wrote:

Exaclly, especially since Algol 60 was one of the three languages
folded into PL/I.


FORTRAN, not Algol, was the starting-point for PL/I.
It was even called FORTRAN VI.
Features of both Algol and COBOL were incorporated into
the language.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Robin Vowels]

On 2022-03-28 20:43, Seymour J Metz wrote:

I'm fully aware of the initial name; the fact remains that IBM and
SHARE looked at three languages, and that FORTRAN had the least
influence of the three.


Static storage came from FORTRAN.
Edited input-output (format lists) came from FORTRAN.
EXTERNAL came from FORTRAN.
Function references came from FORTRAN.
CALL statements came from FORTRAN.
Computed GO TO came from FORTRAN.
Remote formats came from FORTRAN
Label parameters came from FORTRAN.
Assignment statements came from FORTRAN.
Implied DO came from FORTRAN.
Data-directed I/O came from FORTRAN.
FORMAT statements came from FORTRAN.
DO statements came from FORTRAN.


Most of the language derives from Algol 60


Dynamic arrays and scalars came from ALGOL.
Block structure came from ALGOL.
Explicitly allocated arrays did not come from ALGOL.
Free source form came from Algol.
Conditional statements came from Algol.

No I/O came from Algol.
Generic functions did not come from Algol.


and COBOL,


Data structures came from COBOL.
Picture came from COBOL.
Decimal came from COBOL.


and the most obvious feature from FORTRAN has gone by the
wayside.


These new features were introduced in PL/I:
BIT strings.
scaled fixed binary.
Varying-length strings.
ALLOCATE-able variables.
The means of detecting and intercepting run-time errors.
integer overflow detection.
subscript bounds checking.
string range checking.
preprocessor.




From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
behalf of Robin Vowels [robi...@dodo.com.au]
Sent: Monday, March 28, 2022 4:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

On 2022-03-28 19:10, Seymour J Metz wrote:

Exaclly, especially since Algol 60 was one of the three languages
folded into PL/I.


FORTRAN, not Algol, was the starting-point for PL/I.
It was even called FORTRAN VI.
Features of both Algol and COBOL were incorporated into
the language.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Seymour J Metz]

In PL/I (F) Version 5 the optimization regressed. While SUBSTR was still inline 
for CHAR, that was not always the case for bit strings.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Robin Vowels [robi...@dodo.com.au]
Sent: Monday, March 28, 2022 5:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

- Original Message -
From: "allan winston" 
Newsgroups: bit.listserv.ibm-main
To: 
Sent: Saturday, March 26, 2022 1:26 PM
Subject: Re: PL/I question


> From 1970 to 1972, I was in a shop that made the transition from PL/I F to
> the PL/I optimizing compiler. I would frequently use the LIST compiler
> option to look at the machine code generated and found that the PL/I F
> compiler generated quite poor code, frequently having to make a library
> call just to implement the SUBSTR function.

By 1968, the SUBSTR function was implemented as
in-line code in PL/I(F).
If, however, STRINGRANGE was specfied, in-line code was not generated.

In general, to avoid using subroutine calls, it was necessary to specify
a minimum optinisation level of 1, in which case in-line code was generated.

> By contrast, the PL/I
> optimizing compiler generated very good machine code.

---
This email has been checked for viruses by Avast antivirus software.
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.avast.com%2Fantivirusdata=04%7C01%7Csmetz3%40gmu.edu%7Cb88d6b6074004155e27008da109d6b6b%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C637840565556021849%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=k%2B3eL8AkSX9NWqt5pRNGrPmdQpycjdXeGbH6anEP%2BlU%3Dreserved=0

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Seymour J Metz]

Nonsense, that's only one case of a length explicitly determined at run time.. 
A declaration of an AUTO CHAR(foo) variable is another case.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Robin Vowels [robi...@dodo.com.au]
Sent: Monday, March 28, 2022 5:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

On 2022-03-28 20:26, Seymour J Metz wrote:
> Yes, I meant VARYINGZ. Zero termination, no interpolation, the normal
> doubling in literals.
>
> Block entry *is* run time.

I know.  That's why I wrote "explicitly determined at run time".
I was referring to ALLOCATE.

> Also, exempli gratia (e.g.) means for
> example; had that been a complete list I would have written id est
> (i.e.).
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> behalf of Robin Vowels [robi...@dodo.com.au]
> Sent: Monday, March 28, 2022 5:04 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PL/I question
>
> From: "Seymour J Metz" 
> Sent: Monday, March 28, 2022 4:10 AM
>
>
>> There are no troublesome characters. If it's CHARZ
>
> There's no such attribute.  Do you mean VARYINGZ?
>
>> then a '00'X marks the end of the string, as in C. Otherwise there is
>> an explicit length
>> that is the same regardless of what characters are in the string. The
>> length may
>> be determined at, e.g. compile time, block entry, or may be dynamic
>> (VARYING).
>
> And it can be explicitly determined at run time.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Seymour J Metz]

No.

"I meant what I said and I said what I meant,
A SysProg is faithful, 100%."
("Horton Hears an IPL", Dr. Seus)


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Robin Vowels [robi...@dodo.com.au]
Sent: Monday, March 28, 2022 4:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

On 2022-03-28 13:52, Seymour J Metz wrote:
> Personally, I wish that IBM had chosen ":=" for assignment.

You've forgotten that the basis for PL/I was an improved FORTRAN,
which used "="

Anyway, you can define your own assignment operator,
e.g. 'assigned_from', and use the preprocessor.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Seymour J Metz]

I'm fully aware of the initial name; the fact remains that IBM and SHARE looked 
at three languages, and that FORTRAN had the least influence of the three. Most 
of the language derives from Algol 60 and COBOL, and the most obvious feature 
from FORTRAN has gone by the wayside.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Robin Vowels [robi...@dodo.com.au]
Sent: Monday, March 28, 2022 4:53 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

On 2022-03-28 19:10, Seymour J Metz wrote:
> Exaclly, especially since Algol 60 was one of the three languages
> folded into PL/I.

FORTRAN, not Algol, was the starting-point for PL/I.
It was even called FORTRAN VI.
Features of both Algol and COBOL were incorporated into
the language.

> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> behalf of David Spiegel [dspiegel...@hotmail.com]
> Sent: Sunday, March 27, 2022 11:38 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PL/I question
>
> Hi R'Shmuel AMV"SH,
> Like ALGOL and Pascal?
>
> Regards,
> David
>
> On 2022-03-27 22:52, Seymour J Metz wrote:
>> Personally, I wish that IBM had chosen ":=" for assignment.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Robin Vowels]

On 2022-03-28 20:26, Seymour J Metz wrote:

Yes, I meant VARYINGZ. Zero termination, no interpolation, the normal
doubling in literals.

Block entry *is* run time.


I know.  That's why I wrote "explicitly determined at run time".
I was referring to ALLOCATE.


Also, exempli gratia (e.g.) means for
example; had that been a complete list I would have written id est
(i.e.).


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
behalf of Robin Vowels [robi...@dodo.com.au]
Sent: Monday, March 28, 2022 5:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

From: "Seymour J Metz" 
Sent: Monday, March 28, 2022 4:10 AM



There are no troublesome characters. If it's CHARZ


There's no such attribute.  Do you mean VARYINGZ?

then a '00'X marks the end of the string, as in C. Otherwise there is 
an explicit length
that is the same regardless of what characters are in the string. The 
length may
be determined at, e.g. compile time, block entry, or may be dynamic 
(VARYING).


And it can be explicitly determined at run time.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Robin Vowels]

- Original Message - 
From: "allan winston" 

Newsgroups: bit.listserv.ibm-main
To: 
Sent: Saturday, March 26, 2022 1:26 PM
Subject: Re: PL/I question



From 1970 to 1972, I was in a shop that made the transition from PL/I F to
the PL/I optimizing compiler. I would frequently use the LIST compiler
option to look at the machine code generated and found that the PL/I F
compiler generated quite poor code, frequently having to make a library
call just to implement the SUBSTR function.


By 1968, the SUBSTR function was implemented as
in-line code in PL/I(F).
If, however, STRINGRANGE was specfied, in-line code was not generated.

In general, to avoid using subroutine calls, it was necessary to specify
a minimum optinisation level of 1, in which case in-line code was generated.


By contrast, the PL/I
optimizing compiler generated very good machine code.


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Seymour J Metz]

Yes, I meant VARYINGZ. Zero termination, no interpolation, the normal doubling 
in literals.

Block entry *is* run time. Also, exempli gratia (e.g.) means for example; had 
that been a complete list I would have written id est (i.e.).


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Robin Vowels [robi...@dodo.com.au]
Sent: Monday, March 28, 2022 5:04 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

From: "Seymour J Metz" 
Sent: Monday, March 28, 2022 4:10 AM


> There are no troublesome characters. If it's CHARZ

There's no such attribute.  Do you mean VARYINGZ?

> then a '00'X marks the end of the string, as in C. Otherwise there is an 
> explicit length
> that is the same regardless of what characters are in the string. The length 
> may
> be determined at, e.g. compile time, block entry, or may be dynamic (VARYING).

And it can be explicitly determined at run time.

---
This email has been checked for viruses by Avast antivirus software.
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.avast.com%2Fantivirusdata=04%7C01%7Csmetz3%40gmu.edu%7Ca43301e2286b4a159f4508da1099efc5%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C637840550603608176%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=kXy%2B1RafUdg7GOvkg6K7lbgiWmQnf1%2FartCjlfIEa5k%3Dreserved=0

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Robin Vowels]

On 2022-03-28 02:45, Rupert Reynolds wrote:
Related: how does LE handle strings with embedded troublesome bytes 
such as

x'00'? And is it different between PL/I and C?


Conventional strings in PL/I can contain any character.
VARYINGZ strings are terminated with a character X'00'.


I am reading the PL/I Programming Guide,


Read the Language Specification, and check out VARYING and VARYINGZ.


but it takes but I'm hoping there
is an easy off-the-cuff answer.

Most of my PL/I experience was before LE, you see.




---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Robin Vowels]

From: "Seymour J Metz" 
Sent: Monday, March 28, 2022 4:10 AM



There are no troublesome characters. If it's CHARZ


There's no such attribute.  Do you mean VARYINGZ?


then a '00'X marks the end of the string, as in C. Otherwise there is an 
explicit length
that is the same regardless of what characters are in the string. The length may
be determined at, e.g. compile time, block entry, or may be dynamic (VARYING).


And it can be explicitly determined at run time.

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Robin Vowels]

On 2022-03-28 19:10, Seymour J Metz wrote:

Exaclly, especially since Algol 60 was one of the three languages
folded into PL/I.


FORTRAN, not Algol, was the starting-point for PL/I.
It was even called FORTRAN VI.
Features of both Algol and COBOL were incorporated into
the language.



From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
behalf of David Spiegel [dspiegel...@hotmail.com]
Sent: Sunday, March 27, 2022 11:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

Hi R'Shmuel AMV"SH,
Like ALGOL and Pascal?

Regards,
David

On 2022-03-27 22:52, Seymour J Metz wrote:

Personally, I wish that IBM had chosen ":=" for assignment.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Robin Vowels]

On 2022-03-28 19:07, Seymour J Metz wrote:

True, but it's convenient to be able to write things like "foo :=
sine(bar := baz);".


Nonsense.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Robin Vowels]

On 2022-03-28 15:58, Jay Maynard wrote:

Not me. Assignment is a much more common operation than comparison. It
should be the shorter token.


Agreed. '=' has been used for for assignment for 65 years.


On Sun, Mar 27, 2022 at 9:52 PM Seymour J Metz  wrote:


Personally, I wish that IBM had chosen ":=" for assignment.



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Robin Vowels]

On 2022-03-28 13:52, Seymour J Metz wrote:

Personally, I wish that IBM had chosen ":=" for assignment.


You've forgotten that the basis for PL/I was an improved FORTRAN,
which used "="

Anyway, you can define your own assignment operator,
e.g. 'assigned_from', and use the preprocessor.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Seymour J Metz]

Exaclly, especially since Algol 60 was one of the three languages folded into 
PL/I.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
David Spiegel [dspiegel...@hotmail.com]
Sent: Sunday, March 27, 2022 11:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

Hi R'Shmuel AMV"SH,
Like ALGOL and Pascal?

Regards,
David

On 2022-03-27 22:52, Seymour J Metz wrote:
> Personally, I wish that IBM had chosen ":=" for assignment.
>
>
> --
> Shmuel (Seymour J.) Metz
> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmason.gmu.edu%2F~smetz3data=04%7C01%7Csmetz3%40gmu.edu%7Ce9e248bf75944683e28408da106c86f3%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C637840355848465546%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=T0nyZXeRmQFRih61UBfLB4%2B%2FnKYUzInw%2BLudixXVtzs%3Dreserved=0
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> Rupert Reynolds [rreyno...@cix.co.uk]
> Sent: Sunday, March 27, 2022 4:02 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PL/I question
>
> Interesting. Thanks.
>
> I ask because many modern languages owe enough to C, or use libraries that
> do, that it's become a working assumption that null, backslash and the like
> will probably break something.
>
> I wrote a crude x86 compiler once, just to have a compiled language for my
> own use that absolutely, definitely handled any byte value exactly the
> same. It was supposed to be terse like C, but work more like PL/I.
>
> Oh, and I can't remember how far I got, but I started by abolishing = for
> assignment. It was implicit in the syntax and = was only used for
> comparison. I was young and foolish :-)
>
> Roops
>
> On Sun., Mar. 27, 2022, 18:10 Seymour J Metz,  wrote:
>
>> There are no troublesome characters. If it's CHARZ then a '00'X marks the
>> end of the string, as in C. Otherwise there is an explicit length that is
>> the same regardless of what characters are in the string. The length may be
>> determined at, e.g. compile time, block entry, or may be dynamic (VARYING).
>>
>>
>> --
>> Shmuel (Seymour J.) Metz
>> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmason.gmu.edu%2F~smetz3data=04%7C01%7Csmetz3%40gmu.edu%7Ce9e248bf75944683e28408da106c86f3%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C637840355848465546%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=T0nyZXeRmQFRih61UBfLB4%2B%2FnKYUzInw%2BLudixXVtzs%3Dreserved=0
>>
>> 
>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
>> of Rupert Reynolds [rreyno...@cix.co.uk]
>> Sent: Sunday, March 27, 2022 11:45 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: PL/I question
>>
>> Related: how does LE handle strings with embedded troublesome bytes such as
>> x'00'? And is it different between PL/I and C?
>>
>> I am reading the PL/I Programming Guide, but it takes but I'm hoping there
>> is an easy off-the-cuff answer.
>>
>> Most of my PL/I experience was before LE, you see.
>>
>> Roos
>>
>>
>>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> .

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Seymour J Metz]

True, but it's convenient to be able to write things like "foo := sine(bar := 
baz);".


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Jay 
Maynard [jaymayn...@gmail.com]
Sent: Monday, March 28, 2022 12:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

Not me. Assignment is a much more common operation than comparison. It
should be the shorter token.

On Sun, Mar 27, 2022 at 9:52 PM Seymour J Metz  wrote:

> Personally, I wish that IBM had chosen ":=" for assignment.
>

--
Jay Maynard

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Jay Maynard]

Not me. Assignment is a much more common operation than comparison. It
should be the shorter token.

On Sun, Mar 27, 2022 at 9:52 PM Seymour J Metz  wrote:

> Personally, I wish that IBM had chosen ":=" for assignment.
>

-- 
Jay Maynard

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[David Spiegel]

Hi R'Shmuel AMV"SH,
Like ALGOL and Pascal?

Regards,
David

On 2022-03-27 22:52, Seymour J Metz wrote:

Personally, I wish that IBM had chosen ":=" for assignment.


--
Shmuel (Seymour J.) Metz
https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmason.gmu.edu%2F~smetz3data=04%7C01%7C%7Cb18183d576804cdf01d008da10660265%7C84df9e7fe9f640afb435%7C1%7C0%7C637840327652943898%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=oao%2BUalMizCvGh%2BSlkm96WUtUqbEUR2ZSw%2Fkxw1hQ%2F0%3Dreserved=0


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Rupert Reynolds [rreyno...@cix.co.uk]
Sent: Sunday, March 27, 2022 4:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

Interesting. Thanks.

I ask because many modern languages owe enough to C, or use libraries that
do, that it's become a working assumption that null, backslash and the like
will probably break something.

I wrote a crude x86 compiler once, just to have a compiled language for my
own use that absolutely, definitely handled any byte value exactly the
same. It was supposed to be terse like C, but work more like PL/I.

Oh, and I can't remember how far I got, but I started by abolishing = for
assignment. It was implicit in the syntax and = was only used for
comparison. I was young and foolish :-)

Roops

On Sun., Mar. 27, 2022, 18:10 Seymour J Metz,  wrote:


There are no troublesome characters. If it's CHARZ then a '00'X marks the
end of the string, as in C. Otherwise there is an explicit length that is
the same regardless of what characters are in the string. The length may be
determined at, e.g. compile time, block entry, or may be dynamic (VARYING).


--
Shmuel (Seymour J.) Metz
https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmason.gmu.edu%2F~smetz3data=04%7C01%7C%7Cb18183d576804cdf01d008da10660265%7C84df9e7fe9f640afb435%7C1%7C0%7C637840327652943898%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=oao%2BUalMizCvGh%2BSlkm96WUtUqbEUR2ZSw%2Fkxw1hQ%2F0%3Dreserved=0


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
of Rupert Reynolds [rreyno...@cix.co.uk]
Sent: Sunday, March 27, 2022 11:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

Related: how does LE handle strings with embedded troublesome bytes such as
x'00'? And is it different between PL/I and C?

I am reading the PL/I Programming Guide, but it takes but I'm hoping there
is an easy off-the-cuff answer.

Most of my PL/I experience was before LE, you see.

Roos




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Seymour J Metz]

Personally, I wish that IBM had chosen ":=" for assignment.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Rupert Reynolds [rreyno...@cix.co.uk]
Sent: Sunday, March 27, 2022 4:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

Interesting. Thanks.

I ask because many modern languages owe enough to C, or use libraries that
do, that it's become a working assumption that null, backslash and the like
will probably break something.

I wrote a crude x86 compiler once, just to have a compiled language for my
own use that absolutely, definitely handled any byte value exactly the
same. It was supposed to be terse like C, but work more like PL/I.

Oh, and I can't remember how far I got, but I started by abolishing = for
assignment. It was implicit in the syntax and = was only used for
comparison. I was young and foolish :-)

Roops

On Sun., Mar. 27, 2022, 18:10 Seymour J Metz,  wrote:

> There are no troublesome characters. If it's CHARZ then a '00'X marks the
> end of the string, as in C. Otherwise there is an explicit length that is
> the same regardless of what characters are in the string. The length may be
> determined at, e.g. compile time, block entry, or may be dynamic (VARYING).
>
>
> --
> Shmuel (Seymour J.) Metz
> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmason.gmu.edu%2F~smetz3data=04%7C01%7Csmetz3%40gmu.edu%7C1709b15739dc42141e4808da1022%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C637840081846789349%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=Ey5nUu1atuDALxzw7Bwlnj1dwHm46EnHgQqnAsUszrw%3Dreserved=0
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Rupert Reynolds [rreyno...@cix.co.uk]
> Sent: Sunday, March 27, 2022 11:45 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PL/I question
>
> Related: how does LE handle strings with embedded troublesome bytes such as
> x'00'? And is it different between PL/I and C?
>
> I am reading the PL/I Programming Guide, but it takes but I'm hoping there
> is an easy off-the-cuff answer.
>
> Most of my PL/I experience was before LE, you see.
>
> Roos
>
>
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Robin Vowels]

On 2022-03-28 02:45, Rupert Reynolds wrote:
Related: how does LE handle strings with embedded troublesome bytes 
such as

x'00'? And is it different between PL/I and C?


Conventional strings in PL/I can contain any character.
VARYINGZ strings are terminated with a character X'00'.


I am reading the PL/I Programming Guide,


Read the Language Specification, and check out VARYING and VARYING.


but it takes but I'm hoping there
is an easy off-the-cuff answer.

Most of my PL/I experience was before LE, you see.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Rupert Reynolds]

Thanks. That's encouraging.  I really must try to stay up to date :-)

Roops

On Sun., Mar. 27, 2022, 18:02 Tony Harminc,  wrote:

> On Sun, 27 Mar 2022 at 11:45, Rupert Reynolds  wrote:
> >
> > Related: how does LE handle strings with embedded troublesome bytes such
> as
> > x'00'? And is it different between PL/I and C?
>
> LE doesn't change the rules of PL/I - it's merely an implementation
> detail. And PL/I strings (the traditional kind) don't have any
> dependence on the byte values in the data - in particular, a X'00'
> byte is not a string terminator.
>
> > I am reading the PL/I Programming Guide, but it takes but I'm hoping
> there
> > is an easy off-the-cuff answer.
>
> That was it.
>
> Tony H.
>
> --
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Rupert Reynolds]

Interesting. Thanks.

I ask because many modern languages owe enough to C, or use libraries that
do, that it's become a working assumption that null, backslash and the like
will probably break something.

I wrote a crude x86 compiler once, just to have a compiled language for my
own use that absolutely, definitely handled any byte value exactly the
same. It was supposed to be terse like C, but work more like PL/I.

Oh, and I can't remember how far I got, but I started by abolishing = for
assignment. It was implicit in the syntax and = was only used for
comparison. I was young and foolish :-)

Roops

On Sun., Mar. 27, 2022, 18:10 Seymour J Metz,  wrote:

> There are no troublesome characters. If it's CHARZ then a '00'X marks the
> end of the string, as in C. Otherwise there is an explicit length that is
> the same regardless of what characters are in the string. The length may be
> determined at, e.g. compile time, block entry, or may be dynamic (VARYING).
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Rupert Reynolds [rreyno...@cix.co.uk]
> Sent: Sunday, March 27, 2022 11:45 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PL/I question
>
> Related: how does LE handle strings with embedded troublesome bytes such as
> x'00'? And is it different between PL/I and C?
>
> I am reading the PL/I Programming Guide, but it takes but I'm hoping there
> is an easy off-the-cuff answer.
>
> Most of my PL/I experience was before LE, you see.
>
> Roos
>
>
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[David Spiegel]

Hi Robin,
While you're busy correcting ...
IBM uses American spelling  ... *Optimizing (not the 
British/Continental/etc. Optimising).


Regards,
David

On 2022-03-27 11:25, Robin Vowels wrote:
Oops, a typo. The PL/I Optimising and checkout compilers were 
available from 1970.


---
This email has been checked for viruses by Avast antivirus software.
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.avast.com%2Fantivirusdata=04%7C01%7C%7Cb76c08e1017b429f970e08da100608aa%7C84df9e7fe9f640afb435%7C1%7C0%7C637839915462770416%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=rQTT%2FRLSNHxUcjZdOXGLrWjkDoJ%2BlWBAUZZtsicyBbw%3Dreserved=0 



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Seymour J Metz]

PL/I (D) came with DOS/360 and PL/I (F) came with OS/360. It wasn't until the 
"Optimizing" compiler that IBM started charging.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Bob 
Bridges [robhbrid...@gmail.com]
Sent: Friday, March 25, 2022 9:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

License fee?  I always assumed PL/I sort of came with the OS.  I didn't think 
it'd be any extra.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* You've never been lost until you've been lost at Mach 3.  -Paul F Crickmore, 
test pilot */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of CM 
Poncelet
Sent: Friday, March 25, 2022 20:59

AFAIK The reason PL/I was not 'more popular' was its high license fee.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Seymour J Metz]

There are no troublesome characters. If it's CHARZ then a '00'X marks the end 
of the string, as in C. Otherwise there is an explicit length that is the same 
regardless of what characters are in the string. The length may be determined 
at, e.g. compile time, block entry, or may be dynamic (VARYING).


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Rupert Reynolds [rreyno...@cix.co.uk]
Sent: Sunday, March 27, 2022 11:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

Related: how does LE handle strings with embedded troublesome bytes such as
x'00'? And is it different between PL/I and C?

I am reading the PL/I Programming Guide, but it takes but I'm hoping there
is an easy off-the-cuff answer.

Most of my PL/I experience was before LE, you see.

Roos

On Sat., Mar. 26, 2022, 22:25 Charles Mills,  wrote:

> > Does LE make a difference nowadays?
>
> Yes. LE is the runtime for all recent releases of the "popular" languages
> (someone will jump on me on that!) with the exception of Rexx. Rexx will
> run interpreted, but if you want the benefits of compiled Rexx, the target
> machine needs a paid-for runtime library.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Saturday, March 26, 2022 2:28 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PL/I question
>
> On Sat, 26 Mar 2022 00:58:53 +, CM Poncelet wrote:
>
> >AFAIK The reason PL/I was not 'more popular' was its high license fee.
> >
> Circa 1980, my then employer approached IBM seeking permission to
> redistribute the PL/I RTL to support a product we were designing.  We
> were told that each of our customers would have to have a purchase
> agreement with IBM.  We went with a different language.  Admittedly,
> we were a competitor.
>
> Does LE make a difference nowadays?
>
> >Meanwhile, I've known people use even COBOL to write/maintain system code.
> >
> >As for me, I wrote all system code in assembler - bar adhoc stuff, as in
> >
> Yet II was startled when our sysprog mentioned offhand that he was
> writing an ad-hoc assembler program to generate a little report.
>
> --
> gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Tony Harminc]

On Sun, 27 Mar 2022 at 11:45, Rupert Reynolds  wrote:
>
> Related: how does LE handle strings with embedded troublesome bytes such as
> x'00'? And is it different between PL/I and C?

LE doesn't change the rules of PL/I - it's merely an implementation
detail. And PL/I strings (the traditional kind) don't have any
dependence on the byte values in the data - in particular, a X'00'
byte is not a string terminator.

> I am reading the PL/I Programming Guide, but it takes but I'm hoping there
> is an easy off-the-cuff answer.

That was it.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Rupert Reynolds]

Related: how does LE handle strings with embedded troublesome bytes such as
x'00'? And is it different between PL/I and C?

I am reading the PL/I Programming Guide, but it takes but I'm hoping there
is an easy off-the-cuff answer.

Most of my PL/I experience was before LE, you see.

Roos

On Sat., Mar. 26, 2022, 22:25 Charles Mills,  wrote:

> > Does LE make a difference nowadays?
>
> Yes. LE is the runtime for all recent releases of the "popular" languages
> (someone will jump on me on that!) with the exception of Rexx. Rexx will
> run interpreted, but if you want the benefits of compiled Rexx, the target
> machine needs a paid-for runtime library.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Saturday, March 26, 2022 2:28 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PL/I question
>
> On Sat, 26 Mar 2022 00:58:53 +, CM Poncelet wrote:
>
> >AFAIK The reason PL/I was not 'more popular' was its high license fee.
> >
> Circa 1980, my then employer approached IBM seeking permission to
> redistribute the PL/I RTL to support a product we were designing.  We
> were told that each of our customers would have to have a purchase
> agreement with IBM.  We went with a different language.  Admittedly,
> we were a competitor.
>
> Does LE make a difference nowadays?
>
> >Meanwhile, I've known people use even COBOL to write/maintain system code.
> >
> >As for me, I wrote all system code in assembler - bar adhoc stuff, as in
> >
> Yet II was startled when our sysprog mentioned offhand that he was
> writing an ad-hoc assembler program to generate a little report.
>
> --
> gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Robin Vowels]

Oops, a typo. The PL/I Optimising and checkout compilers were available from 
1970.

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Robin Vowels]

From: "Bob Bridges" 
Sent: Saturday, March 26, 2022 12:32 PM



License fee?  I always assumed PL/I sort of came with the OS.


It did come with the OS, from the beginning.


I didn't think it'd be any extra


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Robin Vowels]

From: "CM Poncelet" <03e99a92061c-dmarc-requ...@listserv.ua.edu>
Newsgroups: bit.listserv.ibm-main
Sent: Saturday, March 26, 2022 11:58 AM



AFAIK The reason PL/I was not 'more popular' was its high license fee.


There was an alternatve available, namely, PL/C.


Meanwhile, I've known people use even COBOL to write/maintain system code.

As for me, I wrote all system code in assembler - bar adhoc stuff, as in
to be executed once only (e.g. to convert CICS DFHCSD [?] RDO-defined
LU2 connections and sessions to their equivalent assembler DFHTCT
entries and macros,) which I then wrote in PL/I to save time.

Not sure about PL/I being considered "too slow": it *could* be compiled
with the 'optimize' [or similar] option, in the 1980's.


Well, from 1980 there were available the PL/I checkout and Optimising compilers.
The Optimising compiler had the REORDER option that permitted a
wider range of optimisations that without the option specified.
Even before that, PL/I (F) had an optimising option.  Of course,
PL/I (F) could be used beyond 1980.

It's quite possible that some users and organisations were not aware
of the REORDER option. The classic case was that of Tucker, who,
in his book comparing run times of languages, failed to use the
REORDER option.

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Seymour J Metz]

Between PL/I (F) Version 4 and 5, a fix broke the optimization of unaligned bit 
strings, V5 generated calls to library routines for code that V4 would 
translate into inline TM and such. The "Optimizing" compiler continued to 
generate library calls for that code, making analysis of SMF data slower than 
it ought to be. I'm curious as to whether IBM ever corrected that.

I don't recall the Transient Library as being very expensive, but I understand 
why it could be an issue.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
allan winston [jaw191...@gmail.com]
Sent: Friday, March 25, 2022 10:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

>From 1970 to 1972, I was in a shop that made the transition from PL/I F to
the PL/I optimizing compiler. I would frequently use the LIST compiler
option to look at the machine code generated and found that the PL/I F
compiler generated quite poor code, frequently having to make a library
call just to implement the SUBSTR function. By contrast, the PL/I
optimizing compiler generated very good machine code.

A big difference between the PL/I optimizing compiler and the COBOL
compilers was that to execute PL/I  load modules required a license fee for
the PL/I  runtime (transient library). COBOL did not have a similar
requirement. I ran into this when I later worked in level 2 support for
CA-NETMAN, which was 80% written in PL/I. Our customers would need a
license for the transient library, but would only need a license for the
compiler if they additionally chose to write CA-NETMAN exits in the PL/I
language.

On Fri, Mar 25, 2022, 9:56 PM Jay Maynard  wrote:

> Oh, not at all. At least in the 80s, all of the nice things were separately
> charged program products, and the PL/I Optimizer was definitely in that
> category. You could use the PL/I F compiler from MVT if you wanted and
> could get your hands on a copy, though, at no charge.
>
> On Fri, Mar 25, 2022 at 8:32 PM Bob Bridges  wrote:
>
> > License fee?  I always assumed PL/I sort of came with the OS.  I didn't
> > think it'd be any extra.
> >
> > ---
> > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
> >
> > /* You've never been lost until you've been lost at Mach 3.  -Paul F
> > Crickmore, test pilot */
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On Behalf
> > Of CM Poncelet
> > Sent: Friday, March 25, 2022 20:59
> >
> > AFAIK The reason PL/I was not 'more popular' was its high license fee.
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
>
> --
> Jay Maynard
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Charles Mills]

> Does LE make a difference nowadays?

Yes. LE is the runtime for all recent releases of the "popular" languages 
(someone will jump on me on that!) with the exception of Rexx. Rexx will run 
interpreted, but if you want the benefits of compiled Rexx, the target machine 
needs a paid-for runtime library.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Saturday, March 26, 2022 2:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

On Sat, 26 Mar 2022 00:58:53 +, CM Poncelet wrote:

>AFAIK The reason PL/I was not 'more popular' was its high license fee.
> 
Circa 1980, my then employer approached IBM seeking permission to
redistribute the PL/I RTL to support a product we were designing.  We
were told that each of our customers would have to have a purchase
agreement with IBM.  We went with a different language.  Admittedly,
we were a competitor.

Does LE make a difference nowadays?

>Meanwhile, I've known people use even COBOL to write/maintain system code.
> 
>As for me, I wrote all system code in assembler - bar adhoc stuff, as in
>
Yet II was startled when our sysprog mentioned offhand that he was
writing an ad-hoc assembler program to generate a little report.

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Paul Gilmartin]

On Sat, 26 Mar 2022 00:58:53 +, CM Poncelet wrote:

>AFAIK The reason PL/I was not 'more popular' was its high license fee.
> 
Circa 1980, my then employer approached IBM seeking permission to
redistribute the PL/I RTL to support a product we were designing.  We
were told that each of our customers would have to have a purchase
agreement with IBM.  We went with a different language.  Admittedly,
we were a competitor.

Does LE make a difference nowadays?

>Meanwhile, I've known people use even COBOL to write/maintain system code.
> 
>As for me, I wrote all system code in assembler - bar adhoc stuff, as in
>
Yet II was startled when our sysprog mentioned offhand that he was
writing an ad-hoc assembler program to generate a little report.

-- 
gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Charles Mills]

Someone who has been on this list worked for an IVP that published STC's 
written in COBOL.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of CM Poncelet
Sent: Friday, March 25, 2022 5:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

AFAIK The reason PL/I was not 'more popular' was its high license fee.
 
Meanwhile, I've known people use even COBOL to write/maintain system code.
 
As for me, I wrote all system code in assembler - bar adhoc stuff, as in
to be executed once only (e.g. to convert CICS DFHCSD [?] RDO-defined
LU2 connections and sessions to their equivalent assembler DFHTCT
entries and macros,) which I then wrote in PL/I to save time.
 
Not sure about PL/I being considered "too slow": it *could* be compiled
with the 'optimize' [or similar] option, in the 1980's.
 


On 25/03/2022 11:20, Rupert Reynolds wrote:
> Vaguely related, can anyone comment on the assertions that PL/I was
> considered "too slow" back in the old days, and that it was "too verbose
> for writing system code"? Excuse me? MVS system macros are stuffed with its
> close relative, PL/S!
>
> I can see its size would make compiling slow on limited hardware, but I
> always found the compiled code ran pretty well, and the language supported
> all the bit-twiddling I needed without resorting to PL/S.
>
> I even wrote a PL/I hackpiece for laughs that effectively called data to
> issue SVC 99 without calling assembly (the obvious choice in those days).
> PL/S would have done it more nicely, but PL/I had the facilities to make it
> happen.
>
> I often wonder why it wasn't more popular. C felt like a step backward.
>
> Roops
>
> On Fri., Mar. 25, 2022, 00:06 CM Poncelet, <
> 03e99a92061c-dmarc-requ...@listserv.ua.edu> wrote:
>
>> Yes - and it could not be called NPL as its further development was then
>> transferred to IBM Hursley in England.
>>
>> On 24/03/2022 12:45, Seymour J Metz wrote:
>>> FORTRAN VI -> NPL -> MPPL -> PL/I
>>>
>>> At the time I thought that MPPL was a hideous acronym.
>>>
>>>
>>> --
>>> Shmuel (Seymour J.) Metz
>>> http://mason.gmu.edu/~smetz3
>>>
>>> 
>>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
>> behalf of CM Poncelet [03e99a92061c-dmarc-requ...@listserv.ua.edu]
>>> Sent: Wednesday, March 23, 2022 9:06 PM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: PL/I question
>>>
>>> +1
>>>
>>> It was initially called Fortran VI, because it was considered too
>>> advanced to be called Fortran V (1962), then NPL (1964, but could not
>>> because it was the acronym of the National Physical Laboratory [or
>>> similar] in the UK,) and then PL/I - with the '/' from OS/360 and the
>>> Roman 'I' to preserve its originally having been called Fortran VI.
>>>
>>>
>>>
>>> On 23/03/2022 00:52, Phil Smith III wrote:
>>>> Bob Bridges wrote:
>>>>
>>>>> PL/1 was my first language.
>>>> Only it's "PL/I". "Programming Language/One", but "PL/I". Just sayin'.
>>>>
>>>>
>>>>
>>>> It actually might have been PL/C on that Xerox 530. S long ago.
>>>>
>>>>
>>>> --
>>>> For IBM-MAIN subscribe / signoff / archive access instructions,
>>>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>>> .
>>>>
>>> --
>>> For IBM-MAIN subscribe / signoff / archive access instructions,
>>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>>
>>> --
>>> For IBM-MAIN subscribe / signoff / archive access instructions,
>>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>> .
>>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> .
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[allan winston]

>From 1970 to 1972, I was in a shop that made the transition from PL/I F to
the PL/I optimizing compiler. I would frequently use the LIST compiler
option to look at the machine code generated and found that the PL/I F
compiler generated quite poor code, frequently having to make a library
call just to implement the SUBSTR function. By contrast, the PL/I
optimizing compiler generated very good machine code.

A big difference between the PL/I optimizing compiler and the COBOL
compilers was that to execute PL/I  load modules required a license fee for
the PL/I  runtime (transient library). COBOL did not have a similar
requirement. I ran into this when I later worked in level 2 support for
CA-NETMAN, which was 80% written in PL/I. Our customers would need a
license for the transient library, but would only need a license for the
compiler if they additionally chose to write CA-NETMAN exits in the PL/I
language.

On Fri, Mar 25, 2022, 9:56 PM Jay Maynard  wrote:

> Oh, not at all. At least in the 80s, all of the nice things were separately
> charged program products, and the PL/I Optimizer was definitely in that
> category. You could use the PL/I F compiler from MVT if you wanted and
> could get your hands on a copy, though, at no charge.
>
> On Fri, Mar 25, 2022 at 8:32 PM Bob Bridges  wrote:
>
> > License fee?  I always assumed PL/I sort of came with the OS.  I didn't
> > think it'd be any extra.
> >
> > ---
> > Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
> >
> > /* You've never been lost until you've been lost at Mach 3.  -Paul F
> > Crickmore, test pilot */
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On Behalf
> > Of CM Poncelet
> > Sent: Friday, March 25, 2022 20:59
> >
> > AFAIK The reason PL/I was not 'more popular' was its high license fee.
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
>
> --
> Jay Maynard
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Jay Maynard]

Oh, not at all. At least in the 80s, all of the nice things were separately
charged program products, and the PL/I Optimizer was definitely in that
category. You could use the PL/I F compiler from MVT if you wanted and
could get your hands on a copy, though, at no charge.

On Fri, Mar 25, 2022 at 8:32 PM Bob Bridges  wrote:

> License fee?  I always assumed PL/I sort of came with the OS.  I didn't
> think it'd be any extra.
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> /* You've never been lost until you've been lost at Mach 3.  -Paul F
> Crickmore, test pilot */
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of CM Poncelet
> Sent: Friday, March 25, 2022 20:59
>
> AFAIK The reason PL/I was not 'more popular' was its high license fee.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Jay Maynard

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Wayne Bickerdike]

I think Pl/I was "free" before IBM unbundled software. I started in 1975
and we had the F level and Optimizing compiler. Most of our senior
programmers wrote in Assembler but my first year was all PL/I, Assembler
came later. We never used COBOL but had RPG and Mark IV. A couple of years
later we also had Software AG Adabas and Natural.

On Sat, Mar 26, 2022 at 12:32 PM Bob Bridges  wrote:

> License fee?  I always assumed PL/I sort of came with the OS.  I didn't
> think it'd be any extra.
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> /* You've never been lost until you've been lost at Mach 3.  -Paul F
> Crickmore, test pilot */
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of CM Poncelet
> Sent: Friday, March 25, 2022 20:59
>
> AFAIK The reason PL/I was not 'more popular' was its high license fee.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Wayne V. Bickerdike

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Bob Bridges]

License fee?  I always assumed PL/I sort of came with the OS.  I didn't think 
it'd be any extra.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* You've never been lost until you've been lost at Mach 3.  -Paul F Crickmore, 
test pilot */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of CM 
Poncelet
Sent: Friday, March 25, 2022 20:59

AFAIK The reason PL/I was not 'more popular' was its high license fee.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[CM Poncelet]

AFAIK The reason PL/I was not 'more popular' was its high license fee.
 
Meanwhile, I've known people use even COBOL to write/maintain system code.
 
As for me, I wrote all system code in assembler - bar adhoc stuff, as in
to be executed once only (e.g. to convert CICS DFHCSD [?] RDO-defined
LU2 connections and sessions to their equivalent assembler DFHTCT
entries and macros,) which I then wrote in PL/I to save time.
 
Not sure about PL/I being considered "too slow": it *could* be compiled
with the 'optimize' [or similar] option, in the 1980's.
 


On 25/03/2022 11:20, Rupert Reynolds wrote:
> Vaguely related, can anyone comment on the assertions that PL/I was
> considered "too slow" back in the old days, and that it was "too verbose
> for writing system code"? Excuse me? MVS system macros are stuffed with its
> close relative, PL/S!
>
> I can see its size would make compiling slow on limited hardware, but I
> always found the compiled code ran pretty well, and the language supported
> all the bit-twiddling I needed without resorting to PL/S.
>
> I even wrote a PL/I hackpiece for laughs that effectively called data to
> issue SVC 99 without calling assembly (the obvious choice in those days).
> PL/S would have done it more nicely, but PL/I had the facilities to make it
> happen.
>
> I often wonder why it wasn't more popular. C felt like a step backward.
>
> Roops
>
> On Fri., Mar. 25, 2022, 00:06 CM Poncelet, <
> 03e99a92061c-dmarc-requ...@listserv.ua.edu> wrote:
>
>> Yes - and it could not be called NPL as its further development was then
>> transferred to IBM Hursley in England.
>>
>> On 24/03/2022 12:45, Seymour J Metz wrote:
>>> FORTRAN VI -> NPL -> MPPL -> PL/I
>>>
>>> At the time I thought that MPPL was a hideous acronym.
>>>
>>>
>>> --
>>> Shmuel (Seymour J.) Metz
>>> http://mason.gmu.edu/~smetz3
>>>
>>> 
>>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
>> behalf of CM Poncelet [03e99a92061c-dmarc-requ...@listserv.ua.edu]
>>> Sent: Wednesday, March 23, 2022 9:06 PM
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: PL/I question
>>>
>>> +1
>>>
>>> It was initially called Fortran VI, because it was considered too
>>> advanced to be called Fortran V (1962), then NPL (1964, but could not
>>> because it was the acronym of the National Physical Laboratory [or
>>> similar] in the UK,) and then PL/I - with the '/' from OS/360 and the
>>> Roman 'I' to preserve its originally having been called Fortran VI.
>>>
>>>
>>>
>>> On 23/03/2022 00:52, Phil Smith III wrote:
>>>> Bob Bridges wrote:
>>>>
>>>>> PL/1 was my first language.
>>>> Only it's "PL/I". "Programming Language/One", but "PL/I". Just sayin'.
>>>>
>>>>
>>>>
>>>> It actually might have been PL/C on that Xerox 530. S long ago.
>>>>
>>>>
>>>> --
>>>> For IBM-MAIN subscribe / signoff / archive access instructions,
>>>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>>> .
>>>>
>>> --
>>> For IBM-MAIN subscribe / signoff / archive access instructions,
>>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>>
>>> --
>>> For IBM-MAIN subscribe / signoff / archive access instructions,
>>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>> .
>>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> .
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Rupert Reynolds]

Vaguely related, can anyone comment on the assertions that PL/I was
considered "too slow" back in the old days, and that it was "too verbose
for writing system code"? Excuse me? MVS system macros are stuffed with its
close relative, PL/S!

I can see its size would make compiling slow on limited hardware, but I
always found the compiled code ran pretty well, and the language supported
all the bit-twiddling I needed without resorting to PL/S.

I even wrote a PL/I hackpiece for laughs that effectively called data to
issue SVC 99 without calling assembly (the obvious choice in those days).
PL/S would have done it more nicely, but PL/I had the facilities to make it
happen.

I often wonder why it wasn't more popular. C felt like a step backward.

Roops

On Fri., Mar. 25, 2022, 00:06 CM Poncelet, <
03e99a92061c-dmarc-requ...@listserv.ua.edu> wrote:

> Yes - and it could not be called NPL as its further development was then
> transferred to IBM Hursley in England.
>
> On 24/03/2022 12:45, Seymour J Metz wrote:
> > FORTRAN VI -> NPL -> MPPL -> PL/I
> >
> > At the time I thought that MPPL was a hideous acronym.
> >
> >
> > --
> > Shmuel (Seymour J.) Metz
> > http://mason.gmu.edu/~smetz3
> >
> > 
> > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on
> behalf of CM Poncelet [03e99a92061c-dmarc-requ...@listserv.ua.edu]
> > Sent: Wednesday, March 23, 2022 9:06 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: PL/I question
> >
> > +1
> >
> > It was initially called Fortran VI, because it was considered too
> > advanced to be called Fortran V (1962), then NPL (1964, but could not
> > because it was the acronym of the National Physical Laboratory [or
> > similar] in the UK,) and then PL/I - with the '/' from OS/360 and the
> > Roman 'I' to preserve its originally having been called Fortran VI.
> >
> >
> >
> > On 23/03/2022 00:52, Phil Smith III wrote:
> >> Bob Bridges wrote:
> >>
> >>> PL/1 was my first language.
> >>
> >> Only it's "PL/I". "Programming Language/One", but "PL/I". Just sayin'.
> >>
> >>
> >>
> >> It actually might have been PL/C on that Xerox 530. S long ago.
> >>
> >>
> >> --
> >> For IBM-MAIN subscribe / signoff / archive access instructions,
> >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >> .
> >>
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > .
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[CM Poncelet]

Yes - and it could not be called NPL as its further development was then
transferred to IBM Hursley in England.

On 24/03/2022 12:45, Seymour J Metz wrote:
> FORTRAN VI -> NPL -> MPPL -> PL/I
>
> At the time I thought that MPPL was a hideous acronym.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> CM Poncelet [03e99a92061c-dmarc-requ...@listserv.ua.edu]
> Sent: Wednesday, March 23, 2022 9:06 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PL/I question
>
> +1
>
> It was initially called Fortran VI, because it was considered too
> advanced to be called Fortran V (1962), then NPL (1964, but could not
> because it was the acronym of the National Physical Laboratory [or
> similar] in the UK,) and then PL/I - with the '/' from OS/360 and the
> Roman 'I' to preserve its originally having been called Fortran VI.
>
>
>
> On 23/03/2022 00:52, Phil Smith III wrote:
>> Bob Bridges wrote:
>>
>>> PL/1 was my first language.
>>
>> Only it's "PL/I". "Programming Language/One", but "PL/I". Just sayin'.
>>
>>
>>
>> It actually might have been PL/C on that Xerox 530. S long ago.
>>
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>> .
>>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> .
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[zMan]

On Thu, Mar 24, 2022 at 8:46 AM Seymour J Metz  wrote:

> At the time I thought that MPPL was a hideous acronym.

Nah, it woulda been great: "I'm a computer guy...let me show you my mipple!"
(and normal people think geeks are weird as it is...)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Seymour J Metz]

FORTRAN VI -> NPL -> MPPL -> PL/I

At the time I thought that MPPL was a hideous acronym.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of CM 
Poncelet [03e99a92061c-dmarc-requ...@listserv.ua.edu]
Sent: Wednesday, March 23, 2022 9:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I question

+1

It was initially called Fortran VI, because it was considered too
advanced to be called Fortran V (1962), then NPL (1964, but could not
because it was the acronym of the National Physical Laboratory [or
similar] in the UK,) and then PL/I - with the '/' from OS/360 and the
Roman 'I' to preserve its originally having been called Fortran VI.



On 23/03/2022 00:52, Phil Smith III wrote:
> Bob Bridges wrote:
>
>> PL/1 was my first language.
>
>
> Only it's "PL/I". "Programming Language/One", but "PL/I". Just sayin'.
>
>
>
> It actually might have been PL/C on that Xerox 530. S long ago.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> .
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Bob Bridges]

LOL.  Except any IBM-invented product name that ended in 'F' would surely be a 
something-something-Facility.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* You will find that silence or very gentle words are the most exquisite 
revenge for insult.  -Judge Hall */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Steve Smith
Sent: Wednesday, March 23, 2022 15:52

One might complain about IBM's history of lousy names for its products.
The standard for a long time was obviously to form an initialism from a string 
of 2-4 vague words.  Old story is that if IBM had invented sushi, it would be 
called "CDF" (cold dead fish).  The fact that not all sushi has fish of any 
temperature or vitality can be considered part of the joke.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[CM Poncelet]

+1
 
It was initially called Fortran VI, because it was considered too
advanced to be called Fortran V (1962), then NPL (1964, but could not
because it was the acronym of the National Physical Laboratory [or
similar] in the UK,) and then PL/I - with the '/' from OS/360 and the
Roman 'I' to preserve its originally having been called Fortran VI.
 


On 23/03/2022 00:52, Phil Smith III wrote:
> Bob Bridges wrote:
>
>> PL/1 was my first language.
>  
>
> Only it's "PL/I". "Programming Language/One", but "PL/I". Just sayin'.
>
>  
>
> It actually might have been PL/C on that Xerox 530. S long ago.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> .
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: PL/I question

[Tom Brennan]

That's what I thought too... LOL

On 3/23/2022 3:28 PM, zMan wrote:

Are you asking what PL/I's pronouns are?

On Wed, Mar 23, 2022 at 4:15 PM Charles Mills  wrote:


How does PL/I self-identify?

Charles



--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN