Re: Useful Utility or Not?
From: Robert Wagner (robert_at_wagner.net.yourmammaharvests)
Date: 10/12/04
- Next message: LX-i: "Re: Programmers needed"
- Previous message: William M. Klein: "Re: Working draft of 2 TR (Technical Reports) for new (or newly standardized) COBOL functionaliilty"
- In reply to: Kyle: "Useful Utility or Not?"
- Next in thread: Kyle: "Re: Useful Utility or Not?"
- Reply: Kyle: "Re: Useful Utility or Not?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 11 Oct 2004 22:47:43 GMT
On 11 Oct 2004 08:56:53 -0700, mr.kyle.t@netzero.com (Kyle) wrote:
>By tables, I'm referring to those CoBOL "Search"able structures of
>data which use "occurs" and "indexed by" in their definition, are for
>the most part static in content and whose main function is the support
>and definition of data within dynamic or primary files. As a
>programmer, I've spent significant hours coding in support of these
>data structures. With this utility, that task has been eliminated.
With fast machines, the need to load tables into OCCURS has been
eliminated. Just read entries from the file or database. Let the file
system manage memory (caches). As a side benefit, the arbitrary limit
on table size is eliminated.
>Using the utility, I can create up to 999 table layouts of up to 999
>entries in each table. In the typical "data dictionary" way, up to 24
>fields or 150 characters per table entry, can be defined within each
>table. Generic programs are used to enter data, display and report
>table entries. Working-Storage and Procedure Division load paragraphs
>are created and a single Select, FD and Open statement are all that is
>needed to load as many tables as a program may need to use.
>Documentation about fields is a by-product of the table definition
>process and is available, even at the end-user level, when making data
>entries.
Database schemas offer the same convenience in documentation and
utility update. They also free the data from Cobol.
Take a look at Ryan McFarland's Relativity, which comes at the problem
from the opposite direction. It turns ISAM files into ODBC 'data
sources'.
>A unique feature, perhaps, is the ability to use table '921' in table
>'922' to establish relationships between and/or validation of the data
>being entered to individual fields. Some of the tables in the
>application I wrote using the utility, are used exclusively to
>validate data in other tables.
'Constraints' are a common database feature.
>The utility is currently a Window's application written with Fujitsu's
>PowerCOBOL 7.0 using the CoBOL85 scripting language option. The file
>structures are traditional flat, ISAM files though I believe the
>concept could work with a database structure as well.
It works better when the database dog wags the Cobol tail.
>I hope some of you will let me know what you think and if there is a
>comparable utility already on the market.
If I were doing it with inline code, I'd use a collection class rather
than OCCURS. It can dynamically size the collection at execution time
and populate it with a single INVOKE. Search would INVOKE find rather
than the SEARCH verb.
- Next message: LX-i: "Re: Programmers needed"
- Previous message: William M. Klein: "Re: Working draft of 2 TR (Technical Reports) for new (or newly standardized) COBOL functionaliilty"
- In reply to: Kyle: "Useful Utility or Not?"
- Next in thread: Kyle: "Re: Useful Utility or Not?"
- Reply: Kyle: "Re: Useful Utility or Not?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
