FRANK'S FALLACIES, FACTS, AND FICTION

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:        fchao@cerfnet.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.)