On this page, I will attempt to describe the kinds of knowledge that I possess, and the kind of work I can
perform. This is not a resume: in a way, a resume feels a bit limiting because my interests and knowledge far exceed
the computer arena within which I make my living. That is why I've included a Personal Work History where I describe
all the different kinds of work I've done in the past.
To quickly jump to a topic, click on one of these names, or you can simply scroll down to each topic:
- Networks - A History
- Networks - Current
- Standards Policies
- Personal Work History
- qcsi-Systems(formerly Quadrant Computer Systems)
Networks - A History
My first experience with networks dates back to about 1980 when I had to set up a Corvus
network for the University of Texas Health Science Center, in the old Prudential building, across the street from
M.D. Anderson Hospital. It had a 5Mb hard drive at it's core, and served about 3 users. It seems almost like a
joke, now, but it was fascinating at the time. Shortly after that, I installed a 3Com network for a small oil company
on I-45 near the airport. That was much more impressive, and much more functional. It served about 10 users.
Shortly after that, I received some training with Novell Netware and began to install
networks all around the city. The most noteable installation was for the Houston Rockets basketball team, in the
bowels of The Summit, and for various groups at Texaco in downtown Houston. There were also law firms, employment
agencies, management groups, security firms, and on and on. All this doesn't sound too impressive now, but this
was in the early 80's.
I worked for the only computer store in Houston that -- at that time -- provided
corporate level support. It was a radical idea back then, and we really hummed along selling and supporting all
kinds of equipment and installations. With this background, I then moved on to another store where I was the Director
of Service, Support and Training. This, too, was a gutsy move and reflected the early days of networks and new
concepts in how computer service and support should be executed. I felt I was relatively successful in my tasks,
but I kept running into the "sales mentality" of sell as much as you can by the end of the month, no
matter what. The "no matter what" would always come back to burn me, for I would end up having to correct
the mistakes of the sales staff. A year later, I had had enough, and found a job in the corporate world.
My strong suit for my new job was, of course, networks, and it came in handy. The marketing
group needed a network so we installed a Novell S network, a star bus, with proprietary servers and cards. I was
an advocate of generic systems and suggested we use standard PCs as servers, but that idea was pretty radical back
then, and I was over-ruled. The mainframe mentality compelled my superiors to prefer proprietary and one-stop solutions.
In the long run, however, my advocacy paid off.
The Novell network soon grew to 3 servers and was becoming burdensome to handle. We
knew this network would, in effect, serve as a pilot project for a company-wide network... possibly a corporate-level
Wide Area Network... so we installed the hardware, configured the software and developed standards from the outset
as if it were going to be installed everywhere. (See the section below on Standards and Policies.) But even with
standards, the Novell network was getting hard to handle, and we were appalled with the idea of adding more and
more servers. The administration overhead would kill us. So we looked around for a better solution.
What we came up with was Banyan VINES. Even at that moment early in their history,
we could see where they had significant advantages over Netware. The StreetTalk naming scheme was brilliant and
the ability to hook up multiple servers without any effort was incredible. We even sent a Banyan server to Kansas
City to test the wide-area-networking. We set aside a full two days expecting the attempts at connecting it with
our Houston servers to take that long. It took two minutes! We were stunned and thrilled.
It didn't take too long to replace the 3 Novell servers with 1 Banyan server, including
all structures and access rights. I managed it by loading both the Novell shell and the Banyan shell on a Compaq
transportable, than simply doing copies from one drive to another. Access rights took a bit longer, but I had set
up the subdirectories with the proper access rights ahead of time, so when the files were copied over, they acquired
the default access rights. The switch was complete and was to stay that way for over 10 years.
Networks - Current
- PC Support
- I began my initial position with the company in PC Support, but it quickly metamorphed into Network Support.
To this day, however, if a PC Support question comes along that no one else knows the answer to, it always comes
to me. I have often joked that, if I were named CEO of this billion-dollar company, I'd still get calls from users
asking how to format a floppy.
- Network Support
- Since we were a fledgling network, it wasn't just a small, cubby-holed position of Network Support, it was
design, install, wire, configure, load, administrate, etc. It was everything. As Network Support, I was called
upon to provide installation of hardware components, from the UPSes all the way through BNC connectors, network
card configuration through specifying backup tape brands.
- Network Administration
- Administration was a bigger job than just adding new users, or changing passwords. Information about the
network was critical in making sure it stayed healthy, so programming skills were necessary to write utilities
that would extract the data we needed. It would be foolish to run a network in a reactive mode: proactive judgements
had to be made to ensure the stability and long-term viability of the network.
- Network Design
- Luckily, my earlier days of installing networks provided OJT on what can go wrong if the network isn't designed
properly. (Not to mention the issues of dicey installations!) So, our first network was a broadband system (a system
I did not recommend because of the high tuning costs) which spanned only about 50 users. When we moved to a larger
building, it went from a small, almost manageable configuration, to a large, unwieldy and expensive project. We
did the best we could with the technology, and created all sorts of strategies for dealing with weird problems
-- which we got our share of.
- Eventually, we moved to Token-Ring. Given the physical size of the building, some inventive configurations
were required to make it all work within the limitations of token-ring wiring. Bridges were used until the router
technology made the collapsed backbone a possibility. Now, FDDI links provide super-fast backbone raceways for
the high server-to-server traffic. The wide-area-network was upgraded from analog to digital microwave, against
my objections. I would have rather seen the money go toward running fiber optic between stations. But by this time,
most of the company network was segmented into several discrete areas of responsibility, with no accountability
between the groups. We had gone from a 3-server, 10 user Novell network to a 70-server, 3,500 user, VINES wide-area-network
covering more than 20 states.
- Network Special Projects
- The small utilities I was writing during the early network administration days were providing me with a
solid background in network systems programming, so it didn't take long before larger projects came my way. In
fact, if something was network related, and no one else could do it, it fell on me to figure out a solution. A
virtual sign on my desk: "The Technical Buck Stops Here". Standardizing log-ons required utilities that
interacted first with DOS, then with Windows and Windows NT. Network based backup routines; administrative tools;
network e-mail systems and utilities; network-centric resource access, including optical drives, CD-ROMs, scanners,
fax, etc.; metering network software; including field offices (with slow communications links) in network software
- Glue; SQL; Notes; document management; middleware
- Current projects involve writing DLLs that other systems can use, e.g. PowerBuilder, Visual BASIC, WinBatch,
Access, Delphi; implementing Notes systems and writing utilities to provide an interface between Notes and other
systems; writing a document management system, then re-writing it for Windows; developing CGI components for Web
servers; developing commercial Web pages; writing wide-area-network distribution processes for mission critical
files; and the always needed network utilities...
- Standards Advocacy from Day-One
- When I accepted the job as Director of Support, Service and Training with the computer retail store, it
was patently obvious that having standardized systems, parts, manuals, and support policies would make the difference
between getting the job done, and letting all kinds of things fall between the cracks. When I started in PC and
Network Support in my corporate job and was charged with coming up with network directory structures and log-in
procedures, the idea of standards was again a central theme. We knew we had to get it right at the very beginning,
and develop a system that could get as large as it wanted and still be workable. It had to make sense.
- So, one of the fundamental tenents developed more than 10 years ago was that with standards, you can accomplish
a lot more with a lot fewer people, and still provide the necessary services and support to the end-users and clients.
- Software standards
- In addition to network standards, directory standards, training standards, and and support standards, some
kind of structure for what software tools were to be used was necessary. Even 10 years ago there were many products
in each software category that would adequately fill the bill, so we evaluated what was available, selected the
best all-around product, and then allowed only that product to be purchased.
- Hardware standards
- It also made sense to try to standardize the hardware components as much as possible. This sounds easy but
with many groups and departments wanting to purchase equipment with their own money, and set things up their way,
it came down to policing and top-level management support. The big-whigs had to understand that having everyone
go in their own direction was going to affect the bottom-line, for years to come. Once they understood that, we
got their full support. We then were able to carefully test PCs in our internal lab, and eliminate all but one
or two vendors from consideration. Then we discovered that keeping it down to one or two vendors often wasn't enough.
Since the vendors would change components without notifying anyone, we could be and were often caught looking bad.
This became even more serious when the vendor would change the BIOS and the change either made it more difficult,
or impossible, to make our systems work. The funny part of all this is, we had a glowing reputation among our corporate
brethren as having rock solid standards, but we felt they were still too lax.
- Network standards
- As described above, subdirectory structures were standardized even before there was a network. We then extrapolated
those structures on to the file servers. Other standards that had to be created, designed and implemented dealt
with access rights, resource access to mini- and mainframe sessions, file and print service configurations and
naming standards, user login standards, network card configuration standards, and network documentation and reporting
- Writing policy
- At some point, we had to start documenting our standards policies. Almost from the outset, we recognized
that one of the responsibilities of having a standard was to declare it, defend it and promulgate it. To anyone
who has never had to write actual policy documents, the task seems easy. But like everything else, it can be door
poorly, or done well. It required creative thinking skills as well as analytical and technical thinking skills,
not to mention good writing skills. The bookcase was full of mainframe manuals, 5 inches thick, as good examples
of how NOT to write policy. In the end, we learned that these documents are "living" and must be kept
up as the network and its policies change.
- Preaching to ABUI
- As an early implementer of a relatively large, Banyan VINES network, we were sometimes looked upon to provide
enlightenment at the yearly Association of Banyan Users, International (ABUI) conference. As it turned out, many
of the standards and policies we had developed were universal in nature. So, over the course of many conferences,
I gave several talks on what our standards were, how they worked, and lessons we had learned.
- Interestingly, I found out that a small entrepreneurial group took many of my ideas and made a living providing
consulting services to other companies. Kind of a back-handed compliment. (In fact, this very essay would work
as a good overview to the types of strategy that medium-to-large businesses SHOULD use in their approach the networked
systems. Oh, and, YES, I'm available for consulting! :-)
- Transparency Philosophy
- One of my brightest ideas and philosophies was also my biggest undoing, so to speak. My concept of how a
traditional Information Systems group should work, was to provide service to the end-user but be a transparent
to them as possible. I worked feverishly over many years to implement systems to users that allowed them to push
a button or click on an icon, and their work was done. They didn't have any idea of how complex the underlying
system was, nor did I want them to know. I felt like the information resource should be as much in the background
as possible, since it did not directly provide any income for the corporation. This was also a 180-degree turn-around
from mainframe philosophy, the ivory tower syndrome where the user had to bow-down to the programmers to get any
information out of the computers.
- While this philosophy (at the time) was new and revolutionary -- and INHERENTLY the best philosophy for
information resources -- it had one major problem: if you succeed too well, you become invisible. If you're invisible,
you no longer can get the attention of management; they think everything is working just fine and you don't need
any more money, people or other resources to continue to do the job. In fact, they often start thinking: "Why
are we spending so much money on these guys? They never do anything. You never see them. They just soak up money."
So, my "Transparency Philosophy" works only if the MIS manager/VP/CIO/whatever is politically saavy,
and will constantly "sell" upper management of how well that philosophy is working, and why the MIS group
needs to be supported and maintained.
- History of languages/systems I know...
- Roughly in the order I learned - Hard-wired programming (circa 1969) on IBM sorting, collating and printing
machines, FOCAL, COBOL, RCA Spectra 70 assembly, IBM 360 Assembly, FORTRAN, 6502 assembly, AppleDOS, UCSD Pascal,
MS DOS, MS BASIC, dBASE, Turbo Pascal, MS C, Modula-2, Clipper, PowerBuilder, Object Vision, Borland C++, Delphi,
- Where do I start? Most of the PC languages have had 3rd party toolkits you could purchase to perform any
number of functions. I began using utilities with dBASE II and dBASE III+, but started using actual toolkits in
earnest with Clipper, then C, Pascal, and now with Delphi and Java.
- When Windows 3.x came along, having functions in DLLs that were easily callable from a higher level langauge
was wonderful. It was better than dealing with .OBJ files, and allowed more of a cross-language capability. Then
I realized that creating them wasn't too difficult and started that in 1993. Today it's still a powerful tool for
creating low-level or system-level functions to higher level languages.
- Since most of the tasks I was assigned to do had to do with system-level and network-level functions, I
didn't get into high level programming too much. But I did set up a server specifically for SQL Server, learned
how to implement it over the network, and learned about the lower-level calls. Recently (June 2000), I've even
created an extended stored procedure, which is a process for extending the capabilities of Transact-SQL.
- Network programming is now my "bread-and-butter", usually cranking out 2 or 3 utilities or applications
per week, each having some network function call or another.
- The Internet
- Creating programs for the internet is a little different, but most of the work isn't more difficult. Protocols
(most of which are surprisingly "old") such as HTTP, FTP, and SMTP are used to communicate between programs,
between programs and databases, or simply to create a user-interface -within-a-browser. I've created EDI systems
using FTP and encryption algorithms, automated email deamons that receive data which is then processed and stored
in a database, SMTP processes that allow pagers to be called via a web page, and many other processes.
Click here to view resume
Personal Work History -- Non-Programming
- Mettle -- Someone once
asked me, if I lived in a purely non-technological society, how would I make my living? The answer may reveal
more about me than anything else you might read here. I would say I would be a writer, or -- if that was not quite
acceptable, I would have to say: a carpenter. I not only like creating things, but I like the process of
creating things. I also like to be able to see a finished product... you have to be competent when
your wares are on display.
Here are some of the non-programming things I have done with my working life:
- Writing is a "first love." I do it primarily because I enjoy it, but I've also had a lot of training
in school, including the development of and participation in a Science Writing course at the University of Houston.
I've used that skill many times, particularly in the last 10-15 years, writing and developing catalogs for scientific
instruments, PC journal articles, network magazine articles, and writing training manuals for PC classes. Heck,
I've even been published in some SCUBA journals!
- Over the last ten years, I have developed and taught many classes in PC applications, such as Lotus 1-2-3,
DOS, dBASE, Word Perfect, networks, and communications.
- My interest in photography started around 1970 when I watched my brother dabble in it. Not long after that,
I started to learn about the chemistry involved. Before long I was doing darkroom tasks, and printing my own photos.
In 1973, while in the Navy, the ship upon which I was stationed was ordered into the Red Sea, which no U.S. ship
had done 12 years previous. Although I was merely a personnel manager (Personnelman) on the ship, my knowledge
of photography got me temporarily assigned to a mission where I was to take photos of the military armament staged
at the entrance to the Red Sea. Later, when I was in Iceland, I was under the tutelage of an "old as the hills"
Navy photojournalist. He taught me more about darkroom work, and more about journalistic techniques. I spent most
of my time off in the base darkroom. After leaving the Navy, I first found work as an apprentice for a camera repair
shop. I then got some darkroom work which soon accelerated into photographer. I also found part-time work as a
freelancer. It was wonderful. I was doing something I really wanted to do, learning new things all the time, meeting
new people. But in 1980, I got tired of being poor. So it all ended when I left the photography field to pursue
the almighty dollar.
- -- Darkroom
- In a lot of ways, I think I enjoyed the darkroom work more than being a photographer: I worked alone, I
had to be creative, and I had to have great skill (or it was obvious!). For about a year, I spent everyday in a
black-and-white darkroom. Later, I would spend time installing, maintaining and processing color film and print
machines. I even got an early hand into computer augmentation of images, but it was quite crude by today's standards.
- -- Freelance
- My least successful work was doing freelance photography. It's hard work, you never get to rest, it's hustle,
hustle, hustle. You have to be 98% salesman, and 2% photographer.. not my cup of tea. I much prefered the quiet
darkroom work. But, to make a living, I took photos primarily of babies, pets, and youth baseball teams. More interesting,
I sometimes got work doing food photography, as well as portraits.
- -- Scientific/Medical
I worked for M.D. Anderson hospital first as a darkroom technician, but then later doing medical photography
(mostly pictures of patients), but my final assignment was doing scientific photography. This was exciting because
we often had to come up with our own way of doing things. Sometimes that meant a different set of photochemicals,
different temperatures and/or times, different techniques with the camera or copy board, and a different mind set
(today, we'd call it "thinking outside the box").. We sometimes constructed huge, um, gizmo's, just to
hold an object in place, or to hold lights at special angles. It wasn't all fun... our bread-and-butter were the
diazo slides for the doctors lectures. But it was sometimes worth the wait for the good stuff when a doctor walks
in and says he needs some silohuettes of an eyeball, and plops it down on the desk. Great stuff!
- Camera Repair
- Repairing cameras was a very interesting (if extremely poor paying) enterprise. I apprenticed under several
excellent technicians, and found I could pick it up pretty easily. It was a small shop, and we sat around a long
bench and we'd chat all day about various things. It makes me laugh to think about it now. In a way, it was like
sitting around playing cards all day, and gossiping, telling jokes, discussing the news, and each others lives.
Of course, we were also consumed by the unending problems and variations of problems that you encounter when fixing
the incredible variety of cameras we were given. (This was just before cameras starting going electronic.) It never
enriched my wallet, but it was an interesting environment. I also learned to respect the engineering and optics
that goes into the modern camera.
|qcsi-Systems(formerly Quadrant Computer Systems)
- My consulting and contracting firm is qcsi-Systems (formerly Quadrant Computer Systems). It was formed in
1985. Click here to view the qcsi-Systems page.