Good question Walter.  My client (Union Camp) has chosen to use a "phased
approach" to implement their Y2K applications as they complete the
remediation / test cycle.  This is permissible since most of their apps use
Image databases, and ALL of their apps follow their shop standard of doing
database I/O with the "all list" into a large generic buffer, then moving
the received data into copylib record buffers.  This doesn't address the
applications which deal with KSAM and flat files.  They don't want to have
to remediate ALL the programs which touch a flat file with a date in it
before they can implement the main program which uses it.  The problem
described in my first post (COB ERR - FD doesn't match actual file...)
prohibits  that.

I know I could just "recompile the program" with the updated copy lib to
fix the problem, but there is more to it than that.  We call it "pulling
threads".  You find that the file is also used down stream in an end of day
(month, year, millennium (sp?)) job, so that job must be remediated also.
Then you find job streams with FCOPY's, SUPRTOOL's, etc extracting pieces
of this flat file using byte offsets, so they too must be remediated before
you can implement the simple little application at the "top of the thread".

We have over 500 KSAM and flat files in addition to the Image database
files in this 1980-1984 application.  The application is well used, well
written, and well maintained.  But it is very custom, and very intertwined.
Here at UC, a very small Information Systems staff keeps 11 large plants
around the country running on this application.  For almost 20 years, they
have made modifications to the code to keep the application healthy,
efficient and doing the RIGHT job for their plants.  The result of this is
a data structure that is less than ideal from a DBA purist's perspective.
But hey, it does the job, it serves the customer (the plants) so it can't
be all bad.

This application is yet another quiet testimony to the value of the HP
3000.
<RANT>I just wonder whats going to happen when they put up their first
plant on that B>>> word replacement application next month.  They have
already had to buy O>>>> and two large HP 9000 K class machines to support
B>>>.  I bet I will be able to hear the workers in the plants screaming all
the way back to Florida when they work on B>>> as compared to their trusty
HP 3000 VPlus Turbo Image COBOL applications.</RANT>

Well, hope this explains the reason from my question yesterday.  Thanks to
all who responded and called.



Subject:  Re: Cobol Experts!




Joe Howell ([log in to unmask]) wrote:
: My brain must not be working well this morning.  I am working on a Y2K
: remediation effort for a client, and we would need to get around the
: infamous error quoted below.  Yes, I know that older versions of CM Cobol
: did not enforce file sizes in FD's and now NM COBOL 85 does.  My question
: is, isn't there a way (COBRUNTIME?) to tell Cobol to ignore this
offending
: condition?  (for the time being, anyway) I looked up the COBRUNTIME
: settings on LaserRom and they didn't seem to address this problem.

Just curious.  Rather than compile with the ANSI74 entry point or
the STAT74 control option, to get around the error, why not correct
the error by fixing the program to correctly describe the file?

Walter Murray
Hewlett-Packard
Support Technology Lab