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 20:56 "Clark F Morris" <cfmpublic(a)ns.sympatico.ca> wrote in message news:kd3k84tv8vk3fq82r7m0j87mrf8ttia2up(a)4ax.com... > On Fri, 25 Jul 2008 14:08:13 +1200, "Pete Dashwood" > <dashwood(a)removethis.enternet.co.nz> wrote: > >> >> >>"Howard Brazee" <howard(a)brazee.net> wrote in message >>news:taoh84dumtgpk7btco9a5o2d6p41rff6rn(a)4ax.com... >>> 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. >>>> >>>>The Cobol index file system is considered to be Closed simply >>>>because it requires a knowledge of the file definition/structure, >>>>in order to access the stored data. An open file system should >>>>allow privileged users to access the data and generate queries >>>>on-the-fly in the desired format they need, and facilitates any >>>>column insertions without the need to write special programs. >>>> >>> >>> You have a unique view of what "open" and "closed" mean in our >>> industry. >> >>No he doesn't... I share it. :-) > > I don't. If there is a good repository function where the data is > stored that describes all files, data base tables, views, fields and > data base columns, then the method of storage is irrelevant. 1. That's a pretty big "IF". Yes, large corporations usually invest in Data Dictionary type software, but there are many more companies that don't. 2. Even if such information IS available I need to use it to write a program to access the data. That's NOT open. 3. When I can load an Excel spreadsheet from your ISAM file WITHOUT needing a repository or writing a program to extract the data, THEN I'll agree it is "Open" > Data > base tables can be set up with wonderfully obscure or ambiguous table > and column names either due to lack of discipline or historic > limitations that no longer apply. Yes, bad design CAN make things more difficult, in ANY environment. > While it is easier to control most > kinds of access using a DBMS (network, hierarchical or relational) a > good query mechanism probably can handle files as well. While you may > be comfortable with all privileged users being able to do things on > the fly, I have memories of the parsing of the word sales and whether > or not a given transaction was a sale or reduction to sales. Part of > the problem is that we do not set up systems that allow users to test > their assumptions nor are many properly set up for good audit train on > corrective action. People are not trained on the nuances of the > systems that exist (I had one case where I was asked to write a > special run to delete a data base row and by investigating how the > system worked, I was able to tell the requester how she could do it > herself). Newer systems have tools for help creation so it isn't as > hit or miss as it was with the old CICS systems, especially with > packages. > > I totally support giving people the tools to do their jobs. Good. Me too :-) Files which contain a description of their own structure do that; files that don't, need more work. > I firmly > believe that packages should provide the capabilities for ad hoc > queries but there must be adequate support within the organization for > people to truly understand what they are asking. I would manage that on the basis of "What queries are users running that consume vast resources?" then fix it. > Is the customer the > individual store within the chain, the division within the chain, the > chain, or the conglomerate that owns the chain? >> Any or all of the above, depending on who needs a service. Pete. -- "I used to write COBOL...now I can do anything.
From: Pete Dashwood on 25 Jul 2008 20:58 "Howard Brazee" <howard(a)brazee.net> wrote in message news:7nlj849b8ev27htjlbnbafnonmkr43j1jd(a)4ax.com... > On Fri, 25 Jul 2008 11:54:34 +0000 (UTC), docdwarf(a)panix.com () wrote: > >>>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?' > > There always is a trade-off. If we design for any possible growth in > all foreseeable directions, we might be spending so much that the > non-foreseeable direction we end up with will have to fit our old > design - not the optimal design for then. > > Let's say my 20 year old personal computer was designed that way, > sufficiently to cost $100,000. Would it be better than a $2,000 > replacement that I could get today? > > Sometimes it is better to get what we need today and replace it > tomorrow with what fits tomorrow better. Very wise observation, Howard. Pete. -- "I used to write COBOL...now I can do anything."
From: Robert on 25 Jul 2008 22:01 On Fri, 25 Jul 2008 08:25:09 -0600, Howard Brazee <howard(a)brazee.net> wrote: >On Fri, 25 Jul 2008 07:56:43 -0500, Robert <no(a)e.mail> wrote: > >>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.' > >Some of the car testing was done by the car manufacturer with crash >test dummies, tire blowouts, and extreme conditions. The users >didn't do all of those tests, but that doesn't mean they weren't done. > >And when I bought a new spread sheet program, I assumed that the >testing had already been done - I only was interested in how it fit my >needs, and my testing was limited to what I was interested in. > >So I guess I'm missing your point here. Do you mean we should spend >as much testing a new program design as GM spends testing a new car >design? If GM changed only the ash tray, would it re-test every other system to insure the ash tray didn't inadvertantly affect something else?
From: Anonymous on 26 Jul 2008 09:35 In article <6ev968F93nfpU1(a)mid.individual.net>, Pete Dashwood <dashwood(a)removethis.enternet.co.nz> wrote: > > >"Howard Brazee" <howard(a)brazee.net> wrote in message >news:a6lj84dmbqtfgi4653ie4vuaqc603mcbpa(a)4ax.com... >> On Sat, 26 Jul 2008 01:02:19 +1200, "Pete Dashwood" >> <dashwood(a)removethis.enternet.co.nz> wrote: >> >>>While it may seem that way to you, that isn't what I intended. My >>>intention >>>was that the owners of the data would have the right to manipulate it. >>>Rather than "them as touched it last, owns it" it was more along the lines >>>of "them as owns it can touch it any time they like." >> >> Ownership of data isn't a two-valued thing. Some data are owned to >> various degrees by accounting, sales, finance, management, the >> customers, and the state. We can't give all of them full rights to >> manipulate them nor even to read them. >> >> Instead, we need to have established rules that are more complex than >> assigning a particular owner for a specific datum. > >Why? > >In today's world data can be easily shared by people who are authorised to >access it. My post has never suggested that only ONE "owner" should be >authorised. I am trying to make the point here that data is NOT owned >exclusively by IT, that's all. Mr Dashwood, it may be that you are confusing 'owning' with 'having responsibility for and a certain authority over'. Banks do not own the groats, farthings and tuppences that washerwomen hand over to tellers... but banks' responsibilities include the accounting for, safekeeping and rendering-for-account of these deposits. It does not matter to the customer (as long as the bank remains solvent, that is) whether the funds deposited are loaned out for housing purposes, business expansions or commodities-speculation... so long as the law and customer demand are satisfied the bank is doing its job. Does this comparison help? DD
From: Anonymous on 26 Jul 2008 09:48
In article <6eva6bF8sm27U1(a)mid.individual.net>, Pete Dashwood <dashwood(a)removethis.enternet.co.nz> wrote: > > >"Howard Brazee" <howard(a)brazee.net> wrote in message >news:0lkj84pn1grm75p6ufq1otp5cq66d84hr5(a)4ax.com... >> On Fri, 25 Jul 2008 13:26:13 +1200, "Pete Dashwood" >> <dashwood(a)removethis.enternet.co.nz> wrote: >> >>>I understand there is an element of seriousness in what you're saying, but >>>if you go down that route it ends in tears. >>> >>>IT does NOT own the data and IT should not have exclusive access to it. >>> >>>People who OWN the data should be able to manipulate it if they want to. >> >> Sometimes there are directives from on high limiting ownership >> privileges. These may be legal issues, or policies within a >> company. Maybe sales "owns" the sales data - but the salesmen >> can't manipulate them however they want. >> >> Obviously, neither should IT. But IT needs to enforce the guidelines >> that the enterprise and society demand. > >OK, so you see IT as being the "Data Police"? > >I don't. > >It would appear that both you and Doc have pushed my argument beyond where I >wanted it to go. > >What about companies that don't have an IT department? [snip] >That's it, no more from me on this :-) Mr Dashwood, with all appropriate respect and courtesy due... to ask questions and then say 'I'll not address the replies in the same forum in which I asked the question' is, to my mind, equally as honorable as the 'chastise in public, apologise in private' that I've seen come from many a Manager. This kind of behavior, I would say, is more than discourteous; I would say it lacks a certain kind of moral integrity, kindness and goodwill... in a word, http://www.merriam-webster.com/dictionary/decent , 4. I will say no more lest I be seen as castigating. DD |