Paul Gilmartin wrote: > Is there somewhere a customer who has an esthetic dislike for > "SYS1" and uses an alternative HLQ for production data sets?
I promise you, they are all over the place. If we could somehow gather all IBM z/OS customers together in one place (like SHARE) and then arrange things up so that only those who did NOT like "SYS1" for production data sets could attend SCIDS, you would find that the room would be as crowded as it ever has been. And then there are those that LOVE SYS1 for production anything. I'll share but one (very old) example. Recent examples would not be considered very tactful. But I promise you they exist. In my (relative) youth, there was an IBM customer, a competitor of my employer at the time, whose "no modifications to the OS" policy dictated that everything went into SYS1.something (since to have something else would require that it be created, which, by definition, would be a modification, hence not allowed). No, they did not have a clue, but they did have two 360/65s running just OS/360 -- no ASP, no HASP. They finished upgrading to two 370/165s and installed ASP literally a few weeks before the 165 boxes became boat anchors -- a blessing in disguise, since that eventually resulted in the DP manager's head rolling, which, I was told by an authoritative source, turned out to be the origin of much, if not most, of the cluelessness there. These maroons (designated thusly, so that we don't give morons a bad name -- to steal Chris Craddock's lovely phrase) put all of their production [COBOL] program load modules into -- hold on to your hats, folks -- SYS1.LINKLIB. Yes, I typed and you read that correctly. SYS1.LINKLIB. SysONEdotLINKLIB. Date cards were copied into members of SYS1.PARMLIB (still unblocked F 80 at that point). No TSO. (What!? Give a programmer direct access to the system?! Heaven forbid!) Their programmers still did everything on cards, literally. No "source manager" (e.g., ADR LIBRARIAN). Now, ordinarily, I would have interpreted putting anything at all into SYS1.anything as a "modification" but they considered the creation of something_else.LINKLIB to be a modification. The SYS1.LINKLIB data set was already there, and you didn't need to "modify" the system to create another load module repository. Besides, all the examples in the linkage editor manual showed the use of SYS1.LINKLIB, and that was the default SYSLMOD data set in many of the PROCs that came in (Gasp!) SYS1.PROCLIB. I am not making this stuff up. If I were, I would have to make sure to make it a lot more believable. They were forced to upgrade to the 370/165s not because a faster CPU was needed (obviously, if they were happy running straight OS/360 without ASP or HASP, then they had CPU and I/O resources to burn), but simply because SYS1.LINKLIB had grown too large to be entirely contained on a single 2314. They needed to install 3330s so that their SYS1.LINKLIBs could contain all the OS/360 stuff that IBM put there AND every last production load module they had. Test programs were in SYS1.LINKLIB on one of the two machines, and production programs were then re-link edited into SYS1.LINKLIB on the "production" machine. I don't really know how they shared data among these two systems. I asked. They wouldn't say. They might have been embarrassed, but that would have required a level of comprehension that I do not think they had. I understand very little was on DASD. That was OK given how they had written their applications: they had a boatload of tape drives: TWO full, completely unshared strings for EACH CPU. Maybe they did not share data (on DASD, I mean). But I don't know how they shared tapes, either. They certainly did not have TMS or TLMS (in fact, they did not even know what they were, but even I thought that was just a joke at the time -- in fact, it was not a joke). I do have a _idea_ how they did it, but it would take more lines than this list permits me to post in one message to describe it. You would not believe ... I gave a presentation at the local large system user's group about some OS/360 MVT mods I had brought with me from my last shop (which I was planning to install as soon as we were able to migrate to MVT) in order to improve shared CVOL catalog performance. I remember the talk very well because at that point the systems in my shop were still running MFT-II, which caused these guys to think they were so slick, since they were already running MVT! During that talk, which was not all that technical, their system programmers' eyes glazed over: didn't understand the term 'CVOL'. We both shared an IBM SE; she never said much about them other than that the branch manager had given her and everyone else explicit instructions never to say anything at all about how these guys did things or their capabilities, or what she herself did for them. But her eye rolls and unfinished, just-started-but-only-one-word-uttered sentences revealed all I needed to know. -- WB ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
