I worked primarily on DOS/VSE, not MVS, accounts as a
regional specialist on CICS/DL/I for accounts using IBM's
COPICS. The advent of COBOL II with its structured
programming features proved interesting. My first experience
on it was trying to instruct a COBOL programmer how to write
inline PERFORM's. Now some several decades later out-of-line
still dominate coding practices.
Dwight failed to explain why the "9000-OPEN-FILES" started
off with the "9000-" or why "8090-" would appear before and
"9040-" after it. The programmer essentially numbered and
physically ordered the paragraphs in source to make locating
them in the listing easier. I had the habit in reading COBOL
program listings to "decollate" the pages, laying them out in a
two-dimensional manner to make it easier to move from
reading one paragraph to another.
There was very low overhead in an out-of-line reference.
That was not a performance issue. The performance issue
arose due to the reference pattern physically in storage and
the number of virtual storage pages it touched (and which
therefore had to be brought into memory) in the course of its
travels. This increased the working set of the number of
pages. Putting the executing code inline reduced this number.
I don't know that any of this has any meaning any more when
main storage runs into the gigabytes and essentially no paging
occurs.
I used COBOL to illustrate granularity of reuse down to the
statement level, something not "attractive" through use of
"include's" in C or PL/I. Sometimes people think I invent things
like "reuse at the statement level". I just wanted to show its
presence in existing software technology.
However, the use of a number prefix as part of a label, i.e.
paragraph, name, a compiler (meta-programming) option to
produce inline instead of out-of-line execution, and "smart"
editors that perform syntax checking but seem incapable
processing "include" or "copy" statements by including them
inline in source--whew--makes several points with respect to
the deficiencies of our current tool set and use of third
generation languages.
In the system I propose no "explicit" use of an "include" or
"copy" occurs, because "implicitly" every statement is
accessed as if it were an "include" or "copy". Thus the editor,
in this instance the Developer's Assistant, would present the
fully exploded source.
Now remember this uses a fourth generation language in
which the "code segments" representing specifications can
appear in any order, i.e. unordered. That's the "input" source.
Fourth generation languages, in fact all of logic programming,
uses a two-stage proof engine: a completeness proof and an
exhaustive true/false proof. As part of the processing of the
completeness proof the software "organizes", i.e. orders, the
unordered input source into an optimal output source format.
That means that every specification, which appears only once
in the actual input, is replicated wherever it is referenced by
other specifications. The only exception occurs when a
specification exists as a named subroutine, i.e. a "procedure".
Thus the "output" source resulting from the completeness
proof contains replications of the "input" source where
required and no use of artifacts like paragraph names in
COBOL occurs. This results in a completely structured source,
obeying the one-in-one-out pattern of structured
programming.
You need to understand the "output" source, which is the
input to the code generation process of the completeness
proof, is never stored, only generated. Thus no maintenance
ever occurs on it, only regeneration. Maintenance only occurs
on the unordered input where changes get reflected through
regeneration in the output source.
We achieve this through a data repository/directory, in this
instance based on using a relational database, in which we
store only the individual statements as rows in a table. To do
that the software assigns each statement a name based on
the first 20 bytes of its content appended by a 4-byte
(binary) index value. The index value compensates for the
possibility of homonyms (same name, different referents).
Together they form a 24-byte unique name required for every
row in a table.
Now note that the programmer writes statements as he would
normally without concern for their existence in the database.
The software will process a statement, create a name based
on its content, check it against same names (homonyms) in
the database, and check its total content against that of the
other homonyms. If it finds a match, it will use that existing
name for the source. Otherwise it will add a index suffix to
give it a unique name and store it in the database.
All this is invisible to the programmer. All he sees is the
unaltered source. Now he could look to see if the source
statement he wants is in the database, but that would take
longer than simply writing it. So he just writes it. The
software assumes all responsibility from that point on. Note
that statement reuse is automatic, requiring no effort on the
part of the programmer. Also note that any statement
appears only once in the database, the data repository,
regardless of how many times it appears in how many
programs.
You can write the input in any order. The software will
determine (generate) the output order. Thus you can accept
user changes/requirements as they occur, write them as
specifications, insert them into the input, and the software
will regenerate the output reflecting changes to the input.
Now I said that kind of fast, but not fast enough for the
software which can do all that tens of millions times
faster. If you have followed this to this point--and if you
have not, go back and do so--and you have any kind of
experience in the difficulties of source program maintenance
of third generation languages, you have just seen what a
difference a fourth makes.
Moreover don't forget the completeness proof has two results:
true, if it has all it needs to order the input source completely,
and, false, if it does not. In either case, just in case you don't
understand how it derived the output form from the input or
why it couldn't, it incorporates a feature called "backtracking"
(present in all of logic programming) to show you why it did
what it did or why it could not (an incomplete or false
instance).
Don't stop now. It gets even better. Though the
completeness proof may register a "false" or "incomplete"
status (state), that doesn't mean that completed portions do
not exist, i.e. partially complete. Nothing prevents the
completeness proof from displaying incomplete results based
on its complete portions. By display I mean in the form of
dataflows, structure charts, or any of the dozen of more
forms of UML.
When you use these visual output results to base changes to
the "unordered" input source, it automatically regenerates the
new output source which means it automatically regenerates
the visual output results. Ten million times faster relative to
your speed puts it in real time.
Remember all you do is write specifications. Your's then
becomes a "one-write" activity on input while the software
engages in a "multi-write" activity on output. That means
you maintain only one source, the unordered input, and
automatically gain through the software all the different
outputs, visual and otherwise, that exist as options for your
selection.
If you understand the meaning, the implication (and
simplification) of all these features and functions in a single
tool, you're not the only one. Intelligent people following the
same logic come to the same conclusion: you only need one
comprehensive tool, one user interface, and one form of
source writing translating one form of user requirements. You
now see why the software tool vendors offered lip service
coupled with passive resistance to IBM's proposed AD/Cycle.
You may also come to understand why my friend and
collaborator Bob Blair has his focus on developing the front
end which includes the data repository/directory while I
prattle on the back end which produces all these visual and
text outputs. In the middle we have our "smartest" editor for
maintaining our unordered input source specifications, which
get checked against the front end and processed by the back.
You probably missed the other fact of using a relational
database to house the data repository/directory. You can
query to get a listing of all homonyms. Within any one family
of same "proper names", the text portion of the unique row
name, you can check all the contents at leisure, determining if
simplification, a reduction in number, is possible. If so, you can
have the effect of the reduction replicated in all affected
assemblies.
The point is that you now can administer the entire source of
an entire enterprise and that includes all documentation
within the enterprise, not just source code and source text.
You have a means of employing "literate programming"
technology to an entire enterprise from a single source.
If you are smart enough to know the difference, you will give
up on storing html "files", use the same tool for maintaining
websites as you do for programming as you do for enterprise
documentation. This means you can totally "integrate" the
information or knowledge base of an entire enterprise from a
single source data repository/directory. That means everyone
uses the same means for maintaining unordered source and
generating ordered output.
I thank you for your patience.
=====================================================
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
"rollin@scoug.com".
=====================================================
<< Previous Message <<
>> Next Message >>
Return to [ 29 |
August |
2003 ]
The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA
Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS
RESERVED.
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.
