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: softWare design on 23 Jul 2008 15:29 Hi Folks, 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, and perhaps it should be replaced by RDBs wherever possible. Thus my question is: Why Cobol's vendors do not develop their indexed file systems to be as open and robust as, file systems in database management systems such as SQLs, SAP and Oracle? Appreciate your comments.....
From: Michael Mattias on 23 Jul 2008 16:14 "softWare design" <sabraham(a)baxglobal.com> wrote in message news:ad48ac76-1b00-452e-b289-22d66a366228(a)56g2000hsm.googlegroups.com... > > Why Cobol's vendors do not develop their indexed file > systems to be as open and robust as, file systems in > database management systems such as SQLs, SAP and > Oracle? First, comparing COBOL [compilers] with SAP and/orOracle[is comparing applies and oranges. COBOL is a programming language, SAP an applications suite, and Oracle either a DBMS or application suite. COBOL v SQL is a fairer comparison in that both are standard 'languages')....however, neither has anything do with "openness" beyond its officially supported syntax. "Robustness" is more appropriately considered in the context of brand comparisons of like products. Second - a guess to answer the question as I think you meant to ask it.. or perhaps answering the question which should have been asked.... COBOL compliler vendors do not offer more extensive data access facilities because vendors as of COBOL compilers they are concerned with supporting the COBOL access verbs, not with trying to create a competive standalone DBMS; nor are they particularly interested in supporting access by non-COBOL-developed programs, since that would be cutting their own throats. FWIW, many vendors do offer "Applications Programming Interfaces" to their own DBMS systems, supported by the COBOL "CALL" verb. If you don't like the 'native' file management system provided by the compiler vendor, you are perfectly free and able to use another data management scheme.... bearing in mind those other systems have no obligation to support the COBOL syntax for media storage access. MCM
From: Howard Brazee on 23 Jul 2008 16:22 On Wed, 23 Jul 2008 12:29:57 -0700 (PDT), softWare design <sabraham(a)baxglobal.com> wrote: >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, and perhaps it >should be replaced by RDBs wherever possible. > >Thus my question is: > >Why Cobol's vendors do not develop their indexed file >systems to be as open and robust as, file systems in >database management systems such as SQLs, SAP and >Oracle? > >Appreciate your comments..... I suspect most CoBOL developers work with mainframe & mini computers. In that case, they use the same file systems as everybody else. So I infer that you find indexed file systems used by Windows based CoBOL programs to be less than robust. Those are where the file system had to be created by compiler makers to make up for Windows shortcomings. I haven't had experience with them - what are their lacks?
From: softWare design on 23 Jul 2008 17:49 On Jul 23, 1:22 pm, Howard Brazee <how...(a)brazee.net> wrote: > > I suspect most CoBOL developers work with mainframe & mini computers. > In that case, they use the same file systems as everybody else. > > So I infer that you find indexed file systems used by Windows based > CoBOL programs to be less than robust. Those are where the file > system had to be created by compiler makers to make up for Windows > shortcomings. I haven't had experience with them - what are their > lacks? Yes, I am referring to indexed file systems that are created by compiler makers on Windows based networks (2k and XP). They tend to get corrupted frequently for various reasons especially when storing massive number of records. 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.
From: Richard on 23 Jul 2008 18:55
On Jul 24, 7:29 am, softWare design <sabra...(a)baxglobal.com> wrote: > Hi Folks, > > 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, What survey data did use to come to this conclusion ? On mainframes and many other systems the 'Cobol file system' is the 'Operating System's file system'. > and perhaps it > should be replaced by RDBs wherever possible. Being replaced by RDBs was for the functionality, not because of lack of access. > Thus my question is: > > Why Cobol's vendors do not develop their indexed file > systems to be as open On Unix and DOS/Windows where there is no built-in indexed file system many Cobols give the facility to use C-ISAM (which was adopted by X/ Open as a standard) and/or BTrieve which is common with Netware. Several also use a call interface which allows replacement of the file system by some other and/or use of the called routines by other languages. > and robust as, file systems in I find that the Microfocus and Fujitsu indexed systems to be robust. But then I use these on Linux. > database management systems such as SQLs, SAP and > Oracle? These file systems are proprietry and are _NOT_ 'open'. |