OCO.APR OBJECT CODE ONLY (OCO): NaSPA Member Contributions Editor's Note: We feel this is the best way to present the interesting, informative and controversial topic of Object Code Only (OCO). This article follows the format of our regular NaSCOM Highlights column. In short, Object Code Only (OCO) is source code that programmers can learn from. This topic could have a dramatic influence on the educational advancement of systems programmers. The saying, "A picture is worth a thousand words," holds true when talking about source code written by professionals. Using source code as a learning tool is probably the most important concept for learning an architecture. While it's not a requirement for learning, it's a necessity if you're going to produce future systems in an acceptable time frame. We have to develop ways to help eliminate reinventing the wheel and use existing tools and resources as a foundation for what lies ahead. On the other side of the coin are those creative and innovative individuals and companies that need a way to protect their investment from those greedy, selfserving individuals and companies that want to take the source code away from them. At NaSTEC 2.0, Dwight Miller will discuss OCO and other important topics concerning the data processing profession. We hope you agree, that the following material is informative: Where's the Source? Where's the Source? Most VMers and VSEers still have access to the source code that makes up their operating system. In the MVS world, only JES2 and JES3 are still operating system programs maintained in source mode. Some IUPs and FDPs still provide source such as SDSF, but they are scarce. IBM's OCO policy also would take away microfiche and logic manuals. Computer Associates is rumoring that CA-1 source code will be replaced with OCO maintenance except for exits and MVS hook building modules. How do you feel about OCO? Is it or will it have a big impact on the systems programmer? Have you been getting adequate support from IBM or other vendors? Let me know what you think. Perhaps the threads could be published in Technical Support. Howard Dean (DeanHowA) It seems that IBM, and most PC vendors for that matter, would be happy to eliminate the system programmer. The frustration is that the user depends on quick, easy, simple and correct answers when something smokes. First, I know the user's business initially, then apply systems to it. Second, I am here, in the flesh, bedside manner and all, when the smoke hits. Can you imagine a 13,000 employee high-tech avionics company running on a bunch of diskless PCs IRMAed into a lights-out 3090-900 full of CA software and not one person in the building can even spell assembler, much less JCL or helpdesk. Dwight Miller (MillDwiA) VSE has been OCO for a long time. VM is still primarily source-maintained, but about 20 to 25 percent of VM/XA SP 2 is OCO. IBM does not seem to realize that providing source code serves all our interests. I will say up-front that I work for a software vendor and I am a developer for a CP-enhancement product that is implemented as a CP modification. At least five of our products, including mine, would be almost impossible to implement without source. So, I am biased. VMers, MVSers and VSE-types all contributed to the development of their operating systems through local modifications when source was available. Some of these were picked up in products by IBM and enhanced the utility and marketability of the operating systems. Others made the systems more usable and kept people on blue boxes when other options (DEC, Honeywell and Burroughs) were available. Indeed, VM probably would have perished between 1973 and 1981 if not for source. IBM did almost nothing to enhance it. Users, with source available, fixed performance problems, added functions, fixed bugs and spread the word about VM. Without that, IBM would not have the operating system it has today. Jim McMaster (McmaJamO) Jim, I don't mean to sound snotty, and this is really an honest question: Does VMSG supply its products with source code? I deal with four vendors other than IBM (both VSE and VM) and none supplies source code. It seems to me that the OCO debate is something of a double standard. Am I out of line? Robin Sharpe (SharRobH) Robin, I can't think of another vendor that makes operating systems. If DASDMON or OMEGAMON fails, I probably could live with the function for a few days. But if MVS fails, it's curtains for our business. You're right about the double standard, but no other vendor has had a tradition of users developing code or fixing bugs. IBM and systems programmers are what caused the stability of MVS; otherwise, we'd all still be MVT users. We supplied IBM with most of the ideas to make its code work. Vendors simply were users who decided to sell their ideas. If I don't like a vendor's performance, I can always buy a competing product. Show me where MVS, VM or VSE has any competition. Howard Dean (DeanHowA) VMSG provides full, commented source code for all its products. This has been company policy for several years, and we find it beneficial to us as well as our customers. Gabe Goldberg is one of the front-line crusaders against IBM's OCO policy and is a VP at VMSG. Jim McMaster (McmaJamO) Jim, We recently had a problem with a network product called Network Data Mover (NDM). The symptoms were an ABEND0C4 in one of its queue processing modules. I called the support number and was asked for a dump and trace. I mailed the material to Texas. Five days later, I got a call from the vendor telling me it was an IBM problem and they gave me the APAR number. This product is distributed OCO. If I would have had access to the source even on microfiche, I could have shot the bug in a few hours. Without the source, it took five days. That's five days our users were without a functional product. If that's what IBM intended, it is unacceptable. We hardly can tolerate MVS cuing down for one hour a week (our only stand-alone time). I think both vendors and IBM are too paranoid of theft. We would be glad to sign a nondisclosure agreement in exchange for source. Howard Dean (DeanHowA) The problem with NDM is what I was talking about. This is an issue that all NaSPA members and NaSPA itself, should be concerned with. The only solution is to get upper management concerned. At the 1988 VM workshop, Jim Anderson, an authority in VM development, said that IBM had surveyed hundreds of CEOs at large corporations about their concerns, and not one mentioned source code. Talk about asking the wrong people! In fact, one of their biggest concerns was high overhead costs, especially costs of high-priced systems programmers. IBM is pushing OCO as a solution to those high staff costs! Upper management needs an education from us. Jim McMaster (McmaJamO) Your experience with the NDM vendor is not really an OCO issue. We have had NDM for about two years. It is extremely slow to identify and fix problems in its product. The product seems to work alright if you stay with the current level for a while after the new level of MVS/DFP comes out. Kim Westerling (WestKimF) Kim, you're right. However, if we at least had the microfiche, I wouldn't be dependent on its slow customer support. I could have spent my time shooting the dump instead of playing telephone tag with the reps. Dean Howard (DeanHowA) Howard asked about IBM maintenance. It generally possesses attributes of high vacuum. With source, you don't have to listen to IBM say "working as designed," which means "broken as designed" or accept a DOC APAR closing on broken code. You can fix it yourself and give the fix to others and get them to pressure IBM into taking your fix. Otherwise, you generally are stuck. For example, look at CMS windows. It is a horrible, slow, non-intuitive interface. VMers have complained about it for months, but IBM will not fix it. It is OCO, so users can't fix it. As a result, almost no one uses it. Jim McMaster (McmaJamO) OCO JES2 Since we are still running extensive JES2 MODS (inherited ones, of course), I'm definitely opposed to JES2 OCO. Even if we were not running MODS, the only way to get some of the exit facilities working is to browse through the source code. As far as CA is concerned, we're stilling trying to get the JES2/ACF2 interface working correctly. If its Exit 225 has been shipped OCO (with its level of support), I might as well take a six-month vacation while waiting for the solution. Mike Alexander (AlexWtuH) Well, the start of JES2 OCO is here. JES2 3.1.1 (MVS/ESA) has one module that is OCO. The rest is still source maintained. That module handles the hyperspace interface. When asked why that particular module was OCO at the last SHARE conference, IBM said, "...because it is new and no one has any modifications on it and it uses undocumented interfaces to systems services. This is something we really don't want our customers to experiment with..." I guess this is the mushroom theory of support: Keep 'em in the dark and feed them manure. Howard Dean (DeanHowA) o Some of my management think OCO is the best thing since sliced bread. Fortunately, others disagree. o I really don't want the PL/S or PL/AS source for most things. What would I do with it all? Especially since I can't get a PL/AS compiler (tightly guarded by IBM). o Microfiche is another story. Like it or not, we have made modifications to certain routines, including the FORTRAN run time libraries, to handle and support the users' needs. Remember, the customer comes first, as much as we knock our users. o Contrary to some people's opinions, we try not to modify the system just for the heck of it. We're getting better. However, when a product, including MVS/XA, doesn't do what we need it to do, we must modify it, if the vendor won't. o Also, I believe it is to the vendor's benefit to have knowledgeable end sysprogs out there. Removing microfiche and PLMs IBM (and others) may simply be moving more of the problem determination and fix location work on to their own staffs. Not to mention complaints: it doesn't work and/or I'm not getting the support I need. Don Weimer (WeimDonD) Don, If you've noticed, IBM has been a bit skimpy on its documentation of documented system interfaces. For example, SWA above the line: This was a selling point for MVS/XA, and IBM promised a documented interface to the SWA manager (albeit for APF authorized users only--until 8802). However, there is no documentation on how to code your IEFUJV exit to specify SWA above the line. The bits to set are not even described. The SWAREQ macro documentation leaves many questions. The unauthorized interface to the SWA manager has no documentation. Now, if this is the way IBM treats things it wants you to know, I shudder to think how it'll treat things they don't want you to know. I have complained recently about the lack of examples. The only thing is to ask equal questions, which take a long time to get answers. The fiche usually is necessary to answer my questions about documented EXITS that IBM doesn't. Dean Howard (DeanHowA) Don, IBM certainly has gotten out of the education business in the last decade. But, it has been replaced with better classes by AMDAHL, On-Line Systems, and even Verhoff. The biggest fear, not the only one, I have with OCO is when IBM dries up the internal documentation for these third-party education centers. We will all lose the ability to understand the latest and greatest OS. Several years ago, I was involved with a SHARE white paper to IBM on OCO. After much ado, it simply was watered down and ignored by the IBM/SHARE professionals. At the time, it was opposed violently by nearly all concerned. All we managed to do was delay OCO by a couple of years. Oh well, it was fun. Phil Groome (GrooJtuH) Phil, I was also involved with the SHARE OCO white paper. I think they tried to make a business case to IBM for not going OCO, but it was really a political issue. OCO probably will backfire and cause IBM software quality and functionality to deteriorate over the years. Users cannot make intelligent SHARE requirements if they do not understand how their operating systems and products function internally. You can ask for a few exits, but the diagnostics are useless if you can't understand what your trying to diagnose. It's sort of like a doctor who can ask the AMA for things he'd like to see in the human body, but is not allowed to examine anyone or read any books on how the body functions. It would be difficult to make a valid diagnosis in that case which will cause a lot of crisises. However, by the time IBM realizes what a good thing it has going with users debugging its code, there won't be any systems programmers left. Their job will not be fun anymore and the challenge will be gone. Either they will go to work for IBM or other vendors, or they will move on to other careers. The new systems programmers will be woefully inexperienced because, due to OCO, they won't be able to learn by doing as their ancestors did. I learned an awful lot from modifying code, debugging software and reading the microfiche. Try understanding a PTF cover letter without some concept of the component's logic. How can you even do a search on IBMLINK if you don't have some idea of the component logic? If you look at other vendors doing OCO (most of them are), there are few experts in their products and they have to charge a lot of money to provide support. IBM has always provided excellent support at a reasonable price because its users were knowledgeable about their systems and don't need Level 2 that often. Dean Howard (DeanHowA) Systems Programmers and OCO In reading the messages on NaSCOM about OCO and sysprog being less desired by IBM, I was reminded of a conversation with my manager a few days ago. True, there is a lot of talk by IBM to management about how companies will need fewer sysprogs because of the advances in software and the distribution of software. Also, the advent of Automated Operations, of which we are fanatics, is said to be a way to reduce staff. The advance of OCO also reduces the need for sysprogs. But is this really true with more complex software and its distribution? Also, as the new releases are made available, and the old software is no longer supported (ISAM is one example, IBM moved it to its own LPA library with DFP VER 3), can non-support be far behind? Who is going to fix or bypass the old local applications that require the old software? The more elaborate the automated systems become, who is going to figure out what broke when it fails? There is talk by IBM and other vendors that a lot of the daily things being done by sysprogs can be automated. This may be true, but it takes more than a clist to determine what is monkey-see, monkey-do and what is not. The one thing that fancy software distribution and automation cannot replace is the experience and knowledge that each sysprog has gained and nurtured over the years. IBM does know this, but with the exception of the classes we go to, once in a great while, this does no longer contribute to the old bottom line. Sysprogs will continue to be needed as systems get more complex. Do not let IBM, another vendor or even your own superiors begin to believe that anyone can do systems programming. Sooner or later the tide will turn again. Kim Westerling (WestKimF) Kim, I realize this was just a side issue in your message, but I can't resist commenting. IBM has already announced that ISAM will not be supported on SMS-controlled volumes. Since IBM expects that most good shops eventually will migrate to SMS, it is obviously announcing its demise without actually saying so. In IBM's defense (did I really say that?), it has supported applications written for ISAM with VSAM files via the ISAM compatibility interface since day one of VSAM. It didn't always work well, and it still has a few restrictions, but it was there. Most ISAM applications can be migrated to VSAM without recoding. I also can't resist mentioning that our Innovation Access Method (IAM) supports both natively coded ISAM and VSAM programs without program changes and has much better performance than either. It supports keyed (KSDS-type) files only. Bruce Black (BlacBruK) Kim....Bravo! You have hit the nail on the head. IBM is selling the concept of a system janitor who can take a tape from IBM, load it down and never understand anything about the process or the software. This will allow IBM to sell whatever garbage it desires, with no one the wiser. Jim McMaster (McmaJamO) Jim, we've had direct experience with the janitor approach to systems programming. We opened a datacenter in Hong Kong that was run from California. Two junior systems programmers were hired, but they were not given any tasks. When we were ready to ship an upgraded system to them, we cut a tape, shipped it to Hong Kong and had them load it and IPL. They got bored quickly and even with two people, the turnover was high due to the automation. We finally had to give up the datacenter there and move it about 30 miles away from our current datacenter. Its still automated, but there are no systems programmers and only a few operators. We maintain it from our current site. We learned our lesson. Without some challenge, all you'll get is a janitor mentality who eventually will get bored and quit when he/she is unable to learn. One of the problems with OCO and AO is that systems programmers have been moved down a few notches in the eyes of CEOs or CIOs. Those that were once trusted assets to the company are no longer thought of as professionals but as necessary evils in the DP community. Issues that systems programmers have been dealing with for many years have now been delegated to less experienced administrators. These areas include security, DASD management, program maintenance, technical support and exit coding. Authority has been yanked away from us because now we cannot be trusted and must be closely watched because those that are too familiar with internals can be dangerous. These administrators usually know how to do administrative tasks, but fail miserably when problems arise. They then look to systems programmers for advice. I, for one, do not relish being a mechanic or an answer man. Dean Howard (DeanHowA) Howard, I didn't know you had worked here. Unfortunately, there is too much truth in your comment. One of the largest problems we have is being taken for granted until there is a problem and then suddenly you've become the most important person on earth. We've been trying to get additional support in our area for several years to provide adequate backup for our responsibilities. However, each year we see other areas receive allocations for additional staff while we struggle along with a minimal staff. The funny thing about it is that they keep dropping additional tasks on us at the same time. On one hand, our director (who is a vice-provost) stuck his neck out for our area when we wanted to go to XA. He told everyone from the president of the university down that we could do the job without a detrimental impact on any of the user areas. We made him look good and, in all honesty, we got a lot of perks from it. At the same time, they split DASD, security and performance and created a new department because they needed somewhere to put some people. For two years, this new area had control of our software budget: We had space management and performance packages running out of our ears. I just can't tell where they get the information needed to make decisions. Mike Alexander (AlexWtuH) If IBM is pushing drop-in systems with OCO, why then have the diagnostic(s) publications for MVS/ESA and TSO/E 2.1 grown so quickly? I am currently in the process of front-ending the SMP/E dialogues that simply tell the installer to perform any applicable pre-apply processing (like backups or building a new target zone). Where is this knowledge going to reside except in the experienced system programmer? David Stern (SterDavJ) I think that is the point to the whole discussion. The experienced sysprog will continue to be important to each installation. There may just be fewer of us, and we will have less non-OCO information upon which to make our decisions. Kim Westerling (WestKimF) I think your comments regarding the separation of what a vendor claims is reality and what is reality are most appropriate. I really do not think this issue started with OCO, though. IBM has been shipping software for many years in various forms. The stated goal of these various forms of packaging have been to reduce the systems programmer's effort to get the software installed. If it worked that way, it would less systems programmers. That all sounds great, I'd love to have my systems programmers spend more time making new things work than fixing IBM bugs and reading/verifying installation materials. But that has not been our experience. I really believe if any responsible non-IBM vendor marketed a product that competed with SMP/E, all our jobs would be in much greater danger. If someone besides IBM were doing SMP/E, we'd all be in much greater fear of our jobs. Until IBM can demonstrate a greater ability to deliver system software that runs and makes some moves toward efficiency in its software products, I do not believe any IPO, EXPRESS, SMP/E, MSHP, OCO or SOLUTIONPAC name or claim will result in less IBM systems programmers. The harder IBM makes it for the installations to understand what is happening in their systems, the more money will be made by those who can figure it out. And, the greater opportunity for non-IBM vendors to provide an OCO-product that actually does what is needed translates into more systems programmer jobs. If a qualified software vendor stated they were going to do the complete OCO-thing for IBM system software, I would be scared. But this is IBM. Randy Evans (EvanRanI) The new diagnostics manuals don't tell you how to fix a problem. They simply tell you how to gather the data so you can pass it on to the Level 1 rep. Most newer program's diagnostics publications consist of telling the user how to formulate a RETAIN search string. However, RETAIN (at least, the system the strings are used for) is not available to the user. Only IBM SEs can log-on to RETAIN. The other diagnostic techniques tell users how to run traces, record register contents and certain fields to look for in dumps. The program logic is not really mentioned, because a software janitor has no need to know. Our newer sysprogs use the SMP/E panels to walk them through an installation without real understanding. When they run into problems, they ask me or call the support center. When I help them, I make them run the SMP/E install without the dialogs and explain what the process is doing. Howard Dean (DeanHowA) What Can We Do? One option we all appear to be missing is that we have a forum here that may be able to direct some influence against IBM toward keeping source code available. SHARE has been mentioned many times, but perhaps member chapters could raise the question as well. I have no idea as to the legality of this, but it does appear as if there are alternative options available. I fear that as OCO becomes more prevalent, there will be a reduced number of opportunities for new folks coming up to learn the intricacies of the code (especially as the more experienced programmers retire). Any customization of software has to be within the boundary constraints imposed by the parent program. Without the source available to determine these inherent constraints, it will prove difficult to develop efficient code. Mike Alexander (AlexWtuH) I think chapters' mention of OCO issues is still legal (unless IBM has taken over the government and suspended the first amendment). It's a good idea. Howard Dean (DeanHowA) Perhaps legal was the wrong word. The issue I was looking at was that since the chapters are organized under the auspices of NasPA, what is the relationship between the two. If there is a connection, does NaSPA want to be used as a organized forum for this type of mechanism? Mike Alexander (AlexWtuH) Mike, you raise some good points: lack of knowledge and reduced skill levels. However, as far as efficiency goes, IBM is, after all, an iron monger. Its only concern about efficiency is when DEC comes out with a more cost-efficient solution/application. That's why the 43xx series has such a strange performance curve: scientific vs. business computing. IBM decided to fight DEC with the 43xx and 9370, but it saw no reason to kill itself in the business computing end. Don Weimer (WeimDonD) It may be worth trying to present opinions and dialog to IBM, but remember that NaSPa is an association of individuals with whom IBM generally does not do business, while SHARE is an organization of organizations, each of which is an IBM customer. I doubt we would rate much. Bruce Black (BlacBruK) A while ago, a friend of mine organized an annual conference of RACF users into a SHARE-like organization and requested and received from IBM status equal to SHARE and GUIDE for purposes of requirements submission. I suspect that if NaSPA presented a good case to IBM, the same could be accomplished. Scott Wilson (WilsScoF) Don, your point is well-taken. But the OCO argument transcends the type of operating system and/or hardware it is implemented on. While still an iron monger, the competition in that area is becoming more severe with both Amadahl and NAS having IBM compatible hardware. IBM still provides the majority of software, and that may have to be its emphasis in the near future. By the way, the 9370 is a sweet system. I to a couple presentations on it. If we're talking about a stripped down version, it may prove to be a suitable substitute for a PC/System 2 setup for those who want a bigger system than a straight PC. I figure the cost to be about $15,000 for the basic system. Mike Alexander (AlexWtuH) Bruce, this emphasis would have to be we, as a professional organization, having some input on the decisions made by the respective companies. Judging from the experiences mentioned, I doubt if any of us have that much impact. Mike Alexander (AlexWtuH) Speaking for NaSPA, I don't feel that a chapter discussion on any topic implies NaSPA as an endorser. The only thing that could make that happen would be if a majority of chapters wanted NaSPA to take a stand on an issue. We, at NaSPA, then would have to evaluate the legal and economic consequences of that need and report on our position. Dave Cochrane (SysoP) /* 4690 Was this article of value to you? If so, please let us know by circling Reader Number 00.