SCOUG-Programming Mailing List Archives

Date:	Sat, 17 Apr 2004 23:14:52 PDT7
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-programming@scoug.com
To:	"SCOUG Programming SIG" <scoug-programming@scoug.com >
Subject:	SCOUG-Programming: A Good Meeting

Content Type: text/plain

I particularly enjoyed today's meeting. It illustrated the actual
progress that continues in the OS/2 arena to help level the OS
playing field in spite of M$ and IBM's intent to squeeze us out
of business. We all need to do our homework in trying at
least one Window's application with the Innotek runtime. I
frankly think that we have a viable solution and substitute for
our email server thanks the to effort of Bob Blair. While
Peter continues to inject his own agenda for "broadcasting"
OS/2 replete with background music we can enjoy now his
second straight month in attending in hopes that we can
continue his string unbroken.

I covered considerable territory in several related areas
pertaining to software development. I would like to review
them in some coherent manner here to ensure that I have
managed to communicate them properly.

You need to understand that IBM's industrywide AD/Cycle
project failed due to the threat its success meant to the
numerous vendors wanting to protect their territory(ies) laid
out within their proprietary products. You have a seamless,
five-stage software development process (SDP). You have an
array of vendor products, each of which defined its "territory"
within that process. No seamless path through any sequence
of the different vendor products existed.

This leads to the fact that in the entire history of the IT
profession only one single instance, pointed out by Bob Blair
with reference to NASA, exists in which an actual
implementation of the SDP has ever occurred. That one
exception made the investment in a human process
supplemented by software whose cost, necessary for the
success of the mission, exceeded that acceptable to other
enterprises. For less than what they invested in manual effort
NASA could have written the software tools, but chose not to.
Had they done so no need for AD/Cycle would exist, no
multitude of vendors with proprietary software tools would
exist, and this particular quest (thank you , Peter) would not
exist.

For the the vendor products to mesh somehow into a seamless
whole they would have had to agree on a set of interfaces.
To agree on a set of interfaces they would have to agree on
a set of activities, each of which represented within an IPO
(Input-Process-Output) model. That means that they would
have to agree on one or more seamless paths through the SDP
with all the activities (processes) and the interfaces (inputs
and outputs). In short they would have had to decompose the
five stages of the SDP down to the elementary activities and
their interfaces, the set of completely defining IPOs.

Having done so, again using "standard" interfaces at least at
the product level would have obviated their proprietary
"protection", leaving them vulnerable to encroachment by
their competitors. So AD/Cycle did not fail due to any
deficiency in or impossibility of the SDP, but instead to the
implications of its success.

Nevertheless IBM would have screwed up the Data Repository
for the simple reason that it did. It had nothing to do with
moving it from OS/2 (and the Intel platform) to MVS, though
that certainly detered 85% of the marketplace. It had to do
with choosing too complicated an implementation using DB2.
The KISS principle get ignored any time you assembly a group
of bright people with the opportunity to explore and play with
tens, eventually hundreds, of millions of dollars.

Not having that level of opportunity I chose instead to remain
with the KISS principle. I developed a Data
Respository/Directory based on a relational database doing
something that apparently no one else ever considered doing:
applying a PICS (Production and Iventory Control System) to
software. That system relies on a set of raw materials, in this
instance source statements, from which you can produce an
unlimited number of assemblies. These assemblies exist as
BOMs (Bills of Material). Any assembly decomposes down to
other assemblies or raw materials. A pure manufacturing
concept.

To implement it means storing each unique source statement
once in a table in a database. This requires that you have a
unique key, i.e. name, for each source statement. The
software, not the user, determines that unique key. While the
use may name assemblies as he does now with procedures,
subroutines, functions, and include statements, the software
names the source statements.

It does this based on the content of the source statement.
For example, suppose you had the source statement "mommy
= sqrt(alfred) / betty + david;". In PL/I you can eliminate all
the blanks separating the tokens to produce a compressed
"mommy=sqrt(alfred)/betty+david;". If you take the first 16
bytes of this "mommy=sqrt(alfre", you can use as a key field.
To ensure its uniqueness you can append it with a 4-byte, i.e.
fullword, binary index value. Thus you have two fields, a key
field and an index field, providing a unique key field for this
row in a table.

This does two things. One, it allows for homonyms: same key
value (name) but different referent. Two, as it does this for
both assembly names as well as source statements it provides
automatic version control throughout all hierarchical levels
within any body of software as a builtin function, not one you
have to add or select.

Thus every source statement and assembly has a name.
Furthermore assemblies exist as a list of one or more names
of other assemblies, i.e. sub- or lower-level or co-routines,
and raw material (source statements). Thus a program exists
as a high-level assembly consisting of one or more lower level
assemblies and raw material (source statements).

In short you have a pure manufacturing process with all the
inherent reporting possibilities. Through the query support of
the relational database, i.e. SQL, you can request a
"where-used" listing of any source statement or assembly as
well a a detailed BOM explosion of any assembly, e.g. a
program.

This means you can store all of the software of an enterprise
in a single database, make a change to a single statement,
creating a new unique statement or different version of the
previous (if the name, the 16-byte, prefix hasn't changed),
and make a query regarding all affected assemblies. You can
review each assembly with respect to making the change,
selectively designating them, ask for the names of the
different programs (high-level assemblies) affected, and
receive a list of those names, which you can now submit as a
whole for "recompilation".

If you are also smart enough to recognize that it is not
necessary to limit a compilation to a single program, but allow
an unlimited number on input, you can a a single unit of work
recompile all programs. This guarantees the synchronization
of change regardless of the number of programs involved.

You get all this by moving source creation and maintenance
from a file system to a database manager that stores source
statements only, treating all assemblies as a list of one or
more names of other assemblies and source statements. As
you can see the software has no problem creating names for
the source statements as well as insuring that no duplicates
exist within the database.

If you understand the principle of pattern recognition of text
within a source statement or its abstracted form within its
syntax, you can use standard search queries to further refine,
reuse, and simplify source statements. You can apply a similar
pattern recognition to assemblies, i.e. lists of names.

This allows you to deal with source as data irrespective of its
use. This replaces as well as enhances all the functional
capabilities of existing library maintenance software. In short
you not only have builtin versioning support more than exists
in any versioning product but builtin library maintenance
support more than any library product. All this in going from a
file management system to a database manager with the
query capabilities of SQL.

Whatever IBM's data mining capability which derives from its
experience with the Data Repository in AD/Cycle it does
nothing with respect to program source maintenance, its
original purpose. So much for neglecting the KISS principle.

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

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

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

Return to [ 17 | April | 2004 ]

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.