In whole-array operations, IBM's Windows compiler does not check
that arrays are compatible.
Even if SUBSCRIPTRANGE is enabled, there is no check.
Have there been any PL/I compilers that performed such a check?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/5/21 12:03 AM, Robin Vowels wrote:

In whole-array operations, IBM's Windows compiler does not check
that arrays are compatible.
Even if SUBSCRIPTRANGE is enabled, there is no check.
Have there been any PL/I compilers that performed such a check?

Even the Checkout Compiler does not specifically list an ONCODE for it.
All IBM compilers going back to F specifically say that it is not
allowed, but I can find no documentation that it’s specifically checked.
They may have supposed that it’s too improbable, given that any sensible
user will check either file input or parameter values early on, so as to
give a meaningful diagnostic.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/5/21 12:51 PM, John W Kennedy wrote:

On 6/5/21 12:03 AM, Robin Vowels wrote:

In whole-array operations, IBM's Windows compiler does not check
that arrays are compatible.
Even if SUBSCRIPTRANGE  is enabled, there is no check.
Have there been any PL/I compilers that performed such a check?

Even the Checkout Compiler does not specifically list an ONCODE for it.
All IBM compilers going back to F specifically say that it is not
allowed, but I can find no documentation that it’s specifically checked. They may have supposed that it’s too improbable, given that any sensible user will check either file input or parameter values early on, so as to
give a meaningful diagnostic.

I learned not to count on sensible users sometime during my first
programming job!

I suppose someone could fire up "F" on Hercules to see what happens, but
in my experience IBM cut quite a few corners with the Enterprise
compilers. Some of them they fixed as they went along, but maybe not all.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/5/21 5:10 PM, Iron Spring Software wrote:

On 6/5/21 12:51 PM, John W Kennedy wrote:

On 6/5/21 12:03 AM, Robin Vowels wrote:

In whole-array operations, IBM's Windows compiler does not check
that arrays are compatible.
Even if SUBSCRIPTRANGE  is enabled, there is no check.
Have there been any PL/I compilers that performed such a check?

Even the Checkout Compiler does not specifically list an ONCODE for
it. All IBM compilers going back to F specifically say that it is not
allowed, but I can find no documentation that it’s specifically
checked. They may have supposed that it’s too improbable, given that
any sensible user will check either file input or parameter values
early on, so as to give a meaningful diagnostic.

I learned not to count on sensible users sometime during my first
programming job!

I suppose someone could fire up "F" on Hercules to see what happens, but
in my experience IBM cut quite a few corners with the Enterprise
compilers. Some of them they fixed as they went along, but maybe not all.

Well, all I know for sure is that no IBM compiler seems to have an
ONCODE for the situation. I can’t find a run-time error message, either,
but I have not tried to search the Checkout Compiler messages because I
have only an image of the manual, and it’s just to long to search by eye.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, June 6, 2021 at 5:51:11 AM UTC+10, John W. Kennedy wrote:

On 6/5/21 12:03 AM, Robin Vowels wrote:

In whole-array operations, IBM's Windows compiler does not check
that arrays are compatible.
Even if SUBSCRIPTRANGE is enabled, there is no check.
Have there been any PL/I compilers that performed such a check?

.

Even the Checkout Compiler does not specifically list an ONCODE for it.

.
Any condition that is raised should be the SUBSCRIPTRANGE condition,
of course.
.

All IBM compilers going back to F specifically say that it is not
allowed,

.
The bounds of arrays must be identical.
.

but I can find no documentation that it’s specifically checked.
They may have supposed that it’s too improbable,

.
Given that the equivalent operation is spelled out in terms of
loops, one would expect that SUBSCRIPTRANGE be raised
when the equivalent code experiences a subscript out of range
for an array whose bounds do not conform.
.
At the very least, any bounds check ought to be carried out
once prior to executing code for the operation.
.

given that any sensible
user will check either file input or parameter values early on, so as to give a meaningful diagnostic.

.
A user would only know to include such a check if it were stated in the manual that a check would not be carried out by the compiler. (or, if he/she discovered it by accident).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/6/21 1:09 AM, Robin Vowels wrote:

On Sunday, June 6, 2021 at 5:51:11 AM UTC+10, John W. Kennedy wrote:

On 6/5/21 12:03 AM, Robin Vowels wrote:

In whole-array operations, IBM's Windows compiler does not check
that arrays are compatible.
Even if SUBSCRIPTRANGE is enabled, there is no check.
Have there been any PL/I compilers that performed such a check?

.

Even the Checkout Compiler does not specifically list an ONCODE for it.

.
Any condition that is raised should be the SUBSCRIPTRANGE condition,
of course.
.

All IBM compilers going back to F specifically say that it is not
allowed,

.
The bounds of arrays must be identical.
.

but I can find no documentation that it’s specifically checked.
They may have supposed that it’s too improbable,

.
Given that the equivalent operation is spelled out in terms of
loops, one would expect that SUBSCRIPTRANGE be raised
when the equivalent code experiences a subscript out of range
for an array whose bounds do not conform.

The specification of SUBSCRIPTRANGE speaks of the evaluation of the
subscript. But in an array operation, there is no subscript variable
visible to the user. And the object code penalty would be obscene to
evaluate each individual case when it can be checked by LBOUND = LBOUND
and HBOUND = HBOUND. As far as I can tell, IBM PL/I has worked the way
it does now for over 50 years, so I don’t think you’ll see a change, but
if you want to submit it to IBM, you’re welcome to try. And I suggest
you suggest, at least as a alternative, a new ON-condition, perhaps to
be named ARRAYRANGE or at least a new ONCODE value. (I’m in no position
to do it; I have 30 years of experience with PL/I on DOS/360 and OS/360
and their descendants (and a little on OS/2), but I live in the Apple
world nowadays, and am far more interested in Swift and Cocoa.

At the very least, any bounds check ought to be carried out
once prior to executing code for the operation.
.

given that any sensible
user will check either file input or parameter values early on, so as to
give a meaningful diagnostic.

.
A user would only know to include such a check if it were stated in the manual
that a check would not be carried out by the compiler. (or, if he/she discovered it by accident).

Still smarter to do reasonableness checks first, so that the data error
is expressed to the user in a user-readable form that explains that
there is an input error, instead of a mysterious IBM error message that
can only be interpreted by the original programmer.


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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, June 7, 2021 at 10:19:22 AM UTC+10, John W. Kennedy wrote:

On 6/6/21 1:09 AM, Robin Vowels wrote:

On Sunday, June 6, 2021 at 5:51:11 AM UTC+10, John W. Kennedy wrote:

On 6/5/21 12:03 AM, Robin Vowels wrote:

In whole-array operations, IBM's Windows compiler does not check
that arrays are compatible.
Even if SUBSCRIPTRANGE is enabled, there is no check.
Have there been any PL/I compilers that performed such a check?

.

Even the Checkout Compiler does not specifically list an ONCODE for it.

.
Any condition that is raised should be the SUBSCRIPTRANGE condition,
of course.
.

All IBM compilers going back to F specifically say that it is not
allowed,

.
The bounds of arrays must be identical.
.

but I can find no documentation that it’s specifically checked.
They may have supposed that it’s too improbable,

.
Given that the equivalent operation is spelled out in terms of
loops, one would expect that SUBSCRIPTRANGE be raised
when the equivalent code experiences a subscript out of range
for an array whose bounds do not conform.

.

The specification of SUBSCRIPTRANGE speaks of the evaluation of the subscript. But in an array operation, there is no subscript variable
visible to the user.

.
But it is specified to the user in the detailed explanation of
such an array operation. So would still be appropriate to raise
the SUBSCRIPTRANGE condition.

And the object code penalty would be obscene to
evaluate each individual case

.
No need to evaluate each individual case.
In any case, even if this were done, it would not be any worse
compared with the equivalent piece of code written with
explicit DO loops.
.

when it can be checked by LBOUND = LBOUND
and HBOUND = HBOUND.

.
Of course it can, and that is the obvious way to do it (as I already
suggested below).
.

As far as I can tell, IBM PL/I has worked the way
it does now for over 50 years, so I don’t think you’ll see a change, but if you want to submit it to IBM, you’re welcome to try. And I suggest
you suggest, at least as a alternative, a new ON-condition, perhaps to
be named ARRAYRANGE or at least a new ONCODE value.

.
No need to introduce yet more conditions / keywords.
.

(I’m in no position
to do it; I have 30 years of experience with PL/I on DOS/360 and OS/360
and their descendants (and a little on OS/2), but I live in the Apple
world nowadays, and am far more interested in Swift and Cocoa.

.

At the very least, any bounds check ought to be carried out
once prior to executing code for the operation.
.

given that any sensible
user will check either file input or parameter values early on, so as to >> give a meaningful diagnostic.

.
A user would only know to include such a check if it were stated in the manual
that a check would not be carried out by the compiler. (or, if he/she discovered it by accident).

.

Still smarter to do reasonableness checks first,

.
but only if the programmer sees such limitation spelled out in the manual -- which it wasn't (or discovered it by accident).
.
In the case of procedures to which arguments might be passed,
it's very sensible to do that.
.

so that the data error
is expressed to the user in a user-readable form that explains that
there is an input error,

.
Indeed.
.

instead of a mysterious IBM error message that
can only be interpreted by the original programmer.

.
It can be interpreted by any programmer.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Robin Vowels wrote:

In whole-array operations, IBM's Windows compiler does not check
that arrays are compatible.
Even if SUBSCRIPTRANGE is enabled, there is no check.
Have there been any PL/I compilers that performed such a check?

Hi Robin,

If you post an example we can try it with the current IBM compiler.

- Dave R. -

--
rivers@dignus.com Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, June 8, 2021 at 4:39:58 AM UTC+10, Thomas David Rivers wrote:

Robin Vowels wrote:

In whole-array operations, IBM's Windows compiler does not check
that arrays are compatible.
Even if SUBSCRIPTRANGE is enabled, there is no check.
Have there been any PL/I compilers that performed such a check?

Hi Robin,

If you post an example we can try it with the current IBM compiler.

.
Thanks, David. Here's a example.
.
(SUBSCRIPTRANGE):
T: PROCEDURE OPTIONS (MAIN);
DECLARE A(4,5) FLOAT, B(5,6) FLOAT, C(6,7) FLOAT;
B = 1; C = 2;
CALL ARITH (A, B, C);
ARITH:PROCEDURE (A, B, C);
DECLARE A(*,*) FLOAT, B(*,*) FLOAT, C(*,*) FLOAT;
B = 1; C = 2;
PUT SKIP LIST ('About to perform addition'); PUT SKIP;
A = B + C;
PUT SKIP LIST (A);
END ARITH;
END T;

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Robin Vowels <robin.vowels@gmail.com> wrote:

On Tuesday, June 8, 2021 at 4:39:58 AM UTC+10, Thomas David Rivers wrote:

Robin Vowels wrote:

In whole-array operations, IBM's Windows compiler does not check
that arrays are compatible.
Even if SUBSCRIPTRANGE is enabled, there is no check.
Have there been any PL/I compilers that performed such a check?

Hi Robin,

If you post an example we can try it with the current IBM compiler.

.
Thanks, David. Here's a example.
.
(SUBSCRIPTRANGE):
T: PROCEDURE OPTIONS (MAIN);
DECLARE A(4,5) FLOAT, B(5,6) FLOAT, C(6,7) FLOAT;
B = 1; C = 2;
CALL ARITH (A, B, C);
ARITH:PROCEDURE (A, B, C);
DECLARE A(*,*) FLOAT, B(*,*) FLOAT, C(*,*) FLOAT;
B = 1; C = 2;
PUT SKIP LIST ('About to perform addition'); PUT SKIP;
A = B + C;
PUT SKIP LIST (A);
END ARITH;
END T;

What happens if you do A=B+C; in the main procedure, without a call to
ARITH?

--
Pete

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, June 11, 2021 at 11:28:57 AM UTC+10, bearlyabus...@gmail.com wrote:

Robin Vowels <robin....@gmail.com> wrote:

On Tuesday, June 8, 2021 at 4:39:58 AM UTC+10, Thomas David Rivers wrote:

Robin Vowels wrote:

In whole-array operations, IBM's Windows compiler does not check
that arrays are compatible.
Even if SUBSCRIPTRANGE is enabled, there is no check.
Have there been any PL/I compilers that performed such a check?

Hi Robin,

If you post an example we can try it with the current IBM compiler.

.
Thanks, David. Here's a example.
.
(SUBSCRIPTRANGE):
T: PROCEDURE OPTIONS (MAIN);
DECLARE A(4,5) FLOAT, B(5,6) FLOAT, C(6,7) FLOAT;
B = 1; C = 2;
CALL ARITH (A, B, C);
ARITH:PROCEDURE (A, B, C);
DECLARE A(*,*) FLOAT, B(*,*) FLOAT, C(*,*) FLOAT;
B = 1; C = 2;
PUT SKIP LIST ('About to perform addition'); PUT SKIP;
A = B + C;
PUT SKIP LIST (A);
END ARITH;
END T;

What happens if you do A=B+C; in the main procedure, without a call to
ARITH?

.
I tried that as well. As expected, a compilation error message.
.
S: PROCEDURE OPTIONS (MAIN);
DECLARE A(4,5) FLOAT, B(5,5) FLOAT, C(5,6) FLOAT;
B = 1; C= 2;
A = B + C;
PUT LIST (A);

END S;

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Robin Vowels wrote:

On Tuesday, June 8, 2021 at 4:39:58 AM UTC+10, Thomas David Rivers wrote:

Robin Vowels wrote:

In whole-array operations, IBM's Windows compiler does not check
that arrays are compatible.
Even if SUBSCRIPTRANGE is enabled, there is no check.
Have there been any PL/I compilers that performed such a check?

Hi Robin,

If you post an example we can try it with the current IBM compiler.

.
Thanks, David. Here's a example.
.
(SUBSCRIPTRANGE):
T: PROCEDURE OPTIONS (MAIN);
DECLARE A(4,5) FLOAT, B(5,6) FLOAT, C(6,7) FLOAT;
B = 1; C = 2;
CALL ARITH (A, B, C);
ARITH:PROCEDURE (A, B, C);
DECLARE A(*,*) FLOAT, B(*,*) FLOAT, C(*,*) FLOAT;
B = 1; C = 2;
PUT SKIP LIST ('About to perform addition'); PUT SKIP;
A = B + C;
PUT SKIP LIST (A);
END ARITH;
END T;

I compiled this on z/OS 2.4 with this version of IBM PL/I:


15655-PL5 IBM(R) Enterprise PL/I for z/OS V5.R3.M0 (Built:20190726)

and I got no errors, no warnings.

When I run it though, I get this:


About to perform addition
IBM0421S ONCODE=520 The SUBSCRIPTRANGE condition was raised.
From entry point ARITH at compile unit offset +000003FE at
entry offset +000003FE at address 1F90B62E.
[1] + Done(137) ./incompat_array
50397979 Killed ./incompat_array

(under USS, which is why it's "Killed").

- Dave R. -


--
rivers@dignus.com Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 08.06.2021 um 17:31 schrieb Thomas David Rivers:

Robin Vowels wrote:

On Tuesday, June 8, 2021 at 4:39:58 AM UTC+10, Thomas David Rivers wrote:

Robin Vowels wrote:

In whole-array operations, IBM's Windows compiler does not check
that arrays are compatible. Even if SUBSCRIPTRANGE is enabled, there
is no check. Have there been any PL/I compilers that performed such
a check?

Hi Robin,
If you post an example we can try it with the current IBM compiler.

.
Thanks, David.  Here's a example.
.
(SUBSCRIPTRANGE):
T: PROCEDURE OPTIONS (MAIN);
     DECLARE A(4,5) FLOAT, B(5,6) FLOAT, C(6,7) FLOAT;
     B = 1; C = 2;
     CALL ARITH (A, B, C);
ARITH:PROCEDURE (A, B, C);
        DECLARE A(*,*) FLOAT, B(*,*) FLOAT, C(*,*) FLOAT;
        B = 1; C = 2;
        PUT SKIP LIST ('About to perform addition'); PUT SKIP;
        A = B + C;
        PUT SKIP LIST (A);
     END ARITH;
END T;

I compiled this on z/OS 2.4 with this version of IBM PL/I:

15655-PL5  IBM(R) Enterprise PL/I for z/OS       V5.R3.M0 (Built:20190726)

and I got no errors, no warnings.

When I run it though, I get this:

About to perform addition
IBM0421S  ONCODE=520  The SUBSCRIPTRANGE condition was raised.
        From entry point ARITH at compile unit offset +000003FE at entry offset +000003FE at address 1F90B62E.
[1] + Done(137) ./incompat_array
 50397979      Killed  ./incompat_array

(under USS, which is why it's "Killed").

   - Dave R. -

I can confirm Dave (same architecture, slightly minor compiler level):

IBM0421S ONCODE=520 The SUBSCRIPTRANGE condition was raised.
From compile unit T at entry point ARITH at statement 10 at
compile unit offset +000005BA at entry offset
+0000040A at address 20400DE2.
<> LEAID ENTERED (LEVEL 02/26/2016 AT 17.55)
<> LEAID PROCESSING COMPLETE. RC=0

Jessica

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thomas David Rivers <rivers@dignus.com> wrote:

Robin Vowels wrote:

On Tuesday, June 8, 2021 at 4:39:58 AM UTC+10, Thomas David Rivers wrote:

Robin Vowels wrote:

In whole-array operations, IBM's Windows compiler does not check
that arrays are compatible.
Even if SUBSCRIPTRANGE is enabled, there is no check.
Have there been any PL/I compilers that performed such a check?

Hi Robin,

If you post an example we can try it with the current IBM compiler.

.
Thanks, David. Here's a example.
.
(SUBSCRIPTRANGE):
T: PROCEDURE OPTIONS (MAIN);
DECLARE A(4,5) FLOAT, B(5,6) FLOAT, C(6,7) FLOAT;
B = 1; C = 2;
CALL ARITH (A, B, C);
ARITH:PROCEDURE (A, B, C);
DECLARE A(*,*) FLOAT, B(*,*) FLOAT, C(*,*) FLOAT;
B = 1; C = 2;
PUT SKIP LIST ('About to perform addition'); PUT SKIP;
A = B + C;
PUT SKIP LIST (A);
END ARITH;
END T;

I compiled this on z/OS 2.4 with this version of IBM PL/I:

15655-PL5 IBM(R) Enterprise PL/I for z/OS V5.R3.M0 (Built:20190726)

and I got no errors, no warnings.

When I run it though, I get this:

About to perform addition
IBM0421S ONCODE=520 The SUBSCRIPTRANGE condition was raised.
From entry point ARITH at compile unit offset +000003FE at
entry offset +000003FE at address 1F90B62E.
[1] + Done(137) ./incompat_array
50397979 Killed ./incompat_array

(under USS, which is why it's "Killed").

- Dave R. -

That’s what I would have expected. Without extensive code analysis, that probably no compiler does it, would have been impossible to detect the
error until runtime.

--
Pete

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, June 11, 2021 at 9:52:50 PM UTC+10, Thomas David Rivers wrote:

Robin Vowels wrote:

On Tuesday, June 8, 2021 at 4:39:58 AM UTC+10, Thomas David Rivers wrote:

Robin Vowels wrote:

In whole-array operations, IBM's Windows compiler does not check
that arrays are compatible.
Even if SUBSCRIPTRANGE is enabled, there is no check.
Have there been any PL/I compilers that performed such a check?

Hi Robin,

If you post an example we can try it with the current IBM compiler.

.
Thanks, David. Here's a example.
.
(SUBSCRIPTRANGE):
T: PROCEDURE OPTIONS (MAIN);
DECLARE A(4,5) FLOAT, B(5,6) FLOAT, C(6,7) FLOAT;
B = 1; C = 2;
CALL ARITH (A, B, C);
ARITH:PROCEDURE (A, B, C);
DECLARE A(*,*) FLOAT, B(*,*) FLOAT, C(*,*) FLOAT;
B = 1; C = 2;
PUT SKIP LIST ('About to perform addition'); PUT SKIP;
A = B + C;
PUT SKIP LIST (A);
END ARITH;
END T;

I compiled this on z/OS 2.4 with this version of IBM PL/I:

15655-PL5 IBM(R) Enterprise PL/I for z/OS V5.R3.M0 (Built:20190726)

and I got no errors, no warnings.

When I run it though, I get this:

About to perform addition
IBM0421S ONCODE=520 The SUBSCRIPTRANGE condition was raised.
From entry point ARITH at compile unit offset +000003FE at
entry offset +000003FE at address 1F90B62E.
[1] + Done(137) ./incompat_array
50397979 Killed ./incompat_array

(under USS, which is why it's "Killed").

.
Thanks, Dave. It's a considerable improvement over PL/I-F and PL/I for Windows. Would it be possible to post the assembly listing?
(If it would be too long, please email me.) Many thanks.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

El viernes, 11 de junio de 2021 a la(s) 19:21:21 UTC-3, Robin Vowels escribió:

On Friday, June 11, 2021 at 9:52:50 PM UTC+10, Thomas David Rivers wrote:

Robin Vowels wrote:

On Tuesday, June 8, 2021 at 4:39:58 AM UTC+10, Thomas David Rivers wrote:

Robin Vowels wrote:

In whole-array operations, IBM's Windows compiler does not check >>>that arrays are compatible.
Even if SUBSCRIPTRANGE is enabled, there is no check.
Have there been any PL/I compilers that performed such a check?

Hi Robin,

If you post an example we can try it with the current IBM compiler.

.
Thanks, David. Here's a example.
.
(SUBSCRIPTRANGE):
T: PROCEDURE OPTIONS (MAIN);
DECLARE A(4,5) FLOAT, B(5,6) FLOAT, C(6,7) FLOAT;
B = 1; C = 2;
CALL ARITH (A, B, C);
ARITH:PROCEDURE (A, B, C);
DECLARE A(*,*) FLOAT, B(*,*) FLOAT, C(*,*) FLOAT;
B = 1; C = 2;
PUT SKIP LIST ('About to perform addition'); PUT SKIP;
A = B + C;
PUT SKIP LIST (A);
END ARITH;
END T;

I compiled this on z/OS 2.4 with this version of IBM PL/I:

15655-PL5 IBM(R) Enterprise PL/I for z/OS V5.R3.M0 (Built:20190726)

and I got no errors, no warnings.

When I run it though, I get this:

About to perform addition
IBM0421S ONCODE=520 The SUBSCRIPTRANGE condition was raised.
From entry point ARITH at compile unit offset +000003FE at
entry offset +000003FE at address 1F90B62E.
[1] + Done(137) ./incompat_array
50397979 Killed ./incompat_array

(under USS, which is why it's "Killed").

.
Thanks, Dave. It's a considerable improvement over PL/I-F and PL/I for Windows.
Would it be possible to post the assembly listing?
(If it would be too long, please email me.) Many thanks.

Actually it has no meaning in math or phisicaly to multipy 2 arrays of incompatible size, so why bother?
The only thing I think of is multiplying one array of measurements, by some weight coeffcient, for digital filtering, even a 2 dimmension. But since the size is declared previously it's trivial to check them before using it

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

carlos feldman <carlfelster@gmail.com> wrote:

El viernes, 11 de junio de 2021 a la(s) 19:21:21 UTC-3, Robin Vowels escribió:

On Friday, June 11, 2021 at 9:52:50 PM UTC+10, Thomas David Rivers wrote: >>> Robin Vowels wrote:

On Tuesday, June 8, 2021 at 4:39:58 AM UTC+10, Thomas David Rivers wrote: >>>>

Robin Vowels wrote:

In whole-array operations, IBM's Windows compiler does not check
that arrays are compatible.
Even if SUBSCRIPTRANGE is enabled, there is no check.
Have there been any PL/I compilers that performed such a check?

Hi Robin,

If you post an example we can try it with the current IBM compiler.

.
Thanks, David. Here's a example.
.
(SUBSCRIPTRANGE):
T: PROCEDURE OPTIONS (MAIN);
DECLARE A(4,5) FLOAT, B(5,6) FLOAT, C(6,7) FLOAT;
B = 1; C = 2;
CALL ARITH (A, B, C);
ARITH:PROCEDURE (A, B, C);
DECLARE A(*,*) FLOAT, B(*,*) FLOAT, C(*,*) FLOAT;
B = 1; C = 2;
PUT SKIP LIST ('About to perform addition'); PUT SKIP;
A = B + C;
PUT SKIP LIST (A);
END ARITH;
END T;

I compiled this on z/OS 2.4 with this version of IBM PL/I:

15655-PL5 IBM(R) Enterprise PL/I for z/OS V5.R3.M0 (Built:20190726)

and I got no errors, no warnings.

When I run it though, I get this:


About to perform addition
IBM0421S ONCODE=520 The SUBSCRIPTRANGE condition was raised.
From entry point ARITH at compile unit offset +000003FE at
entry offset +000003FE at address 1F90B62E.
[1] + Done(137) ./incompat_array
50397979 Killed ./incompat_array

(under USS, which is why it's "Killed").

.
Thanks, Dave. It's a considerable improvement over PL/I-F and PL/I for Windows.
Would it be possible to post the assembly listing?
(If it would be too long, please email me.) Many thanks.

Actually it has no meaning in math or phisicaly to multipy 2 arrays of incompatible size, so why bother?
The only thing I think of is multiplying one array of measurements, by
some weight coeffcient, for digital filtering, even a 2 dimmension. But
since the size is declared previously it's trivial to check them before using it

I’ve seen all kinds of bad code that doesn’t check things. Heck, I’ve WRITTEN lots of bad code. It’s always better for the compiler to check whatever it can and not depend on the user. PL/i (among other languages, I guess) is nice because it allows the programmer to turn off these checks to improve efficiency when desired, assuming that they make sure to do the
checks themselves.

--
Pete

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, June 15, 2021 at 4:02:51 AM UTC+10, bearlyabus...@gmail.com wrote:

carlos feldman <carlf...@gmail.com> wrote:

Actually it has no meaning in math or phisicaly to multipy 2 arrays of incompatible size, so why bother?
The only thing I think of is multiplying one array of measurements, by some weight coeffcient, for digital filtering, even a 2 dimmension. But since the size is declared previously it's trivial to check them before using it

I’ve seen all kinds of bad code that doesn’t check things.

.
Remember Murphy's Law? "If anything can go wrong it will."
.
And then there's Roberts's Law: "Even if it can't go wrong it will."
.
Recall the Ariadne disaster? It failed because they did not include
a check for integer overflow.
.

Heck, I’ve
WRITTEN lots of bad code. It’s always better for the compiler to check whatever it can and not depend on the user. PL/i (among other languages, I guess) is nice because it allows the programmer to turn off these checks to improve efficiency when desired, assuming that they make sure to do the checks themselves.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, June 15, 2021 at 1:44:54 AM UTC+10, carlf...@gmail.com wrote:

El viernes, 11 de junio de 2021 a la(s) 19:21:21 UTC-3, Robin Vowels escribió:

On Friday, June 11, 2021 at 9:52:50 PM UTC+10, Thomas David Rivers wrote:

Robin Vowels wrote:

On Tuesday, June 8, 2021 at 4:39:58 AM UTC+10, Thomas David Rivers wrote:

Robin Vowels wrote:

In whole-array operations, IBM's Windows compiler does not check >>>that arrays are compatible.
Even if SUBSCRIPTRANGE is enabled, there is no check.
Have there been any PL/I compilers that performed such a check?

Hi Robin,

If you post an example we can try it with the current IBM compiler.

.
Thanks, David. Here's a example.
.
(SUBSCRIPTRANGE):
T: PROCEDURE OPTIONS (MAIN);
DECLARE A(4,5) FLOAT, B(5,6) FLOAT, C(6,7) FLOAT;
B = 1; C = 2;
CALL ARITH (A, B, C);
ARITH:PROCEDURE (A, B, C);
DECLARE A(*,*) FLOAT, B(*,*) FLOAT, C(*,*) FLOAT;
B = 1; C = 2;
PUT SKIP LIST ('About to perform addition'); PUT SKIP;
A = B + C;
PUT SKIP LIST (A);
END ARITH;
END T;

I compiled this on z/OS 2.4 with this version of IBM PL/I:

15655-PL5 IBM(R) Enterprise PL/I for z/OS V5.R3.M0 (Built:20190726)

and I got no errors, no warnings.

When I run it though, I get this:

About to perform addition
IBM0421S ONCODE=520 The SUBSCRIPTRANGE condition was raised.
From entry point ARITH at compile unit offset +000003FE at
entry offset +000003FE at address 1F90B62E.
[1] + Done(137) ./incompat_array
50397979 Killed ./incompat_array

(under USS, which is why it's "Killed").

.
Thanks, Dave. It's a considerable improvement over PL/I-F and PL/I for Windows.
Would it be possible to post the assembly listing?
(If it would be too long, please email me.) Many thanks.

.

Actually it has no meaning in math or phisicaly to multipy 2 arrays of incompatible size, so why bother?

.
It's still necessary to check that the bounds are compatible.
.
Without a check, wrong results are guaranteed, or none at all.
.

The only thing I think of is multiplying one array of measurements, by some weight coeffcient,
for digital filtering, even a 2 dimmension. But since the size is declared previously it's trivial
to check them before using it

.
Cross-sections of arrays are often required in solving equations, matrix inversion, etc.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

El martes, 15 de junio de 2021 a la(s) 00:42:54 UTC-3, Robin Vowels escribió:

On Tuesday, June 15, 2021 at 4:02:51 AM UTC+10, bearlyabus...@gmail.com wrote:

carlos feldman <carlf...@gmail.com> wrote:

Actually it has no meaning in math or phisicaly to multipy 2 arrays of incompatible size, so why bother?
The only thing I think of is multiplying one array of measurements, by some weight coeffcient, for digital filtering, even a 2 dimmension. But since the size is declared previously it's trivial to check them before using it

I’ve seen all kinds of bad code that doesn’t check things.

.
Remember Murphy's Law? "If anything can go wrong it will."
.
And then there's Roberts's Law: "Even if it can't go wrong it will."
.
Recall the Ariadne disaster? It failed because they did not include
a check for integer overflow.
.

Heck, I’ve
WRITTEN lots of bad code. It’s always better for the compiler to check whatever it can and not depend on the user. PL/i (among other languages, I guess) is nice because it allows the programmer to turn off these checks to
improve efficiency when desired, assuming that they make sure to do the checks themselves.

that's part of debugging the code, thing is most programmers, forget they are working in real environments, and don't do real testing, where things happens. Like calculating a PID in metric units ans a process expecting imperial units ?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, June 4, 2021 at 9:03:13 PM UTC-7, Robin Vowels wrote:

In whole-array operations, IBM's Windows compiler does not check
that arrays are compatible.
Even if SUBSCRIPTRANGE is enabled, there is no check.
Have there been any PL/I compilers that performed such a check?

Sorry I'm so late, I finally got around to checking.

Iron Spring PL/I checks. For non-adjustable arrays it causes an error at compile time:
"(ERR418)Mismatched array dimension or bounds in assignment statement."

For adjustable arrays it raises the ERROR condition at execution time. I guess the consensus is that it should be SUBSCRIPTRANGE if enabled. It probably should raise ERROR if SUBSCRIPTRANGE is not enabled?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

My bad, this was for assignments. I don't yet do array arithmetic, that's still upcoming, but the behavior will be the same as for assignments.

On Friday, July 2, 2021 at 9:22:56 AM UTC-7, peter..wrote:

On Friday, June 4, 2021 at 9:03:13 PM UTC-7, Robin Vowels wrote:

In whole-array operations, IBM's Windows compiler does not check
that arrays are compatible.
Even if SUBSCRIPTRANGE is enabled, there is no check.
Have there been any PL/I compilers that performed such a check?

Sorry I'm so late, I finally got around to checking.

Iron Spring PL/I checks. For non-adjustable arrays it causes an error at compile time:
"(ERR418)Mismatched array dimension or bounds in assignment statement."

For adjustable arrays it raises the ERROR condition at execution time. I guess the consensus is that it should be SUBSCRIPTRANGE if enabled. It probably should raise ERROR if SUBSCRIPTRANGE is not enabled?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, July 3, 2021 at 2:22:56 AM UTC+10, peter....@gmail.com wrote:

On Friday, June 4, 2021 at 9:03:13 PM UTC-7, Robin Vowels wrote:

In whole-array operations, IBM's Windows compiler does not check
that arrays are compatible.
Even if SUBSCRIPTRANGE is enabled, there is no check.
Have there been any PL/I compilers that performed such a check?

Sorry I'm so late, I finally got around to checking.

Iron Spring PL/I checks. For non-adjustable arrays it causes an error at compile time:
"(ERR418)Mismatched array dimension or bounds in assignment statement."

.
Very good.
.

For adjustable arrays it raises the ERROR condition at execution time.

.
If any condition can be raised, it should be the SUBSCRIPTRANGE condition.
.
The normal action from that is to raise the ERROR condition.

I guess the consensus is that it should be SUBSCRIPTRANGE if enabled.

.
Indeed so.
.

It probably should raise ERROR if SUBSCRIPTRANGE is not enabled?

.
In IBM's compilers, anything can happen if SUBRG is not enabled
and a subscript is out of bounds.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)