Re: Useful Utility or Not?

• Previous message: Richard: "Re: Display enhancements"
• In reply to: Pete Dashwood: "Re: Useful Utility or Not?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: 19 Oct 2004 12:41:37 -0700

"Pete Dashwood" <dashwood@enternet.co.nz> wrote in message news:<2tkcmkF1tts50U1@uni-berlin.de>...
> "Kyle" <mr.kyle.t@netzero.com> wrote in message
> news:a6f09cae.0410110756.1b2a78ff@posting.google.com...
> > I've been out of CoBOL professionally since Y2K relegated me and my
> > Wang programming job to relational database and SQL coding. But the
> > new releases of CoBOL for networking platforms caused me to resurrect
> > a personal project. I call it Tables by Design and I'm wondering if
> > it has any commercial potential. It can provide greater flexibility
> > during application design resulting in less maintenance programming
> > after installation. Or so I believe.
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > I hope some of you will let me know what you think and if there is a
> > comparable utility already on the market. If you wish to correspond
> > privately, my e-mail is mr.kyle.t@netzero.com. Thanks for reading.
> >
> > Kyle
> >
> Hi Kyle!
>
> I think your idea is good, and it is so good that I would be surprised if at
> some stage in our careers, most of the old-timers here have not done
> something very similar. I can't speak for everyone here, but I wrote
> software templates that could be copied into COBOL source to define variable
> tables by replacing various values at compile time. That was in the 1960s.
> I'm sure I'm not the only one. Before the advent of Relational Databases I
> know of several courageous COBOL programmers who had a crack at writing
> dictionary type applications that would set up new records on ISAM files and
> keep track of all the fields in them. I did something similar, again with
> templates, which were then used to generate an access module (in COBOL) for
> the newly created ISAM file. You compiled the generated module and it gave
> you facilities for random and sequential fetching, creating, changing, and
> amending records on the ISAM file (That was in the 70s... progress...<G>).
> By the late 80s and (again for PCs in the mid 90s) I wrote a utility to
> convert the ISAM files into Relational databases, and I have used relational
> databases ever since.
>
> The main reason for this is that they are open and do not lock COBOL into a
> closed file system. Users are not happy about needing a COBOL program to be
> written every time they want a new report from their ISAM file. As we see
> more computer literate users arriving on the scene (many Business users now
> know SQL) they expect to be able to make their own ad hoc enquiries and RDBs
> let them do so.
>
> The bottom line on all of this as far as you are concerned is that tables
> defined with OCCURS are totally tied to COBOL, suffer from the limitations
> of being static rather than dynamic, and are riding on what may well be a
> dying horse.
>
> RDBs do provide most of the same functionality without the limitations, and
> include CONSTRAINTS and INDEXES as Robert explained in his posts.
>
> If you proceed with this (and you certainly should if you believe what you
> have is useful), my advice would be not to invest a lot of money in it.
> Consider it a niche market (COBOL shops) with a limited percentage of
> potential customers. Experience has shown (at first hand, I can assure you)
> that there is often strong resistance by programmers to "what was not
> invented here" even when it is good, if it affects what they code.
>
> Try and get the ear of one good site, demo it and show the advantages, let
> them have it cheap, provided they will act as a reference, and then use them
> as a reference site to sell others. It is a backbreaking long hard road and
> you will encounter much frustration. On the whole, writing code is much less
> hassle.
>
> I can tell you about one case back in the 80s where I had developed (for
> mainframes) something that took two full years to write, could cut the time
> to develop systems significantly and was really, for me, a "killer
> application". I managed to get the ear of British Aerospace and was pretty
> excited when they agreed to let me demo it. The demo went like a dream, the
> audience of Senior Programmers and IT people gave it a big "thumbs up" and
> were enthusing about it. The IT manager said he was going to request it be
> purchased, I felt we had a deal and my wife was already spending the
> money... <G>.
>
> The Accountants refused to buy it. The people who needed it recognised it
> was great, but the people who held the purse strings decided that as things
> were currently being produced OK, it must be an inessential tool (which, I
> guess it was, but many useful tools are not ESSENTIAL - you don't NEED a
> power drill if you have a brace and bit...), and I was NOT IBM... so that
> was that.
>
> Totally disheartened I slunk off back to NZ where I was soaking in a hot
> pool, when I had an even better idea <G>...
>
> Nevertheless, I wish you every success.
>
> Pete..

I figured it was such an obvious thing that it would've been done and,
as you say, it has been many times over. I just never saw or heard of
it's use anywhere but then, the last manager I worked for, wasn't even
sure of what CoBOL was. I understand and agree with the limitations
of ISAM -vs- database, but some of the nested reports I've written in
database, were alot tougher to fine tune, but that's probably the
experience factor.

I'll continue to use my utility here on any applications I develop.
Thanks for the encouragement.

Kyle

• Previous message: Richard: "Re: Display enhancements"
• In reply to: Pete Dashwood: "Re: Useful Utility or Not?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]