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: Pete Dashwood on 25 Jul 2008 07:19 <docdwarf(a)panix.com> wrote in message news:g6c68j$cq3$1(a)reader1.panix.com... > In article <r79i84dhrco810pud78m84uucod1kmiqr7(a)4ax.com>, > Robert <no(a)e.mail> wrote: >>On Thu, 24 Jul 2008 12:37:33 -0700 (PDT), softWare design >><sabraham(a)baxglobal.com> wrote: >> >>>On Jul 24, 11:17 am, Howard Brazee <how...(a)brazee.net> wrote: >>>> >>>> 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? >>>> >>> >>> >>>Suppose I want to change my data model by adding a column >>>to a table (field to a file record). With a relational database >>>I add the column and the job is done. Any program that needs >>>to work with that new column can on-the-fly, and any existing >>>programs that do not care about the change stays untouched. >> >>Alternatively, leave the original file unchanged and put the new >>column(s) in a another >>file. Programs interested in the new data will have to join the two >>files, while old >>programs need not be changed. > > Decades on back I was taught a part of the Zen of Programming: > > 'What does a programmer do when given an 80-character record?' > > 'Reserve ten characters for future use.' > > It used to be a common tecnique; a chunk of space - in the example above > at least enough to contain a decent-sized key to an indexed dataset - was > left as FILLER. > > When new uses were found the FILLER decreased... and when the FILLER > finally disappeared it was the job of anyone who dealt with programs that > touched the file (or who dealt with the programmers who dealt with the > programs) to say 'The system has reached its design limits and budget must > be allocated to compare former needs with current ones so that a plan > might be developed which results in a better meeting of our changed > requirements. A newly-married couple or a family with two snall children > can fit comfortably into a compact car; as they age or family size > increases a different vehicle is needed for comfort... this is a > predictable result of growth.' > > DD > Like you say, that was decades ago... The advent of systems that can dynamically allocate more space indefinitely as required kind of rendered it redundant. Pete. -- "I used to write COBOL...now I can do anything."
From: Anonymous on 25 Jul 2008 07:54 In article <6etr5fF8qfmiU1(a)mid.individual.net>, Pete Dashwood <dashwood(a)removethis.enternet.co.nz> wrote: > > ><docdwarf(a)panix.com> wrote in message news:g6c68j$cq3$1(a)reader1.panix.com... [snip] >> When new uses were found the FILLER decreased... and when the FILLER >> finally disappeared it was the job of anyone who dealt with programs that >> touched the file (or who dealt with the programmers who dealt with the >> programs) to say 'The system has reached its design limits and budget must >> be allocated to compare former needs with current ones so that a plan >> might be developed which results in a better meeting of our changed >> requirements. A newly-married couple or a family with two snall children >> can fit comfortably into a compact car; as they age or family size >> increases a different vehicle is needed for comfort... this is a >> predictable result of growth.' > >Like you say, that was decades ago... > >The advent of systems that can dynamically allocate more space indefinitely >as required kind of rendered it redundant. Space could be allocated indefinitely - within the limits of the Operating System and such; I recall something about the WANG VS not allowing records larger than 2,000 characters - in the systems described, Mr Dashwood... but it required a bit of attention and questions along the lines of 'what causes us to do this?' and 'how should we best structure our efforts?' It seems similar to the Eternal Struggle between 'look before you leap' and 'he who hesitates, is lost'. DD
From: Anonymous on 25 Jul 2008 08:02 In article <6etqhuF8q2c8U1(a)mid.individual.net>, Pete Dashwood <dashwood(a)removethis.enternet.co.nz> wrote: > > ><docdwarf(a)panix.com> wrote in message news:g6c6hj$srk$1(a)reader1.panix.com... >> In article <6esodiF8oskkU1(a)mid.individual.net>, >> Pete Dashwood <dashwood(a)removethis.enternet.co.nz> wrote: [snip] >>>IT does NOT own the data and IT should not have exclusive access to it. >> >> Mr Dashwood, this needs clarification. There are, I believe, several >> kinds of access. >> >> Who do you believe to have the responsibility for insuring the accuracy of >> data used for a company's vital (including, but not limited to, strategic, >> tactical, structural and legal-compliance) data? > >Er... that would be the corporate insurers... Phoenix Life, maybe...? :-) > >If you mean ensuring the accuracy of data, then whoever is manipulating it >takes responsibility for the manipulations they apply. No, Mr Dashwood, I intended 'insure' to be used in the sense of http://www.merriam-webster.com/dictionary/insure , 2. What you seem to be saying in 'whoever is manipulating it takes responsibility for the manipulations they apply' you seem to be applying the classic 'them as touched it last, owns it' and that, in my experience, can lead to more problems than it purports to solve. [snip] >Sure. It comes down to people having the right access permissions so they >can maintain their own data and be responsible for it. Hmmmmm... for some reason the Confucian concept of 'rectification of names' comes to mind. DD
From: Michael Mattias on 25 Jul 2008 08:54 "softWare design" <sabraham(a)baxglobal.com> wrote in message news:c06daa0b-42dc-4c04-a88a-9ddd2a900e50(a)p31g2000prf.googlegroups.com... >Can a relational database file system slows down the Cobol >application? >Are there any performance bottlenecks when Cobol application >handles large volume of data? >Will Cobol application take much longer to run if I/O operations >access the RDBMs file system as if they were ISAM files? 'softWare design" is, if nothing else, an effective alias. Seeing these queries I never would have guessed. For the record, the answer to all three questions is, "It's not the paintbrush, it's the artist." MCM
From: Robert on 25 Jul 2008 08:56
On Fri, 25 Jul 2008 09:26:43 +0000 (UTC), docdwarf(a)panix.com () wrote: >In article <r79i84dhrco810pud78m84uucod1kmiqr7(a)4ax.com>, >Robert <no(a)e.mail> wrote: >>On Thu, 24 Jul 2008 12:37:33 -0700 (PDT), softWare design >><sabraham(a)baxglobal.com> wrote: >> >>>On Jul 24, 11:17�am, Howard Brazee <how...(a)brazee.net> wrote: >>>> >>>> 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? >>>> >>> >>> >>>Suppose I want to change my data model by adding a column >>>to a table (field to a file record). With a relational database >>>I add the column and the job is done. Any program that needs >>>to work with that new column can on-the-fly, and any existing >>>programs that do not care about the change stays untouched. >> >>Alternatively, leave the original file unchanged and put the new >>column(s) in a another >>file. Programs interested in the new data will have to join the two >>files, while old >>programs need not be changed. > >Decades on back I was taught a part of the Zen of Programming: > >'What does a programmer do when given an 80-character record?' > >'Reserve ten characters for future use.' > >It used to be a common tecnique; a chunk of space - in the example above >at least enough to contain a decent-sized key to an indexed dataset - was >left as FILLER. > >When new uses were found the FILLER decreased... and when the FILLER >finally disappeared it was the job of anyone who dealt with programs that >touched the file (or who dealt with the programmers who dealt with the >programs) to say 'The system has reached its design limits and budget must >be allocated to compare former needs with current ones so that a plan >might be developed which results in a better meeting of our changed >requirements. A newly-married couple or a family with two snall children >can fit comfortably into a compact car; as they age or family size >increases a different vehicle is needed for comfort... this is a >predictable result of growth.' Imagine test driving a new car the way we test new software. 'Drive around the block? That's a Unit Test. We need to take it on a long trip, say 500 miles, with the whole family aboard. We need to test it in summer weather and in snow. We need to puncture a tire to make sure the spare works.' |