On Mon, Feb 2, 2015 at 11:08 AM, Paul Gilmartin < [email protected]> wrote:
> On Mon, 2 Feb 2015 09:14:35 -0600, John McKown wrote: > > >I liked this article: > > > https://enterprisersproject.com/article/2014/12/how-today-s-young-it-talent-different-previous-generations > > > Where I read: > ... For example, one thing I try to do is to have our IT > infrastructure employees trained > to code so that they can automate repetitive tasks. > > In contrast to the Enterprise mindset frequently apparent here: "We don't > want our general IT infrastructure employees coding." And even (though > less frequently lately): "How can I prevent my coders' using Unix System > Services?" > We have that problem here at bit. The reason is due to staffing levels and the amount of work to _maintain_ said coding. In the past, we had the applications group (about 40 people at the time) work up an ISPF application which they used to do their compiles and tests. The two main people who did the work left. Guess what happened? This applications developed tool got shoved onto the system programming group (in particular to me) because "nobody here can understand it. And we need some immediate updates because we don't remember how to code compile and link JCL properly!" Today we use CA-Endevor. Curiously the same problem still exists because it was implemented by some hot shot consultants talking to the programming staff. Once the hot shots left, guess who had to support the Endevor processors which they had no knowledge of because they were excluded at install time? Oh, and since consultants bill by the hour, nobody wanted to pay them to actually document what they had done. Having said the above, I have one horrible process that I have implemented. It scans the z/OS SYSLOG and produces a report. But it does its work by sending all of the weekly SYSLOG information to my Linux desktop where it is merged together (2 systems), and intelligently time-sorted, then uploaded back to z/OS. In addition, some Linux code takes the sorted information and creates a minor performance report. I will grant that I could do this work on z/OS itself. But I didn't because I am then asked to justify my use of resources (CPU and disk). Again, this is a problem here and hopefully not generic in the industry. Our first law of I.T. "thou shalt spend no money!". The second is like unto the first: "Thou shalt find way to do more while spending even less money so that our budget may be reduced." > > OTOH a current thread in IBMVM: > > https://listserv.uark.edu/cgi-bin/wa?A2=ind1502&L=IBMVM&O=D&F=&S=&P=1987 > missing CUA 2001 package files... > > ... explores the legal, technical, and social hazards of garage tools > development. > > -- gil > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > -- He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
