For the past 6 months, I have been writing articles for the LANET Times, because this activity allows me vent off steam on the subjects of PC's, DOS, Windows, and Netware. With this article, I, hereby, freely, openly and, of my own volition, admit that back in 1975, I worked on mainframes. I hope that no one will hold this against me. If you have any comments about this and other strange revelations related to Netware-based computing please contact me via any of the following means: 1) e-mail at: email@example.com 2) fax at: 310-332-1358 3) "snail" mail at: P.O. Box 2548, El Segundo, CA 90245 4) messages at: 213-600-1235 5) beeper at: 1-800-641-5220 Any messages that I receive will be incorporated in these columns without disclosing the identities of the correspondent, unless I am given explicit permission to do so. FICTION ?? In the May 22 issue of Infoworld, Robert Cringely notes that he has heard a lot of complaints about Compaq's service. Compaq claims that they have 4-hour response via their certified re-seller's--to anywhere in the country. My question is which country? The year before last, the company where I work bought a Compaq Systempro server from one of the largest Compaq VAR's in this country. To start things off wrong, this Compaq reseller refused to install the parts that were not "authorized by Compaq": I appreciate that Compaq does not support parts like the popular Racal Interlan 10Base-T Ethernet card, the DCA mainframe gateway, and the APC UPS unit, that I order. But this VAR also claimed they could not install the Compaq tape backup and it's associated Compaq-proprietary SCSI controller card supposedly because "Compaq did not directly support these items". In reality, I surmise that this VAR needed to make some extra money off of their customers by saving on technician salaries. After slaving away for a week and sarcastically, grumbling about " 'value' added resellers", I finally got the whole thing working. A week later, the Compaq-proprietary "IDA" (Integrated Drive Array) disk drive controller quit working. After calling the VAR, I determined that they did not have a replacement IDA card in stock. To make a long story short, they finally coughed up a new, working card, 4 days later after having it shipped from Compaq's manufacturing facilities. As stated in a previous article, what the vendor tells you, even what they have promised in writing, is often not what you get. Compaq's claim of 4-hour response time to service requests is ludicrous hype, b.s., and few other things that I cannot say in a family publication. It is not reality. They have to get real-- no company in this country or any other one can provide 4-hour on-site response consistently on anything. This does not mean that I or my end-users will not buy Compaq-- they have some of the most sophisticated 486's and Pentium's on the market and the hardware and software diagnostics of these boxes remain second to no one's. Also, their SVGA monitors are one of the sharpest looking one's to my eyes and I am using one to write this article. It's just that some of their authorized VAR's are a bit flaky and I do not expect 4-hour response on everything, despite their claims. Anyone else out there have similar nightmares?--drop me a line and I will relay them in these articles to the benefit of all. FACTS ?? With this article, I have decided to start a section listing the lowest price that I can find on Netware 3.12 and 4.1: This month, the lowest price that I can find is from: Network Trade Center 10578 S. 700 E. Sandy, UT 84070 Voice phone: 801-572-8200 Their price for a single 5-user copy of Netware 3.12 is $495. Their price for a single 10-user copy of Netware 3.12 is $$1,075. Their price for a single 5-user copy of Netware 4.1 is $495. Their price for a single 10-user copy of Netware 4.1 is $1,075 All of these prices are about $100 lower than the lowest prices for Netware 3.12 at about this time last year. Let me know if any of you have a better source for this good stuff. FICTION ?? In response to my comments on his comments, Jerry Parsi, a LANET member, sent me the following e-mail message: From: "Parsi, Jerry"
To: "Chao, Frank" Subject: LANet stuff Date: Tue, 23 May 95 09:02:00 PDT hey Frank, A couple of comments (not really a response) on your reference to my previous article about internal battles within large companies (FACTS ??). Back in the 80's I was doing scary things like Assembly language programming, COBOL, FORTRAN, PL/I and other mainframe stuff on the then IBM system 370 (using punch cards yet !), as were some other brave souls (end users). The Central IS department controlled the mainframe (in the infamous glass house) with a thick lead wall! Trying to get their cooperation to do my job better was like pulling teeth. They protected this mainframe and gave us poor folk the infamous IBM terminals (dumb tubes). Now there were advantages to this (still are in some cases) as far as centralized control of resources, data and some standardization. The problems were there too (as evidenced by today's user revolt) and probably (arguably) outweighed the advantages. The system was proprietary to IBM, there was no competition (and thus IBM made a killing at the time on pricing, even though it later backfired along with other proprietary systems like DEC). The applications and user Interfaces were archaic, and there were again not many alternatives. Then some users (like myself) discovered that lone IBM PC AT (what a paradox that IBM made this wildly popular but then shot themselves in the foot with not seeing the forest for the trees) in the department. We started to use it for doing things unheard of. Naturally the IBM PC clone (and later Macintosh, etc.) market explosion led to the existing Local Area Networks (LAN) with the likes of Novell's Netware, etc. Along the way, users started setting up these LAN's while the Central IS departments were still paying IBM and doing their mainframe stuff. Then all of a sudden, for reasons not understandable to them (!), they started to loose their jobs. It took them a few years to finally see what was happening. Then they started to try and take control back from the users with these networks (i.e. try to save their jobs by switching over). The question is why should they be allowed to ? they failed to properly see this coming and were way too late to be effective. The requirements were already being met by the users. So the conflicts are created not by feudalizing (maybe so WITHIN the IS departments), but by the fact that the Central IS departments are in many cases just plain incompetent. Now centralized control does have its advantages, as does individual freedom (PC), but the happy medium here is the Departmental control with some support for Enterprise-wide tasks from internal support groups. One of the biggest mistakes from the past IBM mainframe era was that the management/staff were so completely absorbed in technical issues that they could not see the customer's needs. The advantage to having system managers be an employee for the business units is that they are in contact with reality to meet the unit's needs. Passing the control back to a central IS group will result in the same type of disconnect from the mainframe years. On the 2nd issue, again there are many causes. First, again in large companies, there are just too many bureaucratic levels, not to mention some really stupid rules (both internal to company and external, i.e. government). Things are getting a little political here, but company and state laws require dealings with small/minority owned businesses. In a lot of cases, these businesses just are plain incompetent to meet the hapless user's requirements. But, since end users are "Forced" to deal with these folk, the systems they purchase don't work as advertised, and when there is a problem the vendor can't fix it. So businesses that NEED to be competitive to stay in business are wasting valuable resources (time, money, etc.) needlessly. the result is loss of jobs (as seen from the current mess that California is in). The original laws were probably well intentioned, but have (and will continue to) backfire with the opposite result. The users that are forced to purchase from certain vendors will go out of business, and the vendors that rely on those businesses to generate income will no longer have that source of income so they are forced out of business, with the end result being that everyone is now jobless. the natural and correct path should be to let the free market work. Those that shouldn't be there won't and those that are competent will. Some recent examples are the Microsoft break-up attempt by it's competitors (through government/media). Even though there are merits to anti-trust laws, etc., taking these too far will again backfire. If the competition isn't up to the task (e.g. IBM/Motorola/Apple vs. Intel, etc.) trying to remedy the situation by force won't work. (End of Jrry's e-mail message) That, folks, in a concise nutshell is a lucid history of what has been happening in the computing world over the past 30 years. All of us who were in computing back then worked on mainframes which were the only game in town. Then IBM, DEC, and others introduced desktop and mid-range computers and the world got complicated: Some folks stayed mainframe-centric and put on blinders and others opened up their field of view and acknowledged, accepted, and incorporated the newer, smaller platforms into their world view. The narrow-minded ones kept saying that the only real computer is a mainframe and the open-minded ones starting dabbling in the smaller stuff. Most of the former folks are now doing something else for a living. The latter folks still have jobs. Jerry's message reminds me of the "data center" manager who stated to group of his employees about 2 years ago that he considered every IBM-compatible PC and Macintosh to be a competitor for his organization's mainframe services. It also reminds me of the brilliant guru that I chatted with last year: She referred to the mainframe department in her company as a "bunch of fascists and power-hungry control freaks". For the sake of fairness to the other side of this issue, I took Jerry's e-mail message with his name deleted and printed them in an extra large font. Then, I showed this message to a few, old, gray-haired, arthritic mainframe experts. After enduring a barrage of unquotable profanities, including a few unwarranted comments about the parentage of the author (of the message) these gentlemen proceeded to explain why in their opinion, mainframes will continue to occupy a significant niche in computing for many years yet to come. Here are the reasons that they gave me--listed, in my opinion, in the order of least significant reason to most significant reason: 1) Studies by various consulting organizations continue to show that mainframes have lower long-run end-user support costs, than smaller computing platforms. By giving the end-user less computing power and less ability to customize the computing environment, mainframes force users to define their needs with are then translated into applications and custom screens by the "glass house" centralized computing department or outsourcer. Mainframes have mature and reliable configuration, change, and systems management applications and processes in place. That makes them more reliable, "robust" for mission-critical applications. The smaller platforms are just beginning to implement these various "managements" and hence, the implementation of these functions is still piecemeal, uncoordinated, and less reliable. 2) Mainframes will continue to be needed in order to view the past 30 years of historic accounting, engineering, and scientific data, in light of the fact that the porting of data and applications to smaller platforms is an extremely costly proposition. For example, in the aerospace business, the intricate technical details of every possible aspect of the current crop of fighterss and bombers were designed using mainframe-based CAD, spreadsheet, manufacturing, and inventory applications. This data must be maintained, modified, and analyzed for the life of the aircraft, including all further advances and variants of a particular aircraft. For the current crop of military aircraft, no one is willing to pay for porting the massive amounts of data and applications from main frames to smaller computing platforms. Hence, the companies that design aircraft must continue to operate mainframes in order to support existing models of aircraft. 3) Mainframes have economies of scale for large computer operations, relative to smaller computing platforms: Mainframe use Direct Access Storage Device (s) (DSSD)-- pronounced "das-dee". Mainframes are the only platforms that can provide enough transactions per second for computing operations which require thousands of users, and/or thousands of applications accessing gigabytes of the same data, simultaneously. Mainframe detractors often use the term "cheaper MIPS" (million instructions per second) for non-mainframe platforms. However, the end-users and computing applications do not really "see" MIPS. They see transactions per second. In intensive disk I/O environments, only mainframes will provide enough computing speed as measured in transactions per second when the parameters of file size, simultaneous users, and simultaneous reach certain high levels. One example would be the payroll for large corporation. After gathering and inputting all of the timecard data, a large corporation typically has less than a week to issue paychecks and stubs to all ofit's employees. At a certain threshold number of employees, virtually all large corporations use mainframes or a mainframe-based outsourcer for this function. Some do not want to but begrudgingly do so: As of last year, Sun Microsystems, the Unix workstation maker still was using a mainframe for it's worldwide payroll application. Even they acknowledged that only mainframes could perform the job in the timeframe that it needed to be done in. To their credit and brilliance, they have been working hard to port the mainframe abilities over to their Unix workstations and they will probably be one of the first large companies to do a large payroll application on a cluster of Unix workstations, instead of a mainframe. As expected, none of the mainframe advocates that I insulted, I mean consulted, felt that the portrayal of mainframe service providers as "dictators" was justified. They stated that having a centralized IT organization or outsourcer allows the employees concentrate in their true line of work, instead of turning them into "islands" of computing expertise which is what, in their opinion, the smaller computer platforms do. These mainframe experts stated that even when an organization has only non-mainframe platforms, a centralized IT operation keeps the overall cost of IT down by concentrating all computing activities in a shared center of computing expertise. Finally, these mainframers stated that the cost of supporting non-mainframe, distributed platforms would be even higher than currently reported, but non-mainframe costs end up being buried in non-IT budgets and this results in the reporting of lower-than-actual IT costs. In their view, the use of smaller platforms is a way for companies who want to reduce their IT budgets artificially by shoving the costs of IT to non-IT organizations and calling the activities by other names such as "engineering", "administrative support", etc. However, according to these mainframe folks, the actual costs are not really reduced after "offloading" or downsizing/rightsizing of mainframe applications. Instead IT costs are "forced" into non-IT budgets. Here is my middle-ground perspective on the mainframe versus non-mainframe issue: A very large portion of data storage and computer applications which are currently on mainframes do not belong there. These "legacy" applications and data can be done more cost effectively on smaller platforms like PC's, Mac's, mini's, workstations, midrange computers, and servers. Many of these computer applications are only done on mainframes for a variety for a variety of sub-optimal/non-optimal reasons: Company politics: the mainframe folks have control of the company's "IT" (Information Technology) dollars and they prefer that these end-users utilize their mainframe. Management edict: managers prefer mainframes for emotional and other non-optimal reasons. Platform availability: the company lacks budget for smaller platforms like PC's and servers (but has plenty of bucks to throw at mainframe upgrades and software). Funding restrictions: The company really does not have the cash to invest in the procurement, training, and support of smaller platforms. The above restrictions to migration off of mainframes ("offloading") are where computer consultants have made the big bucks in the past 5 years. There must be hundreds of self-styled consultants who run around the country preaching to companies large and small that they can offload stuff off of mainframes and save money in the long run. What these consultants have discovered is that a very portion of computing applications do not have to be done on mainframes. For most applications, the "cheaper MIPS" holds true. However, as one encounters larger and large systems in terms of the number of client seats, database size, and other scale measurements, at certain sizes, a mainframe is needed to achieve performance that is adequate: For example, you will not see the larger airline reservations systems migrating to smaller platforms. If they were to attempt to do so, these systems would not be fast enough to respond to the hundreds, perhaps thousands, of travel and ticket agents that are hitting the "enter" key simultaneously on a busy holiday day. What has happened in the travel industry is that while the mainframe-based reservations databases have stayed on mainframes, at the local, enduser level, more and more networks are being deployed in order to provide functionality at lower levels. Instead of the dumb terminal modem-ed into the mainframe, more and more travel agent and ticket agent operations utilize networks that are then linked into the big reservations system mainframes. That way, the applications that require mainframes can reside there and the applications that can be done cost-effectively, including a GUI to the mainframe, can reside on local and intermediate servers. This hybrid environment provides the computer enduser with the best of both, somewhat antithetical, worlds. The downsizing/rightsizing consultants that we have been dealing with have been a breath of the fresh air compared our experiences with IT (Information Technology) consultants in the past: Back then, and you can still find these (sarcasm alert) "geniuses": If you asked a CNE to design any system, you would automatically end up with a Netware LAN. If you asked a mainframe specialist to design a system, you would automatically end up with a mainframe-based application. and If you asked a midrange expert to design a system, you would end up on an AS-400 or a Sun workstation. These days, the relative success of downsizing/rightsizing consultants is due to the fact that a very large portion of applications that reside on mainframes are still there because of the "non-optimal" reasons that were listed above. However, at some large size and scale of operation, mainframes are here to stay indefinitely, for two reasons: 1) As speedy I/O transaction engines for huge, multi-user databases and 2) In order to provide access to "legacy" data and applications for which the migration and porting to smaller applications is cost prohibitive. Unfortunately a lot of mainframe-based folks object to these "lesser" roles and this has caused a lot of political infighting and controversy in many companies. The weak point and problem inherent in the mainframe environment is, as stated by Jerry, is that the speed of response to end-user demands is much slower in the mainframe environment, as compared to smaller platforms: Back in 1982 when I designed an IMS database application on an IBM mainframe, every end-user request for a change to a printed report took 3 months. This application is still in use today and it still takes 3 months to make a change in the reports that this application generates. I assure you that it does not take that long to change any application in a system on a smaller platform: my bosses (I have many) at work currently expect 48 hour turnaround to changes in Paradox, and Access databases, and the customers of Oracle-based applications typically expect 3 day to 1 week turn around on most requests for changes to reports. Of course, I am referring to fairly small databases and applications. At a certain size, data goes up to the "big iron" as the source repository and smaller sorts and queries, "extracts" are then downloaded to non-mainframe platforms for local, departmental use. Let me conclude this section on the mainframe issue by thanking Jerry for his excellent input. Jerry administers a sophisticated Netware LAN at a large aerospace company. He is one of the sharpest network/system administrators that I know. Also, I wish to thank the mainframe advocates who provided me with a an earful (ouch!) and who requested to remain unnamed. It is important for us to discuss these issues as we make the various decisions that determine the course of our careers. So much political venom has been spilled over mainframes versus non-mainframe computing platforms that even I cannot find much humor in it. However, I would like to conclude this article on a humorous note: Humor is contextual. In some situations the same action is funnier than in other circumstances. Let me explain. A personal computer specialist, whom I helped occasionally, received a layoff notification from the huge corporation where he was employed. This fellow was known for his dry sense of humor. Just before he left, he added the following line at the end of the autoexec.bat file of the IBM-compatible PC at his desk: @echo "Welcome to 's virus-infested computer!" After this person exited the company. His management did not find this to be very humorous. At great expense, they brought a whole bevy of computer specialists to this PC in order to verify that the computer was not actually infested with any software viruses. During this time period, the former employee's former co-workers were not allowed near his former computer--a major inconvenience for them. I watched as many of these folks made special efforts to avoid walking near the desk that contained this supposedly infested PC. The whole affair was not funny for the folks that had to deal with the situation. I also doubt if this former employee was able to get much in the way of a letter of reference from his former employer. Tell me about the humorous and not-so-humorous experiences that you have had with computers and I will share them in these articles. In the case of the LANET BBS, which has now been dead for 2 months, I hope that it makes a recovery someday. After missing the April and May LANET meetings, I noticed that several LANET members have been fearing for the worse. Contrary to their suspicions, I am alive and well. I merely got overwhelmed by all the activities I was involved with: Passed 2 Netware courses and their corresponding Drake tests Moved a VIP at my main job and his computing gear Starting slaving away as a committee chairman for the El Camino College Computer Club Started a major project to transport and convert data between between a DEC PDP-11 minicomputer to an IBM-compatible PC These experiences have been depriving me of sleep but they wil provide me with material for these articles for many months to come. It has been fun and with school out for the summer, I can start getting some sleep at nights and I expect to start attending LANET meetings again--until life swamps the heck out of me again or until I get incarcerated, whichever comes first. Also, contrary to what one LANET suggested in jest, I have not been purposely missing meetings in order to keep from upstaging the president of the club. I urge everyone to participate in this newsletter: Having a good newsletter helps us retain and attract new members, so please help out the stressed out, overworked editor of this rag and keep me purturbed about thinmgs by sending your questions, answers, and other ruminations to either me or her. See you at meetings and via the newsletter. (The preceeding diatribe is solely the private opinion of the author. The statements which were made are not neccessarily the opinions of LANET, SCNUI, NUI, Novell, any mentioned software publishers, the author's unsuspecting employers and clients, or anyone else for that matter.)