What I can to do with old PL/1 code? - Programming Languages

MZN wrote:[color=blue]
> I have an old program running on S370 a lot of years ago. It have deal
> with complex numerical computations and its volume about 10000 lines.
>
> I have IBM Visual Age PL/1 compiler, but it gives wrong results. Using
> compatibility mode makes situation slightly better only. Step by step
> debug with hand checking shows that I need to do some senseless
> exchanging lines of code, or write code by another manner (sometimes).
> So, I'm almost completely sure, that that compiler has errors. It's can
> be proved by my another (smaller) program, that had the same behavior
> until I rewrote it to Fortran. I cannot do the same here, due to size
> and semantic complexity. Some features couldn't be reproduced in
> Fortran.[/color]

It's not clear exactly what your problem is, but your description raises
some questions. It's also possible the compiler does not have errors.

First, what do you mean by "wrong results"? Are you comparing them
against previous results obtained a lot of years ago on an S370? Or are
they theoretically wrong? That is, are they just different from those
produced by old runs or are they different from expected results using
mathematical ****ysis?

Second, when you say "complex numerical computations", do you mean using
the FLOAT BINARY data type?

If changing the order of arithmetic operations changes the results, the
difference may be due to roundoff error or other known computational
issues related to limitations on precision and representation of real
numbers. In such cases, translating to Fortran may or may not help
because Fortran has mostly the same operator precedences as PL/I so it
evaluates expressions in mostly the same order.

In addition to compatibility mode, you might try recompiling with
different levels of optimization. Some compilers will change the order
of arithmetic operations in "unsafe" ways for certain (usually higher)
levels of optimization. In this context, "unsafe" means the compiler
changes the order of operations in such a way that roundoff error or
cumulative loss of precision may occur or may be worse than without
reordering. This is not just a PL/I issue; some Fortran compilers do it
as well.

Also, the S360/S370 binary floating point implementation did not have
the same binary precision for all floating point numbers. This is a
hardware issue and would be the same for all supported languages.
Basically, the S360/S370 floating point representation used a
hexadecimal base (base-16) representation for floating point rather than
a binary base. This is why IBM 360/370 PL/I floating point declarations
usually declare variables as having a precision of 21 (single) or 53
(double) bits.

S360 single precision floating point numbers are stored in 32-bit words
with a leading sign bit followed by a 7-bit biased base-16 exponent.
The low-order 24 bits contain the normalized hexadecimal mantissa (in 6
4-bit hexadecimal digits). Thus, the mantissa value is adjusted so the
high-order hexadecimal digit is non-zero; i.e., in the range 1 - 15 (or,
in binary, in the range 0001 - 1111). Note this means that when the
high-order hexadecimal digit is 1, the 3 high-order binary digits must
be zero so the representation of the value would contain only 21
significant binary digits.

This is reflected in source-level declarations. Although
single-precision floating point on S360/S370 systems contain 6
hexadecimal digits for a total of 24 bits, the hexadecimal
representation cannot guarantee more than 21 of those 24 bits will be
significant. Since PL/I's FLOAT BINARY precision is specified in binary
digits, declaring a variable FLOAT BINARY(24) on an S360/S370 system
would require the compiler to allocate two words (64 bits) for the value
because it would need to increase the precision in order to guarantee
the full 24 significant bits for all represented values.

Similarly, although double-precision S360/S370 floating point uses 14
hexadecimal digits (or 56 bits), it can only guarantee that 53 of those
bits will be significant for all represented values.

During computations, this means that the _binary_ precision of the
result of any single-precision arithmetic operation will vary between 21
and 24 significant bits, depending on the value. For long or
complicated computations this will produce roundoff errors and
propagated loss of precision that may be different from those produced
either by a strict 21-bit binary precision or by a strict 24-bit binary
precision representation.

The IEEE floating point standard prescribes a binary representation so
some long or involved computations will produce different results using
IEEE representation than those produced using S360/S370 representation.
This would be true for any legacy S360/S370 application in any language.
[color=blue]
> So, I try to find another way. I see Liant compiler and contact with
> them, but have one response only during to week. Have somebody
> experience with that compiler?[/color]

I've used the Liant compiler, but not for many years. The information
you've provided seems insufficient to determine whether switching to
another compiler would change the results in the way you need.
[color=blue]
> At the same time, I knew about Open VMS PL/1 compiler for Alpha
> computers. I think now I could buy such computer for a modest price,
> but what about compiler? Going to Kednos site and seen Hobbyist
> license, I do not understand how I can get it. Also, can somebody to
> tell about features of that compiler? Or, may be, such way isn't good?[/color]

Before switching to any other compiler, it might be a good idea to run a
test. You indicate you have a smaller program that exhibits the same
(or similar) erroneous behavior. I'd suggest testing any compiler using
that smaller program before making the change.


Bob Lidral
lidral at alum dot mit dot edu

On 10 Dec 2005 02:21:04 -0800, MZN <MikeZmn@gmail.com> wrote:
[color=blue]
> I have an old program running on S370 a lot of years ago. It have deal
> with complex numerical computations and its volume about 10000 lines.
>
> I have IBM Visual Age PL/1 compiler, but it gives wrong results. Using
> compatibility mode makes situation slightly better only. Step by step
> debug with hand checking shows that I need to do some senseless
> exchanging lines of code, or write code by another manner (sometimes).
> So, I'm almost completely sure, that that compiler has errors. It's can
> be proved by my another (smaller) program, that had the same behavior
> until I rewrote it to Fortran. I cannot do the same here, due to size
> and semantic complexity. Some features couldn't be reproduced in
> Fortran.
>
> So, I try to find another way. I see Liant compiler and contact with
> them, but have one response only during to week. Have somebody
> experience with that compiler?[/color]

I licensed it to them in the mid 80's
[color=blue]
>
> At the same time, I knew about Open VMS PL/1 compiler for Alpha
> computers. I think now I could buy such computer for a modest price,
> but what about compiler? Going to Kednos site and seen Hobbyist
> license, I do not understand how I can get it. Also, can somebody to
> tell about features of that compiler? Or, may be, such way isn't good?
>[/color]
It is true that you can buy a reasonably powerful Alpha workstation for a
modest
price. I have several from Island Computers [url]http://www.islandco.com/[/url]
or ebay.

If this is not for commercial use then you would qualify for a hobbyist
license.
To obtain such a license you must first have the underlying hobbyist
license
fro VMS and all the layered products. On our hobbyist's page click on the
shark
logo and you will be directed to the appropraite page which contains all
the
instructions. HP also has a "testdrive" on their web site but it didn't
seem to
be operational when I checked, I'll find out and post when I have the
answer.

Alternatively, if the code is fairly pure PL/I not requiring not much more
effort than
compile, link and run, I could run it for you here. If it is an issue of
precision,
a VAX or VAX emulator night be better as it supports greater precision.
From the
online HELP file

PLI

Attributes

FLOAT

Data type attribute.

Defines a floating-point arithmetic variable.

FLOAT BINARY(p) max=113 default=24 (OpenVMS VAX) FLOAT BINARY(p)
max=53 default=24 (OpenVMS AXP) FLOAT DECIMAL(p) max=34 default=7
(OpenVMS VAX) FLOAT DECIMAL(p) max=15 default=7 (OpenVMS AXP)

If FLOAT is specified without any other data type attributes, the
variable has the attributes FLOAT BINARY(24). Floating-point
binary data with precision in the range of 54-113 may be supported
in software, depending on the processor type and hardware options.

You could also use scaled fixed decimal

FIXED

Data type attribute.

Defines a fixed-point arithmetic variable with precision (p) and
scale-factor (q).

FIXED BINARY (p) max=31
(q) -31 to 31
default=31,0
FIXED DECIMAL (p) max=31
(q) 0 to 31
default=10,0

If FIXED is specified without any other data type attributes, the
variable has the attributes FIXED BINARY(31,0).



Tom

MZN wrote:[color=blue]
> I have an old program running on S370 a lot of years ago. It have deal
> with complex numerical computations and its volume about 10000 lines.
>
> I have IBM Visual Age PL/1 compiler, but it gives wrong results. Using
> compatibility mode makes situation slightly better only. Step by step
> debug with hand checking shows that I need to do some senseless
> exchanging lines of code, or write code by another manner (sometimes).
> So, I'm almost completely sure, that that compiler has errors. It's can
> be proved by my another (smaller) program, that had the same behavior
> until I rewrote it to Fortran. I cannot do the same here, due to size
> and semantic complexity. Some features couldn't be reproduced in
> Fortran.
>
> So, I try to find another way. I see Liant compiler and contact with
> them, but have one response only during to week. Have somebody
> experience with that compiler?
>
> At the same time, I knew about Open VMS PL/1 compiler for Alpha
> computers. I think now I could buy such computer for a modest price,
> but what about compiler? Going to Kednos site and seen Hobbyist
> license, I do not understand how I can get it. Also, can somebody to
> tell about features of that compiler? Or, may be, such way isn't good?
>[/color]
I would help to know [unless I just missed it]:
What hardware are you using?
What compiler? Version, release, etc. are you using?
Carl

First of all, thank you very much, Bob!
Bob Lidral писал(а):
[color=blue]
> MZN wrote:[color=green]
> > I have an old program running on S370 a lot of years ago. It have deal
> > with complex numerical computations and its volume about 10000 lines.
> >
> > I have IBM Visual Age PL/1 compiler, but it gives wrong results. Using
> > compatibility mode makes situation slightly better only. Step by step
> > debug with hand checking shows that I need to do some senseless
> > exchanging lines of code, or write code by another manner (sometimes).
> > So, I'm almost completely sure, that that compiler has errors. It's can
> > be proved by my another (smaller) program, that had the same behavior
> > until I rewrote it to Fortran. I cannot do the same here, due to size
> > and semantic complexity. Some features couldn't be reproduced in
> > Fortran.[/color]
>
> It's not clear exactly what your problem is, but your description raises
> some questions. It's also possible the compiler does not have errors.
>
> First, what do you mean by "wrong results"? Are you comparing them
> against previous results obtained a lot of years ago on an S370? Or are
> they theoretically wrong? That is, are they just different from those
> produced by old runs or are they different from expected results using
> mathematical ****ysis?[/color]

They are wrong in both senses. I have old results, unfortunately as
hard copy (computer paper), so I can compare.[color=blue]
>
> Second, when you say "complex numerical computations", do you mean using
> the FLOAT BINARY data type?[/color]
I declared variables as FLOAT(16)[color=blue]
>
> If changing the order of arithmetic operations changes the results, the
> difference may be due to roundoff error or other known computational
> issues related to limitations on precision and representation of real
> numbers. In such cases, translating to Fortran may or may not help
> because Fortran has mostly the same operator precedences as PL/I so it
> evaluates expressions in mostly the same order.[/color]
Yes, I suspect that this is due to roundoff error, but I have no
knowledge enough in order to prevent it. And it's big work too. Fortran
helped me in very similar, but smaller program.[color=blue]
>
> In addition to compatibility mode, you might try recompiling with
> different levels of optimization. Some compilers will change the order
> of arithmetic operations in "unsafe" ways for certain (usually higher)
> levels of optimization. In this context, "unsafe" means the compiler
> changes the order of operations in such a way that roundoff error or
> cumulative loss of precision may occur or may be worse than without
> reordering. This is not just a PL/I issue; some Fortran compilers do it
> as well.[/color]
I used all optimization modes.[color=blue]
>
> Also, the S360/S370 binary floating point implementation did not have
> the same binary precision for all floating point numbers. This is a
> hardware issue and would be the same for all supported languages.
> Basically, the S360/S370 floating point representation used a
> hexadecimal base (base-16) representation for floating point rather than
> a binary base. This is why IBM 360/370 PL/I floating point declarations
> usually declare variables as having a precision of 21 (single) or 53
> (double) bits.[/color]
I understand that, but all algorithms are very clear, but a complex
too.[color=blue]
>
> S360 single precision floating point numbers are stored in 32-bit words
> with a leading sign bit followed by a 7-bit biased base-16 exponent.
> The low-order 24 bits contain the normalized hexadecimal mantissa (in 6
> 4-bit hexadecimal digits). Thus, the mantissa value is adjusted so the
> high-order hexadecimal digit is non-zero; i.e., in the range 1 - 15 (or,
> in binary, in the range 0001 - 1111). Note this means that when the
> high-order hexadecimal digit is 1, the 3 high-order binary digits must
> be zero so the representation of the value would contain only 21
> significant binary digits.
>
> This is reflected in source-level declarations. Although
> single-precision floating point on S360/S370 systems contain 6
> hexadecimal digits for a total of 24 bits, the hexadecimal
> representation cannot guarantee more than 21 of those 24 bits will be
> significant. Since PL/I's FLOAT BINARY precision is specified in binary
> digits, declaring a variable FLOAT BINARY(24) on an S360/S370 system
> would require the compiler to allocate two words (64 bits) for the value
> because it would need to increase the precision in order to guarantee
> the full 24 significant bits for all represented values.[/color]
As I wrote before, I use FLOAT(16)[color=blue]
>
> Similarly, although double-precision S360/S370 floating point uses 14
> hexadecimal digits (or 56 bits), it can only guarantee that 53 of those
> bits will be significant for all represented values.
>
> During computations, this means that the _binary_ precision of the
> result of any single-precision arithmetic operation will vary between 21
> and 24 significant bits, depending on the value. For long or
> complicated computations this will produce roundoff errors and
> propagated loss of precision that may be different from those produced
> either by a strict 21-bit binary precision or by a strict 24-bit binary
> precision representation.
>
> The IEEE floating point standard prescribes a binary representation so
> some long or involved computations will produce different results using
> IEEE representation than those produced using S360/S370 representation.
> This would be true for any legacy S360/S370 application in any language.
>[color=green]
> > So, I try to find another way. I see Liant compiler and contact with
> > them, but have one response only during to week. Have somebody
> > experience with that compiler?[/color]
>
> I've used the Liant compiler, but not for many years. The information
> you've provided seems insufficient to determine whether switching to
> another compiler would change the results in the way you need.
>[color=green]
> > At the same time, I knew about Open VMS PL/1 compiler for Alpha
> > computers. I think now I could buy such computer for a modest price,
> > but what about compiler? Going to Kednos site and seen Hobbyist
> > license, I do not understand how I can get it. Also, can somebody to
> > tell about features of that compiler? Or, may be, such way isn't good?[/color]
>
> Before switching to any other compiler, it might be a good idea to run a
> test. You indicate you have a smaller program that exhibits the same
> (or similar) erroneous behavior. I'd suggest testing any compiler using
> that smaller program before making the change.[/color]
Unfortunately, now I have a double Opteron machine with Windows 64 bit,
and IBM PL/I compiler doesn't install. I'll try to install Windows XP
32 bit (as virtual machine) and do that, but work looks very hard.[color=blue]
>
>
> Bob Lidral
> lidral at alum dot mit dot edu[/color]

Thank you, Tom!

1. I'll be look about Alpha machine.
2. If it is not a big problem to you, I'll prepare zip archive with
code and data set, but I have test results in hard copy form, or as
graphs.
So, if you give me e-mail, I'll be very appreciated.

Hardware used are dual Pentium III machine with Windows XP 32 bit.
Software IBM Visual age PL/I compiler 2.1.7 with updates up to 2.1.13.

Subject: What I can to do with old PL/1 code?
From: "MZN" <MikeZmn@gmail.com>, [url]http://groups.google.comDate:[/url] 10 Dec 2005
02:21:04 -0800[color=blue]
>I have an old program running on S370 a lot of years ago. It have deal
>with complex numerical computations and its volume about 10000 lines.
>
>I have IBM Visual Age PL/1 compiler, but it gives wrong results. Using
>compatibility mode makes situation slightly better only. Step by step
>debug with hand checking shows that I need to do some senseless
>exchanging lines of code, or write code by another manner (sometimes).
>So, I'm almost completely sure, that that compiler has errors. It's can
>be proved by my another (smaller) program, that had the same behavior
>until I rewrote it to Fortran. I cannot do the same here, due to size
>and semantic complexity. Some features couldn't be reproduced in
>Fortran.[/color]
..
The first thing that you need to do is to enable
subscript bounds checking, and some other checks.
Please add the next line before your main procedure statement.
(SUBRG, SIZE, STRINGRANGE, STRINGSIZE):

There are differences between the IBM S/370 and the
PC in the way in which floating-point values are stored.
You may have an unstable algorithm.
Have you tried using FLOAT (18), which will use the
extra precision of the PC?

There are differences in the way in which MULTIPLY,
DIVIDE, ADD, and SUBTRACT are handled with fixed-point binary.
Are you using any of these functions?

Do you have IBM or ANSI rules specified? ( %PROCESS option.)

The VA compiler is very robust compiler, and it is
unlikely that your problem is caused by the compiler;
nevertheless, a compiler error cannot be dismissed.

Other things you could try:

Do you specify OPTIONS (REORDER) in your procedures?
Does yur program give different results if compiled
with REORDER on or off? (with optimization on).
[color=blue]
>So, I try to find another way. I see Liant compiler and contact with
>them, but have one response only during to week. Have somebody
>experience with that compiler?[/color]
[color=blue]
>At the same time, I knew about Open VMS PL/1 compiler for Alpha
>computers. I think now I could buy such computer for a modest price,
>but what about compiler? Going to Kednos site and seen Hobbyist
>license, I do not understand how I can get it. Also, can somebody to
>tell about features of that compiler? Or, may be, such way isn't good?[/color]

Thank you Robin,

1. I used (SUBRG, SIZE, STRINGRANGE, STRINGSIZE): earlier and now - no
luck
2. I tried FLOAT(18) - no luck. Algorithm possibly may be unstable, but
a. I used some preventive measures
b. It worked good on S370
3. I do not use MULTIPLY, DIVIDE, ADD, and SUBTRACT
4. I tried both IBM and ANSI rules
5. OPTIONS(REORDER) doesn't affect on results.

I have ported numerical computations in PL/I from S370 to NT4/2K/XP/2K3,
with a volume of some 150,000 LOC, and had far fewer problems than you.

Here are the major gotcha's:
1) The Intel hardware has a stupidity known as imprecise interrupts that can
wreak havoc. Compile absolutely everything with NOIMPRECISE and only permit
IMPRECISE (the default) if you are absolutely sure that your code will never
ever raise a floating point exception. If you are even slightly unsure about
the remore possibility of a floating point exception, use NOIMPRECISE.
Ignore the Programming Guide's recommendation.

2) The behaviour of the normal return from an ON block on the old PL/I
compilers is to resume after an OVERFLOW and ZERODIVIDE: the newer compilers
raise ERROR. You must alter your logic to handle this.

3) IEEE float has a shorter mantissa and longer exponent. This can affect
convergence criteria, so that algorithms that converged on /370 don't when
using IEEE float. You will need to review the convergence criteria of your
algorithms to address this issue. Note that a Fortran rewrite won't help you
here, as the problem is not a language dependent one. [This was the worse
problem I encountered].

4) When converted to a string, a float bin (53) ieee becomes a char (24),
whereas a float bin (53) hexadec is a char(22). It is essential that you
review all conversion of floats to chars to ensure you don't miss anything.
This does not normally affect numerical algorithms.

There used to be a problem with the floating point condition enablement when
a PL/I routine was called from non-PLI code. This problem was resolved a
while back, so you won't have a problem with 2.1.13.

The use of Liant or other compiler will only exacerbate your problems, as
these compilers are far less compatible.

If you can reproduce any of the problems you are encountering, you should
open a PMR. The lab are normally very fast in resolving any problems they
can reproduce.

"MZN" <MikeZmn@gmail.com> wrote in message
news:1134210064.904867.222520@z14g2000cwz.googlegroups.com...[color=blue]
>I have an old program running on S370 a lot of years ago. It have deal
> with complex numerical computations and its volume about 10000 lines.
>
> I have IBM Visual Age PL/1 compiler, but it gives wrong results. Using
> compatibility mode makes situation slightly better only. Step by step
> debug with hand checking shows that I need to do some senseless
> exchanging lines of code, or write code by another manner (sometimes).
> So, I'm almost completely sure, that that compiler has errors. It's can
> be proved by my another (smaller) program, that had the same behavior
> until I rewrote it to Fortran. I cannot do the same here, due to size
> and semantic complexity. Some features couldn't be reproduced in
> Fortran.
>
> So, I try to find another way. I see Liant compiler and contact with
> them, but have one response only during to week. Have somebody
> experience with that compiler?
>
> At the same time, I knew about Open VMS PL/1 compiler for Alpha
> computers. I think now I could buy such computer for a modest price,
> but what about compiler? Going to Kednos site and seen Hobbyist
> license, I do not understand how I can get it. Also, can somebody to
> tell about features of that compiler? Or, may be, such way isn't good?
>[/color]