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 1 Feb 2008 18:44 "Robert" <no(a)e.mail> wrote in message news:4oc6q3d8r1acm34uj2rf24mpo244djrq5n(a)4ax.com... > On Fri, 1 Feb 2008 10:43:08 +0000 (UTC), docdwarf(a)panix.com () wrote: > >>It might be seen as moderately amusing what has happened when someone who >>frequently disparages 'the way things were done' confronts an example of >>'how things were'. >> >>'What kind of foolishments are these? This IF is coded across screens and >>screens, why wasn't it broken down into an EVALUATE and some in-line >>PERFORMs?' >> >>'The code-base was laid down in 1975, a decade before those features were >>available... and the shop didn't start using those features until the Y2K >>conversion in 1998 and nobody since then has authorised the budget to >>rewrite and re-test it.' > > I don't find it amusing. While and because old Cobolers were resisiting > change, the world > abandoned Cobol. Note past tense; it already happened. Yes, it did. And the resistance of the COBOL community to new ideas was certainly a major factor. However, it wasn't the ONLY factor, and many who were previously resistant are now aware that certan nettles will have to be grasped and bullets bitten anyway, with or without COBOL. I have spotted a few things recently which make me think that COBOL may be twitching for a while yet. Too soon for optimism, but a "resurrection" of COBOL may not be out of the question. If it happens (and the chances are slight in my opinion) it will require an attitude shift on the part of many in the COBOL community (Managers, Analaysts and Programmers). However, that shift is not as unlikely today as it was 10 years ago... Time will tell. :-) Pete. -- "I used to write COBOL...now I can do anything."
From: Pete Dashwood on 1 Feb 2008 18:45 "Robert" <no(a)e.mail> wrote in message news:p4d6q3hg7qlidtj2sc556ttnkqtcduq5ki(a)4ax.com... > On Fri, 1 Feb 2008 10:31:32 +0000 (UTC), docdwarf(a)panix.com () wrote: > >>In article <1u65q3l1v0rcriqpa82bvev2p8j9hiqcdq(a)4ax.com>, >>Robert <no(a)e.mail> wrote: > >>>Manuals are as close as your Web browser. >> >>Mr Wagner, I saw my first DB2 installation in 1987... and I worked on >>sites where consultants/contractors/hired guns were not allowed web-access >>into the mid-1990s. > > I worked at place with such a policy in 2001. When I needed to look > something up in a > manual, I drove home to do it. Time per lookup was 30-45 minutes. > > Only gubbermint gets away with such inefficiency. Hmmm... :-) If I thought anyone on my team was beng that obtuse, they wouldn't be on it for very long. :-) Pete. -- "I used to write COBOL...now I can do anything."
From: Pete Dashwood on 1 Feb 2008 19:16 "Robert" <no(a)e.mail> wrote in message news:5so6q3l17qiq3gf69mi6bfk976dh1p0hc5(a)4ax.com... > On Fri, 1 Feb 2008 15:32:04 +0000 (UTC), docdwarf(a)panix.com () wrote: > >>In article <p4d6q3hg7qlidtj2sc556ttnkqtcduq5ki(a)4ax.com>, >>Robert <no(a)e.mail> wrote: >>>On Fri, 1 Feb 2008 10:31:32 +0000 (UTC), docdwarf(a)panix.com () wrote: >>> >>>>In article <1u65q3l1v0rcriqpa82bvev2p8j9hiqcdq(a)4ax.com>, >>>>Robert <no(a)e.mail> wrote: >>> >>>>>Manuals are as close as your Web browser. >>>> >>>>Mr Wagner, I saw my first DB2 installation in 1987... and I worked on >>>>sites where consultants/contractors/hired guns were not allowed >>>>web-access >>>>into the mid-1990s. >>> >>>I worked at place with such a policy in 2001. >> >>So, Mr Wagner... since you worked as such a place at some point is it >>reasonable to conclude that you are working at such a place now? > > Web access is almost universal nowadays. But they need SOME way to lower > contractors' > social status. Denial of VPN access is a popular choice. Chicago roads > were terrible > this morning due to a snowstorm. Contractors had to drive in it while > employees worked > from home. The parking lot was more than half empty. There is no valid > security reason > when SecureID is used. VPN ports don't cost anything in royalties. > > Other places restrict contractors to one entry door. The reason is because > administrators > are too lazy to set them up in the security system, but it also serves as > a social marker. Contractors do have a choice, Robert. If the corporate culture is such that contractors are despised, while being considered necessary, then moves should be made to address that culture. Maybe a round table with some Senior Managers, pointing out the fact that such an attitude, apart from being immoral, is simply costly and inefficient, and showing how contractors could bring much more to the table if they were treated properly. (Where is the management logic in demotivating an expensive resource?) I have worked in places where contractors were treated exactly like permanent staff (except for pay) and they were usually happier shops (for everybody, not just the contractors...) Happy contractors are more likely to share expertise with the locals and even go the extra mile occasionally (driving home to check a manual is not "going the extra mile" in this sense :-)) If a company recognises that they need contractor expertise, then they should recognise that to maximise that expertise, it is wise to keep everybody happy. There will always be the disgruntled permies who resent the freedom of contracting and the fact that someone doing "the same job" (whatever that means...) is being paid more, but won't drop the cuddle blanket of paid holidays, sick leave, insurance, (and perceived - it isn't real, and hasn't been for decades- job security...) and go contracting themselves, and the best way I've found to deal with them is to talk frankly (and without antagonism or hostility) and remind them of why they are NOT contracting. Once everybody knows where they stand it is easier to get on with the job, without gnawing resentment. Corporate culture is a major (although largely unrecognised) factor in determining the success of IT projects. It is the reponsibility of managers to ensure this culture is positive and that applies to permanent staff as well as anybody else. If they can't treat their own staff properly, they certainly won't treat contractors properly. If it is a hopeless hierachic structure governed by mean spirited control freaks who have no insight into motivating and treating people properly, and all attempts to address this have failed, then, contractors should vote with their feet. (So should permanent staff, but I recognise that it is much harder for them. If it wasn't, they probably wouldn't be permanent in the first place...) Many years ago, I worked on such a site and I have never forgotten that experience. I was pretty inexperienced at contracting and believed I HAD to stay for the duration (six months); nowadays I would be out in four weeks :-). (Aside to young contractors - read your contract and cross out the paragraph that says you cannot terminate, but they can give you one month. Make it the same for both sides. If the agency protest that it is a "standard contract" and "everybody signs it" tell them you won't. Do this AFTER you have been interviewed and accepted by the client company.) I hope the U.K. company I am referring to have moved on, and have better managers now, but I have no intention of finding out...:-) Pete. -- "I used to write COBOL...now I can do anything."
From: William M. Klein on 1 Feb 2008 19:17 "Robert" <no(a)e.mail> wrote in message news:5so6q3l17qiq3gf69mi6bfk976dh1p0hc5(a)4ax.com... > On Fri, 1 Feb 2008 15:32:04 +0000 (UTC), docdwarf(a)panix.com () wrote: > <snip> > Web access is almost universal nowadays. But they need SOME way to lower > contractors' > social status. Denial of VPN access is a popular choice. Chicago roads were > terrible > this morning due to a snowstorm. Contractors had to drive in it while > employees worked > from home. The parking lot was more than half empty. There is no valid > security reason > when SecureID is used. VPN ports don't cost anything in royalties. > Robert, As someone who lives in suburban Chicago, I am aware of what roads were like today. I don't know a HUGE number of contractors, but the ones that I do know were all (as usual) able to work from home. Are you on a current contract that doesn't give you web access? About what percentage of those contractors that you know are not able to work from home (when employees are)? -- Bill Klein wmklein <at> ix.netcom.com
From: Pete Dashwood on 1 Feb 2008 20:44
-- "I used to write COBOL...now I can do anything." "Judson McClendon" <judmc(a)sunvaley0.com> wrote in message news:0zMoj.64189$vt2.19285(a)bignews8.bellsouth.net... > "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. Yes there were, but it was still a major one. >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. Nope. Most of the old timers (exactly like yourself, Judson... no offence) never really got to understand OO or what it could do for them because they wrote it off with ITSA instead of actually looking at it. People outside the COBOL world were not so certain that there is only one RIGHT way, and did not measure the new paradigm against an old one that they were convinced did not need change. As a result, the world moved on, COBOL was left behind. OO was added to COBOL by forward thinking vendors, recognising an important emerging paradigm. It was a staggering feat of software engineering and did not deserve to be shunned as it was by the COBOL community at large. I used OO COBOL for almost a decade (mainly to build reusable components which I still have a huge investment in) and found it excellent. >I always knew that one of COBOL's greatest > strengths was it's simplicity. Add OO, destroy the simplicity. Absolutely not. "Simplicity" is a subjective thing, and usually relates to that with which we are familiar. (I think Richard was the first to point that out in this forum, and he is absolutely correct.) When I first addressed OO COBOL (trying to learn it by experimentation, and from the manual, as so many of us do when we can't get training...) I found it complex and difficult. I gave up and went to Java. Because it was completely different form COBOL there was no chance to apply ITSAs, and within a week or two I had grasped the concepts and was writing effective Java code. As I wrote more, the concepts began to gel. I never tried to write COBOL in Java; instead, I realised there are many ways to do things and this was a completely new paradigm, with some very special advantages. With this new found knowledge I went back and had another look at OO COBOL. It all fell into place and was no longer complex or difficult. (It was certainly more verbose, but that isn't necessarily a bad thing, especially if you plan to maintain the code.) BOTTOM LINE: OO, even OO COBOL, is NOT difficult, IF you set aside what you already know, and take the new concepts on board WITHOUT deciding at some point in the assimilation process that "it's just modular programming re-invented", or any other ITSA consideration. >The things > that make COBOL great for its heyday are also things that do not fit > current development paradigms. True. Standard procedural COBOL IS a different paradigm to OO. It is a different paradigm to OO COBOL. >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. Yes, agreed. > 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. Partly. I have NOT "abandoned" COBOL (I really can't because I have too large a code base). In fact I was writing COBOL yesterday... it was kind of like walking through molasses, after using C#... :-) I was doing it for someone else, not for myself... Fortunately for me, most of my COBOL code base is components written in OO COBOL (Fujitsu NetCOBOL and PowerCOBOL). When I realised DotNET was the way to go, I needed to upgrade to Fujitsu NetCOBOL for .NET. It is an imperfect product (there are limitations on what it implements as far as COBOL goes), it costs several thousand dollars, and when I enquired about purchasing it (having decided to bite the bullet and spend the money) they ignored me. I asked again and never received a response. As a matter of principle, I don't intend to beg some company to sell me their product, so I looked for other options. I considered MicroFocus Net Express, but the runtime licensing makes it a nonstarter as far as I'm concerned, and I would have had to convert all my existing code anyway. What to do? MicroSoft were offering Visual Studio Express (which supports VB, C#, C++, and some scripting languages) as a free download. I took it. Downloaded the DotNet framework, along with some free videos on getting started and immersed myself in it for a couple of weeks. I decided to go with C# as rumour had it that it was "Java-like" and I couldn't bring myself to go to VB after all these years... :-) It didn't take long to realise that this was a whole new ball game. The tools were light years ahead of the COBOL Editors I was used to, the debuggers simple and visual (and you can set break points ANYWHERE, which you cannot do in Fujitsu COBOL). It was breathtaking. Write code and it is IMPOSSIBLE to make syntax errors; learn as you write. Intellisense shows you the format and parameters of any method call you make as you code it, can't misspell variable or property names or have to remember them; it's a dropdown at the point in the code where you need it. Everything is visual; point and click, minimum typing. And the power of it is phenomenal. Things that took a day to do in COBOL were dropped into my projects in seconds... sorry, it still just blows me away :-) The .Net framework has 80,000 classes, all immediately available as soon as you set a reference to them, and all browseable. That's 80,000 components I didn't have to write, and some of them are amazing. Best of all, it's free :-) Good, but what about the existing COBOL base? Fortunately the FCL (Framework Class Library) provides something called "InteropServices". This allows code that is NOT C# to run in the C# environment as what is termed "unmanaged" code. This means that C# (more properly, the CLR...) takes no responsibility for it (it does for anything that IS C# (managed code) and raises handleable exceptions with great explanations and diagnostics if your code runs off the rails), but runs it "as is". Provided you haven't done anything stupid in it (subscripts out of range, pointers to non-existent code, the usual rubbish), it works perfectly. As most of my COBOL components are COM compliant, Interop Services accepts them very gracefully and even passes COM errors back through the normal exception handling. I love it! :-) Now to the point: How did resistance from the COBOL community bring me to this? Well, if everyone had embraced OO COBOL when it was released, if people had used OO COBOL as their preferred tool for network applications and standard COBOL for the batch stuff, we would have a different world. COBOL would have retained (probably even enhanced) its credibility. Components written in OO COBOL would be running on the network and people using Java and other languages would accept that OO COBOL had as much right to be there as anything else. In fact, OO COBOL components would be playing nicely and interacting with components in other languages. (I can honestly say, that on the occasions when I have demonstrated COBOL stuff to Java people they have always been interested and impressed... Their normal perception of COBOL is as an outmoded batch processing language. That would NOT be the case if OO COBOL had been embraced and propagated.) Never mind. It's an ill wind that blows nobody any good... I'm pretty happy at having been forced away from COBOL. can write applications much more quickly and easily than I ever could, and, for the environments which I target them (Windows and the Internet), I have much more power available than I ever did with COBOL. Furthermore, I can still leverage my existing COBOL, although some of it has to be refactored into COM components before it can be easily reused in the new environments. > 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. It's speculative, but I disagree for the reasons outlined above. While I agree that this was not the ONLY factor in the demise of COBOL, I do believe it was a MAJOR one. >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. Possibly. Not inevitably. If everyone was using OO COBOL, they probably wouldn't need to look at other alternatives, any more than COBOL sites looked at moving to PL/I in the old days (or vice versa). Certainly, I find the verbosity of OO COBOL tedious now, but there are times when a "self documenting" language is still useful, especially for commercial development, and especially, if you have NOT adopted a component based approach... The thing that has really nailed this is the fact that maintenance of code is no longer the primary consideration when systems are built with re-usable components based on Object Classes. If you use component based design, you rarely need to change code and even if you do, it is encapsulated and minimal. As the main justification for COBOL's verbosity is "ease of maintenance of source code", and as this is now not the priority it once was, you have to ask: "Why am I still using a verbose language when I'm not getting the benefits that that verbosity is supposed to confer?" For me, that means C# as preferred language. Quick, powerful, and fun to write. >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. Well, I think COBOL CAN fit into today's webcentric development environment. In fact, I know Richard has written CGI code in straight COBOL, and I have used OO COBOL for both CGI and ISAPI. (It was a while ago; today I would use ASP.NET and C#;) I'm currently trying to find time to evaluate Ajax and Silverlight also, but the weather's too good... :-)) Pete. -- "I used to write COBOL...now I can do anything." |