Traditional COBOL environment
in [Cobol]
|
From: Pete Dashwood on 27 Mar 2010 20:35 docdwarf(a)panix.com wrote: > In article > <aa32012e-c65d-4737-bdda-747f969a024c(a)b33g2000yqc.googlegroups.com>, > Alistair <alistair(a)ld50macca.demon.co.uk> wrote: >> On Mar 27, 2:06?am, docdw...(a)panix.com () wrote: > > [snip] > >>> I recall doing a fair amount of work on such machines that kept a >>> goodly amount of commerce moving. >> >> I thought that you were going to come up with a quote about getting >> old video machines to run on MVS 3.8. > > I once wrote a Formal Proposal that contained the statement 'Contrary > to > what some might say a mainframe *cannot* do everything a PC can; this > is > one of the reasons that 3278 terminals rarely display a Flying Toaster > screen-saver.' > > DD LOL! I hope you got the approval... Pete. -- "I used to write COBOL...now I can do anything."
From: Anonymous on 27 Mar 2010 21:36 In article <b597cb49-abc0-476d-bef8-37c742f806ec(a)q16g2000yqq.googlegroups.com>, WangVS <tjunker(a)tjunker.com> wrote: >On Mar 27, 10:19?am, docdw...(a)panix.com () wrote: >> In article ><9f61be9e-f82f-42c2-b3df-b96fcac95...(a)z11g2000yqz.googlegroups.com>, >> >> >> >> WangVS ?<tjun...(a)tjunker.com> wrote: >> >On Mar 26, 5:49?am, docdw...(a)panix.com () wrote: >> >> In article ><4438cbb8-e9aa-44eb-b9ed-089637b54...(a)35g2000yqm.googlegroups.com>, >> >> >> WangVS ?<tjun...(a)tjunker.com> wrote: >> >> >> [snip] >> >> >> >It's a complete >> >> >environment that turns a Dell PowerEdge server into a >> >> >Wang VS mainframe. ?COBOL 85 would be the language of >> >> >choice, although it also has a powerful 4GL database. >> >> >> Would that '4GL database' happen to be... PACE? >> >> >Yes indeed! ?You are familiar with it? >> >> Naw, just a lucky guess... now, let me gaze into the Eternal Aether, for a >> pathway to wisdom... I see a blue haze... does it have a blue haze, too? ? >> >> No, wait, I see letters... shimmering, floating, forming strange words... >> USERAIDS... USERSUBS... what could this all mean? > >Ah! It seems that in some prior life you inhabited my world. In a prior life I worked on Wall Street for an International Bank that had rigid delineation of functions between groups... and I trod across the borders with joyful abandon. 'Hey... you can't do that, that's Ops' job!' 'It is long after sunset and ops has gone home... are you going to tell them I did this?' 'Uhhhhh... maybe.' 'Tell ya what. Watch me, see what I do, ask questions and I'll give you workable answers, you'll learn something, the job will get done and I'll have a few extra hours of overtime. Call ops... and they'll throw you out of the clean room and let me do it anyway, ops and I get along right fine. Your choice... but make it march, I got a job to do.' DD
From: Anonymous on 27 Mar 2010 21:44 In article <817mitFce9U1(a)mid.individual.net>, Pete Dashwood <dashwood(a)removethis.enternet.co.nz> wrote: >docdwarf(a)panix.com wrote: >> In article >> <aa32012e-c65d-4737-bdda-747f969a024c(a)b33g2000yqc.googlegroups.com>, >> Alistair <alistair(a)ld50macca.demon.co.uk> wrote: [snip] >>> I thought that you were going to come up with a quote about getting >>> old video machines to run on MVS 3.8. >> >> I once wrote a Formal Proposal that contained the statement 'Contrary >> to >> what some might say a mainframe *cannot* do everything a PC can; this >> is >> one of the reasons that 3278 terminals rarely display a Flying Toaster >> screen-saver.' > >LOL! > >I hope you got the approval... Nope, that one went to a lad of oleagenous affect who declared 'We can make any machine do anything you want within 6 weeks for so small a pittance you can readily pay it up front.' DD
From: Anonymous on 27 Mar 2010 21:46 In article <1939228e-18b6-4093-862b-9a9ffc33f0c8(a)e6g2000yqh.googlegroups.com>, WangVS <tjunker(a)tjunker.com> wrote: >On Mar 27, 10:29?am, docdw...(a)panix.com () wrote: >> In article ><2aa10a30-f889-4d56-98fa-ebc93b382...(a)g10g2000yqh.googlegroups.com>, >> >> WangVS ?<tjun...(a)tjunker.com> wrote: >> >> [snip] >> >> >We looked at Hercules before writing our virtualization of the Wang >> >VS, as the VS was originally based on IBM 360/370. >> >> Is that the reason the System Reference was a purple booklet instead of a >> yellow one? > >No idea. It sounds, though, like you are speaking of the small >handbooks, not the primary full-size documentation, which was all >8-1/2 x 11 three ring punched until sometime in the 1990s when a >smaller format was adopted for COBOL 85 and COBOL ReSource manuals and >VS TCP/IP. Exactly, the 'purple booklets' were of the same size and function as the IBM 360/370 'yellow cards' (which, for a goodly part, were booklets as well). DD
From: WangVS on 28 Mar 2010 04:04
On Mar 27, 7:36 pm, docdw...(a)panix.com () wrote: > In a prior life I worked on Wall Street for an International Bank that had > rigid delineation of functions between groups... and I trod across the > borders with joyful abandon. > > 'Hey... you can't do that, that's Ops' job!' This reminds me of another advantage of the Wang VS environment. I never saw a Want site where there was rigid delineation of groups in development or operations. Staffing was remarkably light, with everyone essentially being capable of doing everything. This also led to perhaps the greatest weakness of the Wang VS -- that the system failed to have powerful consituencies among the staff to rise up in defense of the system when threatened. But the efficiencies were manifest. I consulted with a custom contract manufacturer of passive electronics -- cables and what not -- in the $250 million/year size range. The software was third-party, a close-loop JIT MRP package that committed resources in real time and required no overnight update cycle. The package consisted of about 300K lines of compiled Wang VS BASIC code, with many of the modules customized by and for the customer. Some of the customizations dealt with EDI processing of customer forecasts, and generating EDI invoices and shipping advices. Most of the customizations were long-term, though, incremental things done to adapt the package to suit the way the company did business. The fit was exceptionally good. During most of the 4+ years I worked there the programming staff was no greater than four people. Operations had perhaps eight people for 24 x 7 coverage. There came a time when the system was going to be replaced by an AS/ 400 system running Andersen's MAC-PAC MRP package. During the project a boatload of RPG programmers came on board, and Andersen conducted onsite training over many months, and had 29 people on site doing the necessary customizations. The fat AS/400 system they acquired turned out to be woefully insufficient and they had to buy another, one of the largest made. The claims by Andersen of real-time operation and no overnight update cycle turned out to be untrue. An overnight update cycle was required, and each day's available data on committed resources only reflected the previous day's picture. In the end the client shelled out somewhere in the neighborhood of $10-15 million to replace a Wang VS worth about $300K. During the year-long project the client had to deal with growing overload of the Wang VS by buying another high-end VS and clustering the two. That added another several hundred thousand to the value of the system being replaced, but was still dwarfed by the cost of the replacement. The effect of expanding the Wang VS, though, was to make the replacement completely unnecessary, as the original system became lightly loaded, snappy in response, and with a condensed overnight process that left the hardware available for maintenance actions for most of the night. They ended up with over 20 RPG programmers and had to absorb one of the outsourced development companies that helped with the customizations. 20+ programmers to replace about four, plus layers of management. In the end the client figured out that the cost of maintaining the customizations was too much. They cut back on the number of programmers to maybe 10-15, and abandoned six million dollars of customizations to use the stock MAC-PAC package with no customizations, thus giving up much of the custom package behavior that had been thought to be necessary for the way the company did business, unhappy compromise with reality. A big part of the foundation for this disaster was that the Wang VS system had such light staffing requirements that there was only a very small staff constituency to defend the VS and make the case for continuing to use it instead of replacing it with what might turn out to be an inferior package. Only one of the people in the VS staff was at a level to have the ear of top management, and that person didn't have much time in service as a Wang VS manager, and embraced the replacement instead of defending the VS. So management, clueless about the efficiency of the Wang VS and oblivious to the pitfalls of the proposed replacement, literally dashed headlong down the path of replacement, spending a large multiple of the value of the original system and getting what they themselves ultimately determined to be a cost-ineffective solution. In the final FINAL end, the company was acquired by a larger one and the AS/400 system that had consumed a year of more of everyone's time and many millions of dollars of resources was simply discarded as being useless to the new owner. So the whole exercise was a waste. It's possible that had the Wang VS not been so efficient to program and operate, it might have had a staff constituency powerful enough to defend it and avoid the whole disaster. The real shame, though, is that once a company has embarked on one of these failed conversions or replacements, the money has been spent and internal politics will characterize the project as successful no matter how bad it was, objectively. There is no facing up to the failure and taking the obvious step to remedy it. There is no going back. And the management responsible often leaves for new pastures, adding the project to their resumes, leaving the mess for the remainder of staff to live with. TJ |