In praise of compiler writers
in [Cobol]
|
From: Howard Brazee on 13 Apr 2010 11:42 On Tue, 13 Apr 2010 14:14:06 +0000 (UTC), docdwarf(a)panix.com () wrote: >>I have coded internal comb sorts, because my version of CoBOL doesn't >>do table sorts. It's not very complicated (and structured >>programming makes it so that maintenance programmers don't really need >>to look at those paragraphs), and it's quick. That said, if I had a >>table sort, I would have used it. > >In the words of the Oldene Dayse, Mr Brazee, 'If my Grannie had wheels >she'd be a trolley-car'. Even as recently as '03 the IGYCRCTL compiler >(to the best of my knowledge) did not support table sorts... I seem to >recall that the version of Microfocus I worked with (1.8.something?) did. Also, back in the day, if you needed a sorted table, you read a sorted table. And often with SQL, we can still do that. But in my case, I had to do a some database walking to build the table that I wanted sorted. It's a nice feature, but CoBOL changes come slowly. -- "In no part of the constitution is more wisdom to be found, than in the clause which confides the question of war or peace to the legislature, and not to the executive department." - James Madison
From: HeyBub on 15 Apr 2010 08:18
Pete Dashwood wrote: > HeyBub wrote: >> After getting some complaints from our users about the seeming >> inefficiency of a particular process, I had a look at the code. >> >> The programmer who wrote the code used an internal bubble sort to >> rearrange the data and find duplicates. Some 3,000 entries consumed >> as much as two minutes of clock time. >> >> "Screw this," I cried. I ripped out the couple hundred lines of code >> involved and replaced it with a simple ISAM file which summed the >> duplicates into a single entry. >> >> The process went from the aforementioned two minutes to FOUR SECONDS >> ! I considered replacing the ISAM stuff with the SORT verb, but I'm not >> a fanatic about micro-efficiency. > > Good stuff, Jerry! > > It is a bit ironic that in this last week I too used an ISAM file as > paged storage for an internal process. The pages needed to be 8K and > SQL Server doesn't like columns that big... I also wanted the > software to be independent of the RDB so ISAM looked pretty obvious. > Fortunately the pages are completely dynamic, created as needed, > deleted when their usefulness is over, accessed randomly, and the > file gets recreated every day as part of start-up housekeeping, so > issues of maintenance don't arise. It made me smile because the > whole thing is a data base application but without this ISAM file it > wouldn't work.:-) > They still have their uses. > Yep. And as far as "shop standards" are concerned, I'd wager that all my processing was done without ever writing anything to the disk - that is, it was all done at RAM speed in internal buffers. Maybe we could use a "CLOSE WITH DELETE" verb - the file (if any) is deleted automatically when you're done with it. As an aside, I was amazed some time back to discover that an ISAM file was half the size of the oringingal text file. In spite of additional records governing pointers and overflow areas and the like, the file system compressed out multiple blanks before committing the data to the disk. Inasmuch as this was a text file, with oodles of blanks, the saving was, obviously, significant. |