IBM's current language reference manual states
that SIZE condition is raised when high-order
significant binary or decimal digits are lost in an
attempted assignment to a variable or an intermediate
result.
… the SIZE condition is primarily used for program testing.
It can be removed from production programs.
.
The manual then goes on to say …
If the SIZE condition is raised and it is disabled, the program is in error.
.
Sort of contradictory.

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

On 10/10/22 4:48 PM, Robin Vowels wrote:

IBM's current language reference manual states
that SIZE condition is raised when high-order
significant binary or decimal digits are lost in an
attempted assignment to a variable or an intermediate
result.
… the SIZE condition is primarily used for program testing.
It can be removed from production programs.
.
The manual then goes on to say …
If the SIZE condition is raised and it is disabled, the program is in error. .
Sort of contradictory.

It’s just being practical. Determining whether or not SIZE has happened
can often take more code (and CPU time) than doing the calculation
itself. If your code is bug-free, that’s a lot of cycles down the drain.
When debugging, use (SIZE):, and ensure that your code always works for
i = 0...1_000_000 or whatever you need. When actually running, use
(NOSIZE): and ensure that 0 <= i <= 1_000_000 as soon as you read it in.

--
John W. Kennedy
Algernon Burbage, Lord Roderick, Father Martin, Bishop Baldwin,
King Pellinore, Captain Bailey, Merlin -- A Kingdom for a Stage!

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

On Tuesday, October 11, 2022 at 8:10:20 AM UTC+11, John W. Kennedy wrote:

On 10/10/22 4:48 PM, Robin Vowels wrote:

IBM's current language reference manual states
that SIZE condition is raised when high-order
significant binary or decimal digits are lost in an
attempted assignment to a variable or an intermediate
result.
… the SIZE condition is primarily used for program testing.
It can be removed from production programs.
.
The manual then goes on to say …
If the SIZE condition is raised and it is disabled, the program is in error.
.
Sort of contradictory.

.

It’s just being practical. Determining whether or not SIZE has happened can often take more code (and CPU time) than doing the calculation
itself.

.
For binary integer overflow, when the declared size is smaller than
the relevant word size, all that's required is SLA.
When the declared size is the same as the word size,
no extra instruction is required.
.
For decimal overflow, no extra instruction is required when
the declared size has an odd number of decimal digits.
When an even number of digits is declared, a TM
is required to examine the left-most nibble for being non-zero.
A BZ instruction can lead past an instruction to raise an interrupt.
.
Neither of these options looks like an instruction hog or a time hog.
.

If your code is bug-free, that’s a lot of cycles down the drain.

.
Sometimes something in a program is overlooked. It wastes time
to track down an obscure bug - both human time and computer time.
.

When debugging, use (SIZE):, and ensure that your code always works for
i = 0...1_000_000 or whatever you need. When actually running, use
(NOSIZE): and ensure that 0 <= i <= 1_000_000 as soon as you read it in.

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

On Tuesday, October 11, 2022 at 8:10:20 AM UTC+11, John W. Kennedy wrote:

On 10/10/22 4:48 PM, Robin Vowels wrote:

IBM's current language reference manual states
that SIZE condition is raised when high-order
significant binary or decimal digits are lost in an
attempted assignment to a variable or an intermediate
result.
… the SIZE condition is primarily used for program testing.
It can be removed from production programs.
.
The manual then goes on to say …
If the SIZE condition is raised and it is disabled, the program is in error.
.
Sort of contradictory.

It’s just being practical. Determining whether or not SIZE has happened can often take more code (and CPU time) than doing the calculation
itself. If your code is bug-free, that’s a lot of cycles down the drain.

From the internet:
"We let PL/I check the boudaries of the variables/arrays even in production
" (PREFIX(SIZE,STRINGRANGE,SUBSCRIPTRANGE)) what is very useful
" to detect programming errors at runtime (without, you just may have
" wrong data processed that you may find out very later)."

When debugging, use (SIZE):, and ensure that your code always works for
i = 0...1_000_000 or whatever you need. When actually running, use
(NOSIZE): and ensure that 0 <= i <= 1_000_000 as soon as you read it in.

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

On 10/10/22 9:05 PM, Robin Vowels wrote:

On Tuesday, October 11, 2022 at 8:10:20 AM UTC+11, John W. Kennedy wrote:

On 10/10/22 4:48 PM, Robin Vowels wrote:

IBM's current language reference manual states
that SIZE condition is raised when high-order
significant binary or decimal digits are lost in an
attempted assignment to a variable or an intermediate
result.
… the SIZE condition is primarily used for program testing.
It can be removed from production programs.
.
The manual then goes on to say …
If the SIZE condition is raised and it is disabled, the program is in error.
.
Sort of contradictory.

.

It’s just being practical. Determining whether or not SIZE has happened
can often take more code (and CPU time) than doing the calculation
itself.

.
For binary integer overflow, when the declared size is smaller than
the relevant word size, all that's required is SLA.
When the declared size is the same as the word size,
no extra instruction is required.

Not in twos-complement. Look at the actual code any PL/I compiler produces.

For decimal overflow, no extra instruction is required when
the declared size has an odd number of decimal digits.
When an even number of digits is declared, a TM
is required to examine the left-most nibble for being non-zero.
A BZ instruction can lead past an instruction to raise an interrupt.

That means no distinction between SIZE and FIXEDOVERFLOW.

Neither of these options looks like an instruction hog or a time hog.
.

If your code is bug-free, that’s a lot of cycles down the drain.

.
Sometimes something in a program is overlooked. It wastes time
to track down an obscure bug - both human time and computer time.
.

When debugging, use (SIZE):, and ensure that your code always works for
i = 0...1_000_000 or whatever you need. When actually running, use
(NOSIZE): and ensure that 0 <= i <= 1_000_000 as soon as you read it in.

--
John W. Kennedy
Algernon Burbage, Lord Roderick, Father Martin, Bishop Baldwin,
King Pellinore, Captain Bailey, Merlin -- A Kingdom for a Stage!

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

On 10/10/22 9:16 PM, Robin Vowels wrote:

On Tuesday, October 11, 2022 at 8:10:20 AM UTC+11, John W. Kennedy wrote:

On 10/10/22 4:48 PM, Robin Vowels wrote:

IBM's current language reference manual states
that SIZE condition is raised when high-order
significant binary or decimal digits are lost in an
attempted assignment to a variable or an intermediate
result.
… the SIZE condition is primarily used for program testing.
It can be removed from production programs.
.
The manual then goes on to say …
If the SIZE condition is raised and it is disabled, the program is in error.
.
Sort of contradictory.

It’s just being practical. Determining whether or not SIZE has happened
can often take more code (and CPU time) than doing the calculation
itself. If your code is bug-free, that’s a lot of cycles down the drain.

From the internet:
"We let PL/I check the boudaries of the variables/arrays even in production
" (PREFIX(SIZE,STRINGRANGE,SUBSCRIPTRANGE)) what is very useful
" to detect programming errors at runtime (without, you just may have
" wrong data processed that you may find out very later)."

Well, if an anonymous person on the Internet with dreadful spelling and
grammar says so, that must settle the issue.

But why not use Ada, which puts integers into a specific range (e.g., 1752..19999), instead of limiting things to zero..powersOf2?

When debugging, use (SIZE):, and ensure that your code always works for
i = 0...1_000_000 or whatever you need. When actually running, use
(NOSIZE): and ensure that 0 <= i <= 1_000_000 as soon as you read it in.

--
John W. Kennedy
Algernon Burbage, Lord Roderick, Father Martin, Bishop Baldwin,
King Pellinore, Captain Bailey, Merlin -- A Kingdom for a Stage!

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

On Wednesday, October 12, 2022 at 6:19:40 AM UTC+11, John W. Kennedy wrote:

On 10/10/22 9:16 PM, Robin Vowels wrote:

On Tuesday, October 11, 2022 at 8:10:20 AM UTC+11, John W. Kennedy wrote:

On 10/10/22 4:48 PM, Robin Vowels wrote:

IBM's current language reference manual states
that SIZE condition is raised when high-order
significant binary or decimal digits are lost in an
attempted assignment to a variable or an intermediate
result.
… the SIZE condition is primarily used for program testing.
It can be removed from production programs.
.
The manual then goes on to say …
If the SIZE condition is raised and it is disabled, the program is in error.
.
Sort of contradictory.

It’s just being practical. Determining whether or not SIZE has happened >> can often take more code (and CPU time) than doing the calculation
itself. If your code is bug-free, that’s a lot of cycles down the drain.

From the internet:
"We let PL/I check the boudaries of the variables/arrays even in production
" (PREFIX(SIZE,STRINGRANGE,SUBSCRIPTRANGE)) what is very useful
" to detect programming errors at runtime (without, you just may have
" wrong data processed that you may find out very later)."

.

Well, if an anonymous person on the Internet with dreadful spelling and grammar says so, that must settle the issue.

.
Probably English is not his first language. What's important is the message, and his English doesn't make it any less relevant.
.
Another PL/I expert wrote:
"We've used STRINGRANGE and SUBSCRIPTRANGE as a default on all our
production modules since about 1995. In our overall picture (mainframe only) we consider the overhead trivial, compared to the savings in catching potential overlay [corruption] situations before there is an overlay. This standard was triggered particularly by one nasty overlay in a production online IMS program that took a solid week to track down, with several expert people involved. The problem would have been caught by the range checks. We figured out that
the outage for that one problem covered the range check runtime overhead
for several years at least. We have definitely had fewer overlay problems
with the range checks activated." (PL/I Listserver, 9 September 2001)
.

But why not use Ada, which puts integers into a specific range (e.g., 1752..19999), instead of limiting things to zero..powersOf2?

.
For binary, it could be powers of 2. For decimal, it's powers of 10.
Rigid ranges like that (1752..19999) are a pain in the neck when
a program needs to be modified to allow an extended range of values.
.
When Ada was first introduced, it was not possible to write general
algorithms. Arrays had fixed bounds. That's been rectified now.
There are problems with strings.
PL/I has a lot more to offer than Ada.
.
You have to wonder about Ada when people ask questions like
"How do I use Square Root?"
.

When debugging, use (SIZE):, and ensure that your code always works for >> i = 0...1_000_000 or whatever you need. When actually running, use
(NOSIZE): and ensure that 0 <= i <= 1_000_000 as soon as you read it in.

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

On Wednesday, October 12, 2022 at 6:12:43 AM UTC+11, John W. Kennedy wrote:

On 10/10/22 9:05 PM, Robin Vowels wrote:

On Tuesday, October 11, 2022 at 8:10:20 AM UTC+11, John W. Kennedy wrote:

On 10/10/22 4:48 PM, Robin Vowels wrote:

IBM's current language reference manual states
that SIZE condition is raised when high-order
significant binary or decimal digits are lost in an
attempted assignment to a variable or an intermediate
result.
… the SIZE condition is primarily used for program testing.
It can be removed from production programs.
.
The manual then goes on to say …
If the SIZE condition is raised and it is disabled, the program is in error.
.
Sort of contradictory.

.

It’s just being practical. Determining whether or not SIZE has happened >> can often take more code (and CPU time) than doing the calculation
itself.

.
For binary integer overflow, when the declared size is smaller than
the relevant word size, all that's required is SLA.
When the declared size is the same as the word size,
no extra instruction is required.

.

Not in twos-complement.

.
My recollection of twos complement is that SLA will overflow
when any significant bits are lost. Integer overflow will be raised
if enabled).
.
Look at the actual code any PL/I compiler produces.
.

For decimal overflow, no extra instruction is required when
the declared size has an odd number of decimal digits.
When an even number of digits is declared, a TM
is required to examine the left-most nibble for being non-zero.
A BZ instruction can lead past an instruction to raise an interrupt.

.

That means no distinction between SIZE and FIXEDOVERFLOW.

.
These were illustrations to indicate that the code to perform
such checks is trivial.
And no, it does not mean that there is no distinction between SIZE and FOFL.
In the case of decimal, the optional instruction would merely be a
decimal instruction to intentionally raise a decmal interrupt.
.
It should be noted how IBM's current compilers handle decimal arithmetic. Decimal operations can raise decimal overflow interrupt. They can also raise FIXEDOVERFLOW AND ZERODIVIDE.
.

Neither of these options looks like an instruction hog or a time hog.
.

If your code is bug-free, that’s a lot of cycles down the drain.

.
Sometimes something in a program is overlooked. It wastes time
to track down an obscure bug - both human time and computer time.
.

When debugging, use (SIZE):, and ensure that your code always works for >> i = 0...1_000_000 or whatever you need. When actually running, use
(NOSIZE): and ensure that 0 <= i <= 1_000_000 as soon as you read it in.

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

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

On Wednesday, October 12, 2022 at 6:12:43 AM UTC+11, John W. Kennedy wrote:

On 10/10/22 9:05 PM, Robin Vowels wrote:

On Tuesday, October 11, 2022 at 8:10:20 AM UTC+11, John W. Kennedy wrote: >>>> On 10/10/22 4:48 PM, Robin Vowels wrote:

IBM's current language reference manual states
that SIZE condition is raised when high-order
significant binary or decimal digits are lost in an
attempted assignment to a variable or an intermediate
result.
… the SIZE condition is primarily used for program testing.
It can be removed from production programs.
.
The manual then goes on to say …
If the SIZE condition is raised and it is disabled, the program is in error.
.
Sort of contradictory.

.

It’s just being practical. Determining whether or not SIZE has happened >>>> can often take more code (and CPU time) than doing the calculation
itself.

.
For binary integer overflow, when the declared size is smaller than
the relevant word size, all that's required is SLA.
When the declared size is the same as the word size,
no extra instruction is required.

.

Not in twos-complement.

.
My recollection of twos complement is that SLA will overflow
when any significant bits are lost. Integer overflow will be raised
if enabled).
.
Look at the actual code any PL/I compiler produces.
.

For decimal overflow, no extra instruction is required when
the declared size has an odd number of decimal digits.
When an even number of digits is declared, a TM
is required to examine the left-most nibble for being non-zero.
A BZ instruction can lead past an instruction to raise an interrupt.

.

That means no distinction between SIZE and FIXEDOVERFLOW.

.
These were illustrations to indicate that the code to perform
such checks is trivial.
And no, it does not mean that there is no distinction between SIZE and FOFL. In the case of decimal, the optional instruction would merely be a
decimal instruction to intentionally raise a decmal interrupt.
.
It should be noted how IBM's current compilers handle decimal arithmetic. Decimal operations can raise decimal overflow interrupt. They can also raise FIXEDOVERFLOW AND ZERODIVIDE.
.

Neither of these options looks like an instruction hog or a time hog.
.

If your code is bug-free, that’s a lot of cycles down the drain.

.
Sometimes something in a program is overlooked. It wastes time
to track down an obscure bug - both human time and computer time.
.

When debugging, use (SIZE):, and ensure that your code always works for >>>> i = 0...1_000_000 or whatever you need. When actually running, use
(NOSIZE): and ensure that 0 <= i <= 1_000_000 as soon as you read it in.

One point no one noted is that SIZE applies when storing a final result,
while FIXEDOVERFLOW can be raised at any point in a computation, so an expression that overflows but produces an appropriately-sized, but
incorrect , result will not raise any error conditions.

--
Pete

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

With FOFL not being raised by IBM's current PL/I compilers
for overflow of maximum precision of FIXED BINARY,
it might be prudent to make all such declarations of precision
30 or less, rather than 31.

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

On Thursday, October 13, 2022 at 12:19:02 AM UTC+11, bearlyabus...@gmail.com wrote:

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

On Wednesday, October 12, 2022 at 6:12:43 AM UTC+11, John W. Kennedy wrote:

On 10/10/22 9:05 PM, Robin Vowels wrote:

On Tuesday, October 11, 2022 at 8:10:20 AM UTC+11, John W. Kennedy wrote:

On 10/10/22 4:48 PM, Robin Vowels wrote:

IBM's current language reference manual states
that SIZE condition is raised when high-order
significant binary or decimal digits are lost in an
attempted assignment to a variable or an intermediate
result.
… the SIZE condition is primarily used for program testing.
It can be removed from production programs.
.
The manual then goes on to say …
If the SIZE condition is raised and it is disabled, the program is in error.
.
Sort of contradictory.

.

It’s just being practical. Determining whether or not SIZE has happened
can often take more code (and CPU time) than doing the calculation
itself.

.
For binary integer overflow, when the declared size is smaller than
the relevant word size, all that's required is SLA.
When the declared size is the same as the word size,
no extra instruction is required.

.

Not in twos-complement.

.
My recollection of twos complement is that SLA will overflow
when any significant bits are lost. Integer overflow will be raised
if enabled).
.
Look at the actual code any PL/I compiler produces.
.

For decimal overflow, no extra instruction is required when
the declared size has an odd number of decimal digits.
When an even number of digits is declared, a TM
is required to examine the left-most nibble for being non-zero.
A BZ instruction can lead past an instruction to raise an interrupt.

.

That means no distinction between SIZE and FIXEDOVERFLOW.

.
These were illustrations to indicate that the code to perform
such checks is trivial.
And no, it does not mean that there is no distinction between SIZE and FOFL.
In the case of decimal, the optional instruction would merely be a
decimal instruction to intentionally raise a decmal interrupt.
.
It should be noted how IBM's current compilers handle decimal arithmetic. Decimal operations can raise decimal overflow interrupt. They can also raise
FIXEDOVERFLOW AND ZERODIVIDE.
.

Neither of these options looks like an instruction hog or a time hog. >>> .

If your code is bug-free, that’s a lot of cycles down the drain.

.
Sometimes something in a program is overlooked. It wastes time
to track down an obscure bug - both human time and computer time.
.

When debugging, use (SIZE):, and ensure that your code always works for >>>> i = 0...1_000_000 or whatever you need. When actually running, use
(NOSIZE): and ensure that 0 <= i <= 1_000_000 as soon as you read it in.

.

One point no one noted is that SIZE applies when storing a final result,

.
I did note that. I described the action at the beginning of this very post.

while FIXEDOVERFLOW can be raised at any point in a computation, so an expression that overflows but produces an appropriately-sized, but
incorrect , result will not raise any error conditions.

.
My reading of the PL/I LRM is that SIZE can be raised during the evaluation of a decimal expression. From my reading of the PRINCOPS, it seems apparent that a decimal overflow can be raised during any intermediate decimal add/subtract operation. It could be that there is one high-order decimal digit in an intermediate
result that is out of range, but would not be detected. However, if that result
is assigned to a decimal variable (or decimal intermediate) that high-order digit would be detected and would raise SIZE.
If the result were assigned to a FIXED BINARY variable, it would seem to me that no overflow could be detected.
.
I might try this out.
.
What do you think?
.
I would prefer consistent results: FOFL raised for overflow of maximum
size of FIXED BINARY and FIXED DECIMAL,
and SIZE raised for overflows of less-than-maximum FIXED BINARY and
FIXED DECIMAL overflows, as originally specified in C28-6571.
.
Alternatively, FOFL raised for any overflow in FIXED BINARY,
and SIZE to be raised for any overflow of FIXED DECIMAL.
.
In any real-time application in IBM's current z/OS compilers, it would be necessary to include ON statements to trap SIZE, FOFL, and ZDIV, in order
to trap and recover from any overflow.

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

On 10/12/22 7:31 PM, Robin Vowels wrote:

With FOFL not being raised by IBM's current PL/I compilers
for overflow of maximum precision of FIXED BINARY,
it might be prudent to make all such declarations of precision
30 or less, rather than 31.

Only if you do your own temporary handling. Instead of:

y = a * x ** 2 + b * x + c;

you have to write:

t1 = x ** 2;
t2 = a * t1;
t3 = b * x;
t4 = t2 + t3;
y = t4 + c;

because SIZE applies only to assignments.

Also, FIXED BIN(30) won’t solve the problem when the operation is multiplication, exponentiation, or division.

--
John W. Kennedy
Algernon Burbage, Lord Roderick, Father Martin, Bishop Baldwin,
King Pellinore, Captain Bailey, Merlin -- A Kingdom for a Stage!

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

On Friday, October 14, 2022 at 5:57:43 AM UTC+11, John W. Kennedy wrote:

On 10/12/22 7:31 PM, Robin Vowels wrote:

With FOFL not being raised by IBM's current PL/I compilers
for overflow of maximum precision of FIXED BINARY,
it might be prudent to make all such declarations of precision
30 or less, rather than 31.

Only if you do your own temporary handling. Instead of:

y = a * x ** 2 + b * x + c;

you have to write:

t1 = x ** 2;
t2 = a * t1;
t3 = b * x;
t4 = t2 + t3;
y = t4 + c;

because SIZE applies only to assignments.

Also, FIXED BIN(30) won’t solve the problem when the operation is multiplication, exponentiation, or division.

.
I ran a program that used multiplication with FIXED BINARY (30) variables.
.
With the VA compiler of 1998, FOFL was raised, as expected.
With the 64-bit VA compiler c. 2008, SIZE was raised, as expected.

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

On 10/15/22 2:05 AM, Robin Vowels wrote:

On Friday, October 14, 2022 at 5:57:43 AM UTC+11, John W. Kennedy wrote:

On 10/12/22 7:31 PM, Robin Vowels wrote:

With FOFL not being raised by IBM's current PL/I compilers
for overflow of maximum precision of FIXED BINARY,
it might be prudent to make all such declarations of precision
30 or less, rather than 31.

Only if you do your own temporary handling. Instead of:

y = a * x ** 2 + b * x + c;

you have to write:

t1 = x ** 2;
t2 = a * t1;
t3 = b * x;
t4 = t2 + t3;
y = t4 + c;

because SIZE applies only to assignments.

Also, FIXED BIN(30) won’t solve the problem when the operation is
multiplication, exponentiation, or division.

.
I ran a program that used multiplication with FIXED BINARY (30) variables.
.
With the VA compiler of 1998, FOFL was raised, as expected.
With the 64-bit VA compiler c. 2008, SIZE was raised, as expected.

That means nothing if you don’t name the values you were mutiiplying.
Some ought to raise FOFL; some ought not.

--
John W. Kennedy
Algernon Burbage, Lord Roderick, Father Martin, Bishop Baldwin,
King Pellinore, Captain Bailey, Merlin -- A Kingdom for a Stage!

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

On Sunday, October 16, 2022 at 9:21:21 AM UTC+11, John W. Kennedy wrote:

On 10/15/22 2:05 AM, Robin Vowels wrote:

On Friday, October 14, 2022 at 5:57:43 AM UTC+11, John W. Kennedy wrote:

On 10/12/22 7:31 PM, Robin Vowels wrote:

With FOFL not being raised by IBM's current PL/I compilers
for overflow of maximum precision of FIXED BINARY,
it might be prudent to make all such declarations of precision
30 or less, rather than 31.

Only if you do your own temporary handling. Instead of:

y = a * x ** 2 + b * x + c;

you have to write:

t1 = x ** 2;
t2 = a * t1;
t3 = b * x;
t4 = t2 + t3;
y = t4 + c;

because SIZE applies only to assignments.

Also, FIXED BIN(30) won’t solve the problem when the operation is
multiplication, exponentiation, or division.

.
I ran a program that used multiplication with FIXED BINARY (30) variables. .
With the VA compiler of 1998, FOFL was raised, as expected.
With the 64-bit VA compiler c. 2008, SIZE was raised, as expected.

.

That means nothing if you don’t name the values you were mutiiplying.
Some ought to raise FOFL; some ought not.

.
IBM's current compilers never raise FOFL for fixed binary multiplication.
The second VA compiler mentioned is the "modern" version that allows
up to 64 bits for FIXED BINARY.

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