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: Robert on 24 Jul 2008 23:14 On Fri, 25 Jul 2008 14:03:27 +1200, "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote: >I've been looking at set operations as replacement for cursor based ones but >I simply haven't had time to really get my head round it yet. > >How would you insert multiple records, then? In Oracle, like this: employee-ID occurs 1000 pic 9(09). employee-name occurs 1000 pic x(30). employee-salary occurs 1000 pic 9(9)v9(2); row-count pic 9(4). EXEC SQL FOR :row-count INSERT INTO EMPLOYEEES ( ID, NAME, SALARY) VALUES (:employee-ID, :employee-name, :employee-salary); You cannot say 01 employee occurs 1000. 05 ID pic 9(09). ... Each variable must be an array.
From: Anonymous on 25 Jul 2008 05:26 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
From: Anonymous on 25 Jul 2008 05:31 In article <6esodiF8oskkU1(a)mid.individual.net>, Pete Dashwood <dashwood(a)removethis.enternet.co.nz> wrote: > > >"HeyBub" <heybub(a)NOSPAMgmail.com> wrote in message >news:8LednfeyoZGWLBXVnZ2dnUVZ_vninZ2d(a)earthlink.com... >> Pete Dashwood wrote: >>> >>> (Don't take HeyBub's post seriously... he is winding you up... :-)) >>> >> >> You think? > >Yep :-) > >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. 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? I would argue that those who are responsible for this insuring data integrity have exclusive authority to limit INSERT/UPDATE access. READ/BROWSE access is another matter, entire, DD
From: Pete Dashwood on 25 Jul 2008 07:08 <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: >> >> >>"HeyBub" <heybub(a)NOSPAMgmail.com> wrote in message >>news:8LednfeyoZGWLBXVnZ2dnUVZ_vninZ2d(a)earthlink.com... >>> Pete Dashwood wrote: >>>> >>>> (Don't take HeyBub's post seriously... he is winding you up... :-)) >>>> >>> >>> You think? >> >>Yep :-) >> >>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. > > 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. There is corporate backbone data administered by the IT department and there is local data freely circulated within and around departments. IT have a right to require that certain data feeds are provided to them to support the corporate data asset, but the owners of that data have a right to access it too. > > I would argue that those who are responsible for this insuring data > integrity have exclusive authority to limit INSERT/UPDATE access. Yes, you could argue that anyone dealing with the corporate data backbone would not be allowed to apply updates to it directly, and all such updates would be subject to scrutiny before (and after) being applied. That would be covered by process and procedure. You can have crazy situations where a department provides the required data and then realises there are some errors in it. They are not allowed to correct them until the next cycle which could be a week away, or they have to request IT to correct them and there is paperwork involved so they just leave it. A system that allows people with the proper authorization to manipulate data which they originated, given proper checks and balances, is far better than ONLY IT personnel being allowed to do it. (IT are from infallible, anyway...) > READ/BROWSE access is another matter, entire, > Sure. It comes down to people having the right access permissions so they can maintain their own data and be responsible for it. Pete. -- "I used to write COBOL...now I can do anything."
From: Pete Dashwood on 25 Jul 2008 07:16
"Robert" <no(a)e.mail> wrote in message news:cffi84hdasss50ka2g3e00jarq6sppf2l1(a)4ax.com... > On Fri, 25 Jul 2008 14:03:27 +1200, "Pete Dashwood" > <dashwood(a)removethis.enternet.co.nz> > wrote: > >>I've been looking at set operations as replacement for cursor based ones >>but >>I simply haven't had time to really get my head round it yet. >> >>How would you insert multiple records, then? > > In Oracle, like this: > > employee-ID occurs 1000 pic 9(09). > employee-name occurs 1000 pic x(30). > employee-salary occurs 1000 pic 9(9)v9(2); > row-count pic 9(4). > > EXEC SQL FOR :row-count > INSERT INTO EMPLOYEEES ( ID, NAME, SALARY) > VALUES (:employee-ID, :employee-name, :employee-salary); > > You cannot say 01 employee occurs 1000. 05 ID pic 9(09). ... > Each variable must be an array. Thanks for that. Amazing coincidence. I was today just looking at doing that (not for insert) so I could get a series of rows from an attached table with a single join on the base table. I haven't actually tried it yet but both MS ACCESS and SQL Server are supposed to support it. I'll let you know if it succeeds. In the past I have always defined Host Variables at an 01 level (because that works for nearly ANY RDBMS) and have never used an occurs clause on a sub level. According to the Fujitsu docs this is valid. Pete. -- "I used to write COBOL...now I can do anything." |