SCOUG-Programming Mailing List Archives

>> Next Message >>

Date:	Wed, 21 Feb 2007 11:49:45 -0800
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	"SCOUG Programming SIG" <scoug-programming@scoug.com >
Subject:	SCOUG-Programming: And the winner(s) is(are)....

Content Type: text/plain

Sometimes a search takes you back to where you began. In
this instance of a search for an open source OS/2 editor we
early on had two popular candidates, VIM and jEdit. After
much looking elsewhere and in fact purchasing another, MED, I
gave up the quest, deciding that either VIM or jEdit or both
would do.

Actually we have two versions of VIM to consider, the
Windoze version with its GUI interface and the OS/2 version
without it. We have no reason even under OS/2 not to look at
both.

VIM will give us a broader look at C. jEdit will give us an
opportunity to grasp OO and thus also C++. As C, C++, Cxxx
(all other variations) and JAVA (jEdit) offer no more than a
proper subset of PL/I (and thus SL/I), we have the ability to
directly translate from any of these into PL/I. Remember one
of our initial purposes in this endeavor was to provide a
means of comparative linguistics, to actually compare
programming languages.

Historically you need to remember PL/I occurred in 1964 and C
and its derivatives in 1970 and thereafter (since). Actually B
(for Basic Compiler Language), the precursor to C, was
presented by Ritchie (the R in K&R) at the Spring Joint
Computer Conference (SJCC) in Anaheim in 1968.

Thus while IBM was well underway with its PL/S and even
Wirth at Standford had produced PL/360, Ritchie introduced
his "primitive" B language. It reminds me of an internal IBM
conference on programming languages in 1970 when IBM
Raleigh's group proudly announced their macro-assembly
language in the same program as when another IBM group
announced the H-level assembly, now known as the Advanced
Assembly Language. The Raleigh product did not have the
capability of the existing assembly language on the S/360
while the H-level assembly offered unbounded extensions,
limited only by human skills.

Thus the gap between PL/I and C with its derivatives including
JAVA. We should have no difficulty fitting "them" within PL/I
with space left over.

Part of that left over space includes the area of
self-correcting or self-repairable programs. Implicit in that
lies the concept of a non-failing program, one in which at
least one functional piece continues to operate regardless.
Actually this lies at the heart of real-time systems,
particularly those operating in far space environments which
rely on remote assistance in times of trouble.

As you can have all kinds of errors, you need, one, the ability
to detect it, two, the ability to specifically note it, and, three,
turn it over to a correcting function. You have two kinds of
errors, those which you can think of as "standard" that can
occur with any program and those which occur due to a
program, so-called "user" errors.

PL/I offers a broad range of "standard" error types and
basically an unlimited range of "user" error types. In PL/I both
are referred to as "ON" codes, e.g. ON SYTEM, ON ERROR, ON
ENDFILE or ON MYBAD. Each gets invoked implicitly (by the
PL/I runtime environment) or explicitly by the program with a
SIGNAL statement to give control to the specific error
subroutine.

Now a two-level hierarchy of error codes exist. At the top is
ON SYSTEM and below it all the rest. If an abnormal
termination occurs for which the lower levels somehow can't
resolve, control passes to the ON SYSTEM. It can either exit
to the operating system, i.e. terminate the program, or it can
pass control to some entry point in the program. Thus you
have what many people discovered, the ability of a program
to refuse to quit. This required stopping the system and
re-ipling to overcome. It also seems to be missing in the OS/2
version of PL/I, another correction we will have to make in
our effort.

I will offer one last example before ending this. When IBM
went from the 1400 series of commercial computers (meaning
they had a variable precision decimal instruction set) to the
S/360 a conversion problem existed. The 1400 series would
accept a blank (or space) the same as a zero which the S/360
would not. That meant that files containing bland decimal
fields would fail on processing producing "conversion" errors.

IBM assembled a core of programmers in a facility near LAX
whose sole purpose was to write utility programs to read this
files, seek out decimal fields, and if blank, replace them with
zeroes. I don't want to get into how difficult this was given
that probably no two customers had the same file format. IBM
did expend well over 15 million dollars in this largely failing
effort.

Understand that this problem only existed for COBOL accounts.
PL/I accounts simply had to add the following to their source
code:

ON CONV begin;
ONSOURCE = '0';
end;

Thus anytime a conversion error occurred the ON CONV was
invoked which replaced the source byte with a '0' and
returned control back to the statement in which the error
occurred.

Now K&R claimed in their "The C Programming Language" that
they had eliminated all the unnecessary features of earlier
programming languages. That accounts for why in 2007 C
remains behind a 1970 PL/I and given the difference between
1.4 (Java 4) and 1.5 (Java 5) why so much effort goes into
putting back in those "unnecessary" features. Maybe in 30
years Java x.x might approach PL/I.

Have fun.

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"postmaster@scoug.com".

=====================================================

Return to [ 21 | February | 2007 ]

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.