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: Rene_Surop on 24 Jul 2008 03:19 > 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. For a 'heavy' RDBMS setup (30GB), reading a portion of it is a heavy load for the application. Your platform needs more resources. It is on HOW you use it basically.
From: Anonymous on 24 Jul 2008 08:07 In article <40a57f48-8a38-4b5c-a4ee-2378f9005a10(a)u12g2000prd.googlegroups.com>, Rene_Surop <infodynamics_ph(a)yahoo.com> wrote: [snip] >Extracting small portion of data into a 'small' (4GB) ISAM file is >faster. > >For a 'heavy' RDBMS setup (30GB), reading a portion of it is a heavy >load for the application. Your platform needs more resources. > >It is on HOW you use it basically. What's this... are you saying that a SmartCar is better for some purposes while a limosine is better for other purposes and a large truck/lorry is better for yet other purposes? They can't *all* be 'better', can they? *Every* situation is to be approached with the same set of tools, full stop/period... oh, and I am the King of England, God Save the Me! DD
From: Howard Brazee on 24 Jul 2008 09:36 On Thu, 24 Jul 2008 13:28:52 +1200, "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote: > >That's a bit unfair, Howard. > >The COBOL file system on Windows desktops was not implemented to make up for >Windows shortcomings, it was because you can't call it "COBOL" unless you >provide these modules of the language. Mainframes come with data access and update tools - accessible by whatever languages we prefer. >You might as well say that Indexed Sequential files on mainframes were >invented because of shortcomings in the IBM OS. > >[/Pete] I don't think "Mainframe" and "IBM" as being the same thing. When IBM added its 3 types of VSAM files, they were enhancing their file access methods to match what other mainframe systems called indexed, flat, and relative files. Windows not having mainframe type file access systems is only a shortcoming for those who intend to access that kind of data - which is a distinct minority. On the other hand, mainframes have a shortcoming in not being able to put them in a brief case to create a powerpoint presentation to the big boss. But CoBOL is for business processing for computers with business type data files or databases. Some people try to make Windows machines fit this need, and find that they have to add on the basics that are needed for that purpose.
From: Howard Brazee on 24 Jul 2008 09:37 On Thu, 24 Jul 2008 12:07:57 +0000 (UTC), docdwarf(a)panix.com () wrote: >What's this... are you saying that a SmartCar is better for some purposes >while a limosine is better for other purposes and a large truck/lorry is >better for yet other purposes? > >They can't *all* be 'better', can they? *Every* situation is to be >approached with the same set of tools, full stop/period... oh, and I am >the King of England, God Save the Me! Certainly. And each also has shortcomings.
From: Howard Brazee on 24 Jul 2008 09:43
On Wed, 23 Jul 2008 21:45:21 -0500, Robert <no(a)e.mail> wrote: >Most professionally developed Cobol systems abandoned indexed files and switched to >databases, starting in the 1980s. The ones still using indexed files tend to be amateurs >and small shops, who stayed with indexed because databases were expensive. That reason >disappeared in the late 1990s when full-featured free databases such as PostgreSQL and >MySQL became available. I'd like to see stats if you have them. But I want some detail on what a "CoBOL system" is. It's really hard to compare a shop with a CoBOL program running on a few dozen PCs, and a mainframe shop with thousands of programs being run. The last shop I worked at that wasn't primarily database centered was in 1980, but I haven't yet worked in a shop that has abandoned every one of its indexed files. >>They are also considered to be Closed systems. Accessing >>them by external clients or customers would require creating >>new programs to get into the data with the desired formats. > >There are ODBC drivers for proprietary Cobol file systems that allow any SQL tool to >access the data. The drivers are not free. >http://www.datamystic.com/datapipe/odbc_vendors.html > >There are free programs to translate a Cobol indexed file to CSV (comma delimited), which >can easily be loaded to a database or spreadsheet. I posted the source for one here. It >uses a copybook defining the Cobol file. It's very easy to write such a program, but I've only written them for files to be downloaded into spreadsheets - whenever I extract for databases, I've either used undelimited data or gone direct to the database. |