As I am reading this, all I can think of is Windows 10 and Automatic updates. Since accidentally going to Windows 10, I have crashed my laptop at least 10 times and spent many days and a lot of money trying to recover. Be careful what you wish for.
Bill ________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Edward Gould <[email protected]> Sent: Friday, June 23, 2017 3:12 AM To: [email protected] Subject: Re: Eliminating the systems programmer was Re: IBM cuts contractor billing by 15 percent (our else) > On Jun 22, 2017, at 6:50 PM, Clark Morris <[email protected]> wrote: >> ————————————__SNIP------------------------------------------------------ > > If the goal was to eliminate the need for highly technical people who > understand the platform and the tradeoffs, that is a futile goal for > any operating system. If the goal is to eliminate the need for > assembler coded exits, this is more doable but customization will > always be with us. While there can be plenty of obscurity in > assembler, how well documented are the SYS1.PARMLIB members and JES > initialization decks that control how the systems operate? These are > just weird programming interfaces that can be every bit as cryptic. > > As someone who did his last systems programming in the 1990s, I would > hope that systems maintenance and upgrade has become a lot easier (and > if IBM made the Knowledge Center and Shopz 24/365.24 available) and > that less custom code is required because of all the new concerns that > I didn't have to deal with. The environment has become more complex > for all of the operating systems so anything that can be eliminated is > to the good. There is enough to do so that automation of some of the > grunt work is a good thing. > > Clark Morris Clark, The instructor just said systems programmers. I will agree with you on the exits and assembler though. Having said that I just cannot see a non assembler person going through system dumps. The needed CB structure and to decode machine language and understand what each instruction is attempting to do is just impossible (to me)to expect of an average COBOL programmer. Also having said that as long as IBM is as cryptic as some of their messages can be *AND* trying to understand in context what the return code is sort of indicating would be daunting to and programmer type, IMO. AT least they got rid of “call your local system programmer” explanations in the M&C. As long as I semi brought up SERVPAC, IBM needlessly (IMO) complicated the install process. In my opinion CBIPO and CBPDO were pretty much as good as it is going to get. IBM should have kept the level of the base better up to date, was the only issue I had. It would have cut down on the Apply’s. Yes there are pluses for sevrpac but you stilll need to know a bit about SMPE. Given that SMPE is the standard for installation of maintenance I really don’t see SERVPAC being all that helpful. I know when I tried a couple of SERVPACs they were ugly and could be screwed up easily. The German support was less than typical IBM support. I got the feeling that (at least according to IBM) that customers complained about the cost of system programmers. Ed ---------------------------------------------------------------------- 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
