I'm totally on board with Tom Marchant's position. It's why I've presented at so many SHARE sessions over the years. Our profession is uplifted by spreading knowledge and sharing experience. OTOH I can think of a few cases where a little less cleverness early on might have ameliorated some solution designs that eventually became problematic.
A major credit reporting entity based in SoCal wrote a new application that needed some kind of data base. This was in the 70s, long before DB2 and well before VSAM APIs were built seamlessly into COBOL. The clever designers came up with a novel solution. Create a giant multivolume PDS (PO) that could be processed in direct access mode. There was no restriction at the time on opening a PDS as DSORG=DA. It was fast, efficient, and reliable. Trouble was, IBM eventually decided that this was an unnatural perversion and inserted a check for PDS at open time. Last I heard, the customer routinely had to obtain and manage a special usermod from IBM to allow the app to run at all. Another company created a mechanism that serialized CICS data access at the record level using a common storage locking table. This was before LPAR, so all CICS regions could access the same common storage. Then came LPAR, where each system had its own separate common storage. Not all CICS regions could communicate with each other directly via memory. The original design was modified to allow one region to be the traffic cop for all regions. It worked great except when an outage occurred on the lock region. That region could be moved to another LPAR, but there was a several-minute application interruption at each end of the move. At one time this was just a cost of doing business, but when parallel sysplex came along with its promise of continuous availability, these periodic outages became harder to justify. If that original solution had not been so successful so long ago, there might have been a move to coupling facility lock structures that would have been impervious to individual region availability. None of this is to undermine Tom's compelling argument. Heck, it's Friday. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Marchant Sent: Friday, January 13, 2017 6:15 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Smart enough (was Re: SDB and Program Object Library) On Thu, 12 Jan 2017 16:41:58 -0500, Farley, Peter wrote: ><rant> My unfortunate experience has been that ordinary users are not >considered smart enough to see or understand what storage admins do. ></rant> This is one of my pet peeves, so I'll extend your rant a bit. Ever since I started in this business, people have warned me that certain people aren't smart enough to understand, and that giving them too much information will cause problems. As an application programmer, I was told that if I gave operators too much information,they wouldn't understand and would f*** things up worse than if I just keep them ignorant. As an Amdahl SE, I was told that the hardware guys couldn't handle software knowledge, and neither could the customer's sysprogs. As a system programmer, it was the applications programmers, the system analysts, auditors, managers and vendors. Now as an ISV software developer, it is the customers and the support people. There is one person at a customer site who I was told is totally unreasonable, and incapable of learning or following directions. I had occasion to talk on the phone with this person to help resolve an issue. We worked together looking at various things until we discovered the cause of the problem. As it happened, a relatively minor mistake had been made. In the process of working with the him, I learned that everything I had been told about him was untrue. He was bright, thoughtful, and a damn good sysprog. He knew better than us how to do things, and had his own procedures that make more sense than the canned procedures that we provided. In over 45 years in this business, everyone I have ever met does a better job with more information. Even more importantly, when people are treated with respect and with the assumption that they are competent, they do better work. Sure, sometimes all of us make mistakes, sometimes with catastrophic results. I remember well the day that I was getting ready to IPL a test LPAR and reset a production LPAR instead. Was I stoned or stupid? Neither. The user-dummy is a myth. -- Tom Marchant ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
