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/X Open Source and PL/I - Helping to save the world and cut CPU Cycles and electricity

[Paul Gilmartin]

On Tue, 3 Oct 2023 12:12:29 +, Peter Relson wrote:
> ...
>PL/X does have the concept of a variable-length string (with the length being 
>in a separate variable, or in a preceding halfword).
>
PostScript has a fairly opaque "substring" with at lest 3 components:
o the string body
o the amount of storage in use
o the amount of storage allocated.
That last allows dyadic copy and concatenate operators without overrun hazard.

-- 
gil

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

Re: PL/X Open Source and PL/I - Helping to save the world and cut CPU Cycles and electricity

[Kirk Wolf]

You omitted C++, which has std:string which does know how long strings are.   
C++11 is a game changer and makes C++ way more usable.   Sadly, C++11 is still 
not quite fully available AFAIK for XLC++.

Kirk Wolf
Dovetailed Technologies
http:// <http://dovetail.com>coztoolkit.com

On Tue, Oct 3, 2023, at 8:22 AM, Eric D Rossman wrote:
> In the very first message with this new subject line, Clem Clarke said "We 
> know that C searches for a byte with a binary zero to find how long a string 
> is." which is what I was responding to.
> 
> PL/X is good for many things. C is good for many things. So are Java, and 
> Python and Go and Rust, etc. I'm fluent in many languages and none of them is 
> right for every use. Heck, even REXX is great for quick API testing.
> 
> PL/X and C (and arguably assembler) are not the best at higher level 
> interfaces mostly because they were not designed for that, but they excel at 
> OS-level interfaces because they force the developer to think more concretely 
> (in my experience). Java and Python, on the other hand, were clearly designed 
> with a more abstract approach which leads to better UI.
> 
> To my original point, even if IBM had released it many years ago, I don't 
> know if PL/X would be dominating.
> 
> Eric Rossman
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Peter Relson
> Sent: Tuesday, October 3, 2023 8:12 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [EXTERNAL] Re: PL/X Open Source and PL/I - Helping to save the world 
> and cut CPU Cycles and electricity
> 
> 
> PL/X, on the average, is not really better than C in terms of what you 
> describe except when the string's length is known in advance (which is hard 
> or impossible in many circumstances 
> 
> I didn't see stated in any post on this topic the explicit mention of 
> zero-delimited strings. That is what the discussion seems to be talking 
> about. Not all "character areas" are zero-delimited. PL/X has no support for 
> a zero-delimited string. When z/OS interfaces are used within C, there are 
> rarely (if ever) zero-delimited strings. A C program could/would use MEMCPY 
> to copy a string for which the length is known. And there are analogs of that 
> for "compare". That makes it a less natural language construct within C than 
> a zero-delimited string.
> 
> PL/X does have the concept of a variable-length string (with the length being 
> in a separate variable, or in a preceding halfword).
> 
> Manipulation of a variable-length string is going to be very different than 
> manipulation of a zero-delimited string.
> 
> Peter Relson
> z/OS Core Technology Design
> 
> 
> --
> 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/X Open Source and PL/I - Helping to save the world and cut CPU Cycles and electricity

[Eric D Rossman]

In the very first message with this new subject line, Clem Clarke said "We know 
that C searches for a byte with a binary zero to find how long a string is." 
which is what I was responding to.

PL/X is good for many things. C is good for many things. So are Java, and 
Python and Go and Rust, etc. I'm fluent in many languages and none of them is 
right for every use. Heck, even REXX is great for quick API testing.

PL/X and C (and arguably assembler) are not the best at higher level interfaces 
mostly because they were not designed for that, but they excel at OS-level 
interfaces because they force the developer to think more concretely (in my 
experience). Java and Python, on the other hand, were clearly designed with a 
more abstract approach which leads to better UI.

To my original point, even if IBM had released it many years ago, I don't know 
if PL/X would be dominating.

Eric Rossman

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Peter Relson
Sent: Tuesday, October 3, 2023 8:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: PL/X Open Source and PL/I - Helping to save the world 
and cut CPU Cycles and electricity


PL/X, on the average, is not really better than C in terms of what you describe 
except when the string's length is known in advance (which is hard or 
impossible in many circumstances 

I didn't see stated in any post on this topic the explicit mention of 
zero-delimited strings. That is what the discussion seems to be talking about. 
Not all "character areas" are zero-delimited. PL/X has no support for a 
zero-delimited string. When z/OS interfaces are used within C, there are rarely 
(if ever) zero-delimited strings. A C program could/would use MEMCPY to copy a 
string for which the length is known. And there are analogs of that for 
"compare". That makes it a less natural language construct within C than a 
zero-delimited string.

PL/X does have the concept of a variable-length string (with the length being 
in a separate variable, or in a preceding halfword).

Manipulation of a variable-length string is going to be very different than 
manipulation of a zero-delimited string.

Peter Relson
z/OS Core Technology Design


--
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/X Open Source and PL/I - Helping to save the world and cut CPU Cycles and electricity

[Peter Relson]

PL/X, on the average, is not really better than C in terms of what you describe 
except when the string's length is known in advance (which is hard or 
impossible in many circumstances


I didn't see stated in any post on this topic the explicit mention of 
zero-delimited strings. That is what the discussion seems to be talking about. 
Not all "character areas" are zero-delimited. PL/X has no support for a 
zero-delimited string. When z/OS interfaces are used within C, there are rarely 
(if ever) zero-delimited strings. A C program could/would use MEMCPY to copy a 
string for which the length is known. And there are analogs of that for 
"compare". That makes it a less natural language construct within C than a 
zero-delimited string.

PL/X does have the concept of a variable-length string (with the length being 
in a separate variable, or in a preceding halfword).

Manipulation of a variable-length string is going to be very different than 
manipulation of a zero-delimited string.

Peter Relson
z/OS Core Technology Design


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

Re: PL/X Open Source and PL/I - Helping to save the world and cut CPU Cycles and electricity

[Eric D Rossman]

I would say that "inertia" is PL/X's raison d'etre (even though that statement 
is probably controversial within the internal IBM Z development community).

I will acknowledge that PL/X is excellent at integrating HLASM code. GCC style 
inlining isn't terrible for including HLASM code but it is more painful.

I think the reason that PL/X was initially used is because it was the best we 
had at the time. The reason it is STILL used is because it's too 
dangerous/difficult to switch.

I really don't know why it was never truly externalized (that decision predates 
my time at IBM) but I could speculate that someone thought it gave IBM some 
competitive advantage. I don't see it that way, but again, just speculation.

Eric Rossman

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Kirk Wolf
Sent: Monday, October 2, 2023 2:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: PL/X Open Source and PL/I - Helping to save the world 
and cut CPU Cycles and electricity

Eric, 

I'm curious - wouldn't you say that PL/X integration with assembler and 
assembler macros is it's raison d'etre?   Even though I've done all sorts of 
integration of assembler with C/C++  (the GCC-style inlining, xplink assembler 
leaf routines, EDCDSECT conversion of DSECTs, etc, etc), which all work, they 
are still painful compared with PL/X and assembler.

Kirk Wolf
Dovetailed Technologies
http:// <http://dovetail.com >coztoolkit.com

On Mon, Oct 2, 2023, at 12:02 PM, Eric D Rossman wrote:
> I write PL/X daily. PL/X, on the average, is not really better than C 
> in terms of what you describe except when the string's length is known 
> in advance (which is hard or impossible in many circumstances
> 
> Don't get me wrong, it has a number of strengths as compared to C, but it 
> also is too close to "the metal" in some ways which would hamper it.
> 
> As for copying byte at a time, that is not a function of C (i.e. not 
> specified in the standard). It's usually a function of the complier 
> (sometimes deferred to the runtime libraries) and many of them can use 
> benefits of the instructions built into the hardware to speed things up as 
> well as general purpose things like copying DWORDs at a time with small 
> unrolled loops on either end to handle "extra"
> 
> Eric Rossman
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Clem Clarke
> Sent: Monday, October 2, 2023 9:03 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [EXTERNAL] Re: PL/X Open Source and PL/I - Helping to save 
> the world and cut CPU Cycles and electricity
> 
> What would it take for IBM to Open Source the Windows and Linux version of 
> PL/I and PL/X?
> 
> Why?  To potentially make the Internet faster and safer.  How?
> 
> We know that C searches for a byte with a binary zero to find how long a 
> string is.  This takes time. And then it take time to copy a string 
> elsewhere, especially if it is done a byte at a time (often true, depending 
> on the C compiler - some do a word at a time).
> 
> PL/I, Pascal and even Assembler know how long a string is.  They don't have 
> to waste cycle looking for the length of a string. Most of the time, they 
> know how long the receiving string is, and won't go past the end, as C will.
> 
> IBM still has the "authority" to do this.  And it morally should.
> 
> Just do it, IBM.  Help save the planet.
> 
> Clem Clarke
> 
> 
> 
> 
> 
> Wayne Bickerdike wrote:
> > So many acronyms.
> > I've Been Married
> > I've Been Moved
> > It's Better Manual
> > I Broke Microcode
> >
> > etc..
> >
> > On Mon, Oct 2, 2023 at 4:17 AM David Spiegel < 
> > 0468385049d1-dmarc-requ...@listserv.ua.edu> wrote:
> >
> >> Hi Peter,
> >> I was generalizing the problem. Allowing access to PL/ wouyld 
> >> also solve the lack of PDFs.
> >>
> >> This reminds me of a joke.
> >> Q: What does IBM Stand for?
> >> A: Ich Bin M'shugoh
> >>
> >> Regards,
> >> David
> >>
> >> On 2023-09-30 08:18, Peter Relson wrote:
> >>>> There is another solution
> >>> What are you thinking the "problem" is for which you mention a
> >> "solution"? The first post I saw was asking about PDF's, not about 
> >> access to PL/X. Was there a post that did not show up in the daily 
> >> digest? The "access-to-PL/X ship" sailed long ago.
> >>> Peter Relson
> >>> z/OS Core Technology Design
> >>>
> >>>
> >>> --
> >>> --
> >>

Re: PL/X Open Source and PL/I - Helping to save the world and cut CPU Cycles and electricity

[Kirk Wolf]

Eric, 

I'm curious - wouldn't you say that PL/X integration with assembler and 
assembler macros is it's raison d'etre?   Even though I've done all sorts of 
integration of assembler with C/C++  (the GCC-style inlining, xplink assembler 
leaf routines, EDCDSECT conversion of DSECTs, etc, etc), which all work, they 
are still painful compared with PL/X and assembler.

Kirk Wolf
Dovetailed Technologies
http:// <http://dovetail.com>coztoolkit.com

On Mon, Oct 2, 2023, at 12:02 PM, Eric D Rossman wrote:
> I write PL/X daily. PL/X, on the average, is not really better than C in 
> terms of what you describe except when the string's length is known in 
> advance (which is hard or impossible in many circumstances
> 
> Don't get me wrong, it has a number of strengths as compared to C, but it 
> also is too close to "the metal" in some ways which would hamper it.
> 
> As for copying byte at a time, that is not a function of C (i.e. not 
> specified in the standard). It's usually a function of the complier 
> (sometimes deferred to the runtime libraries) and many of them can use 
> benefits of the instructions built into the hardware to speed things up as 
> well as general purpose things like copying DWORDs at a time with small 
> unrolled loops on either end to handle "extra"
> 
> Eric Rossman
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Clem Clarke
> Sent: Monday, October 2, 2023 9:03 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: [EXTERNAL] Re: PL/X Open Source and PL/I - Helping to save the world 
> and cut CPU Cycles and electricity
> 
> What would it take for IBM to Open Source the Windows and Linux version of 
> PL/I and PL/X?
> 
> Why?  To potentially make the Internet faster and safer.  How?
> 
> We know that C searches for a byte with a binary zero to find how long a 
> string is.  This takes time. And then it take time to copy a string 
> elsewhere, especially if it is done a byte at a time (often true, depending 
> on the C compiler - some do a word at a time).
> 
> PL/I, Pascal and even Assembler know how long a string is.  They don't have 
> to waste cycle looking for the length of a string. Most of the time, they 
> know how long the receiving string is, and won't go past the end, as C will.
> 
> IBM still has the "authority" to do this.  And it morally should.
> 
> Just do it, IBM.  Help save the planet.
> 
> Clem Clarke
> 
> 
> 
> 
> 
> Wayne Bickerdike wrote:
> > So many acronyms.
> > I've Been Married
> > I've Been Moved
> > It's Better Manual
> > I Broke Microcode
> >
> > etc..
> >
> > On Mon, Oct 2, 2023 at 4:17 AM David Spiegel < 
> > 0468385049d1-dmarc-requ...@listserv.ua.edu> wrote:
> >
> >> Hi Peter,
> >> I was generalizing the problem. Allowing access to PL/ wouyld 
> >> also solve the lack of PDFs.
> >>
> >> This reminds me of a joke.
> >> Q: What does IBM Stand for?
> >> A: Ich Bin M'shugoh
> >>
> >> Regards,
> >> David
> >>
> >> On 2023-09-30 08:18, Peter Relson wrote:
> >>>> There is another solution
> >>> What are you thinking the "problem" is for which you mention a
> >> "solution"? The first post I saw was asking about PDF's, not about 
> >> access to PL/X. Was there a post that did not show up in the daily 
> >> digest? The "access-to-PL/X ship" sailed long ago.
> >>> Peter Relson
> >>> z/OS Core Technology Design
> >>>
> >>>
> >>> 
> >>> -- 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/X Open Source and PL/I - Helping to save the world and cut CPU Cycles and electricity

[Paul Gilmartin]

On Tue, 3 Oct 2023 00:03:07 +1100, Clem Clarke  
wrote:
>
>PL/I, Pascal and even Assembler know how long a string is.  They don't
>have to waste cycle looking for the length of a string. Most of the
>time, they know how long the receiving string is, and won't go past the
>end, as C will.
>
Have you heard of strncpy(), etc.?

How does "Assembler know how long a string is"?

-- 
gil

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

Re: PL/X Open Source and PL/I - Helping to save the world and cut CPU Cycles and electricity

[Eric D Rossman]

I write PL/X daily. PL/X, on the average, is not really better than C in terms 
of what you describe except when the string's length is known in advance (which 
is hard or impossible in many circumstances

Don't get me wrong, it has a number of strengths as compared to C, but it also 
is too close to "the metal" in some ways which would hamper it.

As for copying byte at a time, that is not a function of C (i.e. not specified 
in the standard). It's usually a function of the complier (sometimes deferred 
to the runtime libraries) and many of them can use benefits of the instructions 
built into the hardware to speed things up as well as general purpose things 
like copying DWORDs at a time with small unrolled loops on either end to handle 
"extra"

Eric Rossman

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Clem Clarke
Sent: Monday, October 2, 2023 9:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: PL/X Open Source and PL/I - Helping to save the world 
and cut CPU Cycles and electricity

What would it take for IBM to Open Source the Windows and Linux version of PL/I 
and PL/X?

Why?  To potentially make the Internet faster and safer.  How?

We know that C searches for a byte with a binary zero to find how long a string 
is.  This takes time. And then it take time to copy a string elsewhere, 
especially if it is done a byte at a time (often true, depending on the C 
compiler - some do a word at a time).

PL/I, Pascal and even Assembler know how long a string is.  They don't have to 
waste cycle looking for the length of a string. Most of the time, they know how 
long the receiving string is, and won't go past the end, as C will.

IBM still has the "authority" to do this.  And it morally should.

Just do it, IBM.  Help save the planet.

Clem Clarke





Wayne Bickerdike wrote:
> So many acronyms.
> I've Been Married
> I've Been Moved
> It's Better Manual
> I Broke Microcode
>
> etc..
>
> On Mon, Oct 2, 2023 at 4:17 AM David Spiegel < 
> 0468385049d1-dmarc-requ...@listserv.ua.edu> wrote:
>
>> Hi Peter,
>> I was generalizing the problem. Allowing access to PL/ wouyld 
>> also solve the lack of PDFs.
>>
>> This reminds me of a joke.
>> Q: What does IBM Stand for?
>> A: Ich Bin M'shugoh
>>
>> Regards,
>> David
>>
>> On 2023-09-30 08:18, Peter Relson wrote:
>>>> There is another solution
>>> What are you thinking the "problem" is for which you mention a
>> "solution"? The first post I saw was asking about PDF's, not about 
>> access to PL/X. Was there a post that did not show up in the daily 
>> digest? The "access-to-PL/X ship" sailed long ago.
>>> Peter Relson
>>> z/OS Core Technology Design
>>>
>>>
>>> 
>>> -- 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/X Open Source and PL/I (off topic)

[Bob Bridges]

I would say "No, no exceptions".  I don't mean that all companies are monsters, 
only that moral behavior is a feature of individual humans.  If a company 
behaves well it's because one or more individuals within the company are making 
moral decisions on its behalf.

This isn't a condemnation of companies.  I'm just saying it's the only way it 
CAN be.  A group is not a person and cannot have moral judgement, though its 
individual members may.

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

/* ...it is not humanity in the abstract that is to be saved, but you -- you, 
the individual reader, John Stubbs or Janet Smith.  Blessed and fortunate 
creature, your eyes shall behold Him and not another'sYour place in heaven 
will seem to be made for you and you alone, because you were made for it -- 
made for it stitch by stitch as a glove is made for a hand.  -from "The Problem 
of Pain" by CS Lewis. */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Robert Prins
Sent: Monday, October 2, 2023 12:40

Big companies do not have morals, with maybe some, I don't know which ones, 
exceptions.

--- On 2023-10-02 13:03, Clem Clarke wrote:
> And it morally should.

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

Re: PL/X Open Source and PL/I - Helping to save the world and cut CPU Cycles and electricity

[Robert Prins]

On 2023-10-02 13:03, Clem Clarke wrote:
What would it take for IBM to Open Source the Windows and Linux version of PL/I 
and PL/X?


Why?  To potentially make the Internet faster and safer.  How?


It's pretty naive to think that open-sourcing PL/I will help, no C(++/#) 
programmer is going to switch, and even if they would consider switching, it 
would be more than likely to Rust, Go, Python, etc.


We know that C searches for a byte with a binary zero to find how long a string 
is.  This takes time. And then it take time to copy a string elsewhere, 
especially if it is done a byte at a time (often true, depending on the C 
compiler - some do a word at a time).


Most, if not all, modern compilers on x86/AMD64 scan (at least) 4/8 bytes at a 
time, and it using YMM, or even ZMM registers on AMD64 it might actually scan 
32, or even 64 bytes at a time, in just 2,3,4 cycles.


And as for other code improvements, there is PL/I code that compiles to shorter 
code with the old OS V2.3.0 compiler, than with Enterprise PL/I, and factoring 
out the common instructions, you end up with ONLY extra instructions generated 
by EPLI... Go figure! And everyone knows, the fastest instructions are those 
that are never executed!
PL/I, Pascal and even Assembler know how long a string is.  They don't have to 
waste cycle looking for the length of a string. Most of the time, they know how 
long the receiving string is, and won't go past the end, as C will. >
IBM still has the "authority" to do this.  


Even Raincode doesn't make an evaluation version of its PL/I compiler available.


And it morally should.


Big companies do not have morals, with maybe some, I don't know which ones, 
exceptions.


Anyway, it never will, the best you can hope for is that someone decides to 
reverse-engineer VA PL/I or RDz PL/I for Windows, but that would open a whole 
lot of cans of worms, and although I do have a copy of Hex Rays' IDA Pro, life's 
way too short to even think about it. I think someone once in a very grey past 
disassembled the old Digital Research PL/I compiler.



Just do it, IBM.  Help save the planet.


I'd better not reply anything to that.

Robert
--
Robert AH Prins
robert.ah.prins(a)gmail.com
The hitchhiking grandfather - https://prino.neocities.org/
Some REXX code for use on z/OS - https://prino.neocities.org/zOS/zOS-Tools.html


Clem Clarke





Wayne Bickerdike wrote:

So many acronyms.
I've Been Married
I've Been Moved
It's Better Manual
I Broke Microcode

etc..

On Mon, Oct 2, 2023 at 4:17 AM David Spiegel <
0468385049d1-dmarc-requ...@listserv.ua.edu> wrote:


Hi Peter,
I was generalizing the problem. Allowing access to PL/ wouyld also
solve the lack of PDFs.

This reminds me of a joke.
Q: What does IBM Stand for?
A: Ich Bin M'shugoh

Regards,
David

On 2023-09-30 08:18, Peter Relson wrote:

There is another solution

What are you thinking the "problem" is for which you mention a

"solution"? The first post I saw was asking about PDF's, not about access
to PL/X. Was there a post that did not show up in the daily digest? The
"access-to-PL/X ship" sailed long ago.

Peter Relson
z/OS Core Technology Design


--
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/X Open Source and PL/I - Helping to save the world and cut CPU Cycles and electricity

[Clem Clarke]

What would it take for IBM to Open Source the Windows and Linux version 
of PL/I and PL/X?


Why?  To potentially make the Internet faster and safer.  How?

We know that C searches for a byte with a binary zero to find how long a 
string is.  This takes time. And then it take time to copy a string 
elsewhere, especially if it is done a byte at a time (often true, 
depending on the C compiler - some do a word at a time).


PL/I, Pascal and even Assembler know how long a string is.  They don't 
have to waste cycle looking for the length of a string. Most of the 
time, they know how long the receiving string is, and won't go past the 
end, as C will.


IBM still has the "authority" to do this.  And it morally should.

Just do it, IBM.  Help save the planet.

Clem Clarke





Wayne Bickerdike wrote:

So many acronyms.
I've Been Married
I've Been Moved
It's Better Manual
I Broke Microcode

etc..

On Mon, Oct 2, 2023 at 4:17 AM David Spiegel <
0468385049d1-dmarc-requ...@listserv.ua.edu> wrote:


Hi Peter,
I was generalizing the problem. Allowing access to PL/ wouyld also
solve the lack of PDFs.

This reminds me of a joke.
Q: What does IBM Stand for?
A: Ich Bin M'shugoh

Regards,
David

On 2023-09-30 08:18, Peter Relson wrote:

There is another solution

What are you thinking the "problem" is for which you mention a

"solution"? The first post I saw was asking about PDF's, not about access
to PL/X. Was there a post that did not show up in the daily digest? The
"access-to-PL/X ship" sailed long ago.

Peter Relson
z/OS Core Technology Design


--
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 early compilers performance issues

[Robin Vowels]

There may have been issues with LCS (Large Core Storage).
Our site had 128K core with 1 Mb LCS.
OS/360 took up almost all the core storage.
Access to LCS was much slower than to core store.
We therefore made local PL/I variables static
(except for arrays, which typically had variable dimensions).

On 2023-09-07 13:32, Bernd Oppolzer wrote:

Thinking a little bit more about this:

the insurance company used auto variables heavily, BUT:

until the 2010 time frame, they didn't allow (or: suggested not to use) 
INTERNAL PL/1 procedures !!
Instead they had some home grown macros based on label variables, which 
worked much the same like
procedure calls, but the "program blocks", which were built using these 
macros - of course - didn't have local variables;

all variables are GLOBAL.

Using this technique, performance issues during procedure startup are 
no problem, of course.


In 2010, one of my co-workers (and a friend of mine) checked out the 
performance of these "program blocks"
and found out that the heavy use of label variables COMPROMISES the 
optimizing strategies of the modern compilers,
so that now the "program blocks" based on label variables are MUCH 
SLOWER than original PL/1 procedures.


That's why the company now changed the recommendation and asked all 
programmers to change the
programs from the old "program blocks" to normal procedures (when doing 
maintenance to the programs).
This led to significant better performance in some cases (especially in 
large Batch programs with many "program blocks").


There are still many programs using the old "program blocks", and we 
are now thinking about forcing
the transformation process in the next months. When compiling a program 
using the old feature,
you get a return code of 8 and a compiler message, but the code is 
produced, anyway.


Kind regards

Bernd


Am 07.09.2023 um 05:13 schrieb Bernd Oppolzer:

Am 07.09.2023 um 01:40 schrieb Leonard D Woren:

Michael Stein wrote on 9/6/2023 3:45 PM:
[...] PL/1 F level subroutine calls did a getmain/freemain for each 
subroutine call. Too much overhead to call even one subroutine for 
each of 30K records on a 360/91 & MVT.


Well, my recollection is that if you had only Static storage, no 
Automatic storage, it didn't do a GETMAIN.
Or was that an enhancement in the new PL/I compiler?  Was that PLIX?  
Yeah, not using stuff for decades can cause memory fade.



/Leonard



I first came into contact with PL/1 in the end of the 1980s at the 
beforementionend insurance company.
At that time, they had the V2.3 optimizer (IIRC), and it produced 
pretty amazing code. I was asked to
do PL/1 classes for the developers there. This company made (and still 
makes) heavy use of automatic storage and tried to
code all modules "naturally reentrant", that is: no modified static 
storage. So the problems with getmain/freemain
at procedure startup and end must have been long gone. That company 
started with PL/1 in the beginning of the 1980s,
before that is was an ASSEMBLER only shop. (C came later, from 1992 
on).


1992 (and 1994 again) I was asked to do a dump analysis class in 
another PL/1 company. They indeed had


DEFEAULT RANGE(*) STATIC;

in almost every program. I didn't understand the reason at that time 
and thought is was for dump reading,
because static variable (in the STATIC CSECT which is part of the load 
module) are much easier to find than
auto variables (living in the stack). But now I have the impression 
that this could have simply been a performance

issue in the beginning.

Kind regards

Bernd

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

PL/I early compilers performance issues

[Bernd Oppolzer]

Thinking a little bit more about this:

the insurance company used auto variables heavily, BUT:

until the 2010 time frame, they didn't allow (or: suggested not to use) 
INTERNAL PL/1 procedures !!
Instead they had some home grown macros based on label variables, which 
worked much the same like
procedure calls, but the "program blocks", which were built using these 
macros - of course - didn't have local variables;

all variables are GLOBAL.

Using this technique, performance issues during procedure startup are no 
problem, of course.


In 2010, one of my co-workers (and a friend of mine) checked out the 
performance of these "program blocks"
and found out that the heavy use of label variables COMPROMISES the 
optimizing strategies of the modern compilers,
so that now the "program blocks" based on label variables are MUCH 
SLOWER than original PL/1 procedures.


That's why the company now changed the recommendation and asked all 
programmers to change the
programs from the old "program blocks" to normal procedures (when doing 
maintenance to the programs).
This led to significant better performance in some cases (especially in 
large Batch programs with many "program blocks").


There are still many programs using the old "program blocks", and we are 
now thinking about forcing
the transformation process in the next months. When compiling a program 
using the old feature,
you get a return code of 8 and a compiler message, but the code is 
produced, anyway.


Kind regards

Bernd


Am 07.09.2023 um 05:13 schrieb Bernd Oppolzer:

Am 07.09.2023 um 01:40 schrieb Leonard D Woren:

Michael Stein wrote on 9/6/2023 3:45 PM:
[...] PL/1 F level subroutine calls did a getmain/freemain for each 
subroutine call. Too much overhead to call even one subroutine for 
each of 30K records on a 360/91 & MVT.


Well, my recollection is that if you had only Static storage, no 
Automatic storage, it didn't do a GETMAIN.
Or was that an enhancement in the new PL/I compiler?  Was that PLIX?  
Yeah, not using stuff for decades can cause memory fade.



/Leonard



I first came into contact with PL/1 in the end of the 1980s at the 
beforementionend insurance company.
At that time, they had the V2.3 optimizer (IIRC), and it produced 
pretty amazing code. I was asked to
do PL/1 classes for the developers there. This company made (and still 
makes) heavy use of automatic storage and tried to
code all modules "naturally reentrant", that is: no modified static 
storage. So the problems with getmain/freemain
at procedure startup and end must have been long gone. That company 
started with PL/1 in the beginning of the 1980s,

before that is was an ASSEMBLER only shop. (C came later, from 1992 on).

1992 (and 1994 again) I was asked to do a dump analysis class in 
another PL/1 company. They indeed had


DEFEAULT RANGE(*) STATIC;

in almost every program. I didn't understand the reason at that time 
and thought is was for dump reading,
because static variable (in the STATIC CSECT which is part of the load 
module) are much easier to find than
auto variables (living in the stack). But now I have the impression 
that this could have simply been a performance

issue in the beginning.

Kind regards

Bernd

--
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 Opt. Compiler V2 manuals?

[Peter Sylvester]

 Seymour J Metz and others wrote:

Yes, but why doesn't it go into a save dialog instead of rendering it 
inappropriately?


because IBM tells that the mime-type is text/plain   they most likely don't have boo in their mime 
"dictionary"


curl should be your friend.




With a .boo ending, you need to use a bookmanager viewer.

The first four links are bad. jibberish is shown, like we are looking at
a character print of some binary file.


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

Re: PL/I Opt. Compiler V2 manuals?

[Seymour J Metz]

Yes, but why doesn't it go into a save dialog instead of rendering it 
inappropriately?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Mike Schwab [mike.a.sch...@gmail.com]
Sent: Sunday, March 19, 2023 9:15 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I Opt. Compiler V2 manuals?

With a .boo ending, you need to use a bookmanager viewer.

On Sun, Mar 19, 2023 at 7:39 PM Robin Vowels  wrote:
>
> On 2023-03-20 11:32, Peter Stockdill wrote:
> > Hi Robin,
> >
> > The first four are direct links to the BookManager book files.
> > The fifth should have been:
> > http://secure-web.cisco.com/1U08Rm2j6fYNp8Jh8eR8ICgE4hnrCH578H0EFyXcv8yS_G8Li99atmMZ3OMRvUvTbRTO5WwToIyLT9oD3tadl8e67J5N6OsD5qOpWcNASHrefrPYKd6eQLEDsaXQrciM40V2so9ugGpCR3-APQBYZxe0fkrjVXh2JZOMJszLIcRjc8_H6C1B2N3J_l36WMi2JcuOJilgzzC6Tw4gD07LVmD12umskwPLY23IfY093ZM2iTu2BaHJR8Ng0uY0lpTsrg1XXCgBzkD_Wv5_I5hgAseSUwDX1sC1UU83cSzkH1b0bMs7T6-Xn85mL0twKmrJVI5BsTVBQq3B1ErLD5Ddvq_XWh319tD6H4Ww29xIlkcllDuxrX7VIhA_aEI7HlGuSEe-AGEGjv1Y2_Uad_fkJm-EQxfLRV-9SqE2NQKXCN7I/http%3A%2F%2Fwww.bitsavers.org%2Fpdf%2Fibm%2F370%2Fpli%2FLY27-9528-0_OS_PLI_Version_2_Proble
> > m_Determination_Dec87.pdf
>
> As I said, the last link is OK.
> The first four links are bad. jibberish is shown, like we are looking at
> a character print of some binary file.
>
> > Cheers,
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of
> > Robin Vowels
> > Sent: Monday, 20 March 2023 8:12 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: PL/I Opt. Compiler V2 manuals?
> >
> > Except for the last, the links are incomplete.
> >
> > On 2023-03-20 08:06, Peter Stockdill wrote:
> >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublib.boulder.ibm.com%2Fepubs%2Fbook%2Fibmop002.boo=05%7C01%7Csmetz3%40gmu.edu%7C6e3d9a7064eb4d28d10208db28e0df3e%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C638148718517346202%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=%2BZdzQLLvJ3yT9MxHr8R%2B%2BmgX3%2FcALv%2FBL2chEidQLus%3D=0
> >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublib.boulder.ibm.com%2Fepubs%2Fbook%2Fibmol004.boo=05%7C01%7Csmetz3%40gmu.edu%7C6e3d9a7064eb4d28d10208db28e0df3e%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C638148718517346202%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=KYLTvHAT4nN%2BSBBt%2F9BQoWvH556XTKaBXxSFfAw6s9E%3D=0
> >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublib.boulder.ibm.com%2Fepubs%2Fbook%2Fibmom002.boo=05%7C01%7Csmetz3%40gmu.edu%7C6e3d9a7064eb4d28d10208db28e0df3e%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C638148718517346202%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=yZoP6LMuQjZ%2FDySHe2Lz7xvydZM57lADpFl0n1RlKgg%3D=0
> >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublib.boulder.ibm.com%2Fepubs%2Fbook%2Fibmot001.boo=05%7C01%7Csmetz3%40gmu.edu%7C6e3d9a7064eb4d28d10208db28e0df3e%7C9e857255df574c47a0c00546460380cb%7C0%7C0%7C638148718517346202%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=biArLf5Y0eh3ypCCuf15TkqF%2BlfKUEGF7e1pVUbCO0Y%3D=0
> >> http://secure-web.cisco.com/1aJrlBbUWMfWhJH1Uz4oco7_vPtbIUJ5Uo6insBfqj3lt9nBB1638CA_EUIlFhj9ZR-oIOJHVhoXtxsJOG0DczThUAnT-UKr1potlzIFSHqZWsy4RmDJXCzESNur8Y2hLLOMbtx-DqrqtxTzlq0CvvSjkiUjDIN-qTemiCGHd9k2TXh4wsIsDQsUaqXsWA5yP2CzoWzPNGSENh8N94Nn-WJq2yENpXHiK8abyyKgFlNgJgLPU_vc3iCegEe6E9Flhz7kkHPUbSFsf5_Zp0sVvmx6HXPdAcr2_40_oHilb9JoKSbACMW8jxz-K3R7YrVMbb_rvqbWlGTuYGQ6q1FVTh4L3jUu2vaOsKGF0bNJD-L7tnHfTauufPKEpaz9ORhOBEAnyWLyHbj4U5NWt9TzFiV5tIV59LaU43UiJmDeqn4Y/http%3A%2F%2Fwww.bitsavers.org%2Fpdf%2Fibm%2F370%2Fpli%2FLY27-9528-0_OS_PLI_Version_2_
> >> Problem_Determination_Dec87.pdf
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
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 Opt. Compiler V2 manuals?

[Seymour J Metz]

I'd rather stick to the native OS/2 version for the time being, until I have 
the native Linux version set up. Thanks.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Martin Trübner [047eec287bd9-dmarc-requ...@listserv.ua.edu]
Sent: Monday, March 20, 2023 12:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I Opt. Compiler V2 manuals?

I use WINE on top - works fine here

Am 20.03.23 um 16:10 schrieb Seymour J Metz:
> If someone responds off-list, please send me the link.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
> Dave Jones [d...@vsoft-software.com]
> Sent: Monday, March 20, 2023 10:24 AM
> To:IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PL/I Opt. Compiler V2 manuals?
>
> Does anyone know where I can download the Softcopy Reader for Linux? The IBM 
> site seems to have only the Windows version.
> Thanks.
> DJ
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email tolists...@listserv.ua.edu  with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email tolists...@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 Opt. Compiler V2 manuals?

[Martin Trübner]

I use WINE on top - works fine here

Am 20.03.23 um 16:10 schrieb Seymour J Metz:

If someone responds off-list, please send me the link.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Dave Jones [d...@vsoft-software.com]
Sent: Monday, March 20, 2023 10:24 AM
To:IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I Opt. Compiler V2 manuals?

Does anyone know where I can download the Softcopy Reader for Linux? The IBM 
site seems to have only the Windows version.
Thanks.
DJ

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

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email tolists...@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 Opt. Compiler V2 manuals?

[Farley, Peter]

Thank you for that link Peter.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Peter Stockdill
Sent: Monday, March 20, 2023 2:28 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I Opt. Compiler V2 manuals?

I found the four books in:
https://publib.boulder.ibm.com/epubs/df/s390app4.des 
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


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

Re: PL/I Opt. Compiler V2 manuals?

[Seymour J Metz]

If someone responds off-list, please send me the link.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Dave Jones [d...@vsoft-software.com]
Sent: Monday, March 20, 2023 10:24 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I Opt. Compiler V2 manuals?

Does anyone know where I can download the Softcopy Reader for Linux? The IBM 
site seems to have only the Windows version.
Thanks.
DJ

--
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 Opt. Compiler V2 manuals?

[Dave Jones]

Does anyone know where I can download the Softcopy Reader for Linux? The IBM 
site seems to have only the Windows version.
Thanks.
DJ

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

Re: PL/I Opt. Compiler V2 manuals?

[Peter Stockdill]

I found the four books in:
https://publib.boulder.ibm.com/epubs/df/s390app4.des

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter
Sent: Monday, 20 March 2023 12:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I Opt. Compiler V2 manuals?

Thanks Mike, I do already have those downloads (or similar from an earlier 
era).  What I don’t have is an address of an archive of .boo's to DL from.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mike Schwab
Sent: Sunday, March 19, 2023 9:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I Opt. Compiler V2 manuals?

Need something from
https://urldefense.com/v3/__https://www.ibm.com/support/pages/downloadable-free-bookmanager-tools-and-components__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!Is3tLzKjqwn7uw0fBC6uRW6DV6XDKNyd-Tawu5K-vTRQS5vGe5AjlL3DJM-TeeVCCTXniAXdfHKRujBoYeb-5ErCLFK6$
for the .boo links.

On Sun, Mar 19, 2023 at 7:13 PM Robin Vowels  wrote:
>
> Except for the last, the links are incomplete.
>
> On 2023-03-20 08:06, Peter Stockdill wrote:
> > https://urldefense.com/v3/__https://publib.boulder.ibm.com/epubs/boo
> > k/ibmop002.boo__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!Is3tLzKjqwn7uw0fBC
> > 6uRW6DV6XDKNyd-Tawu5K-vTRQS5vGe5AjlL3DJM-TeeVCCTXniAXdfHKRujBoYeb-5K
> > 6OLJdE$
> > https://urldefense.com/v3/__https://publib.boulder.ibm.com/epubs/boo
> > k/ibmol004.boo__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!Is3tLzKjqwn7uw0fBC
> > 6uRW6DV6XDKNyd-Tawu5K-vTRQS5vGe5AjlL3DJM-TeeVCCTXniAXdfHKRujBoYeb-5F
> > z2aw83$
> > https://urldefense.com/v3/__https://publib.boulder.ibm.com/epubs/boo
> > k/ibmom002.boo__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!Is3tLzKjqwn7uw0fBC
> > 6uRW6DV6XDKNyd-Tawu5K-vTRQS5vGe5AjlL3DJM-TeeVCCTXniAXdfHKRujBoYeb-5M
> > inwQ4D$
> > https://urldefense.com/v3/__https://publib.boulder.ibm.com/epubs/boo
> > k/ibmot001.boo__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!Is3tLzKjqwn7uw0fBC
> > 6uRW6DV6XDKNyd-Tawu5K-vTRQS5vGe5AjlL3DJM-TeeVCCTXniAXdfHKRujBoYeb-5D
> > Ym64ZE$
> > https://urldefense.com/v3/__http://www.bitsavers.org/pdf/ibm/370/pli
> > /LY27-9528-0_OS_PLI_Version_2_Problem_Determination_Dec87.pdf__;!!Eb
> > r-cpPeAnfNniQ8HSAI-g_K5b7VKg!Is3tLzKjqwn7uw0fBC6uRW6DV6XDKNyd-Tawu5K
> > -vTRQS5vGe5AjlL3DJM-TeeVCCTXniAXdfHKRujBoYeb-5LZuiW-9$
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


--
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 Opt. Compiler V2 manuals?

[Farley, Peter]

Thanks Mike, I do already have those downloads (or similar from an earlier 
era).  What I don’t have is an address of an archive of .boo's to DL from.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mike Schwab
Sent: Sunday, March 19, 2023 9:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I Opt. Compiler V2 manuals?

Need something from
https://urldefense.com/v3/__https://www.ibm.com/support/pages/downloadable-free-bookmanager-tools-and-components__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!Is3tLzKjqwn7uw0fBC6uRW6DV6XDKNyd-Tawu5K-vTRQS5vGe5AjlL3DJM-TeeVCCTXniAXdfHKRujBoYeb-5ErCLFK6$
for the .boo links.

On Sun, Mar 19, 2023 at 7:13 PM Robin Vowels  wrote:
>
> Except for the last, the links are incomplete.
>
> On 2023-03-20 08:06, Peter Stockdill wrote:
> > https://urldefense.com/v3/__https://publib.boulder.ibm.com/epubs/boo
> > k/ibmop002.boo__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!Is3tLzKjqwn7uw0fBC
> > 6uRW6DV6XDKNyd-Tawu5K-vTRQS5vGe5AjlL3DJM-TeeVCCTXniAXdfHKRujBoYeb-5K
> > 6OLJdE$ 
> > https://urldefense.com/v3/__https://publib.boulder.ibm.com/epubs/boo
> > k/ibmol004.boo__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!Is3tLzKjqwn7uw0fBC
> > 6uRW6DV6XDKNyd-Tawu5K-vTRQS5vGe5AjlL3DJM-TeeVCCTXniAXdfHKRujBoYeb-5F
> > z2aw83$ 
> > https://urldefense.com/v3/__https://publib.boulder.ibm.com/epubs/boo
> > k/ibmom002.boo__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!Is3tLzKjqwn7uw0fBC
> > 6uRW6DV6XDKNyd-Tawu5K-vTRQS5vGe5AjlL3DJM-TeeVCCTXniAXdfHKRujBoYeb-5M
> > inwQ4D$ 
> > https://urldefense.com/v3/__https://publib.boulder.ibm.com/epubs/boo
> > k/ibmot001.boo__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!Is3tLzKjqwn7uw0fBC
> > 6uRW6DV6XDKNyd-Tawu5K-vTRQS5vGe5AjlL3DJM-TeeVCCTXniAXdfHKRujBoYeb-5D
> > Ym64ZE$ 
> > https://urldefense.com/v3/__http://www.bitsavers.org/pdf/ibm/370/pli
> > /LY27-9528-0_OS_PLI_Version_2_Problem_Determination_Dec87.pdf__;!!Eb
> > r-cpPeAnfNniQ8HSAI-g_K5b7VKg!Is3tLzKjqwn7uw0fBC6uRW6DV6XDKNyd-Tawu5K
> > -vTRQS5vGe5AjlL3DJM-TeeVCCTXniAXdfHKRujBoYeb-5LZuiW-9$
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


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

Re: PL/I Opt. Compiler V2 manuals?

[Farley, Peter]

Peter, thanks for the .boo links.  I have them downloaded.

But why is it that when I try to get to the main publib.boulder.ibm.com page 
with Firefox I only get one item, a (broken) "favicon" item?  Is there another 
way into that resource?

Or is that originally an ftp link?

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Peter Stockdill
Sent: Sunday, March 19, 2023 5:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I Opt. Compiler V2 manuals?

EXTERNAL EMAIL

https://urldefense.com/v3/__https://publib.boulder.ibm.com/epubs/book/ibmop002.boo__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!OjBfJOLzg-BqgmOjv0IhyCd5bbGi9An0X_dtuuuaHhefNgPcmeqKgcykIb5X67lPNyg55U-dAIzd3oHNsX4WjwhMHBYN34E$
https://urldefense.com/v3/__https://publib.boulder.ibm.com/epubs/book/ibmol004.boo__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!OjBfJOLzg-BqgmOjv0IhyCd5bbGi9An0X_dtuuuaHhefNgPcmeqKgcykIb5X67lPNyg55U-dAIzd3oHNsX4WjwhMk6rok1U$
https://urldefense.com/v3/__https://publib.boulder.ibm.com/epubs/book/ibmom002.boo__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!OjBfJOLzg-BqgmOjv0IhyCd5bbGi9An0X_dtuuuaHhefNgPcmeqKgcykIb5X67lPNyg55U-dAIzd3oHNsX4WjwhMusqLbvg$
https://urldefense.com/v3/__https://publib.boulder.ibm.com/epubs/book/ibmot001.boo__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!OjBfJOLzg-BqgmOjv0IhyCd5bbGi9An0X_dtuuuaHhefNgPcmeqKgcykIb5X67lPNyg55U-dAIzd3oHNsX4WjwhMIvfWQ7A$
https://urldefense.com/v3/__http://www.bitsavers.org/pdf/ibm/370/pli/LY27-9528-0_OS_PLI_Version_2_Proble__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!OjBfJOLzg-BqgmOjv0IhyCd5bbGi9An0X_dtuuuaHhefNgPcmeqKgcykIb5X67lPNyg55U-dAIzd3oHNsX4WjwhMc5oFgrU$
m_Determination_Dec87.pdf

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter
Sent: Monday, 20 March 2023 3:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I Opt. Compiler V2 manuals?

I am particularly looking for any or all of the following manual numbers.  I am 
willing to pay for shipping if only hardcopy is available.  Please contact me 
privately at pjfarley3 at earthlink dot net for hardcopy coordination.

Programming GuideSC26-4307
Language Reference   SC26-4308
Using PLITEST SC26-4310
Messages and Codes  SC26-4309
Problem Determination LY27-9528
Installation and Customization under MVS   SC26-4311
Installation and Customization under CMS   SC26-4312

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter
Sent: Friday, March 17, 2023 10:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: PL/I Opt. Compiler V2 manuals?

I am working with some PL/I code originally developed under the PL/I Optimizing 
Compiler V2 and I need to refer to the manuals for that specific version to 
answer some questions.  Does anyone have access to V2 manuals?  I have searched 
all over bitsavers and AFAICT they have only V1 manuals.

Peter
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential.
If the reader of the message is not the intended recipient or an authorized 
representative of the intended recipient, you are hereby notified that any 
dissemination of this communication is strictly prohibited. If you have 
received this communication in error, please notify us immediately by e-mail 
and delete the message and any attachments from your system.

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

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

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

Re: PL/I Opt. Compiler V2 manuals?

[Peter Stockdill]

Yes, my web browser (Firefox) does the same. You can just 'Save The Page
As...'.

-Original Message-
From: robi...@dodo.com.au  
Sent: Monday, 20 March 2023 8:39 AM
To: IBM Mainframe Discussion List 
Cc: Peter Stockdill 
Subject: Re: PL/I Opt. Compiler V2 manuals?



On 2023-03-20 11:32, Peter Stockdill wrote:
> Hi Robin,
> 
> The first four are direct links to the BookManager book files.
> The fifth should have been:
> http://www.bitsavers.org/pdf/ibm/370/pli/LY27-9528-0_OS_PLI_Version_2_
> Proble
> m_Determination_Dec87.pdf

As I said, the last link is OK.
The first four links are bad. jibberish is shown, like we are looking at a
character print of some binary file.

> Cheers,
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Robin Vowels
> Sent: Monday, 20 March 2023 8:12 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: PL/I Opt. Compiler V2 manuals?
> 
> Except for the last, the links are incomplete.
> 
> On 2023-03-20 08:06, Peter Stockdill wrote:
>> https://publib.boulder.ibm.com/epubs/book/ibmop002.boo
>> https://publib.boulder.ibm.com/epubs/book/ibmol004.boo
>> https://publib.boulder.ibm.com/epubs/book/ibmom002.boo
>> https://publib.boulder.ibm.com/epubs/book/ibmot001.boo
>> http://www.bitsavers.org/pdf/ibm/370/pli/LY27-9528-0_OS_PLI_Version_2
>> _
>> Problem_Determination_Dec87.pdf

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

Re: PL/I Opt. Compiler V2 manuals?

[Mike Schwab]

Need something from
https://www.ibm.com/support/pages/downloadable-free-bookmanager-tools-and-components
for the .boo links.

On Sun, Mar 19, 2023 at 7:13 PM Robin Vowels  wrote:
>
> Except for the last, the links are incomplete.
>
> On 2023-03-20 08:06, Peter Stockdill wrote:
> > https://publib.boulder.ibm.com/epubs/book/ibmop002.boo
> > https://publib.boulder.ibm.com/epubs/book/ibmol004.boo
> > https://publib.boulder.ibm.com/epubs/book/ibmom002.boo
> > https://publib.boulder.ibm.com/epubs/book/ibmot001.boo
> > http://www.bitsavers.org/pdf/ibm/370/pli/LY27-9528-0_OS_PLI_Version_2_Problem_Determination_Dec87.pdf
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: PL/I Opt. Compiler V2 manuals?

[Mike Schwab]

With a .boo ending, you need to use a bookmanager viewer.

On Sun, Mar 19, 2023 at 7:39 PM Robin Vowels  wrote:
>
> On 2023-03-20 11:32, Peter Stockdill wrote:
> > Hi Robin,
> >
> > The first four are direct links to the BookManager book files.
> > The fifth should have been:
> > http://www.bitsavers.org/pdf/ibm/370/pli/LY27-9528-0_OS_PLI_Version_2_Proble
> > m_Determination_Dec87.pdf
>
> As I said, the last link is OK.
> The first four links are bad. jibberish is shown, like we are looking at
> a character print of some binary file.
>
> > Cheers,
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List  On
> > Behalf Of
> > Robin Vowels
> > Sent: Monday, 20 March 2023 8:12 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: PL/I Opt. Compiler V2 manuals?
> >
> > Except for the last, the links are incomplete.
> >
> > On 2023-03-20 08:06, Peter Stockdill wrote:
> >> https://publib.boulder.ibm.com/epubs/book/ibmop002.boo
> >> https://publib.boulder.ibm.com/epubs/book/ibmol004.boo
> >> https://publib.boulder.ibm.com/epubs/book/ibmom002.boo
> >> https://publib.boulder.ibm.com/epubs/book/ibmot001.boo
> >> http://www.bitsavers.org/pdf/ibm/370/pli/LY27-9528-0_OS_PLI_Version_2_
> >> Problem_Determination_Dec87.pdf
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: PL/I Opt. Compiler V2 manuals?

[Robin Vowels]

On 2023-03-20 11:32, Peter Stockdill wrote:

Hi Robin,

The first four are direct links to the BookManager book files.
The fifth should have been:
http://www.bitsavers.org/pdf/ibm/370/pli/LY27-9528-0_OS_PLI_Version_2_Proble
m_Determination_Dec87.pdf


As I said, the last link is OK.
The first four links are bad. jibberish is shown, like we are looking at
a character print of some binary file.


Cheers,


-Original Message-
From: IBM Mainframe Discussion List  On 
Behalf Of

Robin Vowels
Sent: Monday, 20 March 2023 8:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I Opt. Compiler V2 manuals?

Except for the last, the links are incomplete.

On 2023-03-20 08:06, Peter Stockdill wrote:

https://publib.boulder.ibm.com/epubs/book/ibmop002.boo
https://publib.boulder.ibm.com/epubs/book/ibmol004.boo
https://publib.boulder.ibm.com/epubs/book/ibmom002.boo
https://publib.boulder.ibm.com/epubs/book/ibmot001.boo
http://www.bitsavers.org/pdf/ibm/370/pli/LY27-9528-0_OS_PLI_Version_2_
Problem_Determination_Dec87.pdf


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

Re: PL/I Opt. Compiler V2 manuals?

[Peter Stockdill]

Hi Robin,

The first four are direct links to the BookManager book files. 
The fifth should have been:
http://www.bitsavers.org/pdf/ibm/370/pli/LY27-9528-0_OS_PLI_Version_2_Proble
m_Determination_Dec87.pdf

Cheers,


-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Robin Vowels
Sent: Monday, 20 March 2023 8:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I Opt. Compiler V2 manuals?

Except for the last, the links are incomplete.

On 2023-03-20 08:06, Peter Stockdill wrote:
> https://publib.boulder.ibm.com/epubs/book/ibmop002.boo
> https://publib.boulder.ibm.com/epubs/book/ibmol004.boo
> https://publib.boulder.ibm.com/epubs/book/ibmom002.boo
> https://publib.boulder.ibm.com/epubs/book/ibmot001.boo
> http://www.bitsavers.org/pdf/ibm/370/pli/LY27-9528-0_OS_PLI_Version_2_
> Problem_Determination_Dec87.pdf

--
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 Opt. Compiler V2 manuals?

[Robin Vowels]

Except for the last, the links are incomplete.

On 2023-03-20 08:06, Peter Stockdill wrote:

https://publib.boulder.ibm.com/epubs/book/ibmop002.boo
https://publib.boulder.ibm.com/epubs/book/ibmol004.boo
https://publib.boulder.ibm.com/epubs/book/ibmom002.boo
https://publib.boulder.ibm.com/epubs/book/ibmot001.boo
http://www.bitsavers.org/pdf/ibm/370/pli/LY27-9528-0_OS_PLI_Version_2_Problem_Determination_Dec87.pdf


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

Re: PL/I Opt. Compiler V2 manuals?

[Peter Stockdill]

https://publib.boulder.ibm.com/epubs/book/ibmop002.boo
https://publib.boulder.ibm.com/epubs/book/ibmol004.boo
https://publib.boulder.ibm.com/epubs/book/ibmom002.boo
https://publib.boulder.ibm.com/epubs/book/ibmot001.boo
http://www.bitsavers.org/pdf/ibm/370/pli/LY27-9528-0_OS_PLI_Version_2_Proble
m_Determination_Dec87.pdf

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Farley, Peter
Sent: Monday, 20 March 2023 3:47 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I Opt. Compiler V2 manuals?

I am particularly looking for any or all of the following manual numbers.  I
am willing to pay for shipping if only hardcopy is available.  Please
contact me privately at pjfarley3 at earthlink dot net for hardcopy
coordination.

Programming GuideSC26-4307
Language Reference   SC26-4308
Using PLITEST SC26-4310
Messages and Codes  SC26-4309
Problem Determination LY27-9528
Installation and Customization under MVS   SC26-4311
Installation and Customization under CMS   SC26-4312

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Farley, Peter
Sent: Friday, March 17, 2023 10:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: PL/I Opt. Compiler V2 manuals?

I am working with some PL/I code originally developed under the PL/I
Optimizing Compiler V2 and I need to refer to the manuals for that specific
version to answer some questions.  Does anyone have access to V2 manuals?  I
have searched all over bitsavers and AFAICT they have only V1 manuals.

Peter
--

This message and any attachments are intended only for the use of the
addressee and may contain information that is privileged and confidential.
If the reader of the message is not the intended recipient or an authorized
representative of the intended recipient, you are hereby notified that any
dissemination of this communication is strictly prohibited. If you have
received this communication in error, please notify us immediately by e-mail
and delete the message and any attachments from your system.

--
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 Opt. Compiler V2 manuals?

[Farley, Peter]

I am particularly looking for any or all of the following manual numbers.  I am 
willing to pay for shipping if only hardcopy is available.  Please contact me 
privately at pjfarley3 at earthlink dot net for hardcopy coordination.

Programming GuideSC26-4307
Language Reference   SC26-4308
Using PLITEST SC26-4310
Messages and Codes  SC26-4309
Problem Determination LY27-9528
Installation and Customization under MVS   SC26-4311
Installation and Customization under CMS   SC26-4312

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Farley, Peter
Sent: Friday, March 17, 2023 10:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: PL/I Opt. Compiler V2 manuals?

I am working with some PL/I code originally developed under the PL/I Optimizing 
Compiler V2 and I need to refer to the manuals for that specific version to 
answer some questions.  Does anyone have access to V2 manuals?  I have searched 
all over bitsavers and AFAICT they have only V1 manuals.

Peter
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

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

PL/I Opt. Compiler V2 manuals?

[Farley, Peter]

I am working with some PL/I code originally developed under the PL/I Optimizing 
Compiler V2 and I need to refer to the manuals for that specific version to 
answer some questions.  Does anyone have access to V2 manuals?  I have searched 
all over bitsavers and AFAICT they have only V1 manuals.

Peter

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

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

Re: Question on writing PL/I to use EXEC PARM/PARMDD

[Robin Vowels]

On 2022-11-21 05:46, Farley, Peter wrote:

Thanks to all for the PL/I advice, and yes, I do know they changed the
name from 1 to I a long time ago,


The language has always been called PL/I, from IBM's first LRM
C28-6571.
(after, of course, from earlier temporary names such as NPL)


but I didn't much like that rename
starting from when they did it.  What was wrong with using a plain
Arabic numeral?

Then again I use the Roman numeral III for my full name since I am the
third generation with that name (and my son is the IV'th).  We are all
sometimes a bit schizophrenic in our thinking.

Anyway, thanks again to all for the gentle advice.  Appreciated.

Peter


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

Re: Question on writing PL/I to use EXEC PARM/PARMDD

[Seymour J Metz]

Is that across the board or only when it is the parameter for OPTIONS(MAIN)?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Robert Prins [robert.ah.pr...@gmail.com]
Sent: Sunday, November 20, 2022 2:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Question on writing PL/I to use EXEC PARM/PARMDD

No it doesn't EPLI 5.3+ now gives a warning when you use "CHAR(100) VAR".
You should nowadays code "CHAT(*) VAR"!

RTFM!

On Sun, 20 Nov 2022 at 16:59, Robin Vowels  wrote:

> On 2022-11-21 02:29, Steve Smith wrote:
> > Not necessarily.
>
> My example code (which preceded) comes straight from the manual,
> and is required when main PROCEDURE statement is as I showed,
> namely,
> M: PROC (PARAM) OPTIONS (MAIN);
> DECLARE PARAM CHARACTER(100) VARYING;
>
> >  Assuming using an LE compiler, the EXECOPTS compile
> > option controls this.
>
> It doesn't.
> Read the manual.
> What I wrote applies then EXECOPS is not used.
>
> > On Sun, Nov 20, 2022 at 2:30 AM Robin Vowels 
> > wrote:
> >
> >> The string passed to the main procedure needs to start with
> >> a slash, because everything up to and including the slash
> >> is omitted when passed.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


--
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather 
<https://secure-web.cisco.com/1X45p2mu4c3WsOWBoGukxKIZa5PXBadYC-9agrgEuv2qg59rFccNTg4koDJGZSkx_fHfmVzAGrFE7FN1GyUlcV-x2V5irVc-N-wgn-z7TiEan_5plCDVZOXbqgptbPIwZ6AUJ7PzvJ0CEXCnTzVFlVnvMBtgS6m32hpjk0CBRmXVyot7sHiteuhTzpE2lpSVmiNw9OLk5svcF20HYGZGWmstqIX1b_nNR8ydWbDh_3pqMys1JyglmphgkVxU3xz6EZ4ajrSvzFEDi3iNrujrLdBSUXlmbzHWdy4x651bb4ZHR3C_rVg6MMf-T5DBLrZjBf81LxhgdUWWAmMl-JWTzLybSyEMsV2j9qyCQMQobBXW5pylYtjmHORGqivHLx8j6roQtAQ3ENltzu834Pi639ph-Mr8jvvk13Np-0U1ni3gCj5G6hyYoSzA94Q1J1XrJ/https%3A%2F%2Fprino.neocities.org%2Findex.html>
Some REXX code for use on z/OS
<https://secure-web.cisco.com/1Df9t6H1NMlJxhohoTak6hTB4SoL1m-9bMHw_Q1cQBIYtlIOvq49o7DB7eGMcPVfq3pmIetT4NNQvlttc6F6n4pc-hF4OD_EG33csbOAk2URaskwo4bSqAHqH1gfoVhy6rRuRm0EOj5-MmAe01ocix59bJiJeR6zPceqyZF4G7QS_juaZZ_HUHDD8fuqwwvO4-spejlRo0NgqfNzQxpFiy6Y2eVaThxFfNqCvPOoRtxxbl0ou_fDy6HW3HbmY7paOg_XCsrYPJrHeACpXh8rTIR1SjgwWLxxULj352adrHcIV7qluqoxhUOzxnj6wIwG-Z9rDS7z5GkFKJtkWKQ3N8LpvTSsqCv_KH1ZylxE7B_rzRdiDT5y-UDR-NfRbGPtHsuSscqonH-w9j4N9bnxdujvYvFb0AS4SYOOCMj9bI1tBbV7pixuH2DbUfjjh5Tcr/https%3A%2F%2Fprino.neocities.org%2FzOS%2FzOS-Tools.html>

--
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: Question on writing PL/I to use EXEC PARM/PARMDD

[Farley, Peter]

Thanks to all for the PL/I advice, and yes, I do know they changed the name 
from 1 to I a long time ago, but I didn't much like that rename starting from 
when they did it.  What was wrong with using a plain Arabic numeral?

Then again I use the Roman numeral III for my full name since I am the third 
generation with that name (and my son is the IV'th).  We are all sometimes a 
bit schizophrenic in our thinking.

Anyway, thanks again to all for the gentle advice.  Appreciated.

Peter

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Robert Prins
Sent: Sunday, November 20, 2022 2:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Question on writing PL/I to use EXEC PARM/PARMDD

Oops fat finger, "CHAR(*) VAR"

On Sun, 20 Nov 2022 at 19:16, Robert Prins 
wrote:

> No it doesn't EPLI 5.3+ now gives a warning when you use "CHAR(100) VAR".
> You should nowadays code "CHAT(*) VAR"!
>
> RTFM!
>
> On Sun, 20 Nov 2022 at 16:59, Robin Vowels  wrote:
>
>> On 2022-11-21 02:29, Steve Smith wrote:
>> > Not necessarily.
>>
>> My example code (which preceded) comes straight from the manual,
>> and is required when main PROCEDURE statement is as I showed,
>> namely,
>> M: PROC (PARAM) OPTIONS (MAIN);
>> DECLARE PARAM CHARACTER(100) VARYING;
>>
>> >  Assuming using an LE compiler, the EXECOPTS compile
>> > option controls this.
>>
>> It doesn't.
>> Read the manual.
>> What I wrote applies then EXECOPS is not used.
>>
>> > On Sun, Nov 20, 2022 at 2:30 AM Robin Vowels 
>> > wrote:
>> >
>> >> The string passed to the main procedure needs to start with
>> >> a slash, because everything up to and including the slash
>> >> is omitted when passed.
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


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

Re: Question on writing PL/I to use EXEC PARM/PARMDD

[Robert Prins]

Oops fat finger, "CHAR(*) VAR"

On Sun, 20 Nov 2022 at 19:16, Robert Prins 
wrote:

> No it doesn't EPLI 5.3+ now gives a warning when you use "CHAR(100) VAR".
> You should nowadays code "CHAT(*) VAR"!
>
> RTFM!
>
> On Sun, 20 Nov 2022 at 16:59, Robin Vowels  wrote:
>
>> On 2022-11-21 02:29, Steve Smith wrote:
>> > Not necessarily.
>>
>> My example code (which preceded) comes straight from the manual,
>> and is required when main PROCEDURE statement is as I showed,
>> namely,
>> M: PROC (PARAM) OPTIONS (MAIN);
>> DECLARE PARAM CHARACTER(100) VARYING;
>>
>> >  Assuming using an LE compiler, the EXECOPTS compile
>> > option controls this.
>>
>> It doesn't.
>> Read the manual.
>> What I wrote applies then EXECOPS is not used.
>>
>> > On Sun, Nov 20, 2022 at 2:30 AM Robin Vowels 
>> > wrote:
>> >
>> >> The string passed to the main procedure needs to start with
>> >> a slash, because everything up to and including the slash
>> >> is omitted when passed.
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>
>
> --
> Robert AH Prins
> robert(a)prino(d)org
> The hitchhiking grandfather 
> Some REXX code for use on z/OS
> 
>


-- 
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather 
Some REXX code for use on z/OS


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

Re: Question on writing PL/I to use EXEC PARM/PARMDD

[Robert Prins]

No it doesn't EPLI 5.3+ now gives a warning when you use "CHAR(100) VAR".
You should nowadays code "CHAT(*) VAR"!

RTFM!

On Sun, 20 Nov 2022 at 16:59, Robin Vowels  wrote:

> On 2022-11-21 02:29, Steve Smith wrote:
> > Not necessarily.
>
> My example code (which preceded) comes straight from the manual,
> and is required when main PROCEDURE statement is as I showed,
> namely,
> M: PROC (PARAM) OPTIONS (MAIN);
> DECLARE PARAM CHARACTER(100) VARYING;
>
> >  Assuming using an LE compiler, the EXECOPTS compile
> > option controls this.
>
> It doesn't.
> Read the manual.
> What I wrote applies then EXECOPS is not used.
>
> > On Sun, Nov 20, 2022 at 2:30 AM Robin Vowels 
> > wrote:
> >
> >> The string passed to the main procedure needs to start with
> >> a slash, because everything up to and including the slash
> >> is omitted when passed.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather 
Some REXX code for use on z/OS


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

Re: Question on writing PL/I to use EXEC PARM/PARMDD

[Robin Vowels]

On 2022-11-21 02:29, Steve Smith wrote:

Not necessarily.


My example code (which preceded) comes straight from the manual,
and is required when main PROCEDURE statement is as I showed,
namely,
M: PROC (PARAM) OPTIONS (MAIN);
   DECLARE PARAM CHARACTER(100) VARYING;


 Assuming using an LE compiler, the EXECOPTS compile
option controls this.


It doesn't.
Read the manual.
What I wrote applies then EXECOPS is not used.

On Sun, Nov 20, 2022 at 2:30 AM Robin Vowels  
wrote:



The string passed to the main procedure needs to start with
a slash, because everything up to and including the slash
is omitted when passed.


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

Re: Question on writing PL/I to use EXEC PARM/PARMDD

[Steve Smith]

Not necessarily.  Assuming using an LE compiler, the EXECOPTS compile
option controls this.

sas

On Sun, Nov 20, 2022 at 2:30 AM Robin Vowels  wrote:

> The string passed to the main procedure needs to start with
> a slash, because everything up to and including the slash
> is omitted when passed.
>
> --
> 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: Question on writing PL/I to use EXEC PARM/PARMDD

[Robin Vowels]

The string passed to the main procedure needs to start with
a slash, because everything up to and including the slash
is omitted when passed.

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

Re: Old PL/I Optimizing compiler - COUNT & FLOW options

[Robert Prins]

The former. Never tried running it with the LE datasets.

Robert

On Tue, 21 Jun 2022 at 16:13, Allan Staller <
0387911dea17-dmarc-requ...@listserv.ua.edu> wrote:

> Classification: Confidential
>
> SYS1.IBM* ? or the LE VERSION SYS1.CEERUN1/2
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Robert Prins
> Sent: Saturday, June 18, 2022 10:52 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Old PL/I Optimizing compiler - COUNT & FLOW options
>
> [CAUTION: This Email is from outside the Organization. Unless you trust
> the sender, Don't click links or open attachments as it may be a Phishing
> email, which can steal your Information and compromise your Computer.]
>
>  Hi all,
>
> Does anyone know which library modules are responsible for the
> implementation of these two compiler options, and more precisely, for the
> reporting of statement counts, as I need to (try to) patch the latter,
> given that it treats negative counts as zero, and I now have a program
> where four of the counts have turned negative, because the statements are
> executed more than 2^31-1 times.
>
> Robert
> --
> Robert AH Prins
> robert(a)prino(d)org
> The hitchhiking grandfather -
> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprino.neocities.org%2Fdata=05%7C01%7Callan.staller%40HCL.COM%7C8b94cc89d74646896d8108da512988a7%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637911536139011183%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=xERlwjiqImZJxLGf3O9YnMHmi4jMLEihCmRC3q12p0Y%3Dreserved=0
> Some REXX code for use on z/OS -
>
> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprino.neocities.org%2FzOS%2FzOS-Tools.htmldata=05%7C01%7Callan.staller%40HCL.COM%7C8b94cc89d74646896d8108da512988a7%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637911536139011183%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=MQIeqKuwQYogpQrTxgrmGpEhHoIjK%2Fvoe8%2FWbgrn%2FyE%3Dreserved=0
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> ::DISCLAIMER::
> 
> The contents of this e-mail and any attachment(s) are confidential and
> intended for the named recipient(s) only. E-mail transmission is not
> guaranteed to be secure or error-free as information could be intercepted,
> corrupted, lost, destroyed, arrive late or incomplete, or may contain
> viruses in transmission. The e mail and its contents (with or without
> referred errors) shall therefore not attach any liability on the originator
> or HCL or its affiliates. Views or opinions, if any, presented in this
> email are solely those of the author and may not necessarily reflect the
> views or opinions of HCL or its affiliates. Any form of reproduction,
> dissemination, copying, disclosure, modification, distribution and / or
> publication of this message without the prior written consent of authorized
> representative of HCL is strictly prohibited. If you have received this
> email in error please delete it and notify the sender immediately. Before
> opening any email and/or attachments, please check them for viruses and
> other defects.
> 
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather <https://prino.neocities.org/index.html>
Some REXX code for use on z/OS
<https://prino.neocities.org/zOS/zOS-Tools.html>

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

Re: Old PL/I Optimizing compiler - COUNT & FLOW options

[Allan Staller]

Classification: Confidential

SYS1.IBM* ? or the LE VERSION SYS1.CEERUN1/2

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Robert Prins
Sent: Saturday, June 18, 2022 10:52 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Old PL/I Optimizing compiler - COUNT & FLOW options

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don't click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

 Hi all,

Does anyone know which library modules are responsible for the implementation 
of these two compiler options, and more precisely, for the reporting of 
statement counts, as I need to (try to) patch the latter, given that it treats 
negative counts as zero, and I now have a program where four of the counts have 
turned negative, because the statements are executed more than 2^31-1 times.

Robert
--
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather - 
https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprino.neocities.org%2Fdata=05%7C01%7Callan.staller%40HCL.COM%7C8b94cc89d74646896d8108da512988a7%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637911536139011183%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=xERlwjiqImZJxLGf3O9YnMHmi4jMLEihCmRC3q12p0Y%3Dreserved=0
Some REXX code for use on z/OS -
https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprino.neocities.org%2FzOS%2FzOS-Tools.htmldata=05%7C01%7Callan.staller%40HCL.COM%7C8b94cc89d74646896d8108da512988a7%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637911536139011183%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=MQIeqKuwQYogpQrTxgrmGpEhHoIjK%2Fvoe8%2FWbgrn%2FyE%3Dreserved=0

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

The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.


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

Re: Old PL/I Optimizing compiler - COUNT & FLOW options

[Seymour J Metz]

If I wasn't concerned about an audit trail I'd probably use PDS or StarTool 
(whatever the current name), but that's more a matter of taste than anything 
else. TMTOWTDI.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Robert Prins [robert.ah.pr...@gmail.com]
Sent: Sunday, June 19, 2022 6:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Old PL/I Optimizing compiler - COUNT & FLOW options

On Sun, 19 Jun 2022 at 18:42, Seymour J Metz  wrote:

> Well, I would normally advise using a zapmaker, but for something that
> trivial I would just code my own AMASPZAP input.
>

XMIT/RECEIVE also lets you edit load modules, and that's what I used to
change the BLKSIZE of IND$FILE from 6233 to 27998. ;)

Robert
--
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather 
<https://secure-web.cisco.com/1DhbQnpex-RhY_QfElZTvQECRU4_uNKRrJhALFcmErcYA4O4-DjiECLBGx-RwaQxsfwWI6Q_Z8aBUHIcCfsGI5adFZMXNd7Pnx8rnq2hBRD-6oU55KYUxmuZbqfVnNfvxDm2ZUE9ZWy0pz_KNY3RQQLFTyMdyikmRST_YeiyJJ3ZjKg_fqogUOdfCAU7Th3jAH52_549MJL3NsyUZn0AcqjKRegAlGATPMPuJmn9lubNX_0vfZ4aODO7lk1FitVO6RkdtKWX9sNCVumjAyxJ5tk3DkXnOiOiC67khuWkEW6KoTgOAMiV9-7tztqvCpwHHFJhF-2k-GBMaaZd-2H47iUcpgZovlt690f00hKfeDFDtfEZ7Txk98_UICqKVu8dGKU-uAey6nB--nilrr2V4tCfn3aGUII2CSSNN_YvIwvc9Z9rifzK1zs9P9t-EDIci/https%3A%2F%2Fprino.neocities.org%2Findex.html>
Some REXX code for use on z/OS
<https://secure-web.cisco.com/1vawa8TNzZjSuPGshVC5kKLURuJ2Jut8oSvNDJBKQ4BApryr3t5AULbweQSvYsK4H-LhUDzZMZWx7HYpZsbVEH9oaM6h-KymicJHZbv_qGO9FGMDfnMCRxDDVveMjL9F1REw0X_OxFWG8BoquH3sHrjC6yRAUqtM7MMjJW9fs5ysGiIuhc9v9taede5C4URCfxIRDOLO6hev1RgZw3mpv2cSiz0Ejrc7uVfqPUlXKw02uOIEFkCj2hd120LyS6tXbZMgRRqVvKmHjCWVOy5-TJM85mi4Xs6bWhE9kdhDJvHqsk6GZPSdn6N4csZYVu77c7tXUApzFbtKBfp5p-EHa5Uo8hsez52fWn0D8qrbfwbFwI3x4s0-lCufZl0DniZ2eLoaSvDsqF_dnxXz5CdVIYy0Gqae9-Z32e3G9k4z1DfqXIGzBKwrKJ-2-GR0xFxE7/https%3A%2F%2Fprino.neocities.org%2FzOS%2FzOS-Tools.html>

--
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: Old PL/I Optimizing compiler - COUNT & FLOW options

[Robert Prins]

On Sun, 19 Jun 2022 at 18:42, Seymour J Metz  wrote:

> Well, I would normally advise using a zapmaker, but for something that
> trivial I would just code my own AMASPZAP input.
>

XMIT/RECEIVE also lets you edit load modules, and that's what I used to
change the BLKSIZE of IND$FILE from 6233 to 27998. ;)

Robert
-- 
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather 
Some REXX code for use on z/OS


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

Re: Old PL/I Optimizing compiler - COUNT & FLOW options

[Seymour J Metz]

Well, I would normally advise using a zapmaker, but for something that trivial 
I would just code my own AMASPZAP input.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Robert Prins [robert.ah.pr...@gmail.com]
Sent: Sunday, June 19, 2022 5:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Old PL/I Optimizing compiler - COUNT & FLOW options

I'm using, don't ask, the V2.3.0 Optimizing Compiler on, don't ask, z/OS
1.10 ADCD running under, OK enough.

I've managed to find out that the library routine to print the COUNT table
is IBMFEFCA, by doing a SRCHFOR for "GRAND", and by copying it into my
ISPPLIB, I've actually got a disassembly via the DISASM function of ISRDDN.
Now I just need to know how many and which of the, I guess, three BNP
instructions need to be changed into a BNZ, and yes, even a complete
assembler noob like me can do that without the usual tools. If anyone
(privately) likes to help me, feel free to contact me in private.

Robert

On Sun, 19 Jun 2022 at 17:42, Seymour J Metz  wrote:

> Is it the same in Version 2? Which is the OP using?
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Tony Harminc [t...@harminc.net]
> Sent: Saturday, June 18, 2022 2:08 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Old PL/I Optimizing compiler - COUNT & FLOW options
>
> On Sat, 18 Jun 2022 at 08:53, Robert Prins 
> wrote:
>
> > Does anyone know which library modules are responsible for the
> > implementation of these two compiler options, and more precisely, for the
> > reporting of statement counts, as I need to (try to) patch the latter,
> > given that it treats negative counts as zero, and I now have a program
> > where four of the counts have turned negative, because the statements are
> > executed more than 2^31-1 times.
>
> According to
> http://secure-web.cisco.com/1qol48PvmvwyvU-Vi1f7aGKmksvxHw8bnqFB5_TLToKQnvbKn6dAiJSiQY-XIfTaR5iolC3qT6N24hVsQTjfUYpjQqIQJUj9D3jynWCjL47DklWz3F5zO7O5bfrQ0cMkjz-hGrYgt7xFczrNBlBQg7VmH3tuTH9YMuqS1nHCbnTRZ8w2G9QB3z4nG1Nsrusmooh61wJEzajvzH-msvOqRt8ha9ZJ1eFr8Fk-VMWJbkfyG8SknBDJ4prdn9FUTLtDgeBBC7kYmgnO2oa3-Zc_dFLHTjAhBbQXxlSvQ_eLbPIpMB8IthdMY6Hh0MZGO-N0nCbXu6xFZa8cqs6k9qaY6ZeaFiohW75pNe_BAi_QZiqcgCdnkNv2Xop9qWTwgWU4XiFv-4AVbQQ7eZkcWrGrpGG-0JlI4sUz3BegwUwqzneiIj5-y2B4Qw43kY3SdanXN/http%3A%2F%2Fbitsavers.org%2Fpdf%2Fibm%2F370%2Fpli%2FSC33-0025-3_PLI_Optimizing_Compiler_Execution_Logic_Sep85.pdf
> you want module IBMBEFL.
>
> In that book, look at page 141 onwards for the description of how
> things work, and for the Flow data area, page 369. I'm not seeing
> right away where the Count info is stored, but I'm sure you can figure
> it out from there...
>
> Tony H.
>
> --
> 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
>


--
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather 
<https://secure-web.cisco.com/1Z0vvXsv4unJoygvj6vnYFfVlrfA0GseNM0UsKBpoeVikVcSufQa_2lKTSNQ6SY0f-kRUBAEpFSc9RFa7Qv6fwOZOvroHSAGOXoL9vwLFjnDO7B7_61mN6A2Xrbk3cMtLzbJD4lbrwtNjSKLqEpbgM_Sg6q9KJQLN4hQr5eJbsM3ZDSPLAhxlAJRe5WGzfeuyCP3Vl4NqMdczsJZggZYLa1bcecl2gsh_PL6P5H6nZys8LVO90vkgS2VDxZdUh-66bUFCmrEqnYMh9PEfR5XUH37OKlGQUYxTirZc6SIiKNNqvbUPJb6iKl_oekdtb2dQxyHdlT0upZelJUXE_twCAm8vLa_kpcXTTQKyJcCQs5-D_ce-VjEEtboBpkGymDGFh4U19T8DX9hPLZAW14ulpVNARN3TR77rXrHIEbfWGPiWjOEgPtd7CCsNBehTFRDX/https%3A%2F%2Fprino.neocities.org%2Findex.html>
Some REXX code for use on z/OS
<https://secure-web.cisco.com/1dsTcGVRdLPCDOHVhwd6nd7L5OJjO0aupi6QvIA53c2n0H6VyEvAZolIgzx37cZ3kh6YDDUxNcEKMut2FUMTStSDlTlnt_-UwjjZHhwd8bP-6Qy6VzJshpJbfRTetmV1vSB_KvyuZ1A3Mwty6Oep1l55Q6XL7sLczPK6mw3rZwSqvDzukv4gB3ogeiGLDdHrtw0u9-EYu6yMRKUMxhvXVPM_LAhfmbJ1rj1l4uR_OvertxGY2wJomnRFj0rTk1pYfsk2bN-On-f2bC4WUaU01r6Nmhb3jOi0HTpxkFtTAeVaYSZeZ9rSo8ZsSfgByhYwtDBH0ytcDtuJ1iS5ftgwV2v-UApT-3FSuWuNEygClc_ObuRYEKySkJopI8iWs7XtuToHSU3Q4wm4Agq49uQ_gS84krIYaHNPuY7hSAiBHDswNKgI2iciQIejAQjNyC44K/https%3A%2F%2Fprino.neocities.org%2FzOS%2FzOS-Tools.html>

--
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: Old PL/I Optimizing compiler - COUNT & FLOW options

[Robert Prins]

I'm using, don't ask, the V2.3.0 Optimizing Compiler on, don't ask, z/OS
1.10 ADCD running under, OK enough.

I've managed to find out that the library routine to print the COUNT table
is IBMFEFCA, by doing a SRCHFOR for "GRAND", and by copying it into my
ISPPLIB, I've actually got a disassembly via the DISASM function of ISRDDN.
Now I just need to know how many and which of the, I guess, three BNP
instructions need to be changed into a BNZ, and yes, even a complete
assembler noob like me can do that without the usual tools. If anyone
(privately) likes to help me, feel free to contact me in private.

Robert

On Sun, 19 Jun 2022 at 17:42, Seymour J Metz  wrote:

> Is it the same in Version 2? Which is the OP using?
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf
> of Tony Harminc [t...@harminc.net]
> Sent: Saturday, June 18, 2022 2:08 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Old PL/I Optimizing compiler - COUNT & FLOW options
>
> On Sat, 18 Jun 2022 at 08:53, Robert Prins 
> wrote:
>
> > Does anyone know which library modules are responsible for the
> > implementation of these two compiler options, and more precisely, for the
> > reporting of statement counts, as I need to (try to) patch the latter,
> > given that it treats negative counts as zero, and I now have a program
> > where four of the counts have turned negative, because the statements are
> > executed more than 2^31-1 times.
>
> According to
> http://secure-web.cisco.com/1qol48PvmvwyvU-Vi1f7aGKmksvxHw8bnqFB5_TLToKQnvbKn6dAiJSiQY-XIfTaR5iolC3qT6N24hVsQTjfUYpjQqIQJUj9D3jynWCjL47DklWz3F5zO7O5bfrQ0cMkjz-hGrYgt7xFczrNBlBQg7VmH3tuTH9YMuqS1nHCbnTRZ8w2G9QB3z4nG1Nsrusmooh61wJEzajvzH-msvOqRt8ha9ZJ1eFr8Fk-VMWJbkfyG8SknBDJ4prdn9FUTLtDgeBBC7kYmgnO2oa3-Zc_dFLHTjAhBbQXxlSvQ_eLbPIpMB8IthdMY6Hh0MZGO-N0nCbXu6xFZa8cqs6k9qaY6ZeaFiohW75pNe_BAi_QZiqcgCdnkNv2Xop9qWTwgWU4XiFv-4AVbQQ7eZkcWrGrpGG-0JlI4sUz3BegwUwqzneiIj5-y2B4Qw43kY3SdanXN/http%3A%2F%2Fbitsavers.org%2Fpdf%2Fibm%2F370%2Fpli%2FSC33-0025-3_PLI_Optimizing_Compiler_Execution_Logic_Sep85.pdf
> you want module IBMBEFL.
>
> In that book, look at page 141 onwards for the description of how
> things work, and for the Flow data area, page 369. I'm not seeing
> right away where the Count info is stored, but I'm sure you can figure
> it out from there...
>
> Tony H.
>
> --
> 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
>


-- 
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather <https://prino.neocities.org/index.html>
Some REXX code for use on z/OS
<https://prino.neocities.org/zOS/zOS-Tools.html>

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

Re: Old PL/I Optimizing compiler - COUNT & FLOW options

[Seymour J Metz]

Is it the same in Version 2? Which is the OP using?


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Tony Harminc [t...@harminc.net]
Sent: Saturday, June 18, 2022 2:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Old PL/I Optimizing compiler - COUNT & FLOW options

On Sat, 18 Jun 2022 at 08:53, Robert Prins  wrote:

> Does anyone know which library modules are responsible for the
> implementation of these two compiler options, and more precisely, for the
> reporting of statement counts, as I need to (try to) patch the latter,
> given that it treats negative counts as zero, and I now have a program
> where four of the counts have turned negative, because the statements are
> executed more than 2^31-1 times.

According to 
http://secure-web.cisco.com/1qol48PvmvwyvU-Vi1f7aGKmksvxHw8bnqFB5_TLToKQnvbKn6dAiJSiQY-XIfTaR5iolC3qT6N24hVsQTjfUYpjQqIQJUj9D3jynWCjL47DklWz3F5zO7O5bfrQ0cMkjz-hGrYgt7xFczrNBlBQg7VmH3tuTH9YMuqS1nHCbnTRZ8w2G9QB3z4nG1Nsrusmooh61wJEzajvzH-msvOqRt8ha9ZJ1eFr8Fk-VMWJbkfyG8SknBDJ4prdn9FUTLtDgeBBC7kYmgnO2oa3-Zc_dFLHTjAhBbQXxlSvQ_eLbPIpMB8IthdMY6Hh0MZGO-N0nCbXu6xFZa8cqs6k9qaY6ZeaFiohW75pNe_BAi_QZiqcgCdnkNv2Xop9qWTwgWU4XiFv-4AVbQQ7eZkcWrGrpGG-0JlI4sUz3BegwUwqzneiIj5-y2B4Qw43kY3SdanXN/http%3A%2F%2Fbitsavers.org%2Fpdf%2Fibm%2F370%2Fpli%2FSC33-0025-3_PLI_Optimizing_Compiler_Execution_Logic_Sep85.pdf
you want module IBMBEFL.

In that book, look at page 141 onwards for the description of how
things work, and for the Flow data area, page 369. I'm not seeing
right away where the Count info is stored, but I'm sure you can figure
it out from there...

Tony H.

--
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: Old PL/I Optimizing compiler - COUNT & FLOW options

[Mike Schwab]

Might ask for help on the Hercules forums.  They have updated the IFOX
assembler with user mode z instructions, for example.

On Sat, Jun 18, 2022 at 4:47 PM Robert Prins  wrote:
>
> Thanks, that might help. I've found that for the 2.3.0compiler, the table
> is printed via "ibmfefca", got the "brilliant" idie of looking for "grand
> total" in the library routines. Haven't yet figured out how to disassemble
> it, and even if I could, I'm not sure what I would be looking for, i.e. the
> instruction that skips the printing of zero, or, as negative counts come
> out as zero, zeror-or-negative counts, if anyone here could help with that,
> I'd be grateful.
>
> Robert
>
> On Sat, 18 Jun 2022 at 18:08, Tony Harminc  wrote:
>
> > On Sat, 18 Jun 2022 at 08:53, Robert Prins 
> > wrote:
> >
> > > Does anyone know which library modules are responsible for the
> > > implementation of these two compiler options, and more precisely, for the
> > > reporting of statement counts, as I need to (try to) patch the latter,
> > > given that it treats negative counts as zero, and I now have a program
> > > where four of the counts have turned negative, because the statements are
> > > executed more than 2^31-1 times.
> >
> > According to
> > http://bitsavers.org/pdf/ibm/370/pli/SC33-0025-3_PLI_Optimizing_Compiler_Execution_Logic_Sep85.pdf
> > you want module IBMBEFL.
> >
> > In that book, look at page 141 onwards for the description of how
> > things work, and for the Flow data area, page 369. I'm not seeing
> > right away where the Count info is stored, but I'm sure you can figure
> > it out from there...
> >
> > Tony H.
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
>
> --
> Robert AH Prins
> robert(a)prino(d)org
> The hitchhiking grandfather 
> Some REXX code for use on z/OS
> 
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: Old PL/I Optimizing compiler - COUNT & FLOW options

[Robert Prins]

I could simply add a few "fixed dec (15)" counters into the code, and turn
the do-while loop into the discrete one from the manuals. The whole
exercise is of course a bit silly, as I knew that was coming for years, and
meeting someone from the Dominican Republic finally made it happen.

And I'm sure that leaves all of you very puzzled. ;)

I'll explain it later.

Robert

On Sat, 18 Jun 2022 at 19:18, Bob Bridges  wrote:

> I wouldn't for the world want to discourage anyone who wants to try
> patching compiled code, just for the fun of it.  If you want to, go for
> it.  But wouldn't it be simpler just to do the calculation?
>
> Or are you wondering HOW MANY TIMES the counter cycled?
>
> ---
> Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313
>
> /* The best principles may be espoused by crass hypocrites (and they
> usually are).  But if we consider a principle refuted every time its
> advocates fail to live up to it, we'll soon be left with no principles at
> all.  -Joseph Sobran */
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Robert Prins
> Sent: Saturday, June 18, 2022 11:52
>
> Does anyone know which library modules are responsible for the
> implementation of these two compiler options, and more precisely, for the
> reporting of statement counts, as I need to (try to) patch the latter,
> given that it treats negative counts as zero, and I now have a program
> where four of the counts have turned negative, because the statements are
> executed more than 2^31-1 times.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather 
Some REXX code for use on z/OS


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

Re: Old PL/I Optimizing compiler - COUNT & FLOW options

[Robert Prins]

Thanks, that might help. I've found that for the 2.3.0compiler, the table
is printed via "ibmfefca", got the "brilliant" idie of looking for "grand
total" in the library routines. Haven't yet figured out how to disassemble
it, and even if I could, I'm not sure what I would be looking for, i.e. the
instruction that skips the printing of zero, or, as negative counts come
out as zero, zeror-or-negative counts, if anyone here could help with that,
I'd be grateful.

Robert

On Sat, 18 Jun 2022 at 18:08, Tony Harminc  wrote:

> On Sat, 18 Jun 2022 at 08:53, Robert Prins 
> wrote:
>
> > Does anyone know which library modules are responsible for the
> > implementation of these two compiler options, and more precisely, for the
> > reporting of statement counts, as I need to (try to) patch the latter,
> > given that it treats negative counts as zero, and I now have a program
> > where four of the counts have turned negative, because the statements are
> > executed more than 2^31-1 times.
>
> According to
> http://bitsavers.org/pdf/ibm/370/pli/SC33-0025-3_PLI_Optimizing_Compiler_Execution_Logic_Sep85.pdf
> you want module IBMBEFL.
>
> In that book, look at page 141 onwards for the description of how
> things work, and for the Flow data area, page 369. I'm not seeing
> right away where the Count info is stored, but I'm sure you can figure
> it out from there...
>
> Tony H.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather 
Some REXX code for use on z/OS


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

Re: Old PL/I Optimizing compiler - COUNT & FLOW options

[Bob Bridges]

I wouldn't for the world want to discourage anyone who wants to try patching 
compiled code, just for the fun of it.  If you want to, go for it.  But 
wouldn't it be simpler just to do the calculation?

Or are you wondering HOW MANY TIMES the counter cycled?

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

/* The best principles may be espoused by crass hypocrites (and they usually 
are).  But if we consider a principle refuted every time its advocates fail to 
live up to it, we'll soon be left with no principles at all.  -Joseph Sobran */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Robert Prins
Sent: Saturday, June 18, 2022 11:52

Does anyone know which library modules are responsible for the implementation 
of these two compiler options, and more precisely, for the reporting of 
statement counts, as I need to (try to) patch the latter, given that it treats 
negative counts as zero, and I now have a program where four of the counts have 
turned negative, because the statements are executed more than 2^31-1 times.

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

Re: Old PL/I Optimizing compiler - COUNT & FLOW options

[Tony Harminc]

On Sat, 18 Jun 2022 at 08:53, Robert Prins  wrote:

> Does anyone know which library modules are responsible for the
> implementation of these two compiler options, and more precisely, for the
> reporting of statement counts, as I need to (try to) patch the latter,
> given that it treats negative counts as zero, and I now have a program
> where four of the counts have turned negative, because the statements are
> executed more than 2^31-1 times.

According to 
http://bitsavers.org/pdf/ibm/370/pli/SC33-0025-3_PLI_Optimizing_Compiler_Execution_Logic_Sep85.pdf
you want module IBMBEFL.

In that book, look at page 141 onwards for the description of how
things work, and for the Flow data area, page 369. I'm not seeing
right away where the Count info is stored, but I'm sure you can figure
it out from there...

Tony H.

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

Old PL/I Optimizing compiler - COUNT & FLOW options

[Robert Prins]

 Hi all,

Does anyone know which library modules are responsible for the
implementation of these two compiler options, and more precisely, for the
reporting of statement counts, as I need to (try to) patch the latter,
given that it treats negative counts as zero, and I now have a program
where four of the counts have turned negative, because the statements are
executed more than 2^31-1 times.

Robert
-- 
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather - https://prino.neocities.org/
Some REXX code for use on z/OS -
https://prino.neocities.org/zOS/zOS-Tools.html

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

Re: PL/I

[Seymour J Metz]

That's how I view it. But then I'm paranoid about such matters. There are 
others who don't agree.

Cheap, fast or correct: pick one.


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


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of 
Tony Harminc [t...@harminc.net]
Sent: Wednesday, March 30, 2022 3:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I

On Wed, 30 Mar 2022 at 12:26, Seymour J Metz  wrote:
>
> Yes, range checking carries a performance penalty, and there have been 
> arguments in the past about performance versus safety. I'm in the camp that 
> believes that they should be enabled in any program where incorrect output 
> would cause a problem or where there are security issues.

So basically you don't need checking if it doesn't matter what your
program does...

Tony H.

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

[Tony Harminc]

On Wed, 30 Mar 2022 at 12:26, Seymour J Metz  wrote:
>
> Yes, range checking carries a performance penalty, and there have been 
> arguments in the past about performance versus safety. I'm in the camp that 
> believes that they should be enabled in any program where incorrect output 
> would cause a problem or where there are security issues.

So basically you don't need checking if it doesn't matter what your
program does...

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

[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

[Seymour J Metz]

I see that you don't know what "e.g." means. STRINGSIZE is the appropriate 
condition for assignment. It is not the appropriate condition for SUBSTR; 
STRINGRANGE. For that matter, neither is the correct condition for an array of 
strings, SUBSCRIPTRANGE is. Any of the three would have been appropriate after 
the "e.g.".

I would recommend enabling all three, but then I'm paranoid. YMMV.


--
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 11:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I

On 2022-03-31 01:42, Seymour J Metz wrote:
> 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.

No, the appropriate condition is STRINGSIZE.
And that is disabled by default.
STRINGRANGE is disabled by default also.

It is always recommended to enable the STRINGSIZE condition.

> 
> From: IBM Mainframe Discussion List  on
> behalf of Paul Gilmartin
> Sent: Wednesday, March 30, 2022 10:31 AM
> 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?

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

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

[Robert Prins]

On Wed, 30 Mar 2022 at 16:26, Seymour J Metz  wrote:

> Yes, range checking carries a performance penalty, and there have been
> arguments in the past about performance versus safety. I'm in the camp that
> believes that they should be enabled in any program where incorrect output
> would cause a problem or where there are security issues.


While working at a client in the late 1990'ies development compiles used
all checking prefixes, production compiles used SUBSCRIPTRANGE, and that
was occasionally triggered in CICS, users always manage to outsmart the
most fool-proof code. Of course in PL/I you should never ever used
hardcoded array bounds in DO-loops, but rather the "LBOUND()", "HBOUND()"
and "DIM()" builtins!

Robert
-- 
Robert AH Prins
robert(a)prino(d)org
The hitchhiking grandfather <https://prino.neocities.org/index.html>
Some REXX code for use on z/OS
<https://prino.neocities.org/zOS/zOS-Tools.html>

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

Re: PL/I

[Robin Vowels]

On 2022-03-31 03:25, Seymour J Metz wrote:

Yes, range checking carries a performance penalty, and there have been
arguments in the past about performance versus safety. I'm in the camp
that believes that they should be enabled in any program where
incorrect output would cause a problem or where there are security
issues.


An overrun is dangerous, since it can result in other data being 
destroyed

without warning, and if those corrupted data are then used or printed,
the results will be wrong -- again without warning.

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

Re: PL/I

[Robin Vowels]

On 2022-03-31 03:06, Jay Maynard wrote:
ISTR that STRINGRANGE and STRINGSIZE carried a performance penalty, 
though
it's been a very long time since I did PL/I. I would expect that the 
hit is

small but measurable, and generally worth it.


The overhead for STRINGSIZE is usually small, small enough to be 
trivial,

since it requires a comparison between the declared length and the
length of the string to be assigned.  Typically that requires
one each of L, C, and BC instructions.

The overhead for SUBSTR requires more checking, since there are now
two integer arguments that need to be tested.

On Wed, Mar 30, 2022 at 10:54 AM Robin Vowels  
wrote:



On 2022-03-31 01:42, Seymour J Metz wrote:
> 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.

No, the appropriate condition is STRINGSIZE.
And that is disabled by default.
STRINGRANGE is disabled by default also.

It is always recommended to enable the STRINGSIZE condition.


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

[Seymour J Metz]

Yes, range checking carries a performance penalty, and there have been 
arguments in the past about performance versus safety. I'm in the camp that 
believes that they should be enabled in any program where incorrect output 
would cause a problem or where there are security issues.


--
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: Wednesday, March 30, 2022 12:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I

ISTR that STRINGRANGE and STRINGSIZE carried a performance penalty, though
it's been a very long time since I did PL/I. I would expect that the hit is
small but measurable, and generally worth it.

On Wed, Mar 30, 2022 at 10:54 AM Robin Vowels  wrote:

> On 2022-03-31 01:42, Seymour J Metz wrote:
> > 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.
>
> No, the appropriate condition is STRINGSIZE.
> And that is disabled by default.
> STRINGRANGE is disabled by default also.
>
> It is always recommended to enable the STRINGSIZE condition.
>
> > 
> > From: IBM Mainframe Discussion List  on
> > behalf of Paul Gilmartin
> > Sent: Wednesday, March 30, 2022 10:31 AM
> > 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?
>
> --
> 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

[PINION, RICHARD W.]

I know the COBOL team/manuals published numbers for things like this, with the 
option turned on and with the option turned off.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Jay 
Maynard
Sent: Wednesday, March 30, 2022 12:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I

[External Email. Exercise caution when clicking links or opening attachments.]

ISTR that STRINGRANGE and STRINGSIZE carried a performance penalty, though it's 
been a very long time since I did PL/I. I would expect that the hit is small 
but measurable, and generally worth it.

On Wed, Mar 30, 2022 at 10:54 AM Robin Vowels  wrote:

> On 2022-03-31 01:42, Seymour J Metz wrote:
> > 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.
>
> No, the appropriate condition is STRINGSIZE.
> And that is disabled by default.
> STRINGRANGE is disabled by default also.
>
> It is always recommended to enable the STRINGSIZE condition.
>
> > 
> > From: IBM Mainframe Discussion List  on 
> > behalf of Paul Gilmartin
> > Sent: Wednesday, March 30, 2022 10:31 AM
> > 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?
>
> --
> 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
Confidentiality notice: 
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.


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

Re: PL/I

[Jay Maynard]

ISTR that STRINGRANGE and STRINGSIZE carried a performance penalty, though
it's been a very long time since I did PL/I. I would expect that the hit is
small but measurable, and generally worth it.

On Wed, Mar 30, 2022 at 10:54 AM Robin Vowels  wrote:

> On 2022-03-31 01:42, Seymour J Metz wrote:
> > 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.
>
> No, the appropriate condition is STRINGSIZE.
> And that is disabled by default.
> STRINGRANGE is disabled by default also.
>
> It is always recommended to enable the STRINGSIZE condition.
>
> > 
> > From: IBM Mainframe Discussion List  on
> > behalf of Paul Gilmartin
> > Sent: Wednesday, March 30, 2022 10:31 AM
> > 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?
>
> --
> 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

[Robin Vowels]

On 2022-03-31 01:42, Seymour J Metz wrote:

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.


No, the appropriate condition is STRINGSIZE.
And that is disabled by default.
STRINGRANGE is disabled by default also.

It is always recommended to enable the STRINGSIZE condition.



From: IBM Mainframe Discussion List  on
behalf of Paul Gilmartin
Sent: Wednesday, March 30, 2022 10:31 AM
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?


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