Scott:I do not know if your STC's are production or not. I would hope changes go through change control. I also do not know how you manage change when a OS demands that the program goes though the update process. Generally I am for COBOL (whatever works for you). What I am finding is that COBOL (major business basic foundation) is mandated to go to the next version of COBOL. The microscope is quite different between one and 1000's (or more) that is where this issue comes in. I would hope that major logic changes are not needed but in the case of COBOL depending on what IBM is obsoleting it may or may not be a major change. For instance ISAM is long since dead and at least before IBM had a bridge for ISAM to VSAM (transparent mostly). Between the change to COBOL and LE in our case in was a major pain. Other places barely felt it. I am sure the last 30 years came and bit us rather badly. Was it bad coding, bad compile options, bad programming I am sure it was a little bit of everything. However (big however) IBM did not provide to us anyway, transparency like in the past. I don't know how many versions of the compiler we had gone through with essentially no pain. The subroutines (LE) were a case in point of a disaster. Again there was really a bad manual whether it was a conversion guide or migration guide (mute point IMO) it caused a uprising I have yet to see in a programming group. When we sent it out the phones started to ring off the hook. Our best programmers were up in arms. At one point my call back list was 25 deep and my boss (and his boss) was inundated with really nasty phone calls from managers and their managers (VP's were a dime a dozen and I treated them all the same). A meeting was held and we had to have two meetings as we couldn't find a room large enough. The meetings went off on a bad note and went down hill. After the meetings we regrouped and with all the political heat we came up with a suggestion that all program were to be recompiled into a separate libraries and stages into separate libraries into production. We then could fight battles that were containable. The programmers had to come up with on site support staff as groups of programs were staged. Yes we had issues (especially with multiple modules in one lmod) but we fought and eventually won the fight. Never in my history with IBM was there an utter breakdown in compatibility like there was for COBOL AND LE before. (LE was new but the arrogance of the LE people was astounding IMO). Issues called in were at best handle with "so?" their standard pat answer was not fun to listen to. I got sick and tired of talking with the LE people.
The arrogance of the level 2, COBOL people on simple compile issues (with super vague error messages) was astounding almost as bad as the LE people . Programmers wanted to kill our group as we could not help as we were just stooges to call in to IBM. I am not sure which group I disliked more whether it was COBOL or LE. I was trolling for all maintenance for both products and disliked the vagueness of language on ptf cover letters and the verbiage on IBMLINK. When I would call up on what the cover letter was really saying I was brusquely told to read the english and put in whatever language I wanted it to say.
IBM did not have programmers at the door like I did. I wish I could have sicked them on IBM but as much as I wanted to I couldn't.
Ed On Jun 16, 2012, at 11:30 AM, Scott Ford wrote:
Ed,We have our STCs written in COBOL calling assembler sub routines, which works great. We are a tcpip socket server and client ...the client is like a hybrid app. The point is the only drawback I see to using COBOL, is the ability to multi- task or thread, I know COBOL can, but haven't seen samples or heard anyone doing that. The other small issue are samples , some god and some bad, like any other languageScott ford www.identityforge.com On Jun 15, 2012, at 4:22 PM, Ed Gould <[email protected]> wrote:Scott:Manual reading has always been an issue. For year we have been asking IBM to write clear and useful manuals. Somewhere around the mid 1990's IBM seem to have done a reverse and either stop issuing manuals (eg COBOL MESSAGES AND CODES) or made them so complicated to read (COBOL conversion guide) it takes a lawyer to understand them (not only do you have to by a lawyer you have to have technical knowledge of a guru in order to understand the vagaries of the writing. That leaves most of the other manuals difficult or hard to understand. The COBOL conversion manual is probably the clearest case of manual writers gone wrong.Ed On Jun 3, 2012, at 12:42 PM, Scott Ford wrote:Kirk,Yes, I agree also and the ability to read a manual....have a ton of customers who don't even take the time to rtfm..lScott ford www.identityforge.com On Jun 1, 2012, at 5:33 PM, Kirk Talman <[email protected]> wrote:IBM Mainframe Discussion List <[email protected]> wrote on 05/23/201205:39:26 PM:From: "Roberts, John J" <[email protected]>When the last Cobol programmers walk out the door, so may 50 yearsof business processes within the software they created. Will you beready?Ed, Interesting article and fairly accurate IMO. This is what I can foresee happening: (1) Many companies will try to offshore their COBOL application support. But this won't work so well because it is hard enough to understand these systems without facing the complications of language and arcane terminology. And the young ones back in Bangalore will want to do Java, not COBOL.Actually the language is not a problem. We have people here from multiplenations, some whose English is lacking. But they can doing the programming work - well.The problem is the lack of application knowledge. We just had a senior person retire to a ranch in FL. He was senior person in his critical application. He ran a series of weekly one hour technical seminars. The problem was that he could answer any question off the top of his head. But an organized overview and drill down into each part of the system and the relationship of that system to multiple other systems was not there.He was used to being a S(ubject)M(atter)E(xpert)/guru. Ask him a questionand he could answer it or tell you where to find the answer.Without that kind of person, trying to port the application to anythingelse is risky as is training newbies.(2) Other companies will want to recruit overseas, either for CS grads that they can train, or for those few that are willing toinvest in COBOL learning if that is what it takes to punch that H1B ticket. But even so, once here they are all going to be looking todo something else, not COBOL. So that company that recruits and trains a COBOL resource is going to be looking for a replacement within a couple years.We have had over the years training programs to build new Cobolprogrammers. They work fine. But again, the application knowledge is notin books. It was transmitted by SMEs.(3) Efforts to train new young COBOL resources are going to flop, as the article mentions. Again, everyone expects COBOL to be a careerdead-end once beyond a 5 to 10 year transition period.Since Cobol is now talking to distributed applications in various ways, Cobol people are getting exposure to distributed applications. I recently had a project transferred from me which was going to have me build part of an environment that is both mainframe and distributed. As long as thedocumentation is there, there is not a huge chasm to cross.(4) In the end, US companies are going to be forced to pay a premiumjust to hang on to their old-timers long enough to buy time toimplement that new ERP package or new custom application. The onesthat will be successful doing this are going to be the ones that accommodate their senior developer's desires: lots of time off, telecommuting, job sharing, benefits, etc.Right now at the moment there are enough Cobol programmers leaving other companies that is still a supply of new people, some of which have fineskill sets. But as time goes on, there will be a cliff.I just returned from Germany. There was talk there that there is an "engineering" shortage in the market there. Never bothered with the details. Maybe the recession there will give them time to kick the can down the road more. After all, it has been working so well for dealingwith their financial problems.John----------------------------------------- The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you------------------------------------------------------------------- ---For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN-------------------------------------------------------------------- --For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN--------------------------------------------------------------------- -For IBM-MAIN subscribe / signoff / archive access instructions,send email to [email protected] with the message: INFO IBM- MAIN---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
