help with tables
in [Cobol]
|
Prev: oracle10g SQLBEX giving 114 with Oracle Dynamic SQL Method 4(ora9 works well)
Next: compile+link Fujitsu Linux
From: Pete Dashwood on 31 Jan 2008 23:38 "Robert" <no(a)e.mail> wrote in message news:jof2q31shvbu6d9ia1i7gelptabq9slahe(a)4ax.com... > On Wed, 30 Jan 2008 10:39:28 -0700, "Frank Swarbrick" > <Frank.Swarbrick(a)efirstbank.com> > wrote: > >>-------------------------------------------------------------------- >> SQL0060W The "COBOL" precompiler is in progress. >> 19 SQL0008N The token "occurs" found in a host variable >> declaration is not valid. >> 41 SQL4943W The number of host variables in the INTO clause >> is not the same as the number of items in the SELECT >> clause. SQLSTATE=01503 > > The manual says DB2 doesn't allow a simple SELECT to return multiple rows. > You must do the > SELECT in a cursor declaration and read the table with a single FETCH, as > illustrated by > Frederico. > > Thanks for the experiment. > While I don't claim the same level of SQL knowledge that you have demonstrated, Robert, I have managed to use it successfully for a number of years. Obviously you CAN return multiple rows from a query if you can process a result set, however, in embedded SQL I've always used the cursor and FETCHed it. (In C# I deal with result sets, and there are specific operations to step through them) I was very interested to see your posts in this thread and hope I've learned something for the next time I have to deal with Oracle :-) It was partly limitations like this in embedded SQL which caused me to start looking at LINQ. At the moment there is some debate as to whether the addition of LINQ functionality into DotNET languages, and, specifically C#, have caused the gap to widen between C# and Java. I saw a post from a Java guy who definitely thinks so, and he explored various options that Sun could do to try and catch up. None of them were very attractive. Here's a link: http://www.sdtimes.com/printArticle/LatestNews-20080115-20.html I'd be interested to see comments from people here. For myself, I'm still learning functional programming and LINQ, but find it fascinating and VERY cool :-) (I haven't been able to spend enough time on it recently, but hope to get back to it as the weather here deterioriates... :-) (No sign of that yet... we are having a fantastic summer; far too good to waste indoors :-))) I believe it is approaches such as this that will simply render embedded SQL obsolete, but time will tell... Pete. -- "I used to write COBOL...now I can do anything."
From: Robert on 1 Feb 2008 00:27 On Thu, 31 Jan 2008 01:37:24 +0000 (UTC), docdwarf(a)panix.com () wrote: >In article <bav1q3t26jjt26156j9eh4lpp1ivtot9a0(a)4ax.com>, >Robert <no(a)e.mail> wrote: >>>That's similar to a way I have seen things done on mainframes, yes... but >>>a way that would not pass muster in more than a few shops where I've >>>worked and would have gotten you laughed out of Prod Implementation >>>reviews. >> >>I've never seen a Prod Implementation review. I've only seen reviews >>BEFORE testing began. >>Sounds like you're putting untested rewrites into production. > >That might be due to the fact that it is something you admit to being >outside of your experience, Mr Wagner; a Prod Implementation review can >require a programmer to submit test results. In my experience, test results are checked by TEST TEAMS, who run pair, integration, system, regression and performance tests. Each test case is evidenced by a document showing expected versus actual, and signed in blood. Unit tests run by programmers aren't taken seriously by anyone. >>>(if 3100- begins in column 8 (as indicated by the debugging line >>>following it) then the imperatives which follow precede column 12) >> >>My keypunch machine was down. > >Try the ISPF editor, Mr Wagner... it's good 1970s technology. Outside the mainframe world it's called XEdit and KEdit. I wrote one in Cobol. Mine didn't have REXX; its macro language was anything that compiled to machine language. I don't use it much now.
From: Robert on 1 Feb 2008 01:06 On Thu, 31 Jan 2008 17:38:23 +1300, "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote: > > >"Robert" <no(a)e.mail> wrote in message >news:jof2q31shvbu6d9ia1i7gelptabq9slahe(a)4ax.com... >> On Wed, 30 Jan 2008 10:39:28 -0700, "Frank Swarbrick" >> <Frank.Swarbrick(a)efirstbank.com> >> wrote: >> >>>-------------------------------------------------------------------- >>> SQL0060W The "COBOL" precompiler is in progress. >>> 19 SQL0008N The token "occurs" found in a host variable >>> declaration is not valid. >>> 41 SQL4943W The number of host variables in the INTO clause >>> is not the same as the number of items in the SELECT >>> clause. SQLSTATE=01503 >> >> The manual says DB2 doesn't allow a simple SELECT to return multiple rows. >> You must do the >> SELECT in a cursor declaration and read the table with a single FETCH, as >> illustrated by >> Frederico. >> >> Thanks for the experiment. >> > >While I don't claim the same level of SQL knowledge that you have >demonstrated, Robert, I have managed to use it successfully for a number of >years. > >Obviously you CAN return multiple rows from a query if you can process a >result set, however, in embedded SQL I've always used the cursor and FETCHed >it. Many Cobol programmers think it's not possible to get a result set, except by FETCHing one row at a time. They regard a database as VSAM on drugs. >I was very interested to see your posts in this thread and hope I've learned >something for the next time I have to deal with Oracle :-) I'd expect it can be done with any database, because .NET people take sets for granted. >It was partly limitations like this in embedded SQL which caused me to start >looking at LINQ. > >At the moment there is some debate as to whether the addition of LINQ >functionality into DotNET languages, and, specifically C#, have caused the >gap to widen between C# and Java. I saw a post from a Java guy who >definitely thinks so, and he explored various options that Sun could do to >try and catch up. None of them were very attractive. LINQ is integrated into the .NET languages. It doesn't use a clunky precompiler. I wish SQL were integrated into Cobol. If I were king, I'd drop flat file support from Cobol, replacing it with SQL for access to indexed and sequential files as well as databases. I've done that with sequential flat files using Microsoft's ODBC driver. It's surprisingly fast, even on files containing a million records. >I believe it is approaches such as this that will simply render embedded SQL >obsolete, but time will tell... LINQ is embedded SQL by another name. I don't think there are any native LINQ databases. Under the covers LINQ must be converting its queries to dynamic SQL. It's probably holding locks locally on the client, which will give database purists heartburn.
From: Pete Dashwood on 1 Feb 2008 04:51 "Robert" <no(a)e.mail> wrote in message news:29n2q3p0caoh922pmsenajrl1niln3j4m3(a)4ax.com... > On Thu, 31 Jan 2008 17:38:23 +1300, "Pete Dashwood" > <dashwood(a)removethis.enternet.co.nz> > wrote: > >> >> >>"Robert" <no(a)e.mail> wrote in message >>news:jof2q31shvbu6d9ia1i7gelptabq9slahe(a)4ax.com... >>> On Wed, 30 Jan 2008 10:39:28 -0700, "Frank Swarbrick" >>> <Frank.Swarbrick(a)efirstbank.com> >>> wrote: >>> >>>>-------------------------------------------------------------------- >>>> SQL0060W The "COBOL" precompiler is in progress. >>>> 19 SQL0008N The token "occurs" found in a host variable >>>> declaration is not valid. >>>> 41 SQL4943W The number of host variables in the INTO clause >>>> is not the same as the number of items in the SELECT >>>> clause. SQLSTATE=01503 >>> >>> The manual says DB2 doesn't allow a simple SELECT to return multiple >>> rows. >>> You must do the >>> SELECT in a cursor declaration and read the table with a single FETCH, >>> as >>> illustrated by >>> Frederico. >>> >>> Thanks for the experiment. >>> >> >>While I don't claim the same level of SQL knowledge that you have >>demonstrated, Robert, I have managed to use it successfully for a number >>of >>years. >> >>Obviously you CAN return multiple rows from a query if you can process a >>result set, however, in embedded SQL I've always used the cursor and >>FETCHed >>it. > > Many Cobol programmers think it's not possible to get a result set, except > by FETCHing one > row at a time. They regard a database as VSAM on drugs. > >>I was very interested to see your posts in this thread and hope I've >>learned >>something for the next time I have to deal with Oracle :-) > > I'd expect it can be done with any database, because .NET people take sets > for granted. > >>It was partly limitations like this in embedded SQL which caused me to >>start >>looking at LINQ. >> >>At the moment there is some debate as to whether the addition of LINQ >>functionality into DotNET languages, and, specifically C#, have caused the >>gap to widen between C# and Java. I saw a post from a Java guy who >>definitely thinks so, and he explored various options that Sun could do to >>try and catch up. None of them were very attractive. > > LINQ is integrated into the .NET languages. It doesn't use a clunky > precompiler. I wish > SQL were integrated into Cobol. If I were king, I'd drop flat file support > from Cobol, > replacing it with SQL for access to indexed and sequential files as well > as databases. > I've done that with sequential flat files using Microsoft's ODBC driver. > It's surprisingly > fast, even on files containing a million records. > >>I believe it is approaches such as this that will simply render embedded >>SQL >>obsolete, but time will tell... > > LINQ is embedded SQL by another name. I disagree. It is integrated into the Language and is an integral part of the language so it is hardly "embedded", in the sense that SQL is... It is statically linked at the moment although I saw an interview with Anders where he said they are currently working on PLINQ which will be parallell threads of LINQ and these will autmatically be assigned to available processors. It all looks quite exciting. > I don't think there are any native LINQ databases. > Under the covers LINQ must be converting its queries to dynamic SQL. Yes, it does that today, but the promise is that the CLR will support PLINQ, and it is not tied to SQL, as LINQ supports ANY data source, including in-memory, flat files, even hierarchic databases. The idea is to be able to slice and dice ALL sources of data, and have these operations automatically optimized for whatever hardware is available to run them. I suspect it will take about two years and we'll see it around the same time we see Windows 7... :-) > It's probably holding > locks locally on the client, which will give database purists heartburn. Maybe... I think we have to accept that initial implementations will not be perfect... :-) Pete. -- "I used to write COBOL...now I can do anything."
From: Anonymous on 1 Feb 2008 05:26
In article <gfl2q319rd84spnb10q3f9huuvjq2254f9(a)4ax.com>, Robert <no(a)e.mail> wrote: >On Thu, 31 Jan 2008 01:37:24 +0000 (UTC), docdwarf(a)panix.com () wrote: > >>In article <bav1q3t26jjt26156j9eh4lpp1ivtot9a0(a)4ax.com>, >>Robert <no(a)e.mail> wrote: > >>>>That's similar to a way I have seen things done on mainframes, yes... but >>>>a way that would not pass muster in more than a few shops where I've >>>>worked and would have gotten you laughed out of Prod Implementation >>>>reviews. >>> >>>I've never seen a Prod Implementation review. I've only seen reviews >>>BEFORE testing began. >>>Sounds like you're putting untested rewrites into production. >> >>That might be due to the fact that it is something you admit to being >>outside of your experience, Mr Wagner; a Prod Implementation review can >>require a programmer to submit test results. > >In my experience, test results are checked by TEST TEAMS, who run pair, >integration, >system, regression and performance tests. Each test case is evidenced by >a document >showing expected versus actual, and signed in blood. Now think of expanding your experience, Mr Wagner... and imagine that the TEST TEAM (caps original) makes a copy of their documentation... and returns it (in exchange for a signature, of course), to the programmer... who brings this stack o' foolscap along when he sits down with other folks at a Prod Implementation meeting. There... that wasn't so difficult, was it? A wonderful world it is, that has New Things - even from decades past! - to learn in it. >Unit tests run by >programmers aren't >taken seriously by anyone. Remember your Goedel, Mr Wagner... if that sentence is true then programmers (part of the sub-set of 'anyone') who do unit tests don't take their own work seriously. > >>>>(if 3100- begins in column 8 (as indicated by the debugging line >>>>following it) then the imperatives which follow precede column 12) >>> >>>My keypunch machine was down. >> >>Try the ISPF editor, Mr Wagner... it's good 1970s technology. > >Outside the mainframe world it's called XEdit and KEdit. Not much use for an example of 'the mainframe world', then, is it? DD |