SCOUG Logo


Next Meeting: Sat, TBD
Meeting Directions


Be a Member
Join SCOUG

Navigation:


Help with Searching

20 Most Recent Documents
Search Archives
Index by date, title, author, category.


Features:

Mr. Know-It-All
Ink
Download!










SCOUG:

Home

Email Lists

SIGs (Internet, General Interest, Programming, Network, more..)

Online Chats

Business

Past Presentations

Credits

Submissions

Contact SCOUG

Copyright SCOUG



warp expowest
Pictures from Sept. 1999

The views expressed in articles on this site are those of their authors.

warptech
SCOUG was there!


Copyright 1998-2024, 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.

The Southern California OS/2 User Group
USA

SCOUG-Programming Mailing List Archives

Return to [ 27 | March | 2006 ]

>> Next Message >>


Date: Mon, 27 Mar 2006 09:25:18 PST8
From: "Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To: scoug-programming@scoug.com
To: < "scoug-programming@scoug.com" > scoug-programming@scoug.com >
Subject: SCOUG-Programming: Data Repository/Directory

Content Type: text/plain

Gosh, Uncle Lynn goes away for a weekend for event political.
He comes back to view a SQL merry-go-round. Before he left
he felt good that he didn't miss Bob Blair's presentation at the
last meeting, as apparently once more presenters extended
the 55-minute hour beyond all bounds. Maybe the great
scheduer in the sky will insure at the April meeting, which I
fully expect to attend, that Bob has enough time on the
schedule for his "Introduction to PM Progamming"
presentation. I'm sure Nathan who believes that at least six
months necessary to get comfortable with PM programming
would like to see that occur in real time, not SCOUG time.:-)

I didn't want to bother in my description of the Data
Repository/Directory (DR/D) with anything other than possibly
implementing it using a relational database manager. In truth
we have three basic forms of database managers: network,
hierarchical, and relational. You can implement the DR/D with
any of them with the same results logically. I would actually
prefer to use hierarchical for performance reasons as no other
to date has out hustle IMS or VSE DL/I.

I don't know how Greg overlooked the fact that the "unque
name" consists of two columns, a 16-byte text name and a
4-byte, full-word binary index. The the alias table consists of
four columns representing the "pairing" of two unique names.
The "association" comes from having them appear together.

You have three forms of analysis: classification, structure, and
operation. All three have a membership list under a single
name. In one, classification, this list can appear in any order,
meaning that it order is unimportant relative to membership.
The other two, structure and operation, imposed an order
upon the member ship. Thus you need two tables, one for
membership within a name, the other for order within the
membership.

Neither has anything to do with how a relational database
works as long whether or not it returns an ordered list. The
ordering that occurs here does so by association just as it did
in the alias table. Thus it remains independent of any
database manager use.

The DR/D interface, that which sits between the editor and
the database manager, makes the request, in this instance in
the form of an SQL query, and constructs the statement order
based on the "associations" returned, which it then passes to
the editor for presentation. Thus it does not depend upon SQL
ordering anything.

Though initially we will use a relational database manager,
open source or not, eventually in keeping with the only one
language necessary philosophy this too will need implementing
in SL/I...or whatever language of choice.

Greg will have to forgive Uncle Lynn for his reliance upon his
experience with bill of material processing in manufacturing
and distribution accounts which began with punch cards
shifted to BOMP (Bill Of Material Processing) files (sequential
files on tape drives) to DBOMP (Disk BOMP) to DL/I (COPICS)
(Communications Oriented Production and Inventory Control
System) using CICS, and more recently (in IBM) to DB2 and
SQL (in the AS/400). In all of them we had the means to
produce ordered lists...as in punch cards, files, and
database.:-)

Thus when I apply manufacturing processing techniques to
source management because I see "raw material" in source
statements (code) and in source sentences (text) and their
different (hierarchical) levels of assemblies I didn't really
expect anyone to have concerns about whether or not an
ordered output could result.

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

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

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


>> Next Message >>

Return to [ 27 | March | 2006 ]



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.