PICSPEC question

[Roger Henn]

OK, can anyone explain why this fragment:
PICSPEC (SUBSTR (TRACKING_CODE, INX, 1), '9')
produces this error (Enterprise PL/I for z/OS V4.R1.M0):
IBM2183I S 387 The first argument to PICSPEC built-in must have
constant length equal to that of the second argument.

The actual logic is something like:
DCL WORK FIXED DEC (31) INIT (0);
DCL TRACKING_CODE CHAR (20);
DCL INX FIXED BIN (31);
DO INX = 1 TO LENGTH (TRACKING_CODE);
WORK = WORK * 5 + PICSPEC (SUBSTR (TRACKING_CODE, INX, 1), '9');
END;

I thought 1 was a constant.

[John W Kennedy]

Neither the modern manual nor the Optimizer manual specifies anything
one way or the other, but the 60s manual (the abstract one, not the (F)
documentation) says expressly that the result of SUBSTR is always
VARYING. 1 being a constant doesn't change that.

Unfortunately, all modern PL/I documentation is vague, and all precise
PL/I documentation has gone without revision since the 60s. A pity,
seeing that PL/I was the first language to be decently documented, but
there you are.

--
John W Kennedy
"The first effect of not believing in God is to believe in anything...."
-- Emile Cammaerts, "The Laughing Prophet"

[Robin Vowels]

On Dec 22, 10:17 am, John W Kennedy <jwke...@attglobal.net> wrote:
> On 2012-12-21 18:03:21 +0000, Roger Henn said:
>
> > OK, can anyone explain why this fragment:
> > PICSPEC (SUBSTR (TRACKING_CODE, INX, 1), '9')
> > produces this error (Enterprise PL/I for z/OS V4.R1.M0):
> > IBM2183I S 387 The first argument to PICSPEC built-in must have
> >                constant length equal to that of the second argument.
>
> > The actual logic is something like:
> > DCL WORK FIXED DEC (31) INIT (0);
> > DCL TRACKING_CODE CHAR (20);
> > DCL INX FIXED BIN (31);
> > DO INX = 1 TO LENGTH (TRACKING_CODE);
> >   WORK = WORK * 5 + PICSPEC (SUBSTR (TRACKING_CODE, INX, 1), '9');
> > END;
>
> > I thought 1 was a constant.
>
> Neither the modern manual nor the Optimizer manual specifies anything
> one way or the other, but the 60s manual (the abstract one, not the (F)
> documentation) says expressly that the result of SUBSTR is always
> VARYING. 1 being a constant doesn't change that.

Well researched.
I think that that early IBM documentation is not applicable,
as the current IBM compiler is the third completely
different compiler from PL/I-F of 1966.

In the case of the IBM compiler here, it looks like an
implementation restriction. I see no reason why SUBSTR
should return anything other than NONVARYING string
when the third argument is a constant.

It looks like the requirement of PICSPEC (insisting on a
fixed-length string) is likewise an implementation restriction, merely
to simplify code generation.

> Unfortunately, all modern PL/I documentation is vague, and all precise
> PL/I documentation has gone without revision since the 60s. A pity,
> seeing that PL/I was the first language to be decently documented, but
> there you are.

I think that you will find that the Kednos PL/I documentation
is precise.

[John W Kennedy]

Robin Vowels <robin....@gmail.com> wrote:
> On Dec 22, 10:17 am, John W Kennedy <jwke...@attglobal.net> wrote:
>> On 2012-12-21 18:03:21 +0000, Roger Henn said:
>>
>>> OK, can anyone explain why this fragment:
>>> PICSPEC (SUBSTR (TRACKING_CODE, INX, 1), '9')
>>> produces this error (Enterprise PL/I for z/OS V4.R1.M0):
>>> IBM2183I S 387 The first argument to PICSPEC built-in must have
>>> constant length equal to that of the second argument.
>>
>>> The actual logic is something like:
>>> DCL WORK FIXED DEC (31) INIT (0);
>>> DCL TRACKING_CODE CHAR (20);
>>> DCL INX FIXED BIN (31);
>>> DO INX = 1 TO LENGTH (TRACKING_CODE);
>>> WORK = WORK * 5 + PICSPEC (SUBSTR (TRACKING_CODE, INX, 1), '9');
>>> END;
>>
>>> I thought 1 was a constant.
>>
>> Neither the modern manual nor the Optimizer manual specifies anything
>> one way or the other, but the 60s manual (the abstract one, not the (F)
>> documentation) says expressly that the result of SUBSTR is always
>> VARYING. 1 being a constant doesn't change that.
>
> Well researched.
> I think that that early IBM documentation is not applicable,
> as the current IBM compiler is the third completely
> different compiler from PL/I-F of 1966.

What part of my statement that this was /not/ documentation for the F
compiler didn’t you understand? This is IBM's official description of the
PL/I language, and, although it's decades out of date, it has never been
revised.

> In the case of the IBM compiler here, it looks like an
> implementation restriction. I see no reason why SUBSTR
> should return anything other than NONVARYING string
> when the third argument is a constant.
>
> It looks like the requirement of PICSPEC (insisting on a
> fixed-length string) is likewise an implementation restriction, merely
> to simplify code generation.

That’s your explanation for everything, and, as usual, you’re off-base. In
order for the first operand of PICSPEC to be VARYING, it is necessary for
the second operand to be a run-time string variable, which could be sanely
done only out-of-line, which in itself is trivial from a code-generation
viewpoint, but which means in turn that the type, precision, and scale of
the expression all become unknown at compile time, which opens the same
rat's nest that assigning from CHARACTER to numeric did, only worse, since
the CHARACTER case at least allowed of arbitrary defaults.

If you want a language that is interpreted at runtime, I suggest REXX in
the IBM world, or Ruby elsewhere. PL/I is designed to be compiled.

>> Unfortunately, all modern PL/I documentation is vague, and all precise
>> PL/I documentation has gone without revision since the 60s. A pity,
>> seeing that PL/I was the first language to be decently documented, but
>> there you are.
>
> I think that you will find that the Kednos PL/I documentation
> is precise.

No it isn’t. Indeed, on this particular issue, it’s flat wrong, seeing that
the plain reading of it is that the result of SUBSTR is NONVARYING, which
is absurd.

If you want to see a precise language specification, look at the ULD, or at
the Ada Language Reference. IBM's PL/I Language Reference manuals since
1970 fall somewhere between precise and "Mister Blobby's Fun with PL/I".

[Peter J. Seymour]

On 2012-12-23 15:40, John W Kennedy wrote:
.....

I must be missing something here, why do you consider that F-level
compiler documentation overrides all later documentation? Personally, I
don't remember being that impressed with the F-level manuals.

[John W Kennedy]

For the third time, I am talking about the Language Specification
Manual, which is of the F era, but, in its final editions, was not
explicitly associated with that or any other compiler; it was replaced
as F-compiler documentation by the newer (F) Language Reference Manual.
No PL/I compiler, in fact, ever implemented this exact form of the
language. (For example, the CELL attribute -- similar to the modern
UNION -- was never made available.)

And I am not saying that it overrides more recent documentation; I am
saying that on many questions of detail, more recent manuals are
silent, leaving it and the ULD as the only fallback source. That is a
Bad Thing. But I can't make IBM write better documentation. I'm not an
IBM customer. I'm not even an employee of an IBM customer anymore. I'm
just a guy who regularly used a lot of PL/I from 1968 to 1997, and
tries to keep up.

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

[James J. Weinkam]

As others have already noted, the compiler apparently treats the result of substr as varying which seems silly, but
there you go.

The following will work around the problem:

dcl work fixed dec(31),tc char(20),i bin fixed(31),p ptr,d pic'9' based(p),addr builtin;
p=addr(tc); do i=1 to 20; work=work*5+d; p+=1; end;

In fact if your problem is really as simple as your example you could just

do i=1 to 20; work=work*5+substr(tc,i,1); end;

[Shmuel Metz]

In
<548241885377966994.3252...@news.optonline.net>,
on 12/23/2012

at 03:40 PM, John W Kennedy <jwk...@attglobal.neg> said:

>What part of my statement that this was /not/ documentation for the F
>compiler didn t you understand?

When was the last time you saw anything useful out of robin?

>This is IBM's official description of the PL/I language, and,
>although it's decades out of date, it has never been revised.

Yes and no. AFAIK there's never been an official IBM update, but there
were three editions of the "Vienna Telephone Directory" plus the ANSI
standard.

>IBM's PL/I Language Reference manuals since 1970 fall somewhere
>between precise and "Mister Blobby's Fun with PL/I".

I found IBM's PL/I documentation in the 1960's and 1970's to be far
better than the dog's breakfast they served up for FORTRAN. The
VSFORTRAN documentation was particularly galling because IBM had
promised to improve documentation quality before going OCO.

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

[Robin Vowels]

On Dec 24, 2:40 am, John W Kennedy <jwke...@attglobal.neg> wrote:

What part of my statement "I think that that early IBM
documentation is not applicable" did you not understand?

> This is

was

> IBM's official description of the
> PL/I language, and, although it's decades out of date, it has never been
> revised.
>
> > In the case of the IBM compiler here, it looks like an
> > implementation restriction. I see no reason why SUBSTR
> > should return anything other than NONVARYING string
> > when the third argument is a constant.
>
> > It looks like the requirement of PICSPEC (insisting on a
> > fixed-length string) is likewise an implementation restriction, merely
> > to simplify code generation.
>
> That’s your explanation for everything,

You're talking nonsense, which is amply evident from your
next sentence.

> and, as usual, you’re off-base.

Don't make silly statements.

> In order for the first operand of PICSPEC to be VARYING, it is necessary for
> the second operand to be a run-time string variable,

Obviously you don't understand the meaning of VARYING.
The requirement is that both arguments are to be the same length.

> which could be sanely
> done only out-of-line, which in itself is trivial from a code-generation
> viewpoint, but which means in turn that the type, precision, and scale of
> the expression all become unknown at compile time, which opens the same
> rat's nest that assigning from CHARACTER to numeric did, only worse, since
> the CHARACTER case at least allowed of arbitrary defaults.

You have absolutely no idea what you are talking about.

> If you want a language that is interpreted at runtime, I suggest REXX in
> the IBM world, or Ruby elsewhere. PL/I is designed to be compiled.

(But it can also be interpreted.)

> >> Unfortunately, all modern PL/I documentation is vague, and all precise
> >> PL/I documentation has gone without revision since the 60s. A pity,
> >> seeing that PL/I was the first language to be decently documented, but
> >> there you are.

Some would say the honor of being the first
decently-documented language belongs to ALGOL.

> > I think that you will find that the Kednos PL/I documentation
> > is precise.
>
> No it isn’t. Indeed, on this particular issue, it’s flat wrong, seeing that
> the plain reading of it is that the result of SUBSTR is NONVARYING, which
> is absurd.

No it isn't. It's painfuly clear that you don't inderstand the
meaning of the attribute VARYING.

The KEDNOS documentation on SUBSTR is correct for KEDNOS.
The length of the string delivered by SUBSTR
is of one and only one length, regardless of how that
length is specified (as either constant or expression).
Thus that string is quite capable of being represented as
CHARACTER.
In point of fact, in general, SUBSTR could return either a
NONVARYING or VARYING string. The only difference is in the
way in which the string is represented in storage.

> If you want to see a precise language specification, look at the ULD, or at
> the Ada Language Reference. IBM's PL/I Language Reference manuals since

> 1970 fall somewhere between precise and "Mister Blobby's Fun with PL/I".- Hide quoted text -

Are you just having a bad day?

[Peter J. Seymour]

On 2012-12-24 04:06, John W Kennedy wrote:
> On 2012-12-23 22:09:00 +0000, Peter J. Seymour said:
>
>> On 2012-12-23 15:40, John W Kennedy wrote:
>> .....
>>
>> I must be missing something here, why do you consider that F-level
>> compiler documentation overrides all later documentation? Personally,
>> I don't remember being that impressed with the F-level manuals.
>
> For the third time, I am talking about the Language Specification
> Manual, which is of the F era, but, in its final editions, was not
> explicitly associated with that or any other compiler; it was replaced
> as F-compiler documentation by the newer (F) Language Reference Manual.
> No PL/I compiler, in fact, ever implemented this exact form of the
> language. (For example, the CELL attribute -- similar to the modern
> UNION -- was never made available.)
>
> And I am not saying that it overrides more recent documentation; I am
> saying that on many questions of detail, more recent manuals are silent,
> leaving it and the ULD as the only fallback source. That is a Bad Thing.
> But I can't make IBM write better documentation. I'm not an IBM
> customer. I'm not even an employee of an IBM customer anymore. I'm just
> a guy who regularly used a lot of PL/I from 1968 to 1997, and tries to
> keep up.
>

OK, I am with you now, there is Y33-6003 which is a language definition
manual. Presumably no update was considered necessary as the language
definition had been palmed off to an outside body. I remember that for
many years IBM insisted that they could not update their implemented
compilers as they did not control the standard and did not want to be
seen to exercise any initiative. It resulted in a customer management
drift away from PL/I.

[Peter Flass]

On 12/23/2012 11:29 PM, James J. Weinkam wrote:
> Roger Henn wrote:
>> OK, can anyone explain why this fragment:
>> PICSPEC (SUBSTR (TRACKING_CODE, INX, 1), '9')
>> produces this error (Enterprise PL/I for z/OS V4.R1.M0):
>> IBM2183I S 387 The first argument to PICSPEC built-in must have
>> constant length equal to that of the second argument.
>>
>> The actual logic is something like:
>> DCL WORK FIXED DEC (31) INIT (0);
>> DCL TRACKING_CODE CHAR (20);
>> DCL INX FIXED BIN (31);
>> DO INX = 1 TO LENGTH (TRACKING_CODE);
>> WORK = WORK * 5 + PICSPEC (SUBSTR (TRACKING_CODE, INX, 1), '9');
>> END;
>>
>> I thought 1 was a constant.
>
> As others have already noted, the compiler apparently treats the result
> of substr as varying which seems silly, but there you go.

It does seem silly. That's an incompatibility with Iron Spring PL/I,
which treats all SUBSTR results as nonvarying, either adjustable or
non-adjustable.

--
Pete

[Peter Flass]

On 12/23/2012 11:06 PM, John W Kennedy wrote:
> On 2012-12-23 22:09:00 +0000, Peter J. Seymour said:
>
>> On 2012-12-23 15:40, John W Kennedy wrote:
>> .....
>>
>> I must be missing something here, why do you consider that F-level
>> compiler documentation overrides all later documentation? Personally,
>> I don't remember being that impressed with the F-level manuals.
>
> For the third time, I am talking about the Language Specification
> Manual, which is of the F era, but, in its final editions, was not
> explicitly associated with that or any other compiler; it was replaced
> as F-compiler documentation by the newer (F) Language Reference Manual.
> No PL/I compiler, in fact, ever implemented this exact form of the
> language. (For example, the CELL attribute -- similar to the modern
> UNION -- was never made available.)

Another incompatibility with Iron Spring PL/I, and others. I think
Multics PL/I and VAX PL/I support CELL.

>
> And I am not saying that it overrides more recent documentation; I am
> saying that on many questions of detail, more recent manuals are silent,
> leaving it and the ULD as the only fallback source. That is a Bad Thing.
> But I can't make IBM write better documentation. I'm not an IBM
> customer. I'm not even an employee of an IBM customer anymore. I'm just
> a guy who regularly used a lot of PL/I from 1968 to 1997, and tries to
> keep up.
>

What has bothered me is I've seen the same things carried forward in the
manuals for each new compiler, typos, inconsistencies, vague
descriptions, missing punctuation in diagrams, etc. At some point I
submitted a couple of reader's comments, but I haven't gotten back to
see if anything has been fixed.


--
Pete

[John W Kennedy]

Slowly and painfully, IBM has been shifting to ANSI PL/I, but what they
implement is still more or less IBM PL/I with optional ANSI features. And
it doesn't help that, while this has been going on, the de-facto standard
of IBM PL/I has continued to evolve without being published. And in the
meantime, since neither IBM nor ANSI has any interest in upgrading their
standards, real advances, like OO, or a clear resolution of the
boolean/short-circuit issue, are blocked.

[John W Kennedy]

Well, that will work, but it will produce vile object code.

[John W Kennedy]

You're an idiot. Shut up.

[Shmuel Metz]

In <kb9j3u$mcs$1...@dont-email.me>, on 12/24/2012

at 07:57 AM, Peter Flass <Peter...@Yahoo.com> said:

>At some point I submitted a couple of reader's comments, but I
>haven't gotten back to see if anything has been fixed.

I've gotten good responses from the PL/I people; in some cases, the
proposed text for the next edition of the manual I was commenting on.

The OS/360 Utilities authors, OTOH, were dreadful.

[Peter J. Seymour]

On 2012-12-24 14:40, John W Kennedy wrote:
.....

> Slowly and painfully, IBM has been shifting to ANSI PL/I, but what they
> implement is still more or less IBM PL/I with optional ANSI features. And
> it doesn't help that, while this has been going on, the de-facto standard
> of IBM PL/I has continued to evolve without being published. And in the
> meantime, since neither IBM nor ANSI has any interest in upgrading their
> standards, real advances, like OO, or a clear resolution of the
> boolean/short-circuit issue, are blocked.
>

Going on my experience of OO in java, I'm not too bothered about its
absence in PL/I. Structures and arrays of structures go a long way to
making it unnecessary. OO seems to provide an easy way of making
programs woefully complex and inefficient.

[Peter J. Seymour]

Getting back to the original topic, I was not familiar with PICSPEC so I
had to look it up. The situation looks to me like lazy
design/implementation. Why would PICSPEC require a fixed length first
argument?

As to SUBSTR. I recall that the Optimising Compiler had a dual
implementation of it. If the length was fixed and less that 256 (I think
it was that value) the reference was implemented efficiently inline as a
fixed value. Otherwise, if it was longer or the field was VARYING a
library call was used. It shouldn't matter what happens under the hood
if there is no possibility of side effects.

[Roger Henn]

Well, the shop I'm in is just now converting to Enterprise PL/I, and they're somewhat hyper about some of the warning messages from the 'new' compiler. That last causes a message about library calls that's against what they loosely call "standards" (most of which are based more on old COBOL standards than anything to do with PL/I. The rest don't seem to be documented at all).

Their usual way to get rid of it is to move the CHAR value to an intermediate CHAR variable that has a PIC variable overlaid on it, then use the PIC variable. I was just trying to get rid of the extra data movement, without using UNSPEC, which ist verboten. I hadn't seen PICPSEC before, which looked like it might be worth a try, but apparently not.

[Peter Flass]

On 12/24/2012 12:57 PM, Peter J. Seymour wrote:
> On 2012-12-21 18:03, Roger Henn wrote:
>> OK, can anyone explain why this fragment:
>> PICSPEC (SUBSTR (TRACKING_CODE, INX, 1), '9')
>> produces this error (Enterprise PL/I for z/OS V4.R1.M0):
>> IBM2183I S 387 The first argument to PICSPEC built-in must have
>> constant length equal to that of the second argument.
>>
>> The actual logic is something like:
>> DCL WORK FIXED DEC (31) INIT (0);
>> DCL TRACKING_CODE CHAR (20);
>> DCL INX FIXED BIN (31);
>> DO INX = 1 TO LENGTH (TRACKING_CODE);
>> WORK = WORK * 5 + PICSPEC (SUBSTR (TRACKING_CODE, INX, 1), '9');
>> END;
>>
>> I thought 1 was a constant.
>>
> Getting back to the original topic, I was not familiar with PICSPEC so I
> had to look it up. The situation looks to me like lazy
> design/implementation. Why would PICSPEC require a fixed length first
> argument?

I had to look it up too. It doesn't convert, it "redefines" the
argument as pictured type, so the source length and the picture length
have to match.

--
Pete

[Peter J. Seymour]

In the "good old days" we used to do something like

DCL P1 PIC'99999';
DCL C1 CHAR(5) DEF P1;
(not sure if that is the exact syntax, if might have to be
BASED(ADDR(P1)) ).

However, I'm signing off for a few days - it's Christmas.

[James J. Weinkam]

Peter Flass wrote:
> I had to look it up too. It doesn't convert, it "redefines" the argument as pictured type, so the source length and the
> picture length have to match.
>

Yeah. In other words, it's basically the same as defining but without the warning message about mismatched types.

[James J. Weinkam]

Roger Henn wrote:
> Their usual way to get rid of it is to move the CHAR value to an intermediate CHAR variable that has a

PIC variable overlaid on it, then use the PIC variable. I was just trying to get rid of the extra data

movement, without using UNSPEC, which ist verboten. I hadn't seen PICPSEC before, which looked like it

might be worth a try, but apparently not.

Well in that case define a 20 element pic'9' array on the 20 character string. No extra data movement.

[John W Kennedy]

Then you've never seriously used OO for a serious project. GUI,
collection classes, simulation, and many other common functions are
infinitely simplified by OO. Why do you suppose virtually every
existing language received OO extensions or had OO derivatives within
about five years? (I still remember the GOTO wars, and the
assembler-vs-compiler wars before that.)

--
John W Kennedy
"There are those who argue that everything breaks even in this old dump
of a world of ours. I suppose these ginks who argue that way hold that
because the rich man gets ice in the summer and the poor man gets it in
the winter things are breaking even for both. Maybe so, but I'll swear
I can't see it that way."
-- The last words of Bat Masterson

[Robin Vowels]

> > Are you just having a bad day?
>
> You're an idiot. Shut up.

Look, you bad-tempered old man. You're the idiot around here.
You have demonstrated your next-to-nothing knowledge of
PL/I with your glib remarks on how it works.

I wrote an optimising compiler for PL/I,
and I did some optimised code generation for the XPL compiler.

And no, I won't shup up. It's you who needs to shut up.

[Robin Vowels]

Not sure what you mean about adjustable and non-adjustable
non-varying strings.
A non-varying string has only one length.

[Robin Vowels]

On Dec 25, 1:40 am, John W Kennedy <jwke...@attglobal.neg> wrote:

> Slowly and painfully, IBM has been shifting to ANSI PL/I, but what they
> implement is still more or less IBM PL/I with optional ANSI features. And
> it doesn't help that, while this has been going on, the de-facto standard
> of IBM PL/I has continued to evolve without being published.

Look at the current IBM Language Reference,
published within the past two years.

[Robin Vowels]

On Dec 25, 5:27 am, Roger Henn <rogerjh...@gmail.com> wrote:

> Well, the shop I'm in is just now converting to Enterprise PL/I, and they're somewhat hyper about some of the warning messages from the 'new' compiler. That last causes a message about library calls that's against what they loosely call "standards" (most of which are based more on old COBOL standards than anything to do with PL/I. The rest don't seem to be documented at all).
>
> Their usual way to get rid of it is to move the CHAR value to an intermediate CHAR variable that has a PIC variable overlaid on it, then use the PIC variable. I was just trying to get rid of the extra data movement, without using UNSPEC, which ist verboten. I hadn't seen PICPSEC before, which looked like it might be worth a try, but apparently not.

UNION would be an appropriate mechanism, which avoids the
need for data movement.

[Robin Vowels]

On Dec 25, 8:33 am, "Peter J. Seymour" <Newsgro...@pjsey.demon.co.uk>
wrote:

A better way is to use UNION.

[Peter Flass]

Non-adjustable has a known constant length. Adjustable is fixed-length,
but the length is known only at run time.

--
Pete

[John W Kennedy]

...which is hopelessly vague and ambiguous, which is how this whole
stupid thread started.

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

[John W Kennedy]

No it is not. UNION is a blunt instrument that should be used only as a
last resort.

[Peter J. Seymour]

On 2012-12-24 22:33, John W Kennedy wrote:
> On 2012-12-24 17:39:50 +0000, Peter J. Seymour said:
>
>> On 2012-12-24 14:40, John W Kennedy wrote:
>> .....
>>> Slowly and painfully, IBM has been shifting to ANSI PL/I, but what they
>>> implement is still more or less IBM PL/I with optional ANSI features.
>>> And
>>> it doesn't help that, while this has been going on, the de-facto
>>> standard
>>> of IBM PL/I has continued to evolve without being published. And in the
>>> meantime, since neither IBM nor ANSI has any interest in upgrading their
>>> standards, real advances, like OO, or a clear resolution of the
>>> boolean/short-circuit issue, are blocked.
>>>
>> Going on my experience of OO in java, I'm not too bothered about its
>> absence in PL/I. Structures and arrays of structures go a long way to
>> making it unnecessary. OO seems to provide an easy way of making
>> programs woefully complex and inefficient.
>
> Then you've never seriously used OO for a serious project. GUI,
> collection classes, simulation, and many other common functions are
> infinitely simplified by OO. Why do you suppose virtually every existing
> language received OO extensions or had OO derivatives within about five
> years? (I still remember the GOTO wars, and the assembler-vs-compiler
> wars before that.)
>

Eh? I don't believe in war.

[John W Kennedy]

"Peter J. Seymour" <Newsg...@pjsey.demon.co.uk> wrote:

“Believe in” is an ambiguous phrase.

[Peter J. Seymour]

Correct. I mean in the sense I don't see it as a desirable form of
conflict resolution (at any level). Personally, I never saw assembler v.
PL/I as a conflict anyway. I have quite happily used both. In
straightforward commercial data processing situations, IBM mainframe
assembler can be quite productive. For me, GOTO was never an issue.
"Flowcharted" programs I had to deal with were an unwelcome morass.
Consequently, IBM's IPT (Improved Programming Techniques) with goto-less
programming was wholeheartedly taken on board by myself and my
colleagues. It resulted in a leap in productivity. I later made use of
labelled LEAVE statements to produce interesting code but that is
another story.

[John W Kennedy]

If you did not /witness/ these quarrels, you're younger than I. There
was a time when compilers were rejected by some as a waste of machine
time (although FORTRAN generally did better than other languages), and
the suggestion that GOTO might be better done without brought out the
wrath of some people like gun control on a "militia" member. (Heck,
when the 360/44 came out, there were still enough people who hated the
very idea of using disk instead of tape that IBM included the option of
a little disk drive [borrowed from the 1130] inside the CPU just to
host the OS on.)

--
John W Kennedy
"Though a Rothschild you may be
In your own capacity,
As a Company you've come to utter sorrow--
But the Liquidators say,
'Never mind--you needn't pay,'
So you start another company to-morrow!"
-- Sir William S. Gilbert. "Utopia Limited"

[Shmuel Metz]

In <mH%Cs.430044$kX.1...@fx18.am4>, on 12/27/2012
at 05:37 PM, "Peter J. Seymour" <Newsg...@pjsey.demon.co.uk>
said:

>Personally, I never saw assembler v. PL/I as a conflict anyway.
>I have quite happily used both.

I've written both for the same program. It's a bit harder these days,
at least with IBM compilers, because the mapping macros may not be
available.

As for GOTO, the problem is that some things cannot[1] ne done without
GOTO, and others are actually less maintainable without GOTO. You have
to carve the bird at the joint.

[1] Don't cite B&J; read it and note carefully what it applies to.

[Peter J. Seymour]

On 2012-12-27 20:53, Shmuel (Seymour J.) Metz wrote:
> In <mH%Cs.430044$kX.1...@fx18.am4>, on 12/27/2012
> at 05:37 PM, "Peter J. Seymour" <Newsg...@pjsey.demon.co.uk>
> said:
>
>> Personally, I never saw assembler v. PL/I as a conflict anyway.
>> I have quite happily used both.
>
> I've written both for the same program. It's a bit harder these days,
> at least with IBM compilers, because the mapping macros may not be
> available.
>
> As for GOTO, the problem is that some things cannot[1] ne done without
> GOTO, and others are actually less maintainable without GOTO. You have
> to carve the bird at the joint.
>
> [1] Don't cite B&J; read it and note carefully what it applies to.
>

I'm not against branching in programs(!), but if I can do what I want
without a goto then I prefer it that way.

What is B&J ?

[John W Kennedy]

"Peter J. Seymour" <Newsg...@pjsey.demon.co.uk> wrote:

That would be the Böhm-Jacopini theorem, also known as the Structured
Programming theorem, which proved that GOTO is never necessary on any
Turing-complete system. I suppose he means that the method used in the
Böhm-Jacopini proof results in some awkward and inefficient code. But the
Böhm-Jacopini proof is like a Turing machine; it’s a proof of concept, not
a piece of engineering. Practical methods of avoiding GOTOs have advanced
far beyond it, especially when license is given to use SELECT/WHEN and
LEAVE.

[Shmuel Metz]

In <0LdDs.952755$W63.7...@fx05.am4>, on 12/28/2012
at 09:36 AM, "Peter J. Seymour" <Newsg...@pjsey.demon.co.uk>
said:

>What is B&J ?

Bohm, Corrado; and Giuseppe Jacopini (May 1966). "Flow Diagrams,
Turing Machines and Languages with Only Two Formation Rules".
Communications of the ACM 9 (5): 366?371. doi:10.1145/355592.365646

A paper often cited by those who have not read and understood it. It's
an important paper, and the authors are not to blame for those who
attribute to it things that are not in it.

[Shmuel Metz]

In
<2033694375378395074.929...@news.optonline.net>,
on 12/28/2012

at 01:56 PM, John W Kennedy <jwk...@attglobal.neg> said:

>That would be the Böhm-Jacopini theorem, also known as the
>Structured Programming theorem, which proved that GOTO is never
>necessary on any Turing-complete system.

FSVO system.

>I suppose he means that the method used in the Böhm-Jacopini
>proof results in some awkward and inefficient code.

That's only part of what I mean. The authors were very careful in
defining the types of systems that they were addressing; the paper is
often cited in the context of systems that do not meet the criteria of
the paper.

[John W Kennedy]

On 2012-12-28 15:24:37 +0000, Shmuel (Seymour J.) Metz said:

> In
> <2033694375378395074.929...@news.optonline.net>,
> on 12/28/2012
> at 01:56 PM, John W Kennedy <jwk...@attglobal.neg> said:
>
>> That would be the Böhm-Jacopini theorem, also known as the
>> Structured Programming theorem, which proved that GOTO is never
>> necessary on any Turing-complete system.
>
> FSVO system.
>
>> I suppose he means that the method used in the Böhm-Jacopini
>> proof results in some awkward and inefficient code.
>
> That's only part of what I mean. The authors were very careful in
> defining the types of systems that they were addressing; the paper is
> often cited in the context of systems that do not meet the criteria of
> the paper.

Even if this be so, their original paper was published in 1966, and is
long out of date. See Kozen-Tseng, for example, for more recent work.
(I knew Dexter Kozen back in the 50s; he was my kid sister's
elementary-school "boyfriend".)

--
John W Kennedy
"Give up vows and dogmas, and fixed things, and you may grow like That.
...you may come to think a blow bad, because it hurts, and not because
it humiliates. You may come to think murder wrong, because it is
violent, and not because it is unjust."
-- G. K. Chesterton. "The Ball and the Cross"

[Shmuel Metz]

In <50ddce8f$0$24744$607e...@cv.net>, on 12/28/2012

at 11:53 AM, John W Kennedy <jwk...@attglobal.net> said:

>Even if this be so, their original paper was published in 1966, and
>is long out of date.

I've seen nothing newer that justifies the claims that have been made
with regard to GOTO. In particular, "The Böhm-Jacopini Theorem is
False, Propositionally" (Dexter Kozen and Wei-Lung Dustin Tseng) makes
narrower claims and does not justify the claims I was alluding to

[John W Kennedy]

On 2012-12-28 22:31:12 +0000, Shmuel (Seymour J.) Metz said:

> In <50ddce8f$0$24744$607e...@cv.net>, on 12/28/2012
> at 11:53 AM, John W Kennedy <jwk...@attglobal.net> said:
>
>> Even if this be so, their original paper was published in 1966, and
>> is long out of date.
>
> I've seen nothing newer that justifies the claims that have been made
> with regard to GOTO. In particular, "The Böhm-Jacopini Theorem is
> False, Propositionally" (Dexter Kozen and Wei-Lung Dustin Tseng) makes
> narrower claims and does not justify the claims I was alluding to

...and which you refuse either to describe or to point to. Even in such
anti-BJ papers as I have examined, I can find no restriction suggested
except (if it can even be counted as one) that the flowchart being
implementned must be deterministic.

In any case, none of this changes the fact that real programs can
generally get along very well without GOTO, especially when the
traditional three structured elements are augmented with subroutine
calls, functions, LEAVE, and exception handling of the sort seen in
Ada, C++, or Java. Neither does it change the fact that, following the
publication of the Dijkstra paper and the attendant publicity, there
was tremendous denial and pushback over this from some real programmers
in real shops, which is the /only/ point I had to make in the first
place.

--
John W Kennedy
"Those in the seat of power oft forget their failings and seek only the
obeisance of others! Thus is bad government born! Hold in your heart
that you and the people are one, human beings all, and good government
shall arise of its own accord! Such is the path of virtue!"
-- Kazuo Koike. "Lone Wolf and Cub: Thirteen Strings" (tr. Dana Lewis)

[Shmuel Metz]

In <50de3573$0$1214$607e...@cv.net>, on 12/28/2012
at 07:12 PM, John W Kennedy <jwk...@attglobal.net> said:

>....and which you refuse either to describe or to point to.

Nonsense; nobody asked me to do either.

[Peter Flass]

I rarely use GOTO, but it's really handy to have it available when needed.

--
Pete

[Robin Vowels]

On Dec 22 2012, 5:03 am, Roger Henn <rogerjh...@gmail.com> wrote:
> OK, can anyone explain why this fragment:
> PICSPEC (SUBSTR (TRACKING_CODE, INX, 1), '9')
> produces this error (Enterprise PL/I for z/OS V4.R1.M0):
> IBM2183I S 387 The first argument to PICSPEC built-in must have
>                constant length equal to that of the second argument.
>
> The actual logic is something like:
> DCL WORK FIXED DEC (31) INIT (0);
> DCL TRACKING_CODE CHAR (20);
> DCL INX FIXED BIN (31);
> DO INX = 1 TO LENGTH (TRACKING_CODE);
>   WORK = WORK * 5 + PICSPEC (SUBSTR (TRACKING_CODE, INX, 1), '9');
> END;
>
> I thought 1 was a constant.

Maybe it's an old compiler.

Your code compiles and runs on IBM PL/I for Windows, without
producing the above compilation error:-

test: proc options (main);

DCL WORK FIXED DEC (31) INIT (0);
DCL TRACKING_CODE CHAR (20);
DCL INX FIXED BIN (31);

TRACKING_CODE = '12345678909876543219';

DO INX = 1 TO LENGTH (TRACKING_CODE);

put edit (substr(tracking_code, inx, 1)) (a);

WORK = WORK * 5 + PICSPEC (SUBSTR (TRACKING_CODE, INX, 1), '9');
END;

put skip data (work);
end test;

12345678909876543219
WORK= 29802218627939;

As for 1 being a constant, there's an old adage:
Constants arent; variables don't. :^)

[Robin Vowels]

On Dec 24 2012, 2:40 am, John W Kennedy <jwke...@attglobal.neg> wrote:
> Robin Vowels <robin.vow...@gmail.com> wrote:
> > On Dec 22, 10:17 am, John W Kennedy <jwke...@attglobal.net> wrote:
> >> On 2012-12-21 18:03:21 +0000, Roger Henn said:
>

> >>> OK, can anyone explain why this fragment:
> >>> PICSPEC (SUBSTR (TRACKING_CODE, INX, 1), '9')
> >>> produces this error (Enterprise PL/I for z/OS V4.R1.M0):
> >>> IBM2183I S 387 The first argument to PICSPEC built-in must have
> >>>                constant length equal to that of the second argument.
>
> >>> The actual logic is something like:
> >>> DCL WORK FIXED DEC (31) INIT (0);
> >>> DCL TRACKING_CODE CHAR (20);
> >>> DCL INX FIXED BIN (31);
> >>> DO INX = 1 TO LENGTH (TRACKING_CODE);
> >>>   WORK = WORK * 5 + PICSPEC (SUBSTR (TRACKING_CODE, INX, 1), '9');
> >>> END;
>
> >>> I thought 1 was a constant.
>

> >> Neither the modern manual nor the Optimizer manual specifies anything
> >> one way or the other, but the 60s manual (the abstract one, not the (F)
> >> documentation) says expressly that the result of SUBSTR is always
> >> VARYING. 1 being a constant doesn't change that.
>
> > Well researched.
> > I think that that early IBM documentation is not applicable,
> > as the current IBM compiler is the third completely
> > different compiler from PL/I-F of 1966.
>
> What part of my statement that this was /not/ documentation for the F

> compiler didn’t you understand? This is IBM's official description of the

> PL/I language, and, although it's decades out of date, it has never been
> revised.
>
> > In the case of the IBM compiler here, it looks like an
> > implementation restriction. I see no reason why SUBSTR
> > should return anything other than NONVARYING string
> > when the third argument is a constant.
>
> > It looks like the requirement of PICSPEC (insisting on a
> > fixed-length string) is likewise an implementation restriction, merely
> > to simplify code generation.
>

> That’s your explanation for everything, and, as usual, you’re off-base. In

> order for the first operand of PICSPEC to be VARYING, it is necessary for

> the second operand to be a run-time string variable, which could be sanely

> done only out-of-line, which in itself is trivial from a code-generation
> viewpoint, but which means in turn that the type, precision, and scale of
> the expression all become unknown at compile time, which opens the same
> rat's nest that assigning from CHARACTER to numeric did, only worse, since
> the CHARACTER case at least allowed of arbitrary defaults.
>

> If you want a language that is interpreted at runtime, I suggest REXX in
> the IBM world, or Ruby elsewhere. PL/I is designed to be compiled.
>

> >> Unfortunately, all modern PL/I documentation is vague, and all precise
> >> PL/I documentation has gone without revision since the 60s. A pity,
> >> seeing that PL/I was the first language to be decently documented, but
> >> there you are.
>

> > I think that you will find that the Kednos PL/I documentation
> > is precise.
>
> No it isn’t. Indeed, on this particular issue, it’s flat wrong, seeing that
> the plain reading of it is that the result of SUBSTR is NONVARYING, which
> is absurd.

It's not absurd.

The Kednos PL/I manual is correct.

In point of fact, on current IBM PL/I compilers, SUBSTR always
yields CHAR NONVARYING, regardless of the CHARACTER argument being
VARYING or NONVARYING.

[Robin Vowels]

On Dec 24 2012, 3:29 pm, "James J. Weinkam" <j...@cs.sfu.ca> wrote:

> As others have already noted, the compiler apparently treats the result of substr as varying which seems silly, but
> there you go.

IBM compilers treat SUBSTR as delivering a NONVARYING string.

[Robin Vowels]

On Dec 24 2012, 11:50 pm, Peter Flass <Peter_Fl...@Yahoo.com> wrote:

> It does seem silly.  That's an incompatibility with Iron Spring PL/I,
> which treats all SUBSTR results as nonvarying, either adjustable or
> non-adjustable.

Iron Spring PL/I is correct. IBM compilers deliver a nonvarying
string result when SUBSTR is used.

[John W Kennedy]

There is no such thing as "correct" unless there is an authoritative standard.

> In point of fact, on current IBM PL/I compilers, SUBSTR always
> yields CHAR NONVARYING, regardless of the CHARACTER argument being
> VARYING or NONVARYING.

You can't prove how the SUBSTR function works by appealing to the
SUBSTR pseudovariable.

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

[Robin Vowels]

Try X3.4-1977 and X3.74-1987, which are the standards used
by IBM's compilers (see p. 4, Industry Standards Used).
The Kednos compiler is a definitive specification, and it follows
X3.74-1981, X3.74-1987, and X3.4-1977.

> > In point of fact, on current IBM PL/I compilers, SUBSTR always
> > yields CHAR NONVARYING, regardless of the CHARACTER argument being
> > VARYING or NONVARYING.
>
> You can't prove how the SUBSTR function works by appealing to the
> SUBSTR pseudovariable.

Another nonsensical reply.
The discussion has been about the SUBSTR built-in function.
And I proved that IBM's SUBSTR built-in function always returns
a non-varying string.

[John W Kennedy]

It may use them, but it doesn't follow them.

> The Kednos compiler is a definitive specification,

A compiler is not a specification. And if by "compiler" you mean the
manuals appertaining, no, those manuals do not come close to being an
adequate specification, as I already pointed out.

> and it follows
> X3.74-1981, X3.74-1987, and X3.4-1977.
>
>>> In point of fact, on current IBM PL/I compilers, SUBSTR always
>>> yields CHAR NONVARYING, regardless of the CHARACTER argument being
>>> VARYING or NONVARYING.
>>
>> You can't prove how the SUBSTR function works by appealing to the
>> SUBSTR pseudovariable.
>
> Another nonsensical reply.
> The discussion has been about the SUBSTR built-in function.
> And I proved that IBM's SUBSTR built-in function always returns
> a non-varying string.

You "proved" it A) by experimenting with a compiler to see what it did
and B) by using the SUBSTR pseudo-variable.

[Peter Flass]

On 1/3/2013 10:11 PM, John W Kennedy wrote:
> On 2013-01-04 01:36:50 +0000, Robin Vowels said:
>>
>> Try X3.4-1977 and X3.74-1987, which are the standards used
>> by IBM's compilers (see p. 4, Industry Standards Used).
>
> It may use them, but it doesn't follow them.

Yes, IBM found they made excellent places to set coffee cups.


--
Pete

[Shmuel Metz]

In <kc6iba$kon$2...@dont-email.me>, on 01/04/2013

at 07:36 AM, Peter Flass <Peter...@Yahoo.com> said:

>Yes, IBM found they made excellent places to set coffee cups.

Given that ANSI only updated the G subset, can you blame IBM.

[Robin Vowels]

Not only are you wrong, you are just being silly, because you found
by looking in it that Kednos PL/I LRM states that SUBSTR returns a
non-varying string.

> >  and it follows
> > X3.74-1981, X3.74-1987, and X3.4-1977.
>
> >>> In point of fact, on current IBM PL/I compilers, SUBSTR always
> >>> yields CHAR NONVARYING, regardless of the CHARACTER argument being
> >>> VARYING or NONVARYING.
>
> >> You can't prove how the SUBSTR function works by appealing to the
> >> SUBSTR pseudovariable.
>
> > Another nonsensical reply.
> > The discussion has been about the SUBSTR built-in function.
> > And I proved that IBM's SUBSTR built-in function always returns
> > a non-varying string.
>
> You "proved" it A) by experimenting with a compiler to see what it did

I checked with IBM PL/I compiler after you made the stupid claim
(see quote following) that the Kednos PL/I LRM was not only wrong,
but that to deliver a non-varying result for SUBSTR was "absurd".
Peter Flass already had advised you that Iron Spring compiler
delivered a non-varying result.
You have been using an out-of-date 40-year-old manual as reference.

" No it isn’t. Indeed, on this particular issue, it’s flat wrong,
seeing that
" the plain reading of it is that the result of SUBSTR is NONVARYING,
which
" is absurd."

> and B) by using the SUBSTR pseudo-variable.

The SUBSTR pseudo-variable had nothing to do with the proof,
as I already said.
See if you can find a pseudo-variable in my PL/I example using
generic facility.

[Robin Vowels]

On Dec 22 2012, 5:03 am, Roger Henn <rogerjh...@gmail.com> wrote:

> OK, can anyone explain why this fragment:

...

> The actual logic is something like:
> DCL WORK FIXED DEC (31) INIT (0);
> DCL TRACKING_CODE CHAR (20);
> DCL INX FIXED BIN (31);
> DO INX = 1 TO LENGTH (TRACKING_CODE);
>   WORK = WORK * 5 + PICSPEC (SUBSTR (TRACKING_CODE, INX, 1), '9');
> END;
>
> I thought 1 was a constant.

Here's an interesting alternative:

declare TC(20) fixed (1);
get string (tracking_code) edit (TC) (F(1));
work = (...(((TC(1)*5 + TC(2))*5 + TC(3))*5 + ... + TC(20);

[Robin Vowels]

On Dec 26 2012, 6:26 am, John W Kennedy <jwke...@attglobal.net> wrote:
> On 2012-12-25 07:35:47 +0000, Robin Vowels said:
>
>
>
>
>
>
>
>
>
> > On Dec 25, 8:33 am, "Peter J. Seymour" <Newsgro...@pjsey.demon.co.uk>
> > wrote:
> >> On 2012-12-24 18:52, Peter Flass wrote:
>
> >>> On 12/24/2012 12:57 PM, Peter J. Seymour wrote:

> >>>> On 2012-12-21 18:03, Roger Henn wrote:
> >>>>> OK, can anyone explain why this fragment:

> >>>>> PICSPEC (SUBSTR (TRACKING_CODE, INX, 1), '9')

> >>>>> produces this error (Enterprise PL/I for z/OS V4.R1.M0):
> >>>>> IBM2183I S 387 The first argument to PICSPEC built-in must have
> >>>>>                 constant length equal to that of the second argument.
>

> >>>>> The actual logic is something like:
> >>>>> DCL WORK FIXED DEC (31) INIT (0);
> >>>>> DCL TRACKING_CODE CHAR (20);
> >>>>> DCL INX FIXED BIN (31);
> >>>>> DO INX = 1 TO LENGTH (TRACKING_CODE);
> >>>>>    WORK = WORK * 5 + PICSPEC (SUBSTR (TRACKING_CODE, INX, 1), '9');
> >>>>> END;
>
> >>>>> I thought 1 was a constant.
>

> >>>> Getting back to the original topic, I was not familiar with PICSPEC so I
> >>>> had to look it up. The situation looks to me like lazy
> >>>> design/implementation. Why would PICSPEC require a fixed length first
> >>>> argument?
>
> >>> I had to look it up too.  It doesn't convert, it "redefines" the
> >>> argument as pictured type, so the source length and the picture length
> >>> have to match.
>
> >> In the "good old days" we used to do something like
>
> >> DCL P1  PIC'99999';
> >> DCL C1  CHAR(5) DEF P1;
> >> (not sure if that is the exact syntax, if might have to be
> >> BASED(ADDR(P1)) ).
>
> > A better way is to use UNION.
>
> No it is not. UNION is a blunt instrument that should be used only as a
> last resort.

Don't be ridiculous again.

Look at the UNION example under the heading UNIONS.
(It illustrates using a familiar idea that might, in earlier times,
have been done with DEFINED -- although for that instance I would
have used DEFINED).
UNION is a perfect for this situation (overlaying PIC and CHAR).

[Robin Vowels]

On Dec 25 2012, 4:57 am, "Peter J. Seymour"
<Newsgro...@pjsey.demon.co.uk> wrote:

> As to SUBSTR. I recall that the Optimising Compiler had a dual
> implementation of it. If the length was fixed and less that 256 (I think
> it was that value) the reference was implemented efficiently inline as a
> fixed value. Otherwise, if it was longer or the field was VARYING a
> library call was used. It shouldn't matter what happens under the hood
> if there is no possibility of side effects.

It was not uncommon on S/360/370 to do optimisations for strings of
length up to 256 characters.
For such strings, the MVC/CLC instructions were efficient,
particularly on fixed-length strings. Longer than that, a loop
was needed on S/360, and likely a subroutine would be used.
On the F-compiler, dope vectors were produced for strings and arrays
of length greater than 256 bytes, and when lengths of strings and
bounds of arrays are variable.

[Roger Henn]

On Tuesday, December 25, 2012 1:34:40 AM UTC-6, Robin Vowels wrote:
>> On Dec 25, 5:27 am, Roger Henn <rogerjh...@gmail.com> wrote:
>> Well, the shop I'm in is just now converting to Enterprise PL/I, and they're somewhat hyper about some of the warning messages from the 'new' compiler. That last causes a message about library calls that's against what they loosely call "standards" (most of which are based more on old COBOL standards than anything to do with PL/I. The rest don't seem to be documented at all).
>>
>> Their usual way to get rid of it is to move the CHAR value to an intermediate CHAR variable that has a PIC variable overlaid on it, then use the PIC variable. I was just trying to get rid of the extra data movement, without using UNSPEC, which ist verboten. I hadn't seen PICPSEC before, which looked like it might be worth a try, but apparently not.

>UNION would be an appropriate mechanism, which avoids the need for data movement.

UNION looks like a good solution, but I'm pretty sure the standards Gestapo would choke on it. "We've never done it that way, so nobody can understand it". Well, of course not. The compiler we used to use didn't have it. Doesn't mean we can't learn.

[gerardsch...@gmail.com]

On Monday, December 24, 2012 6:14:28 AM UTC-6, Peter J. Seymour wrote:
> On 2012-12-24 04:06, John W Kennedy wrote:
> > On 2012-12-23 22:09:00 +0000, Peter J. Seymour said:
> >> On 2012-12-23 15:40, John W Kennedy wrote:
> >> .....
> >> I must be missing something here, why do you consider that F-level
> >> compiler documentation overrides all later documentation? Personally,
> >> I don't remember being that impressed with the F-level manuals.

> > For the third time, I am talking about the Language Specification
> > Manual, which is of the F era, but, in its final editions, was not
> > explicitly associated with that or any other compiler; it was replaced
> > as F-compiler documentation by the newer (F) Language Reference Manual.
> > No PL/I compiler, in fact, ever implemented this exact form of the
> > language. (For example, the CELL attribute -- similar to the modern
> > UNION -- was never made available.)

> > And I am not saying that it overrides more recent documentation; I am
> > saying that on many questions of detail, more recent manuals are silent,
> > leaving it and the ULD as the only fallback source. That is a Bad Thing.
> > But I can't make IBM write better documentation. I'm not an IBM
> > customer. I'm not even an employee of an IBM customer anymore. I'm just
> > a guy who regularly used a lot of PL/I from 1968 to 1997, and tries to
> > keep up.

> OK, I am with you now, there is Y33-6003 which is a language definition
> manual. Presumably no update was considered necessary as the language
> definition had been palmed off to an outside body. I remember that for
> many years IBM insisted that they could not update their implemented
> compilers as they did not control the standard and did not want to be
> seen to exercise any initiative. It resulted in a customer management
> drift away from PL/I.

I have that manual somewhere, I believe this is the only IBM publication
to be re-called (that is, distributed copies were to be gathered up
and sent back to IBM). From a much earlier PL/I post of mine:

Form YY33-6003-0
Language Specifications

IBM System/360
PL/I Language Specifications

Restricted Distribution

Inside cover:

Major Revision (March 1968)
This publication, Form Y33-6003-0, makes obsolete the
previous edition, Form C28-6571-4.

...

(c) Copyright International Business Machines Corporation 1965,
1968.
______________________________________________ Gerard Schildberger

[John W Kennedy]

I don't know about this YY edition; the edition at BitSavers is plain
Y, but has the same date.

--
John W Kennedy
A proud member of the reality-based community.

[Shmuel Metz]

In <516c7345$0$20192$607e...@cv.net>, on 04/15/2013

at 05:38 PM, John W Kennedy <jwk...@attglobal.net> said:

>I don't know about this YY edition;

There is none; it's nice to know that i'm not the only person whose
typing has a stuttering problem.

FTR, there are IBM publications with form codes Yxx-xxxx, GYxx-xxxx,
LYxx-xxxx and SYxx-xxxx, but no YYxx-xxxx. There are ZZxx-xxxx
manuals, but those for are internal use only; don't east them.