Programming Language / I

A. Craig Dixon
CSC 415: Programming Languages
Dr. Lyle
October 9, 2001

History of Programming Language / I

Development
In the early 1960s, computing itself was still evolving. Most innovations in the
industry were brought about by necessity rather than long range planning and research.
This had lead to a wide separation between computers for business applications, which
required more fixed point and string operations, and computers for scientific applications,
which required more support for arrays and floating point operations. IBM, the major
player in the computer industry at the time, had developed models 7090 and 1620 for the
scientists and models 7080 and 1401 for the business programmers. (Sebesta 69)
However, toward the middle of the decade, these two groups had begun to move
closer together in terms of their computing needs. IBM saw the opportunity to unite most
of the computing world under a single system design. The result was IBMs all-purpose
System 360. With the release of the System 360, IBM had united much of the hardware
side of the industry, yet the software side remained divided; business applications were
programmed in COBOL, while scientific applications were done in FORTRAN. The
logical next step for IBM was to create a universal, all-purpose development tool. The
result was Programming Language / I (PL/I.) Of PL/I, Peter Norton writes, "PL/I was
built out of four parts: FORTRAN's calculations, COBOL's I/O formatting, ALGOL's
structure, and some new topics." Later he identifies these "new topics" as "support of
interrupts, use of macros and program libraries, and other goodies of that ilk."

Programming Language / I

Results
Though somewhat popular through the 1970s, PL/I never experienced the
success that the System 360 did. For the most part, FORTRAN programmers continued to
program in FORTRAN, and COBOL programmers continued to program in COBOL. As
it turns out, PL/Is greatest strength was also its fatal flaw: flexibility. As Robert Sebesta
puts it: the design of PL/I was based on the premise that any construct that was useful
and could be implemented should be included (Sebesta 71) This philosophy led to a
language that was almost infinitely complex and much too complicated for the average
programmer to master fully.
PL/I was not without its merits, however. As Peter Norton points out above, PL/I
included some programming constructs that were completely without precedent. Sebesta
cites concurrency, error handling, pointers as a data type, and cross sections of arrays
(slices.) (Sebesta 71) Problems with these new features will be discussed in other sections
of this report, but it is important to remember that, as with any innovation, the first
implementation seldom turns out to be the best implementation.

Data Types
Data types in PL/I are both numerous and flexible. Numeric types include integer,
fixed-point, floating-point, and complex. Each of these types can be declared as signed or
unsigned, stored as binary or decimal, and can have a set length and precision at runtime
or be left a variable length and precision. A character data type is included, as is an array
data type. Arrays can be manipulated at the elemental level, but part or all of the array
can be manipulated as an aggregate. That is, if A is declared as a 3 x 3 array of any

Programming Language / I
numeric type, performing the square root operation on the array yields a second 3 x 3
array whose elements are the square roots of their corresponding elements in A.
While many languages choose to implement strings as arrays of characters, PL/I
treats strings as a separate data type, including functions that concatenate, reverse, search,
and compare strings as part of the language rather than an external package. For this
reason, PL/I is often considered one of the best languages for string manipulation.
As mentioned earlier, pointers are also a data type to themselves in PL/I. Sebesta
maintains that dangling pointers (pointers that contain the address of heap-dynamic
variables that have been deallocated) and lost heap dynamic variables (variables no
longer accessible to the user program) are problems in PL/I. (Sebesta 241-42) However,
in an email interview with this author, Dana Guild remarks that pointers in PL/I are
more intuitive making it much easier to read and write with pointers. (The complete text
of this interview may be found in the appendix to this report.)
PL/I is touted by its proponents as one of the best languages for data types both
because of the sheer number of types that are inherently supported and because data types
in PL/I are structure type compatible, allowing variables with the same structure to be
related (e.g. assigned to one another, etc.) While this allows a good deal of mixing data
types, sometimes in powerful arrangements, it also can lead to programming mistakes
that will not be caught by the compiler.

Program Structure
PL/I is considered the first structured programming language. Peter Flass
describes PL/Is structure thusly:

Programming Language / I

PL/I is a block-structured language. The outermost block, the External

Procedure, provides the shell for all code and data. Other blocks,
Procedures, which are executed only as subroutines or functions, and
Begin-blocks, which are executed inline can be nested to any depth.

An example of PL/Is block structure can be seen in the following code sample
from Concepts of Programming Languages by Robert Sebesta:

/* READ INPUT DATA INTO AN ARRAY AND COMPUTE THE SUM */

DO COUNTER = 1 TO LISTLEN;
GET LIST ( INTLIST (COUNTER));
SUM = SUM + INTLIST (COUNTER);
END;
(Sebesta 72)
The block starts with the keyword that identifies the kind of block (i.e. DO indicates a
loop,) and ends with the keyword END.

Keywords vs. Reserved Words

At this point an important distinction in terminology should be noted. Keyword
and reserved word are not synonymous terms. For this discussion, we shall use Sebestas
definition of these terms. A keyword is a word of a programming language that is
special only in certain contexts. A reserved word is a special word of a programming
language that cannot be used as a name. (Sebesta 158) In other words, a reserved word
4

Programming Language / I
has significance to a compiler and can only be used in the context which the compiler
expects. For example, in C++ the programmer cannot make the following declaration:
int new;
because new is a reserved word which declares a new block of dynamic memory. If new
is used in any other context, the compiler generates a compile error. By contrast, a
keyword is a word that has significance to a compiler, but can be used as an identifier
without conflict.
PL/I uses keywords rather than reserved words. Many proponents of PL/I
consider this a benefit because a beginning programmer does not have to have knowledge
of all the words that are significant to the compiler. He or she can just code the program
using identifiers that make sense to him or her. This is especially important in PL/I
because it has so many significant words. The downside, however, is that the experienced
programmer may have a hard time reading such a program because of the perceived
ambiguity of using keywords as identifiers. Furthermore, Sebesta points out that the
following hopelessly confusing declaration is perfectly legal:
INTEGER REAL;
REAL INTEGER;
While the experienced programmer will likely know to avoid such strange declarations,
the novice programmer could easily write totally unreadable code without even knowing
it.

Scoping
Because of its block structure, PL/I allows variables to be declared in the middle
of executable code. This feature was borrowed from ALGOL 60. (Sebesta 177) In fact,
5

Programming Language / I
scoping in PL/I is pretty much identical to scoping in ALGOL 60. Peter Flass describes
PL/Is scoping scheme as follows: Data declared within a block has a scope consisting
of the block within which it is declared and all nested blocks, unless overridden by
another declaration.
By overridden, Flass means that a variable declared in a nested block that has
the same name as a variable declared in any parent blocks will override the declaration in
the parent block. When the inner variable goes out of scope, (i.e. the block in which it is
declared terminates,) any further references to a variable of that name will refer to the
variable in the parent block, which will have retained its original value throughout the
execution of the nested block.
To pass a variable that would otherwise be out of scope, PL/I allows subprograms
to receive arguments. By default, these are passed by reference, that is, any modifications
made to the variable in the subprogram are made to the variable in place (the address
where it is stored.) This can be changed however, by enclosing the argument in
parentheses when the subprogram is called. This will cause the subprogram to receive a
copy of the variable, so no change will be made to the variable itself. Consider this
example from Sturms Power vs. Adventure:
call Sub ((K), M, A);
In this example, M and A are passed by reference and K is passed by value.

Concurrency
PL/I was also the first language to support concurrency. Of course, it isnt true
concurrency, in the sense that two processors are performing two separate tasks at the

Programming Language / I
same time. At the time that PL/I was introduced, multi-processor systems hadnt even
been developed yet. Peter Norton describes use of concurrency in PL/I like this:
PL/I programmers use event or task variables to spawn and coordinate
tasks, with two built-in functions -- STATUS and COMPLETION. PL/I
programmers can prioritize tasks with the PRIORITY option and check
the priority of any executing task with the PRIORITY built-in function.
PL/I performs task rendezvous with the WAIT statement.
Sebesta points out that this feature of PL/I wasnt that good. True concurrency is
just becoming possible. It is likely that we will only now begin to see languages
where concurrency that is well implemented.

Evaluation
The last part of this report will be this authors evaluation of the PL/I language.
This evaluation will be based on Sebestas four criteria of program language evaluation,
namely: readability, writability, reliability, and cost.

Readability
For all its flexibility and innovation, PL/I is notoriously difficult to read for a
number of reasons. First is its use of the much-maligned GOTO statement. Though a
common feature at the time of PL/Is creation, the GOTO has been largely abandoned in
recent years because of its tendency to produce spaghetti code, that is, code that is so
intertwined that it is difficult to read.

Programming Language / I
Further contributing to this problem is PL/Is method of exception handling. In
PL/I, exceptions are dynamically bound, that is, bound at run-time. Therefore, the last
encountered definition of an exception is the one used when that exception is raised, no
matter its location relative to the statement that raises the exception. While this problem
can be avoided by giving all exceptions unique names, the concept of dynamic binding as
it relates to exception handling has been long-since abandoned.
Yet another impediment to PL/Is readability is discussed in Eberhard Sturms
article Power vs. Adventure: PL/I and C. Sturm points out that the following two
declarations are identical in PL/I:
dcl F float init (1) nonasgn abnormal;
dcl F float nonasgn abnormal init (1);
In other words, as long as the first keyword is present, the subsequent statement modifiers
may be in any order that the programmer chooses. (It should be noted that although
Sturm presents this as a beneficial feature of PL/I, it is this authors opinion that it
impairs readability and is here presented as such.)

Writability
Most of the features that hinder readability in PL/I are helpful in terms of
writability. Not having to worry about reserved words or ordering of statements makes
PL/I easily writable for even novice programmers. Also, unlike C++, PL/I is not case
sensitive. That means that the keyword put functions the same whether the programmer
spells it put, PUT, Put, or even PuT!

Programming Language / I
Another feature that adds to the writability of PL/I is use of compiler defaults.
Peter Flasss website best sums up this feature:

In the minimal case, data does not need to be declared at all, but will be
provided with a set of default attributes depending on the context in which
it is used. The programmer has to declare only enough information as
necessary and the compiler will fill in the rest. For example, declaring a
variable FIXED with no other attributes will cause the compiler to add the
default attributes DECIMAL and a precision (number of digits).

PL/I is very similar to QBASIC in this respect. This feature is a clear advantage to
beginning programmers who do not yet fully understand data types, although in the
commercial programming world, Dana Guild points out, the standard is to always
declare variables, so commercial programmers will likely get little or no benefit from
this feature.

Reliability
The ultimate measure of code reliability is code lifespan. If code is not reliable,
companies will obviously abandon it in favor of something better. Not to do so is to incur
unnecessary cost. While it is by no means commonplace, PL/I code is still in place at
many large companies worldwide. This would seem to speak highly of its reliability.
On the other hand, Dana Guild points out that PLI is definitely on the way out.
Though it is still supported by IBM, as PL/I legacy code becomes less and less common,

Programming Language / I
IBMs support of the product itself will wane. Companies who still have PL/I legacy code
when this happens will find it very difficult to maintain that code without IBMs
continued support.

Cost
When discussing cost, we do not simply mean the cost of the software itself. Cost
also includes expenses incurred from training people to use software, finding qualified
personnel to use the software, and the hardware to run the software.
PL/I runs on both mainframe and microcomputer systems and is available for
most every operating system, so hardware costs are not a problem. VisualAge PL/1
Enterprise V2.1, which runs under both Windows and OS/2, sells on IBMs website for
$2,849.00. I would assume that this is comparable to most other commercial design
environments.
That leaves only the cost of personnel. When asked about finding PL/I personnel,
Dana Guild responded: Its difficult to find people who already know PLI but its not
too hard to find people willing to learn it. While knowledge of PL/I is a rare commodity,
its also one that is in low demand, which keeps the cost of hiring qualified programmers
to a minimum.
With PL/I, the major cost is training. To train a programmer in all the features of
PL/I would obviously be extremely costly because of the sheer volume of features of the
language. Companies must decide which features are most important to their purpose,
and train their employees accordingly.

10

Programming Language / I

Overall
Which of our aforementioned criteria is most important is the decision of each
individual or company. Thus an overall evaluation is little more than the evaluators
opinion. In the case of PL/I, this author sees a language that was a true pioneer in its day;
no doubt head and shoulders above anything available at the time. However, PL/Is time
has come and gone. Increased learning about programming principles has brought new
languages to supplant outdated ones like PL/I. PL/I, like Latin, was meant to be a
universal language, and has contributed much to modern languages. But like Latin, it is
now considered a dead language.

11

Appendix: Abridged* Text of Email Interview

With PL/I Programmer Dana Guild
The following is the text of an email interview that the author conducted with Dana
Guild. Ms. Guild is a Murray State University alumnus and maintains PL/I code for State
Farm Insurance. Questions and answers are included exactly as they appeared in the
email.
Craig Dixon: How long have you been programming in PL/I?
Dana Guild: 3 years
CD: What other programming languages do you have experience with?
DG: Cobol, C, C++, Visual Basic, Pascal, SQL, PowerBuilder, RPG, Assembler
CD: Overall, how does PL/I compare to these languages?
DG: Its a bit of a cross between Pascal and C++...not nearly as wordy as Cobol, but not
as cryptic as C++. I'd say its fairly close processing-wise to Cobol (good at
handling everyday data manipulation, etc), although it makes handling pointers
much easier.
CD: Overall, is PL/I the best language you have used?
DG: I guess it probably depends on what you are using it to code for (if its highly
mathematical, definitely no), but I'd probably have to say overall no its not the
best. I've run into limitations with it just in the minimal contexts I use if for
(variable definitions, for example) and sometimes you have to jump through hoops
to get it to do what you want (data conversions, for example)
CD: Many would consider PL/I a dead (or at least dying) language. In your opinion, is
PL/I on its way out, or will it live on through legacy code the way COBOL has?
DG: Oh, PLI is definitely on the way out...there are very few companies left that have
any code in PLI. However, the companies that do still have it, will probably have it
until they have to get rid of it. Almost half of all the mainframe code at State Farm
is in PLI and we do still develop new code in PLI. COBOL is much more common
in companies all over the US, so PLI will probably leave the scene way before
COBOL, but I don't see it dying anytime soon.
CD: Most universities don't teach programming in PL/I. How difficult is it to move from
another language to PL/I?

* Questions to which the interviewee provided no response have been omitted.

Appendix
DG: Not difficult at all. Its pretty easy to pick up any new language, so long as you have
the basics of programming (linear, not OO) down already. All you have to do is
learn the syntax and most of that is similar enough to other languages that its easy
to learn. There are a few oddities of PLI that you would have to learn (such as
based storage, or pointers) but they are pretty easy to understand. The class they
give here at SF is only about 6 - 8 weeks and they include more than just learning
PLI (such as SF standards and tools, etc).
CD: Is it difficult to find programmers who can already write and maintain PL/I or who
are willing to learn PL/I?
DG: Its difficult to find people who already know PLI (I don't think SF even looks for
that anymore), but its not too hard to find people willing to learn it...I'm sure most
people would prefer to work with something that makes them marketable, but if
there are other opportunities available in the same company, people are easily
willing to work with PLI for a while. State Farm doesn't seem to have a hard time
finding people willing to learn PLI...they just hire the people and train them on it.
CD: What is the primary purpose of the PL/I programs that you maintain?
DG: My programs support some Accounting functions...we pull in payments made and
make sure the transactions get ledgerized and EFTed(money transferredfrom bank
account to bank account) to the correct places.
CD: Why was PL/I chosen for this task?
DG: I'm not sure...it was way before my time here when these programs were written.
My best guess is that PLI was the State Farm standard at the time or that other,
similar functions were already written in PLI. Today if we make changes which
require a new program or module, we still write it in PLI just because that's what
everything (in this system) is already in. However, the standard today is
COBOL...brand new systems that have been written in the past 10 or 15 years have
been written in Cobol.
CD: PL/I is platform independent. On what platform does your PL/I code run?
DG: IBM mainframe (OS/309)
CD: My preliminary research indicates that PL/I is interpreted rather than compiled.
(Authors note: Further research revealed that PL/I is compiled rather than
interpreted.) How does this fundamental difference affect the performance of PL/I
programs?
DG: I haven't noticed any performance issues with PLI at all, but then most of the stuff
we use it for doesn't really depend on milliseconds to make the difference. It is

ii

Appendix
completely transparent to me...we use a complier, just the same way we do for
Cobol programs and they both seem to very similar.
CD: I have also discovered that there are no reserved words in PL/I. Many proponents of
PL/I claim this is one of the beneficial features of PL/I, but it seems to me that this
would lead to problems with both readability and writability. Based on your
experience with PL/I, what is your opinion on this issue?
DG: I haven't had any problems not having reserved words. Standards here at State Farm
requires naming variables descriptively, so I haven't really run across any problems
with reserved words, but I don't think it would cause problems with readability so
long as the variables were defined.
CD: Specifying lengths and types of variables is optional in PL/I. Do you find this
beneficial, or do the language's default settings and implicit conversions make the
code too hard to debug? What other benefits or problems does this feature cause?
DG: The standard here at State Farm is to always declare variables, so all the code here
has the variables declared. When I was learning the code though, it did make it a
bit more difficult to debug, if you accidentally left out a variable declaration or
misspelled a variable somewhere, because it doesn't cause the compile to crash, so
you might not even realize that you had made a mistake (and its always harder to
debug logic errors than compile errors). I suppose a benefit would be that you don't
have type quite as much, but I don't think that's worth the effort you would have to
put in to make sure you followed the standards to get the defaults used correctly.
CD: From the sparse sample code I have looked at, it seems that pointer variables are
easier (at least in terms of readability) in PL/I, than say, C++. How do PL/I's
pointers stack up in terms of writability and reliability?
DG: I really like the way PLI uses pointers...they are more intuitive making it much
easier to read and write with pointers (at least from my point of view). I guess the
only drawback that I can see is that you may not always realize you are dealing with
a pointer unless you check the declarations (if you don't use a naming convention
for pointers). But it makes using pointers so easy and simple to understand that its
like a normal variable.

iii

Bibliography
Flass, Peter. The PL/I Language. 6 Sept. 2001 <http://home.nycap.rr.com/pflass/pli.htm>.
Guild, Dana. Email interview with the author. 5 Oct. 2001
IBM.com. 6 Sept. 2001 <http://www.ibm.com>
Marco, Lou. In Praise of PL/I. Enterprise Systems Journal (December 1996): 32-37.
Rpt. at <http://www.users.bigpond.com/robin_v/enterp.htm>. Eds. D. Jones and Robin
Vowels. 13 Sept. 2001
Norton, Peter. The Norton Chronicles. PC Magazine (15 May 1984). Rpt. at
<http://www.users.bigpond.com/robin_v/norton.htm>. 13 Sept. 2001
Sebesta, Robert W. Concepts of Programming Languages. 4th ed. Reading, MA: AddisonWesley
Sturm, Eberhard. Power vs. Adventure: PL/I and C. Presentation at G.U.I.D.E. &
SHARE Europe Joint Conference (10-13 October 1994, Vienna, Austria). Rpt. at
<http://www.uni-muenster.de/ZIV/Mitarbeiter/EberhardSturm/PL1andC.html>. Eds. John
R. Ehrman and Dave Jones. Sept. 1996. 13 Sept. 2001
Vowels, Robin. Why You Should Consider Using PL/I. Editorial. 5 Sept. 1998. 13 Sept.
2001. <http://www.users.bigpond.com/robin_v/why_not.htm.>.