On Sat, Jun 16, 2012 at 9:30 AM, Scott Ford <[email protected]> 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 language > Have you tried using an assembler main which attaches separate subtasks? And then have the subtasks issue CEEPIPI to setup an LE enclave for the COBOL programs? This works well. > > Scott 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..l > >> > >> Scott 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/2012 > >>> 05:39:26 PM: > >>> > >>>> From: "Roberts, John J" <[email protected]> > >>> > >>>>> 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 [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
