S0C4 x'4' abend while reading VSAM KSDS file
in [Cobol]
|
From: Anonymous on 26 Jun 2008 20:50 In article <LsT8k.91002$6q2.28302(a)fe03.news.easynews.com>, William M. Klein <wmklein(a)nospam.netcom.com> wrote: >Unlike you, I don't care (too much) when it was outsourced. My point was not to get an answer, Mr Klein... my point was to show that neglecting to respond to questions was a behavior that's been demonstrated previously. (as for my interest... it'd be a curious bit of trivia to learn how long the code's been running without being touched) DD
From: Robert on 26 Jun 2008 21:36 On Fri, 27 Jun 2008 00:14:59 +1200, "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote: >"Robert" <no(a)e.mail> wrote in message >news:r966641piavtlfe3ov1pgbg6oiqll6ojq3(a)4ax.com... >> On Thu, 26 Jun 2008 13:19:20 +1200, "Pete Dashwood" >> <dashwood(a)removethis.enternet.co.nz> >> wrote: >> >>>If a corporation decides that the local market is "too expensive" and they >>>can buy the service elsewhere, cheaper, that is their prerogative and, >>>while >>>we may not like it, we can't really blame them. But if the quality of that >>>service is actually poorer, then why would we do anything other than offer >>>to fix it, for a proper fee? >> >> It is semi-common, especially in the Big Five world, to staff a project >> with mostly cheap >> labor plus one or two hotshots, whose role is to rescue the drones when >> they shoot >> themselves in the feet, review their code, and solve problems requiring a >> high level of >> expertise. > >Yes, a certain primary coloured company was doing it in the 1960s. The >people were referred to internally as "brains" and "bunnies"... That terminology is not used in the US. Grunt, peon and body is used for unskilled workers. >The goal of >a bunny was to become a brain, the goals of brains were multifarious and >complex. They usually involved ego, recognition, and large amounts of money. There are two kinds of brains. Egoists will never be anything but techies; non-egoists are seen as management material. In some non-US contracting companies, all or most managers are former brains (and not arab or american). Managers in American companies tend to be politicians. >A few brains who I knew personally were really into challenges and hated it >when everything was going fine. These people thrived when the chips were >down and seemed to develop new personalities overnight. It was an education >to see them at work. An education in management by crisis rather than planning ahead. In big companies, emergencies are the only way to get money. When things are going smoothly, top management gets rid of developers. There is no incentive to plan ahead. > I invariably got on well with these people, one of them >once remarking he was always glad to see me because I brought him problems >that were interesting and worth doing... :-) (I'm not sure to this day >whether that was good or bad...) Good for him; bad for stockholders. >> Contracting companies say more than 95% of the work is routine. > >So bunnies can do it. But when problems arise, a brain is needed. Now, if >you don't employ a brain because it will cost too much, or you are an >outsourcing company that doesn't want to train people (despite earning very >large sums of money by the standards of the countries where they operate), Management thinks all knowledge came through training. If you ask the brains, they'll say they figured out the solution. Management keeps wanting to routinize computers, like factory jobs. We know the problems are unique, not repetative. You can't train to handle a problem that's never happened before. >then isn't it a much superior management stratagem to simply pressure the >bunnies until they either solve the problem, crack up, or quit? (Given that >bunnies are just cannoin fodder to unscrupulous employers and can be easily >replaced...) Lock them in a War Room. No one leaves until the problem is fixed, even if it takes all night. Some companies have dozens of war rooms going day and night. Waterfall was invented to prevent such frequent failures. It doesn't work in these companies because of hidden coupling between systems. The systems work in isolation, but don't play well together. > So what are you going to do? You have a problem, have given it >your best shot, and can't solve it. Seek help. Hey, there's a forum where >you can get free advice... You post, get a solution and keep your job... But >what you SHOULD do is admit that this problem requires expertise you don't >have, and tell your employer it will cost to solve it. If all of the bunnies >did this, and if the forum was more careful about free advice, eventually, >employers would get the message... No, they wouldn't get the message. They'll fire one bunny and hire another just as bad. They're now making the same mistakes they made 30 years ago. >(I hasten to add that if someone's job was actually on the line and I could >help, I would not withold information. Survival trumps idealism every time. >However, I would make it very clear what the course of action should be in >future.) >> >> How would you feel about being one of the experts? In other words, >> facilitating the >> replacement of ~50 of your countrymen with cheap labor? > >Robert, I have worked as both a brain and a bunny. No jobs were lost or >countrymen replaced in either case. Twenty years ago, these projects were staffed with Americans making the equivalent of $50/hr. Now they're staffed with third worlders making $30/hr, or people in their native countries making $10/hr. Twenty years ago, the bill rate was the equivalent of $80/hr. Now it's still $80/hr. Clients are getting less for the same money; contracting companies are getting rich.
From: Pete Dashwood on 27 Jun 2008 20:09 "Robert" <no(a)e.mail> wrote in message news:lta86493p3lh3st265vlni5vh72p0tas9a(a)4ax.com... > On Fri, 27 Jun 2008 00:14:59 +1200, "Pete Dashwood" > <dashwood(a)removethis.enternet.co.nz> > wrote: > >>"Robert" <no(a)e.mail> wrote in message >>news:r966641piavtlfe3ov1pgbg6oiqll6ojq3(a)4ax.com... >>> On Thu, 26 Jun 2008 13:19:20 +1200, "Pete Dashwood" >>> <dashwood(a)removethis.enternet.co.nz> >>> wrote: >>> >>>>If a corporation decides that the local market is "too expensive" and >>>>they >>>>can buy the service elsewhere, cheaper, that is their prerogative and, >>>>while >>>>we may not like it, we can't really blame them. But if the quality of >>>>that >>>>service is actually poorer, then why would we do anything other than >>>>offer >>>>to fix it, for a proper fee? >>> >>> It is semi-common, especially in the Big Five world, to staff a project >>> with mostly cheap >>> labor plus one or two hotshots, whose role is to rescue the drones when >>> they shoot >>> themselves in the feet, review their code, and solve problems requiring >>> a >>> high level of >>> expertise. >> >>Yes, a certain primary coloured company was doing it in the 1960s. The >>people were referred to internally as "brains" and "bunnies"... > > That terminology is not used in the US. Grunt, peon and body is used for > unskilled > workers. > >>The goal of >>a bunny was to become a brain, the goals of brains were multifarious and >>complex. They usually involved ego, recognition, and large amounts of >>money. > > There are two kinds of brains. Egoists will never be anything but techies; > non-egoists are > seen as management material. In some non-US contracting companies, all or > most managers > are former brains (and not arab or american). Managers in American > companies tend to be > politicians. > >>A few brains who I knew personally were really into challenges and hated >>it >>when everything was going fine. These people thrived when the chips were >>down and seemed to develop new personalities overnight. It was an >>education >>to see them at work. > > An education in management by crisis rather than planning ahead. In big > companies, > emergencies are the only way to get money. When things are going smoothly, > top management > gets rid of developers. There is no incentive to plan ahead. > >> I invariably got on well with these people, one of them >>once remarking he was always glad to see me because I brought him problems >>that were interesting and worth doing... :-) (I'm not sure to this day >>whether that was good or bad...) > > Good for him; bad for stockholders. > >>> Contracting companies say more than 95% of the work is routine. >> >>So bunnies can do it. But when problems arise, a brain is needed. Now, if >>you don't employ a brain because it will cost too much, or you are an >>outsourcing company that doesn't want to train people (despite earning >>very >>large sums of money by the standards of the countries where they operate), > > Management thinks all knowledge came through training. If you ask the > brains, they'll say > they figured out the solution. > > Management keeps wanting to routinize computers, like factory jobs. We > know the problems > are unique, not repetative. You can't train to handle a problem that's > never happened > before. Hmmm... I think we part company here :-) I believe there are general approaches to problem solution that can be learned (empirically, by experience, and, to a lesser extent perhaps, but still valuably, in the classroom...), and I also believe that many of the problems encountered in IT have been encountered before. I would agree that every company THINKS their problems are unique... but that doesn't make it so. It is arguaable, and I see you disagree. No problem. > >>then isn't it a much superior management stratagem to simply pressure the >>bunnies until they either solve the problem, crack up, or quit? (Given >>that >>bunnies are just cannoin fodder to unscrupulous employers and can be >>easily >>replaced...) > > Lock them in a War Room. No one leaves until the problem is fixed, even if > it takes all > night. Some companies have dozens of war rooms going day and night. If the skills and information required to solve the problem are not actually available in the "War Room" then you can lock them in there until the next Ice Age and it won't make any difference... Besides, I have yet to see the Company that could contain me in a room where I didn't want to be...:-) I have never seen this particular approach employed but I accept your assurance that it is. It doesn't sound like a good way to motivate people... > > Waterfall was invented to prevent such frequent failures. It doesn't work > in these > companies because of hidden coupling between systems. The systems work in > isolation, but > don't play well together. Waterfall doesn't work perfectly for a number of reasons. Didn't you say earlier that Waterfall was invented to retard change? I think you later amended that to be that Waterfall was invented, not to retard change or keep control, but to avoid blame for errors? Now it is to prevent the frequent failings that companies experience, but it doesn't work due to system coupling... Although I am no fan of the Waterfall approach (except under certain very special and easily identifiable circumstances), I think that to keep blaming it for any problems that arise is, well... inconsistent. Let's leave the development Methodology out of the discussion.:-) > >> So what are you going to do? You have a problem, have given it >>your best shot, and can't solve it. Seek help. Hey, there's a forum where >>you can get free advice... You post, get a solution and keep your job... >>But >>what you SHOULD do is admit that this problem requires expertise you don't >>have, and tell your employer it will cost to solve it. If all of the >>bunnies >>did this, and if the forum was more careful about free advice, eventually, >>employers would get the message... > > No, they wouldn't get the message. They'll fire one bunny and hire another > just as bad. > They're now making the same mistakes they made 30 years ago. But doing that wouldn't solve their problem. Sooner of later (with the controls I mentioned in place) they would have to pay a market rate for proper advice or abandon the project. > >>(I hasten to add that if someone's job was actually on the line and I >>could >>help, I would not withold information. Survival trumps idealism every >>time. >>However, I would make it very clear what the course of action should be in >>future.) >>> >>> How would you feel about being one of the experts? In other words, >>> facilitating the >>> replacement of ~50 of your countrymen with cheap labor? >> >>Robert, I have worked as both a brain and a bunny. No jobs were lost or >>countrymen replaced in either case. > > Twenty years ago, these projects were staffed with Americans making the > equivalent of > $50/hr. Now they're staffed with third worlders making $30/hr, or people > in their native > countries making $10/hr. Well, most companies in our part of the world are NOT outsourcing. By adopting more modern approaches there is no need to. I have friends who simply laugh at the idea of coding a new system development line by line, in house OR outsourced. Moving to component based approaches rather than line-by-line Procedural code simply obviates the need to outsource (and also gets systems delivered in a fraction of the time it would otherwise take...). I believe it is only the procedural approach that is so labour intensive it needs to be outsourced. Having said that, the sub-continent and China both offer outsourced solutions in languages other than COBOL. I don't personally know of any companies who are outsourcing C# or Java, but there probably are some. I guess if VERY large development was being undertaken, it could make sense. The modern trend is NOT to do that. Instead, manageable systems are constructed quickly and easily using visual tools. This approach means that things can be rebuilt quickly using existing components if the original design is found to be lacking. It is much less risky to build and deploy a series of subsystems rather than to attempt construction of one huge monolithic solution. > > Twenty years ago, the bill rate was the equivalent of $80/hr. Now it's > still $80/hr. > Clients are getting less for the same money; contracting companies are > getting rich. Hmmm... I know personally of a couple of recruitment agencies in the UK that have failed within the last few years. I'm sure there are more. It is a very competitive market place and more and more companies are using preferred supplier lists that will only admit agencies with a markup within 15% (the old cowboy days of agencies using 60% markups are thankfully, virtually gone...) This may not be the case in the USA, of course. Certainly, LARGE contracting agencies with many people placed are doing well. I imagine that outsourcing is affecting their bottom lines, though. The simple fact is that the old glory days of contracting are gone. As the knowledge required to build commercial computer systems is deskilled and moved to tools and packages, the levels of programming skill required are less than once was the case. This means that people who are computer literate, but not necessarily skilled programmers, can build their own solutions. For "mission critical" systems, most companies will still require professional construction and this is either outsourced or built quickly using contract resource. Modern tools and approaches have made this possible; in the COBOL days it simply couldn't be done. (Nothing ever got done quickly using COBOL...) Today it is the "Solutions Architect", rather than the Programmer who is moving centre stage. Pete. -- "I used to write COBOL...now I can do anything."
From: Robert on 28 Jun 2008 00:27 On Sat, 28 Jun 2008 12:09:53 +1200, "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote: >"Robert" <no(a)e.mail> wrote in message >news:lta86493p3lh3st265vlni5vh72p0tas9a(a)4ax.com... >> On Fri, 27 Jun 2008 00:14:59 +1200, "Pete Dashwood" >> <dashwood(a)removethis.enternet.co.nz> >> wrote: >> Management thinks all knowledge came through training. If you ask the >> brains, they'll say >> they figured out the solution. >> >> Management keeps wanting to routinize computers, like factory jobs. We >> know the problems >> are unique, not repetative. You can't train to handle a problem that's >> never happened >> before. > >Hmmm... I think we part company here :-) I believe there are general >approaches to problem solution that can be learned (empirically, by >experience, and, to a lesser extent perhaps, but still valuably, in the >classroom...), and I also believe that many of the problems encountered in >IT have been encountered before. I would agree that every company THINKS >their problems are unique... but that doesn't make it so. Every company thinks its BUSINESS problems are unique, but its computer problems are routine. It's actually the other way around. >> Lock them in a War Room. No one leaves until the problem is fixed, even if >> it takes all >> night. Some companies have dozens of war rooms going day and night. > >If the skills and information required to solve the problem are not actually >available in the "War Room" then you can lock them in there until the next >Ice Age and it won't make any difference... They solve the problem by deleting the errant transaction. It recurrs a month later because no one fixed (or understood) the underlying logic error. >> Waterfall was invented to prevent such frequent failures. It doesn't work >> in these >> companies because of hidden coupling between systems. The systems work in >> isolation, but >> don't play well together. > >Waterfall doesn't work perfectly for a number of reasons. Didn't you say >earlier that Waterfall was invented to retard change? I think you later >amended that to be that Waterfall was invented, not to retard change or keep >control, but to avoid blame for errors? Now it is to prevent the frequent >failings that companies experience, but it doesn't work due to system >coupling... They are variations of the same idea. If it works, don't change anything. Lockdowns are an overt version of this. If you MUST change something, change only the bare minimum and then test the hell out of it before it goes to production. There's no such thing as too much testing. If it fails in production, redouble testing so that can't happen again. >Although I am no fan of the Waterfall approach (except under >certain very special and easily identifiable circumstances), I think that to >keep blaming it for any problems that arise is, well... inconsistent. The real problem with Waterfall is not waste of time and money; the real problem is that it prevents us from doing things right. It seems to prefer spending twice as much on stopgap solutions. >> Twenty years ago, these projects were staffed with Americans making the >> equivalent of >> $50/hr. Now they're staffed with third worlders making $30/hr, or people >> in their native >> countries making $10/hr. > >Well, most companies in our part of the world are NOT outsourcing. By >adopting more modern approaches there is no need to. I have friends who >simply laugh at the idea of coding a new system development line by line, in >house OR outsourced. Most of the world thinks Americans are dumb. New Zealand is no exception. >Moving to component based approaches rather than line-by-line Procedural >code simply obviates the need to outsource (and also gets systems delivered >in a fraction of the time it would otherwise take...). I believe it is only >the procedural approach that is so labour intensive it needs to be >outsourced. Having said that, the sub-continent and China both offer >outsourced solutions in languages other than COBOL. I don't personally know >of any companies who are outsourcing C# or Java, but there probably are >some. I guess if VERY large development was being undertaken, it could make >sense. The modern trend is NOT to do that. Instead, manageable systems are >constructed quickly and easily using visual tools. This approach means that >things can be rebuilt quickly using existing components if the original >design is found to be lacking. It is much less risky to build and deploy a >series of subsystems rather than to attempt construction of one huge >monolithic solution. There must be a receptive audience for that idea, because I've been hearing it as long as I can remember. In the 70s, 4GLs would eliminate programmers by GENERATING all the code. In the 80s, 'your people' could do it themselves with Lotus or Excel macros, or with Access. In the 90s, any chimpanzee could drag and drop widgets, VB or VC++ would spit out the code. The words change, but the melody remains the same. It's old wine in new bottles. >> Twenty years ago, the bill rate was the equivalent of $80/hr. Now it's >> still $80/hr. >> Clients are getting less for the same money; contracting companies are >> getting rich. > >Hmmm... I know personally of a couple of recruitment agencies in the UK that >have failed within the last few years. I'm sure there are more. It is a very >competitive market place and more and more companies are using preferred >supplier lists that will only admit agencies with a markup within 15% (the >old cowboy days of agencies using 60% markups are thankfully, virtually >gone...) This may not be the case in the USA, of course. <laugh> Ever since Y2K, 50% is a starting point. Contracting companies aspire to get more. I've told the story here about one who cried poor because it was making only 70 out of 120 bill rate. I know for a fact that IBM keeps 160 out of 200 bill rate. Blended Rate is their favorite phrase. That means you pay the same for everyone, from bunny to brain. Never mind that there are 50 bunnies for every brain. >Certainly, LARGE contracting agencies with many people placed are doing >well. I imagine that outsourcing is affecting their bottom lines, though. Big winners ARE outsourcing companies: Tata and Tech Mahindra. >The simple fact is that the old glory days of contracting are gone. No they're not. The action moved to India. >As the >knowledge required to build commercial computer systems is deskilled and >moved to tools and packages, the levels of programming skill required are >less than once was the case. This means that people who are computer >literate, but not necessarily skilled programmers, can build their own >solutions. For "mission critical" systems, most companies will still require >professional construction and this is either outsourced or built quickly >using contract resource. Modern tools and approaches have made this >possible; in the COBOL days it simply couldn't be done. (Nothing ever got >done quickly using COBOL...) Actually, it is done quickly. A typical six month project is timelined this way. Take away planning from the front end, say two months. Take away testing and approval signatures from the back end, say three months, although 3.5 is better because you don't know whether the manager will be on vacation. Whatever is left in the middle is programming time. Typically that's two weeks, although it is common for it to be 2-3 days. I've even seen it go negative. But programmers are kept around and paid for six months, just in case something goes wrong. Management sees the bill and THINKS programming took the whole six months, when it actually took two weeks. >Today it is the "Solutions Architect", rather than the Programmer who is >moving centre stage. Programmers used to be called Engineers, until real engineers complained about usurption of the title. Now it's architects' turn to complain.
From: Pete Dashwood on 28 Jun 2008 03:28
"Robert" <no(a)e.mail> wrote in message news:vlab645g2aa2idppk6r0n6o3qhsv4nlnk3(a)4ax.com... > On Sat, 28 Jun 2008 12:09:53 +1200, "Pete Dashwood" > <dashwood(a)removethis.enternet.co.nz> > wrote: > >>"Robert" <no(a)e.mail> wrote in message >>news:lta86493p3lh3st265vlni5vh72p0tas9a(a)4ax.com... >>> On Fri, 27 Jun 2008 00:14:59 +1200, "Pete Dashwood" <snip> > Most of the world thinks Americans are dumb. New Zealand is no exception. > I'm surprised you feel empowered to speak for all New Zealanders, Robert. (I certainly don't... :-)) It is certainly true that many people here are disappointed with the leadership (or lack of it) in the USA, but I think that goes for many Americans, too. Americans visiting NZ will be assured of the same warm welcome and courtesy we afford all our visitors (just as most Americans do for guests in their country, also...) Personally, I don't think Americans are stupid, being mindful of the technological and scientific breakthroughs that have come out of America during the 20th Century, and even, at a level closer to home, by some of the contributions made in this very forum by Americans, including yourself :-).. I DO think that some US foreign policy is "dumb" (foolish, stupid...), and it bugs me I don't get to vote on something that affects my future almost as much as anyone living in the USA... <snip> > > There must be a receptive audience for that idea, because I've been > hearing it as long as > I can remember. In the 70s, 4GLs would eliminate programmers by GENERATING > all the code. > In the 80s, 'your people' could do it themselves with Lotus or Excel > macros, or with > Access. In the 90s, any chimpanzee could drag and drop widgets, VB or VC++ > would spit out > the code. > > The words change, but the melody remains the same. It's old wine in new > bottles. There is some truth in what you say, insofar as things have been consistently overhyped throughout the latter part of the 20th century. But lessons are being learned. Last week MicroSoft only paid $100 million for a new "natural language" search technology; a few years back during the dot com boom, a lesser technology in the same field sold for over $500 million. The lower price reflects the fact that overhyped claims about natural language processing have been around for years. This time I believe they have a bargain. Just like you, and having been a programmer all of my working career, I am also cynical about lurid claims for software. But I do believe stuff I have seen and used myself. Drag and drop tools like Visual Studio increase productivity (well, MY productivity, anyway...:-)) many fold. Other visual tools like Iron Speed and Stimulsoft make Web sites and reports a matter of minutes, rather than days. Software and tools ARE getting better, more powerful and smarter than ever before and this trend looks like continuing. Smart scripting languages like Ruby, PHP, and Python are bringing quick builds of shared applications within reach of non-specialist people. Frameworks like Rails for Ruby, .Net (MicroSoft), Mono (Open Source), and Prototype (JavaScript) are providing tens of thousands of packaged components that can be accessed with a mouse click. People are building with Lego instead of with daub and what they are building is ready much quicker and is more structurally sound. More importantly, it can be easily disassembled and reassembled differently if needed... I'm currently working in a mixed COBOL / C# environment building some tools for a client. Every day I kind of dread moving to the COBOL machine and carving out code with the prehistoric IDE provided by Fujitsu and having to test and debug thousands of lines of procedural code. Yet there was a time (not so long ago...) when I did this quite happily. I'm even irritated at having to go back into that environment to check and test procedural COBOL generated by my own C# toolset... it is tiresome, boring and tedious. I'll be glad when I've finished it and can get back to the much more interesting task of expanding my horizons with LINQ and the finer details of C#...:-) The point I'm trying to make is that if you had asked me say, 10 years ago, if I would be unhappy writing COBOL, I would never have imagined that could happen. Since then, I have visited new worlds and found them to be good...:-) Despite all the hype we've had over decades about future tools, there is real evidence here and now, that at least some of these tools are delivering what they promised. > >>> Twenty years ago, the bill rate was the equivalent of $80/hr. Now it's >>> still $80/hr. >>> Clients are getting less for the same money; contracting companies are >>> getting rich. >> >>Hmmm... I know personally of a couple of recruitment agencies in the UK >>that >>have failed within the last few years. I'm sure there are more. It is a >>very >>competitive market place and more and more companies are using preferred >>supplier lists that will only admit agencies with a markup within 15% (the >>old cowboy days of agencies using 60% markups are thankfully, virtually >>gone...) This may not be the case in the USA, of course. > > <laugh> Ever since Y2K, 50% is a starting point. Contracting companies > aspire to get more. > I've told the story here about one who cried poor because it was making > only 70 out of 120 > bill rate. I know for a fact that IBM keeps 160 out of 200 bill rate. > > Blended Rate is their favorite phrase. That means you pay the same for > everyone, from > bunny to brain. Never mind that there are 50 bunnies for every brain. Then it's time this racket was publicly exposed and companies simply refused to pay outrageous bill rates to middlemen. (It happened in the U.K....) Sure, companies need contractors, but there are many agencies competing for the business... Imagine how ONE ethical agency that charged say, 20% markup and pitched their charge out rate 20% below what the cowboys are charging, could clean up. They would have no trouble getting contractors or clients. <snip> >> (Nothing ever got >>done quickly using COBOL...) > > Actually, it is done quickly. A typical six month project is timelined > this way. Take away > planning from the front end, say two months. Take away testing and > approval signatures > from the back end, say three months, although 3.5 is better because you > don't know whether > the manager will be on vacation. Whatever is left in the middle is > programming time. > Typically that's two weeks, although it is common for it to be 2-3 days. > I've even seen it > go negative. But programmers are kept around and paid for six months, just > in case > something goes wrong. Yeah, right... :-) > > Management sees the bill and THINKS programming took the whole six months, > when it > actually took two weeks. Whether they worked or not, they were on site for six months, being charged to that project. As a Project Manager, I'd be a little perturbed by this :-)... Pete. -- "I used to write COBOL...now I can do anything." |