FIXED DECIMAL -> FIXED BINARY conversion rules with large scale values

[Thomas David Rivers]

In this example:

SMALL: PROC;

DCL I FIXED BIN(31,127);
DCL D FIXED DECIMAL(15,100);

I = D;

END SMALL;

we have a conversion of a FIXED DECIMAL with a precision of 15 and a
scale of 100,
to a FIXED BINARY. The FIXED BINARY has the maximum precision & scale
allowed..

FIrst question - the IBM Language Reference manual indicates that result
(I'm assuming
it means the intermediate result) is a FIXED BINARY(p2,q2) with these
attributes:

The precision of the result is p2 = min(N,1+CEIL(p1*3.32)) and
q2=CEIL(ABS(q1*3.32))*SIGN(q1).

(I guess 'N' is defined somewhere - but I can't seem to find it.. so I
take it to mean
the maximum precision allowed by a FIXED BINARY, which would be 63???
I'm not
sure that matters as p2 would be 54 here... I sure would like to know
the definition
of 'N'.)

But, if you follow that rule - does it mean that the scale of the
intermediate result
is 332? 332 is much larger than the maximum scale (which is 127.) So
- how
is that handled? (Just an internal matter.. or?)

And - our result scale is 127 - so presumably the intermediate value
would have to be left-shifted 205 bits... which, I imagine, could cause
an OVERFLOW condition (if the result had any 1 bits at all) and could
only be satisfied without the possibility of a condition if D were 0.

Lastly - IBM provides a table of the values for calculating
CEIL(n*3.32), but
the table only seems to go up to 33. What about the other possible values?

- Dave Rivers -



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

[Robin Vowels]

On Mar 15, 7:37 am, Thomas David Rivers <riv...@dignus.com> wrote:
> In this example:
>
>  SMALL: PROC;
>
>    DCL I FIXED BIN(31,127);
>    DCL D FIXED DECIMAL(15,100);
>
>    I = D;
>
>  END SMALL;
>
> we have a conversion of a FIXED DECIMAL with a precision of 15 and a
> scale of 100,
> to a FIXED BINARY.  The FIXED BINARY has the maximum precision & scale
> allowed..
>
> FIrst question - the IBM Language Reference manual indicates that result
> (I'm assuming
> it means the intermediate result) is a FIXED BINARY(p2,q2) with these
> attributes:
>
>        The precision of the result is p2 = min(N,1+CEIL(p1*3.32)) and
>        q2=CEIL(ABS(q1*3.32))*SIGN(q1).
>
> (I guess 'N' is defined somewhere - but I can't seem to find it.. so I
> take it to mean
> the maximum precision allowed by a FIXED BINARY, which would be 63???
> I'm not
> sure that matters as p2 would be 54 here... I sure would like to know
> the definition
> of 'N'.)

N is the max. precision for fixed decimal;
M is the max. precision for fixed binary.
Look in the section "Results of Arithmetic Expressions".

> But, if you follow that rule - does it mean that the scale of the
> intermediate result
> is 332?   332 is much larger than the maximum scale (which is 127.)  So
> - how
> is that handled? (Just an internal matter.. or?)

The scale factor cannot exceed the maximum permitted.
You will need to do something to ensure that the limit
is not exceeded, such as pre-scaling and use of PRECISION, etc.

> And - our result scale is 127 - so presumably the intermediate value
> would have to be left-shifted 205 bits... which, I imagine, could cause
> an OVERFLOW condition (if the result had any 1 bits at all) and could
> only be satisfied without the possibility of a condition if D were 0.

Did you try compiling it?

[glen herrmannsfeldt]

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

> In this example:

> SMALL: PROC;

> DCL I FIXED BIN(31,127);
> DCL D FIXED DECIMAL(15,100);

> I = D;

> END SMALL;

> we have a conversion of a FIXED DECIMAL with a precision of 15 and a
> scale of 100, to a FIXED BINARY. The FIXED BINARY has the maximum
> precision & scale allowed..

> FIrst question - the IBM Language Reference manual indicates
> that result (I'm assuming it means the intermediate result) is
> a FIXED BINARY(p2,q2) with these attributes:

> The precision of the result is p2 = min(N,1+CEIL(p1*3.32)) and
> q2=CEIL(ABS(q1*3.32))*SIGN(q1).

I thought those were used when the rest of the attributes weren't
known.

> (I guess 'N' is defined somewhere - but I can't seem to find it..
> so I take it to mean the maximum precision allowed by a
> FIXED BINARY, which would be 63???

Used to be 31, but is probably 63 by now.

> I'm not sure that matters as p2 would be 54 here... I sure would
> like to know the definition of 'N'.)

Yes it is the maximum allowed, but I don't know if that is,
by now, 31 or 63 or even more.

> But, if you follow that rule - does it mean that the scale of the
> intermediate result is 332? 332 is much larger than the
> maximum scale (which is 127.) So - how
> is that handled? (Just an internal matter.. or?)

As well as I know it, when the destination precision and
scale are known, then there is no need for the table.

> And - our result scale is 127 - so presumably the intermediate value
> would have to be left-shifted 205 bits... which, I imagine, could cause
> an OVERFLOW condition (if the result had any 1 bits at all) and could
> only be satisfied without the possibility of a condition if D were 0.

Easy for the compiler, just test for zero, and either signal
FIXEDOVERFLOW or assign zero. (Unless FIXEDOVERFLOW is disabled.)

> Lastly - IBM provides a table of the values for calculating
> CEIL(n*3.32), but the table only seems to go up to 33.
> What about the other possible values?

It should just be the actual value of CEIL(n*3.32).
I seem to remember at one time that when the value would have
given extended precision, but just barely, there was a table
that rounded down just enough.

CEIL(3.32*33) is CEIL(109.56) or 110. When extended precision
has '1' for the leftmost hex digit it has 109 significant bits.

CEIL(16*3.32) is CEIL(53.12), just barely more than double
precision with a '1' leftmost hex digit. The table I remember
gives 53 instead of 54 for that case.

-- glen

[Robin Vowels]

On Mar 15, 9:07 am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Thomas David Rivers <riv...@dignus.com> wrote:
>
> > In this example:
> > SMALL: PROC;
> >   DCL I FIXED BIN(31,127);
> >   DCL D FIXED DECIMAL(15,100);
> >   I = D;
> > END SMALL;
> > we have a conversion of a FIXED DECIMAL with a precision of 15 and a
> > scale of 100, to a FIXED BINARY.  The FIXED BINARY has the maximum
> > precision & scale allowed..
> > FIrst question - the IBM Language Reference manual indicates
> > that result (I'm assuming it means the intermediate result) is
> > a FIXED BINARY(p2,q2) with these attributes:
> >       The precision of the result is p2 = min(N,1+CEIL(p1*3.32)) and
> >       q2=CEIL(ABS(q1*3.32))*SIGN(q1).
>
> I thought those were used when the rest of the attributes weren't
> known.

Look at "Source-to-target rules" for data conversions,
in which those ARE the quoted formulas.
The attributes ARE known (look at the declarations).

> > (I guess 'N' is defined somewhere - but I can't seem to find it..
> > so I take it to mean the maximum precision allowed by a
> > FIXED BINARY, which would be 63???
>
> Used to be 31, but is probably 63 by now.

Look in a current manual for the limits.

> > I'm not sure that matters as p2 would be 54 here... I sure would
> > like to know the definition of 'N'.)
>
> Yes it is the maximum allowed, but I don't know if that is,
> by now, 31 or 63 or even more.

Look in a current manual for the limits.

> > But, if you follow that rule - does it mean that the scale of the
> > intermediate result is 332?   332 is much larger than the
> > maximum scale (which is 127.)  So - how
> > is that handled? (Just an internal matter.. or?)
>
> As well as I know it, when the destination precision and
> scale are known, then there is no need for the table.

David R. quoted the relevant formulas above.
You can find them in the manual.

> > And - our result scale is 127 - so presumably the intermediate value
> > would have to be left-shifted 205 bits... which, I imagine, could cause
> > an OVERFLOW condition (if the result had any 1 bits at all) and could
> > only be satisfied without the possibility of a condition if D were 0.
>
> Easy for the compiler, just test for zero, and either signal
> FIXEDOVERFLOW or assign zero. (Unless FIXEDOVERFLOW is disabled.)

SIZE is enabled, and is raised in situations when FOFL is raised.

> > Lastly - IBM provides a table of the values for calculating
> > CEIL(n*3.32), but the table only seems to go up to 33.
> > What about the other possible values?
>
> It should just be the actual value of CEIL(n*3.32).

??? That's what the table would give.

> I seem to remember at one time that when the value would have
> given extended precision,

??? There was no such thing as "extended precision" for fixed-point.

> but just barely, there was a table
> that rounded down just enough.

Why not look in a manual to find out what actually happens?
instead of guessing.

> CEIL(3.32*33) is CEIL(109.56) or 110. When extended precision
> has '1' for the leftmost hex digit it has 109 significant bits.

What? Floating-point now? That's irrelevant.

> CEIL(16*3.32) is CEIL(53.12), just barely more than double
> precision with a '1' leftmost hex digit. The table I remember
> gives 53 instead of 54 for that case.

That's irrelevant. The operands are fixed-point.

[Robin Vowels]

On Mar 15, 7:37 am, Thomas David Rivers <riv...@dignus.com> wrote:
> In this example:
>
>  SMALL: PROC;
>
>    DCL I FIXED BIN(31,127);
>    DCL D FIXED DECIMAL(15,100);
>
>    I = D;
>
>  END SMALL;
>
> we have a conversion of a FIXED DECIMAL with a precision of 15 and a
> scale of 100,
> to a FIXED BINARY.  The FIXED BINARY has the maximum precision & scale
> allowed..
>
> FIrst question - the IBM Language Reference manual indicates that result
> (I'm assuming
> it means the intermediate result) is a FIXED BINARY(p2,q2) with these
> attributes:
>
>        The precision of the result is p2 = min(N,1+CEIL(p1*3.32)) and
>        q2=CEIL(ABS(q1*3.32))*SIGN(q1).
>
> (I guess 'N' is defined somewhere - but I can't seem to find it.. so I
> take it to mean
> the maximum precision allowed by a FIXED BINARY, which would be 63???
> I'm not
> sure that matters as p2 would be 54 here... I sure would like to know
> the definition of 'N'.)

It may help to envisage how the value is stored.
Your decimal value [assuming that there is an assignment somewhere]
is stored as an integer, and a separate value represents the
scale factor.

Your conversion is to integer (31,127), while your decimal value is
converted to binary integer, with scale factor of 332.

Now, thinking of the binary digits in each value, the binary
representation of D is well out-of-range of the the available
binary digits of I. Thus, the value of I can be safely assigned
the value 0.

For this assignment to do anything useful, binary digits of I
and of the intermediate binary value of D must line up.

Therefore, the precision of D must be (15, 38) or thereabouts.

[Thomas David Rivers]

Hi Robin,

Yeah - I think that's what I was alluding to... that nothing
more than a 0 value could be assigned to 'I'.

I'm just trying to get the abstract "path" right...

So, if I understand things correctly this is the semantic
definition:

1) D is converted to a FIXED BIN value with a scale factor of 332.

2) That FIXED BIN value is then rescaled to the scale of I,
which is 127. Thus, the value is shifted by 205 bits.

Does that seem correct according to the Language Reference?

If that is the proper semantic path, then when would any overflow
be recognized? (semantically, not necessarily practically).

Since there seems to be no semantic prohibition to a scale of 332,
there would be no problem converting D to this large FIXED BIN
value. It would fit...

Does that mean that there is an OVERFLOW recognized when
the "intermediate" FIXED BIN is shifted to the target scale?

- OR -

since, in this case, the target scale is known - is the semantic
path

1) Convert D to a FIXED BIN of scale 127 - the value in D might
not "fit" in the scale, so recognize the overflow then?

And, if one wanted to qualify the overflow further (I'm not sure
that's possible in PL/I) is this an overflow of a FIXED DECIMAL
value, or a FIXED BINARY value.

I'm just trying to nail things down - I suppose I should consult
the PL/I standard - I bet it speaks to this...

[John W Kennedy]

The ANSI PL/I standard apparently doesn't allow FIXED BIN(n,m) at all,
where m is not zero. The IBM PL/I standard was last updated in the late
60s, but is often a good guide for why a modern compiler does something
that seems strange.

--
John W Kennedy
"'Your art then,' said Vertue, 'seems to teach men that the best way of
being happy is to enjoy unbroken good fortune in every respect. They
would not all find the advice helpful.'"
-- C. S. Lewis. "The Pilgrim's Regress"

[Thomas David Rivers]

John W Kennedy wrote:

>
> The ANSI PL/I standard apparently doesn't allow FIXED BIN(n,m) at all,
> where m is not zero. The IBM PL/I standard was last updated in the
> late 60s, but is often a good guide for why a modern compiler does
> something that seems strange.
>

I think that may be the 'G' subset - the standard I have (ANSI INCITS
53-1976 (R1998) ) seems
to allow it... Section 4.4.3.5. Section 4.4.7, etc...

I'm not sure I understand what you mean by "IBM PL/I standard" - is
there a particular document
you're thinking of? (The IBM PL/I Language Reference manual?) My
original question originates
from that very document :-)

[Robin Vowels]

On Mar 16, 7:31 am, John W Kennedy <jwke...@attglobal.net> wrote:

> The ANSI PL/I standard apparently doesn't allow FIXED BIN(n,m) at all,
> where m is not zero. The IBM PL/I standard was last updated in the late
> 60s,

It has been updated as recently as last year.
Take a look at a current manual.

[Robin Vowels]

There is no shifting required.
Think of it another way.

For the intermediate value converted from D --
Think of there being 332 bits altogether after the binary point.
The binary digits from the converted value of D being at the right.
Think of I as a binary value of 127 bits after the binary point.
Now think of the binary points lining up.
Truncate all bits of the intermediate value to the right of the
127th binary digit.
What you have left is assigned to I.

>   Does that seem correct according to the Language Reference?
>
>   If that is the proper semantic path, then when would any overflow
>  be recognized?

Overflow CANNOT occur. It's the low-order bits of the
intermediate value that are being truncated.

 (semantically, not necessarily practically).
>
>   Since there seems to be no semantic prohibition to a scale of 332,
>  there would be no problem converting D to this large FIXED BIN
>  value.  It would fit...
>
>    Does that mean that there is an OVERFLOW recognized when
>  the "intermediate" FIXED BIN is shifted to the target scale?

The larger the scale factor, the smaller is the value involved.
Overflow can never occur in this program.

[John W Kennedy]

On 2013-03-15 21:06:58 +0000, Thomas David Rivers said:

> John W Kennedy wrote:
>
>>
>> The ANSI PL/I standard apparently doesn't allow FIXED BIN(n,m) at all,
>> where m is not zero. The IBM PL/I standard was last updated in the late
>> 60s, but is often a good guide for why a modern compiler does something
>> that seems strange.
>>
>
> I think that may be the 'G' subset - the standard I have (ANSI INCITS
> 53-1976 (R1998) ) seems
> to allow it... Section 4.4.3.5. Section 4.4.7, etc...
>
> I'm not sure I understand what you mean by "IBM PL/I standard" - is
> there a particular document
> you're thinking of? (The IBM PL/I Language Reference manual?) My
> original question originates
> from that very document :-)

Back in the 60s, IBM's PL/I (F) compiler for OS/360 originally had a
PL/I Language Specification and a Programmer's Guide, just like all
other compilers. But the Specification was a bit of a wish book, with
future features, many of which were never implemented, and was also
seen by many COBOL programmers trying to learn PL/I as too
inconveniently detailed. So around 1969, the Language Specification
manual was moved to the Y series of manuals for techies, and a new,
simpler PL/I (F) Language Reference Manual was created. All subsequent
IBM PL/I compilers have had rewrites of that old Language Reference
Manual, but the Language Specification Manual stopped being updated.
Unfortunately, that means that the only really detailed specification
of IBM PL/I is decades out of date (and out of print, too, I think),
while the Language Reference, though up-to-date, is frequently
inadequate. (ANSI PL/I, of course, is also outdated.)

I recommend, whenever you run into messy "language lawyer" situations,
that you find the Language Specification Manual on-line at
BitSavers.org and see what it has to say. It /may/ answer your
questions. (If you have the a good, fast, duplexing laser printer, you
might want to print it, because it's only a scan, and is therefore
impossible to search.)

--
John W Kennedy
"...if you had to fall in love with someone who was evil, I can see why
it was her."
-- "Alias"

[John W Kennedy]

You know you're lying. Stop it.

--
John W Kennedy
"...when you're trying to build a house of cards, the last thing you
should do is blow hard and wave your hands like a madman."
-- Rupert Goodwins

[glen herrmannsfeldt]

John W Kennedy <jwk...@attglobal.net> wrote:

(snip)

> Back in the 60s, IBM's PL/I (F) compiler for OS/360 originally had a
> PL/I Language Specification and a Programmer's Guide, just like all
> other compilers.

As I remember it, there are three. There is the Language Specification,
compiler independent description. I believe it is Language Reference
that describes it as implemented in a specific compiler and version,
and also Programmers Guide with more "how to use" and not so much
about the language.

> But the Specification was a bit of a wish book, with
> future features, many of which were never implemented, and was also
> seen by many COBOL programmers trying to learn PL/I as too
> inconveniently detailed. So around 1969, the Language Specification
> manual was moved to the Y series of manuals for techies, and a new,
> simpler PL/I (F) Language Reference Manual was created. All subsequent
> IBM PL/I compilers have had rewrites of that old Language Reference
> Manual, but the Language Specification Manual stopped being updated.
> Unfortunately, that means that the only really detailed specification
> of IBM PL/I is decades out of date (and out of print, too, I think),
> while the Language Reference, though up-to-date, is frequently
> inadequate. (ANSI PL/I, of course, is also outdated.)

-- glen

[Robin Vowels]

On Mar 16, 4:12 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

> John W Kennedy <jwke...@attglobal.net> wrote:
>
> (snip)
>
> > Back in the 60s, IBM's PL/I (F) compiler for OS/360 originally had a
> > PL/I Language Specification and a Programmer's Guide, just like all
> > other compilers.
>
> As I remember it, there are three.

No, only two.

> There is the Language Specification,
> compiler independent description. I believe it is Language Reference
> that describes it as implemented in a specific compiler and version,
> and also Programmers Guide with more "how to use" and not so much
> about the language.

The Programmer's Guide was not a Language Reference
in any shape or form. It included such things as
compiler options, optimisation considerations,
means of specifying files, compiler restrictions, and so on.

[Robin Vowels]

On Mar 16, 1:40 pm, John W Kennedy <jwke...@attglobal.net> wrote:

> You know you're lying. Stop it.

You sound like a baby. Is that all you can repeat?

[Peter J. Seymour]

Reminds me of an old joke. In Tudor London, The successive levels of
buildings often stepped out slightly, so that on the top floor there
could be quite an overhang and opposite building could almost meet. One
day, two women in opposite houses were arguing from top floor windows. A
passer-by remarks that those women will never agree, they are arguing
from different premises.

[Peter Flass]

On 3/15/2013 10:39 PM, John W Kennedy wrote:
> So around 1969, the Language Specification manual was moved to
> the Y series of manuals for techies, and a new, simpler PL/I (F)
> Language Reference Manual was created. All subsequent IBM PL/I compilers
> have had rewrites of that old Language Reference Manual, but the
> Language Specification Manual stopped being updated. Unfortunately, that
> means that the only really detailed specification of IBM PL/I is decades
> out of date (and out of print, too, I think)

Bitsavers has a couple of versions - I think the last G- version and one
of the Y- versions.

--
Pete

[glen herrmannsfeldt]

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

(snip)

> The Programmer's Guide was not a Language Reference
> in any shape or form. It included such things as
> compiler options, optimisation considerations,
> means of specifying files, compiler restrictions, and so on.

Well duh, I mean, it is the Programmer's Guide, and not the
Language Reference, so why should it be a Language Reference?

Still, useful to have around when using the language.

-- glen

[John W Kennedy]

On 2013-03-16 05:12:51 +0000, glen herrmannsfeldt said:

> John W Kennedy <jwk...@attglobal.net> wrote:
>
> (snip)
>> Back in the 60s, IBM's PL/I (F) compiler for OS/360 originally had a
>> PL/I Language Specification and a Programmer's Guide, just like all
>> other compilers.
>
> As I remember it, there are three. There is the Language Specification,
> compiler independent description. I believe it is Language Reference
> that describes it as implemented in a specific compiler and version,
> and also Programmers Guide with more "how to use" and not so much
> about the language.

That's what I go on to say. But that was later. All OS/360 compilers
except RPG (E) had a language manual and a programmer's guide, and,
from the first shipment, PL/I (F) was no exception. Originally, it had
Language Specification and Programmer's Guide, but sometime around
1969, PL/I got a third manual, Language Reference, a newly written
manual that defined the language up to a point, but eliminated
unimplemented features (good) and precise semantics (not so good). All
IBM 360-and-up PL/I compilers since then have had Language Reference
and Programmer's Guide.

--
John W Kennedy
"You can, if you wish, class all science-fiction together; but it is
about as perceptive as classing the works of Ballantyne, Conrad and W.
W. Jacobs together as the 'sea-story' and then criticizing _that_."
-- C. S. Lewis. "An Experiment in Criticism"

[Robin Vowels]

On Mar 16, 11:12 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu>
wrote:

> Robin Vowels <robin.vow...@gmail.com> wrote:
>
> > The Programmer's Guide was not a Language Reference
> > in any shape or form.  It included such things as
> > compiler options, optimisation considerations,
> > means of specifying files, compiler restrictions, and so on.
>
> Well duh, I mean, it is the Programmer's Guide, and not the
> Language Reference, so why should it be a Language Reference?

Well, you said it not me, that there were three,
and implicating the PG as [part of the language reference.

In point of fact, originally, there were only two
volumes, namely, the language reference, and the PG.

[John W Kennedy]

No, the Language Specification was first. The Language Reference came
out only around 1969.

And Glen did not say that the Programmer's Guide was a Language Reference.

      He was finding the answer to Aston Moffatt's last
      published letter difficult, yet he was determined
      that Moffatt could not be right.  He was beginning
      to twist the intention of the sentences in his
      authorities, preferring strange meanings and
      awkward constructions, adjusting evidence,
      manipulating words.  In defense of his conclusion
      he was willing to cheat in the evidence -- a habit
      more usual to religious writers than to historical.
                    -- Charles Williams, "Descent into Hell"

--
John W Kennedy
"The grand art mastered the thudding hammer of Thor
And the heart of our lord Taliessin determined the war."
-- Charles Williams. "Mount Badon"

[Shmuel Metz]

In <51438D72...@dignus.com>, on 03/15/2013

at 05:06 PM, Thomas David Rivers <riv...@dignus.com> said:

>John W Kennedy wrote:

>>
>> The ANSI PL/I standard apparently doesn't allow FIXED BIN(n,m) at all,
>> where m is not zero. The IBM PL/I standard was last updated in the
>> late 60s, but is often a good guide for why a modern compiler does
>> something that seems strange.
>>

>I think that may be the 'G' subset

Maybe 1976 - certainly not 1987.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spam...@library.lspace.org

[Shmuel Metz]

In <51438518$0$19547$607e...@cv.net>, on 03/15/2013

at 04:31 PM, John W Kennedy <jwk...@attglobal.net> said:

>The ANSI PL/I standard apparently doesn't allow FIXED BIN(n,m) at
>all,

What ANSI standard? X3.74-1987 certainly does.

[Peter Flass]

On 3/17/2013 6:12 PM, Shmuel (Seymour J.) Metz wrote:
> In <51438518$0$19547$607e...@cv.net>, on 03/15/2013
> at 04:31 PM, John W Kennedy <jwk...@attglobal.net> said:
>
>> The ANSI PL/I standard apparently doesn't allow FIXED BIN(n,m) at
>> all,
>
> What ANSI standard? X3.74-1987 certainly does.
>

I believe subset G doesn't allow scaled fixed binary.

--
Pete

[John W Kennedy]

If the one allows it and the other doesn't, then it cannot be, strictu
sensu, a subset. (I lack direct knowledge; I have never held a
definition of either.)

--
John W Kennedy
If Bill Gates believes in "intelligent design", why can't he apply it
to Windows?

[Peter Flass]

On 3/18/2013 9:25 AM, John W Kennedy wrote:
> On 2013-03-18 11:48:40 +0000, Peter Flass said:
>
>> On 3/17/2013 6:12 PM, Shmuel (Seymour J.) Metz wrote:
>>> In <51438518$0$19547$607e...@cv.net>, on 03/15/2013
>>> at 04:31 PM, John W Kennedy <jwk...@attglobal.net> said:
>>>
>>>> The ANSI PL/I standard apparently doesn't allow FIXED BIN(n,m) at
>>>> all,
>>>
>>> What ANSI standard? X3.74-1987 certainly does.
>>>
>>
>> I believe subset G doesn't allow scaled fixed binary.
>
> If the one allows it and the other doesn't, then it cannot be, strictu
> sensu, a subset. (I lack direct knowledge; I have never held a
> definition of either.)
>

They're not - for example "G" includes the SELECT statement and "Full
PL/I" doesn't.

--
Pete

[Robin Vowels]

On Mar 16, 1:39 pm, John W Kennedy <jwke...@attglobal.net> wrote:

> So around 1969, the Language Specification
> manual was moved to the Y series of manuals for techies, and a new,
> simpler PL/I (F) Language Reference Manual was created.

IBM's S/360 PL/I Reference Manual was first published 1967,
replacing the earlier manual which was for the language
envisaged by IBM. This new manual "PROVIDES THE RULES FOR
WRITING PL/I PROGRAMS" [emphasis added] under PL/I (F).
It was not necessary to refer to any other language manual,
including the original PL/I Language specifications, which was already
obsolete. You will probably find that the text is the same
as the earlier manual for those features that were implemented.

> All subsequent
> IBM PL/I compilers have had rewrites of that old Language Reference
> Manual, but the Language Specification Manual stopped being updated.
> Unfortunately, that means that the only really detailed specification
> of IBM PL/I is decades out of date (and out of print, too, I think),

The Language Reference is sufficiently detailed to enable
the writing of programs. It is, after all, a PL/I Language
specification manual.

[Shmuel Metz]

In <ki7i5r$kjb$1...@dont-email.me>, on 03/18/2013

at 01:24 PM, Peter Flass <Peter...@Yahoo.com> said:

>They're not - for example "G" includes the SELECT statement and "Full
> PL/I" doesn't.

1976 or 1987?

[Shmuel Metz]

In <ki6uij$aj$1...@dont-email.me>, on 03/18/2013

X3.74-1987 *is* subset G. I don't recall what the 1976 version
allowed.

[Peter Flass]

On 3/18/2013 10:15 PM, Shmuel (Seymour J.) Metz wrote:
> In <ki6uij$aj$1...@dont-email.me>, on 03/18/2013
> at 07:48 AM, Peter Flass <Peter...@Yahoo.com> said:
>
>> On 3/17/2013 6:12 PM, Shmuel (Seymour J.) Metz wrote:
>>> In <51438518$0$19547$607e...@cv.net>, on 03/15/2013
>>> at 04:31 PM, John W Kennedy <jwk...@attglobal.net> said:
>>>
>>>> The ANSI PL/I standard apparently doesn't allow FIXED BIN(n,m) at
>>>> all,
>>>
>>> What ANSI standard? X3.74-1987 certainly does.
>>>
>
>> I believe subset G doesn't allow scaled fixed binary.
>
> X3.74-1987 *is* subset G. I don't recall what the 1976 version
> allowed.
>

I have -1987. "A nonzero scale factor may be specified only for FIXED
DECIMAL values." (p.417)

SELECT is not in X3.53-1976 "Full" PL/I.

--
Pete