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: Judson McClendon on 2 Feb 2008 09:06 <docdwarf(a)panix.com> wrote: > William M. Klein <wmklein(a)nospam.netcom.com> wrote: > > [snip] > >>About what percentage of those contractors that >>you know are not able to work from home (when employees are)? > > I cannot speak for Mr Wagner's experience but I have a few decades' worth > of experience as a consultant/contractor/hired gun... and my present > client is the first one that has permitted me to log on remotely. > > I was not given the ability to do so for my first three years on site and > even now I looked at... askance if I use it as a substitute for driving > down to the office. I've been a full time consultant since 1980, and have worked both ways. Some managers are apparently reassured by seeing a warm body at a workstation. Perhaps they're not confident enough in their managerial skills to trust in productivity and quality control assessments. It's been since the early '90s that I was required to be onsite, other than for occasional meetings. These days, even the onsite meetings are rare, usually just for planning meetings, demos and software installation. Communication is normally done by email or phone, with an occasional conference call. I've always had a relatively few, long term clients who knew me well. My clients tend toward small business and local government, not Fortune 500 corporations. I only remember doing a few small one-shot projects for large companies like BellSouth and Vulcan Materials. I don't know how representative that is of typical consultants. Considering the emphasis on "green" these days, you would think companies that require bodily presence would consider that it's a lot "greener" to move electrons than human bodies. -- Judson McClendon judmc(a)sunvaley0.com (remove zero) Sun Valley Systems http://sunvaley.com "For God so loved the world that He gave His only begotten Son, that whoever believes in Him should not perish but have everlasting life."
From: Frank Swarbrick on 2 Feb 2008 10:36 >>> On 1/31/2008 at 9:10 PM, in message <kn65q3pual2uooc5j7skq4vm1mvatp4imq(a)4ax.com>, Robert<no(a)e.mail> wrote: > On Thu, 31 Jan 2008 17:27:50 -0700, "Frank Swarbrick" > <Frank.Swarbrick(a)efirstbank.com> > wrote: > >>>>> On 1/31/2008 at 5:17 PM, in message >><c3p4q3tji85k6tegudomp2k4f4bmtk744o(a)4ax.com>, Robert<no(a)e.mail> wrote: >>> On Thu, 31 Jan 2008 11:56:10 -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. >>>> 51 SQL0306N The host variable "TABLE2-ENTRY" is undefined. >>>> SQL0095N No bind file was created because of previous >>>> errors. >>>> SQL0091W Precompilation or binding was ended with "3" >>>> errors and "0" warnings. >>>> >>>>I also tried this and got the same error >>>> 05 table2-entry occurs 100. >>>> >>>>Now of course you can remove the occurs, but then you're stuck with >>> fetching >>>>one row at a time. >>>> >>>>I see no way to do a multi row (at once) fetch using DB2/LUW. >>>> >>>>More thoughts would be welcome. >>> >>> I believe this will work for sure: >>> >>> 05 table2-entry. >>> 10 t2-name pic x(30) occurs 100. >>> 10 t2-dept pic x(04) occurs 100. >>> >>> fetch t2_curs >>> into :t2-name, :t2-dept >> >>Nope. I tried that one too. >> >>LINE MESSAGES FOR tabtest.sqb >>------ >>-------------------------------------------------------------------- >> SQL0060W The "COBOL" precompiler is in progress. >> 21 SQL0314N The host variable "t2-name" is incorrectly >> declared. >> 22 SQL0314N The host variable "t2-dept" is incorrectly >> declared. >> 20 SQL4007N The host structure "table2-entry" has no fields. >> 18 SQL4007N The host structure "table2-area" has no fields. >> 51 SQL0104N An unexpected token "t2_curs" was found following >> "<identifier>". Expected tokens may include: "INTO". >> SQL0095N No bind file was created because of previous >> errors. >> SQL0091W Precompilation or binding was ended with "6" >> errors and "0" warnings. > > Here is an sample from the IBM DB2 manual: > > EXEC SQL > FETCH NEXT ROWSET FROM EMPSET > FOR :SIZE-ROWSET ROWS > INTO :HVA-EMPNO, :HVA-LASTNAME, -- defined with occurs > :HVA-WORKDEPT, :HVA-JOB > END-EXEC. > > http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/index.jsp?topic=/ > com.ibm.db29.doc.apsg/db2z_xmpsfetchingrowscursor.htm > > DB2 Version 9.1 for z/OS That's the issue. This feature is available for DB2 for z/OS (mainframe!) but not DB2 for Linux, Unix and Windows! Frank
From: Frank Swarbrick on 2 Feb 2008 10:39 >>> On 2/1/2008 at 8:18 AM, in message <0LGoj.23675$m_6.612(a)fe01.news.easynews.com>, William M. Klein<wmklein(a)nospam.netcom.com> wrote: > Sorry, the thread has wandered so much that I had forgotten exactly what > platform this was for. > > Frank, > If this was your question, was it for Windows, Unix, VSE, or where? I > know > that yours was not the ORIGINAL post, but maybe you came in when there > was > discussion of what "DB2" can/cannot do. Linux. We have DB2 for LUW 9.5 running on zSeries Linux. We are using DB2/VSE as the client, but that's not really relevant for this discussion. The only issue is that DB2 for LUW does not support this kind of 'multi-row fetch'. (Even if LUW did support it I doubt VSE would, but...) Frank
From: Pete Dashwood on 2 Feb 2008 10:50 <docdwarf(a)panix.com> wrote in message news:fo1qvl$hhl$1(a)reader2.panix.com... > In article <qEOoj.26935$m_6.14703(a)fe01.news.easynews.com>, > William M. Klein <wmklein(a)nospam.netcom.com> wrote: > > [snip] > >>About what percentage of those contractors that >>you know are not able to work from home (when employees are)? > > I cannot speak for Mr Wagner's experience but I have a few decades' worth > of experience as a consultant/contractor/hired gun... and my present > client is the first one that has permitted me to log on remotely. > > I was not given the ability to do so for my first three years on site and > even now I looked at... askance if I use it as a substitute for driving > down to the office. > > DD > They obviously enjoy having you around, Doc... :-) Pete. -- "I used to write COBOL...now I can do anything."
From: Frank Swarbrick on 2 Feb 2008 10:53
>>> On 2/1/2008 at 2:55 PM, in message <0zMoj.64189$vt2.19285(a)bignews8.bellsouth.net>, Judson McClendon<judmc(a)sunvaley0.com> wrote: > "Robert" <no(a)e.mail> wrote: >> >> I don't find it amusing. While and because old Cobolers were resisiting >> change, the world abandoned Cobol. Note past tense; it already happened. > > There were many other reasons for the demise of COBOL than resistance to > change by old-timers. And I think a lot of the resistance was because the > old-timers knew that the new OO paradigm, for example, fit COBOL like a > square peg in a round hole. I always knew that one of COBOL's greatest > strengths was it's simplicity. Add OO, destroy the simplicity. The > things > that make COBOL great for its heyday are also things that do not fit > current development paradigms. Another of COBOL's great strengths was > the > Data Division, and the ease and power of the hierarchical structures and > data formatting in the Picture clause. But with standardized databases, > XML, et al, those became irrelevant. Consider Pete Dashwood. He embraced > and championed OO COBOL diligently for years. But Pete has abandoned > COBOL for other languages better suited to today's development needs. I > don't want to put words in Pete's mouth, but I don't think his decision > had anything to do with resistance by old-timers; I believe it was based > on pragmatic evaluation of the relative strengths of the tools in > today's > development environment. I've made a similar change. I still support my > clients who use COBOL, but I don't foresee developing any new systems in > COBOL, except for those clients who want it. And they are steadily > moving > away from COBOL. > > To me it is clear that, if Old Cobolers, as you put it, had jumped on > change as eagerly as anyone, we would still be watching COBOL's demise, > maybe even sooner. Their openness to change would have propelled them > inevitably to the same objective conclusions about current development > realities that me, and I think Pete also, to change. COBOL, in any form, > just does not fit well into today's webcentric development environment, > and no one here feels more regret over the passing of that simpler era > than I do. Personally, I *wish* COBOL would die in my environment. Unfortunately, unless we through out our current environment (mainframe VSE with CICS and DL/I / VSAM) and migrate to a whole other platform we're pretty much stuck, since there are no modern languages available on VSE. (Not even C++! Not that I'd recommend C++...) We have begun the slow march toward DB2. It is my hope that someday we'll have all of our data in DB2 and can then start migrating things away from VSE and COBOL. But that is years down the road. As you say, Cobol is simple. Unfortunately it's not powerful, at least not for many things. Frank |