Cobol's File System Vs. RDBMs...
in [Cobol]
|
Prev: COBOL: Don`t Call It a Comeback
Next: All X'0D' lost during reading line sequential file using microfocus se
From: HeyBub on 24 Jul 2008 12:42 Pete Dashwood wrote: > > (Don't take HeyBub's post seriously... he is winding you up... :-)) > You think? The biggest screw-up I ever saw was a shop that turned loose EasyTrieve to all the analysts. Change the spelling on one lease name? No problem, couple of statements. Presto! The names of 240,000 leases were all changed to the same thing. Try to compute the pressure on an oil well pipe where the record says the bit is at a depth of MINUS 18,000 feet! That translates into three miles of pipe sticking up in the air! What's the sense of having data validation in an edit program if some weasel can come in downstream and diddle with the data? I had to write a report writer program. By actual count, 2700 of the 3000 statements were to check (and correct) the data on a master file! I should have known; when I asked in what order the data were in, I was told: "It depends on what we did with the data before you get it." "You, uh, SORT the master file?" I asked. "Sure," said the manager.
From: Howard Brazee on 24 Jul 2008 13:05 On Thu, 24 Jul 2008 11:42:49 -0500, "HeyBub" <heybub(a)NOSPAMgmail.com> wrote: >Change the spelling on one lease name? No problem, couple of statements. >Presto! The names of 240,000 leases were all changed to the same thing. Let them retrieve with EasyTrieve, but don't let them update. The biggest similar screw-up I've seen was when someone wrote a script to change everything screen by screen. Not much we can do to stop that. >I had to write a report writer program. By actual count, 2700 of the 3000 >statements were to check (and correct) the data on a master file! I should >have known; when I asked in what order the data were in, I was told: "It >depends on what we did with the data before you get it." > >"You, uh, SORT the master file?" I asked. > >"Sure," said the manager. Sorting it then overwriting it with the sorted copy? I'm not quite understanding why. Must have been some space problem in a shop without keyed files. I did know of a shop that did not have a sort utility. To sort, it added an ISAM key and copied by key order. But I haven't come across the opposite. A typical process in lots and lots of shops was: 1. Copy and sort the master file. 2. Use the temporary file for the report.
From: Robert on 24 Jul 2008 13:24 On Thu, 24 Jul 2008 00:19:45 -0700 (PDT), Rene_Surop <infodynamics_ph(a)yahoo.com> wrote: >> As for Windows implementations of the COBOL file system being flaky, I've >> been using it for more than twenty years and have never experienced data >> corruption with either Fujitsu or MicroFocus implementations under Windows >> or DOS. But then, I've never used it to store 64 million records... :-) >> >> If proper regular housekeeping and reorganization is done, there is less >> likely to be trouble. >> >> It is certainly true that if programs abend, and proper cleanup is not >> instituted, there is a risk of data corruption. But that has ALWAYS been >> true on mainframes OR PCs. RDBMS automatically take care of this and that is >> one reason why they are perceived as more "stable". >> >> Pete. > >I agree. > >I am using Cobol ISAM files for "regular" data processing.... but >eventually use RDBMS for data warehousing. The benefit of using ISAM >file is initially on 'how' you design and properly read a recordset. >Extracting small portion of data into a 'small' (4GB) ISAM file is >faster. You could get the same speed improvement with a temp table or indexed view.
From: softWare design on 24 Jul 2008 13:51 On Jul 23, 3:55 pm, Richard <rip...(a)azonic.co.nz> wrote: > > What survey data did use to come to this conclusion ? > The inability to insert new columns into an existing index file. You have to create a new index file and then transfer the old data into the new file, change the copybook and recompile every program that accesses the file, whether or not they care about the new columns.
From: Howard Brazee on 24 Jul 2008 14:17
On Thu, 24 Jul 2008 10:51:14 -0700 (PDT), softWare design <sabraham(a)baxglobal.com> wrote: >On Jul 23, 3:55�pm, Richard <rip...(a)azonic.co.nz> wrote: >> >> What survey data did use to come to this conclusion ? >> > > >The inability to insert new columns into an existing index file. >You have to create a new index file and then transfer the old >data into the new file, change the copybook and recompile >every program that accesses the file, whether or not they >care about the new columns. Looking back, the conclusion in this thread is: >>> Many years ago most Cobol developers have came to the >>> conclusion that Cobol's file system is closed, especially >>> when access to corporate data is required, This leads me to ask: 1. What do you man by columns in an index file? 2. What is the relationship between being open or closed and being able to add columns? I'd argue that databases are by design, more closed than files - because security and privacy needs have been integrated with their designs. Files (not "CoBOL files"), on the other hand, are just hunks of data open for anybody to use. |