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 language
Scott ford www.identityforge.com On Jun 15, 2012, at 4:22 PM, Ed Gould <edgould1...@comcast.net> 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..l >> >> Scott ford >> www.identityforge.com >> >> On Jun 1, 2012, at 5:33 PM, Kirk Talman <rkueb...@tsys.com> wrote: >> >>> IBM Mainframe Discussion List <ibm-m...@bama.ua.edu> wrote on 05/23/2012 >>> 05:39:26 PM: >>> >>>> From: "Roberts, John J" <jrobe...@dhs.state.ia.us> >>> >>>>> When the last Cobol programmers walk out the door, so may 50 years >>>> of business processes within the software they created. Will you be >>>> ready? >>> >>>> >>>> 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 multiple >>> nations, 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 question >>> and he could answer it or tell you where to find the answer. >>> >>> Without that kind of person, trying to port the application to anything >>> else 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 to >>>> invest 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 to >>>> do 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 Cobol >>> programmers. They work fine. But again, the application knowledge is not >>> in 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 career >>>> dead-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 the >>> documentation is there, there is not a huge chasm to cross. >>> >>>> (4) In the end, US companies are going to be forced to pay a premium >>>> just to hang on to their old-timers long enough to buy time to >>>> implement that new ERP package or new custom application. The ones >>>> that 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 fine >>> skill 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 dealing >>> with 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 lists...@bama.ua.edu with the message: INFO IBM-MAIN >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
