The client was a rapidly growing dot-com with stretched human resources. I provided management with hardware sizing based on expected system load. Because of deadlines and lack of personnel, I put the system together from its shipping containers. The client lacked rack space in their datacenter for quite some time, thus the system had to live in a trailer with bad power. It developed a fault in one cpu board which I diagnosed and then had to lobby to have fixed.

The client had their own ghost image for Solaris 2.8 which they loaded. This was a bare bones system disk image hardened for security with ssh and tcp wrappers. I set up the storage array for RAID 10 using the Sun VXVA (Veritas) storage array manager, removing a flawed configuration provided in the ghost load that badly apportioned the storage and lacked transaction logs necessary for failure detection and sparing. I set up NFS and provided for backup of important data to a remote NFS volume.

I configured and installed applications to make this a full blown development system, building GNU sources including compilors from source. Applications included: Netscape Enterprise Server 3.6, gcc compilor suite, emacs, sendmail, Sun JDK1.2, Continuus CM Synergy 4.5, Continuus ChangeSynergy 2.x. The sendmail implementation included writing a complete sendmail.cf from scratch to provide the masquerading necessary for a one-way email delivery link of software notifications only to the corporate Exchange Email servers. The masqerading fooled the Exchange servers into thinking that the email came from themselves.

I wrote a full set of System Procedures Documents (SPD's), a roadmap for the staff of the changes that I made to this system's software, the NES Web Server and the application software. This also included procedures for day-to-day operation and maintenance.

Consulting engagements with the Continuus client base required a lot of system and network configuration and troubleshooting of Solaris based systems from Ultra 10 to ES10000 running Solaris versions 2.5-1 to 2.8. The three tier client-server Continuus products and their embedded Informix Server are sensitive to any network related issues. In some cases such as in the ES450 above, I took over the initial setup and admin of the server used for Continuus until the client was trained and able to assume an admin role.

Common problems diagnosed at clients include misconfiguration of NIS maps and host files for networking, multiple passwd files with overlapping UID and GUID numbers, split IP horizons, bad client network stacks, bad netmasks, mismatched DNS entries between the Unix side of the client's network and the Windows desktop side, lack of coordination between DHCP, DNS and WINS servers. For some clients I also did the intial setup of ssh to go through their firewalls in order to connect servers at multiple remote sites via the Continuus Distributed Change Managmenent product.

I usually briefed the client SA staff on the impact of their Continuus implementation. This involved changes to their system and network configurations, using Sun/Veritas Volume Array Manager to create RAID 5 and 10 partitions for the Continuus repository, coordinating backups of the repository via Solstice Backup and other third party products, and setting out diagnosis procedures for continuing support of their Continuus desktop clients. This was a combination of a formal training package offered by Continuus Professional Services and site specific documentation.

Consulting engagements with the Continuus client base often involved HP server and client installations. Systems ranged from desktop models 9000-48 to N class, but most often used D, R and K class servers. The most common HP/UX versions I worked with were 10.2 and 11.0, but I also had several 11i's and two situations where the client was still running 9 and we had to work around Y2K functionality issues.

As is the case with Solaris Continuus servers, the product was sensitive to any issues with the configuration of the underlying host or the network. I usually had to coordinate closely with the local SA staff to get these issues resolved. I also helped the staff modify their SPD's to take into account the maintenance, call desk support and other day to day operations of Continuus.

I built GNU tools including compilors from source. Applications included: gcc compilor suite, emacs, sendmail, Sun JDK1.2, and Continuus CM Synergy 4.5. The sendmail implementation included writing a complete sendmail.cf from scratch to provide the masquerading for a one-way email delivery link of software notifications to the corporate Exchange Email servers. The masqerading fooled the Exchange servers into thinking that the email came from themselves.

I wrote a full set of SPD's delivered to the staff documenting the changes that were made to this system's configuration and the application software. This also included procedures for day-to-day operation and maintenance.

I built my home domain's firewall server from custom Intel hardware running Mandrake 8.0, custom built 2.4.12 Linux Kernel, and a netfilter and iptables based firewall. An example of the configuration file for iptables is here. This configuration also provides the Network Address Translation (NAT) and other packet mangling necessary to allow my other systems access to the Internet via its DSL connection. My mail server is based on Qmail, a secure mail server that is in use at yahoo and other large corporations. My DNS server is based on bind version 9.1.3 built from source. The Web server is based on Apache maintained by the Mandrake distribution.

Besides acting as a firewall, this system also allows me to see what sort of virii, worms and hacker exploits are currently popular around the internet. I was surprised to see how quickly my system became the subject of random attacks after I came on-line. Every day I see at least a dozen attempts by cable modem based Windows systems to infect me with the nimda virus. I was also surprised to see several port scans and intrusion attempts of my "backwater domain" by individuals in Europe and Asia.

A number of new Continuus clients chose to use Linux based servers when Continuus 5.0 was certified against Red Hat 6.0. I was one of the few among Professional Services and the Help Desk staff who had already been working with Linux and could be called upon to work out any problems.

In one case, I rolled out a client based on a Linux server setting them up with an implementation of Samba that acted as the Primary Domain Controller for their Windows based laptops. The Samba configuration also allowed them to keep their work areas on the Samba server where they could be efficiently kept backed up.

The Irvine help desk was pedantic about keeping clients to the officially supported Red Hat 6.0 release for Continuus 5.0 in spite of the fact that it was quickly become obsoleted and no longer available in retail stores or used in vendor bundles. In one case I had a client with a Red Hat 7.0 implementation that was provided by the hardware vendor, and I personally vouched for the support and successfully rolled out the product.

Various Unix systems I have worked on include: Amiga 3000UX - the first implementation of Unix System Vr4 ever shipped, Apple A/UX - A BSD 4.3 variant hosting MultiFinder running on a DOD sponsored oddity called a HoneyMac consisting of a Mac II F/X and Honeywell DPS microcomputer, Apollo Unix (later HP PA-CISC), DecStation 3100 running DEC Unix, older Sun servers and desktops running SunOS, Sequent i386 based server running Dynix (Primary SA)

Consulting with Continuus brought me into second tier Unix supported sites where I worked with IBM AIX 4.2 and 4.3, DEC (Compaq) Alpha servers running TRU-Unix, SGI (O2, Crimson, Challenger, Onyx, Indigo) running IRIX.

I was responsible for the transition of a VAX based development environment as it was switched by the DOD from the TRW to Lockheed Martin, working for both contractors and an intermediary in the process. Besides being the primary SA for the VMS systems, I was also the primary DBA of an Oracle 6.0 DBMS server running on these systems.

The legacy VaxCluster configuration consisted of two VAX 6420 machines clustered together with a single HSC based disk farm and various locally attached disks. During a bridge period, I split the VAXCluster apart with one machine and the Clustering hardware sent off to storage by Lockheed while they readied their site. I reconfigured and ran the remaining machine standalone for a three month bridge period to allow legacy development to wind down. The TRW incumbent had taken the VaxCluster off of hardware support, leaving me to perform all of hardware reconfiguration by myself.

When hired by the Lockheed, I assisted the hardware technician with reassembling the cluster, restored original configuration from backup tapes that I kept away from the chaos caused by the DOD movers and then reconciled the changes made during interim development back to the configuration. I also reconfigured the Wollongong TCP/IP network stack to work within the newly established NIS/NIS+ network and configured the Wollongong LPR facility to work with the new network's printers. I acted as the Primary SA and trained the SA for a Honeywell based server to be the secondary SA for the VAXen. He eventually took over day to day operations from me, but I continued to provide major support.

I built up a MicroVAX II based server with a modem rack for use as a dial-up BBS system by the US Postal Service. This system was also used for dial out by headquarters personnel for remote access to the computer sites for various Postal programs. I implemented the BBS portion as a captive account using extensive DCL scripting to provide user menus and integration with the DEC Notes product used as its conferencing system.

Because of the inflexibility and relatively poor performance of DecNet over dial up modem (Dynamic DDCMP), I ported a public domain version of Zmodem written in C to run under VMS and made numerous improvements and performance tweaks. This became the heart of all file transfer capability for the BBS and remote system access. I also embedded it into a DCL script that I wrote which provided an rdist-like remote access and update capability. As the NDSS program grew to over 200 sites, this remote script became mission critical and was used by several headquarters organizations to remotely monitor sites and push out updates to the software.

I provided the lead technical support for the rollout of the National Directory Support System, a MicroVAX based IT system installed by the US Postal Service for Zip code automation at over 200 mail facilities throughout the US. I was the primary SA and Configuration Manager for the NDSS testbeds and reference platforms. I was responsible for integrating NDSS application software written by others of the team with the VMS operating system, providing VMSInstall kits, captive system maintenance account scripts, documentation and other support required for turnkey installation by DEC Field Service and site Electronics Technicians.

I guided the the program through 3 major installation phases and over a dozen major application releases over a four year period. This included recommending the sizing and selection of all hardware and software for the three multi-million dollar expansion phases, shakedown of prototype configurations and follow up travel at early sites. I also worked closely with the program and staff at San Mateo Postal DataCenter where a VaxCluster and dialup network was built and operated to provide database updates to the sites.

Continuus Software Inc (now Telelogic AB) and its line of CM Synergy, Distributed Change Management, ChangeSynergy and WebSynergy products is in use at many of the Fortune 1000 and top international corporations. It is a process oriented change management system that provides for all aspects of CM: version control, multi-site synchronization, build management, release management, change request management, role based security, audits and reports.

I was initially recruited from the Continuus client base into the sales organization where I spent 2 1/2 years analyzing the current process and pains of prospective clients and engineering a new technical vision. The final 2 years saw me in the Professional Services organization where I worked with the clients to migrate to the product, provided training to their staff, supported some in obtaining SEI-CMM and ISO-900x certification and did many of the other things necessary in integrating Continuus into a corporations infrastructure.

My travels to dozens of different IT organizations in military/aerospace, telco, software, dot-com and financial industries gave me a wealth of experience in the good, the bad, and the ugly of corporate development processes.

I was the technical lead for all software CM in the Lockheed Martin Army Global Command and Control System (AGCCS) project. AGCCS is now known as GCCS-A and was previously known as AWIS when it was under development at the previous incumbent TRW. After switching from TRW and helping to move the infrastructure to Lockheed, I maintained a legacy CM system based on a VAX/VMS platform under Softool CCC/Manager and a custom built change request management system running under Oracle. This included getting the existing 72 hour VMS, Unix and other platform build process working again at Lockheed.

After doing a technical evaluation of various CM tools on the market including Platinum Harvest, the successor to CCC/Manager, I recommended and implemented Continuus at AGCCS. I migrated the legacy CM baseline and its SCR history into Continuus/CM and Continuus/PT (predecessor to ChangeSynergy). The porting process from VAX to Unix and its rehosting under Continuus was known as the CW01 baseline. In a parallel effort, I brought a baseline of software from Computer Sciences Corporation and the US Army known as the Strategic Theatre Army Command & Control System (STACCS) into the system. The combined baselines became known as CP1, and I was responsible for developing all formal build processes and performing builds for the systems. I managed the process until formal testing was underway for CP2.

One of the compelling features of Continuus that AGCCS needed was the ability to handle parallel development. Parts of the STACCS development continued at CSC and needed to be reconciled with in-house work. Also the legacy codebase for CW01 had previous versions in use in the field at Army FORSCOMM, HQDA and other organizations. Because the code base was built for VMS, various Unix, PC and Apple A/UX, the CM system also needed to keep binaries separated by platform type. During the Army deployment into Bosnia in 1996 a bug was exposed in the AWIS system at FORSCOMM that needed an emergency fix. I was able to re-create the necessary configuration items of the AWIS system in Continuus to allow the development team to re-create, fix and patch the software.

As a salesman, I had to have a general knowledge of all CM tools for the Unix and Windows markets including their competitive advantages and disadvantages. Companies using the tools at the left had already outgrown their scalability or had encountered other limitations that were causing them to make a decision to switch. My primary competition consisted of the the Rational ClearCase CM system with ClearTrack, DDTS and later ClearQuest for Change Request management in the military and aerospace market space. To a much lessor extent, I went up against the Sql Software Dimensions (now Merant PVCS Dimensions) product in this space. In the corporate and IT market space the competition was primarily Platinum Harvest (now a part of Computer Associates). In general there was no overlap between these client-server CM systems and the mainframe products from CA and the like.

When implementing Continuus/CM as a professional services consultant at new customers, I often had a requirement to migrate their legacy code base from their former CM system. Approximately 80-90% of the client-server CM market consists of home-grown version control systems built on SCCS and RCS and the commercial tools Visual SourceSafe from Microsoft and Merant's PVCS Version Manager. As a result, I gained a hands-on familiarity with these tools since I had to access them to retrieve code.

I gained an intimate knowledge of Visual SourceSafe's command line and COM interfaces when I took over the initial development of a migration tool that would transfer its entire version history to Continuus. This sort of functionality had already been built into the Continuus/CM migration facility for SCCS, RCS and PVCS Version Manager.

The Continuus product architecture was based on various verions of embedded Informix server (5 - 7.x). As a client of a Continuus and then later as an employee, I was intimately involved with the installation, care and feeding of the Informix servers as well as its impact on the underlying host Unix or Windows NT server and TCP/IP network.

As a client of Continuus, I reverse engineered the database schema of the product and wrote various Perl scripts for diagnostics. This also allowed me to more efficiently migrate a legacy Change Request Management system from an Oracle Server on a VAX to Continuus P/T.

I took over primary DBA role for an Oracle 6.0 server running on VAXCluster. This server implemented a home-grown Change Request Management system for a series of legacy software baselines. I did all continuing maintenance and resizing of the server, handled user access and maintained and expanded various SQL scripts that allowed the CR system to coordinate with its corresponding verson management system maintained by Softool CCC/Manager.

I trained new CM staff on canned and ad-hoc SQL queries and reports needed for control board meetings and other activities. I also wrote a series of Perl scripts to dump and then sanitize the legacy CR system for later import into Continuus P/T.

A large number of IT shops have written call tracking and change request management systems in-house for their development staff. When a client chose Continuus ChangeSynergy for their new Web based system, I worked with their staff to map their database schema, vette and clean up the data and then import the results into a customized CS implementation. In several cases, the client handed me the passwords to their database, had me develop a migration strategy and then signed off on the work. The work involved a lot of ad-hoc querying, joins, temporary tables and a fair amount of Perl scripting to clean and format the data for import into Continuus.

In one case, a client had developed a home-grown analog of Task based CM which had its versioning in an RCS archive and metadata in Access. In this case I wrote scripts to sift through the RCS headers for version info, knocked it against various tables in Access and then mirrored their change request->tasking->versioning information in the new CM Synergy/ChangeSynergy system. The client was extremely happy to see their ten year legacy system cleanly moved into Continuus as CR, Task and File objects.

I took over the initial drafts of the NDSS users guide and performed a radical rewrite with extensive examples including layout with a typesetting package in the pre-Microsoft Office era. I created a corresponding NDSS Maintenance Users guide from scratch which covered both installation and day to day operations of the system. Both guides were duplicated and distributed to hundreds of users around the country: postal employees usually with basic high school and college educations. I worked with a fellow postal employee to keep the guides up to date and to produce installation guides for major updates to the system.

At one point, I did a large part of the development and production of a training video covering the expansion of NDSS sites from a single MicroVAX based system to a MicroVAX and VAXStation based Local Area VAXCluster. The shooting and final production were handled by a video services unit affiliated with headquarters, but I used a self-owned Newtek Video Toaster system to create a number of still stores and accompanying graphics.

I conducted a "train the trainer" training seminar with members of the Maintenance, Overhaul and Technical Services (MOTSC) organization. These folk were the postal personnel who would handle all support and continuing rollout of NDSS sites in the field.

As NDSS was implemented, a users group started and began to hold meetings sponsored by various postal regions around the country. I gave presentations and participated in various Q&A sessions at these one and two day meetings. Audience size varied from a dozen up to hundreds of people.

I gave informal one-on-one training sessions lasting from a day to several weeks with a number of clients. These usually covered the Newtek Video Toaster and its software bundle for Paint, keying, titling and for its Lightwave 3D modeling and animation program.

The shorter sessions usually involved helping the client with installation, integration into their video editing suites and an overview of the software. Other one and two day sessions also included advanced concepts, tips and tricks and consulting with the user who was attempting to create a particular effect or graphic.

Some of the longer engagements were week long or twice a week sessions spanning several weeks with the in-house video production facilities of a company. For the Defense Mapping Agency and the WSSC, I did all installation, integration and timing with the video suite and then gave a full training regimen with followup sessions specific to the clients production needs.

One installation engagement for the US Army actually turned into a major role as an video editor and post production specialist for a week long NATO congress hosted by the US Department of Defense. An Army Reserve Public Affairs Unit had been activated to cover the combined meeting and military sports competition. The unit had bought a Video Toaster just before the congress and needed someone to give them both hands on training and a major hand in the post-production work as they got up to speed. This was one of the most unusual and rewarding consulting engagements I have ever had.

I was recruited by Continuus from their client base to become a System Engineer in the field sales force. I was given Bosworth solution selling training and then paired with an Account Executive in the Eastern Region. Our quota went from $1.1m the first year to $1.3m in the third year. I worked with an established AE the first year and then bought a new AE up to speed and worked with him for the rest of my tenure. I also eventually became the "goto guy" for the Eastern Region in handling technically oriented followup demos and for conducting pilots and proof of concepts.

Both full years I was in sales, my AE exceeded quota and went to Presidents Club. I narrowly missed becoming SE of the year by $40k the second year, ironically losing to an SE who used me for the technical assists when landing several new accounts. I did win SE of the Quarter and helped my AE land the largest single revenue transaction of the year in a quarter that was crucial to Continuus' IPO.

The Telelogic (Continuus) ChangeSynergy product is a Java servlet and JavaScript based change request management system. The servlets tie a series of framesets and forms into the back-end Continuus repository. Since every customer's change request managment process and forms are different, the product needs extensive on-site modifications of the HTML and JavaScript forms. I performed a lot of this content layout in development in Macromedia DreamWeaver and emacs with debugging in Visual Interdev.

CS had a package concept that allowed customizations to be encapsulated and passed around. During my field work I performed a number of popular customizations that were used by field sales and services. Some eventually were incorporated into the standard product. The examples section of my Web site contains three examples of this work for time based queries, matrix style reports and a major extension that allowed the query and reporting facility to work with Continuus Change Folder Objects.

Another requirement by one client was to provide a pop-up form for forwarding a copy of a displayed change request via email. I installed and modified a Java servlet for email submission (coolservlet), making modifications to perform better error checking and to properly work with the SMTP mail interface of Microsoft Exchange. At the time I was using Visual Cafe Enterprise for coding and debugging of the servlet. I currently use Jbuilder 4 Professional at home.

These are a set of Perl scripts originally written by one of my colleagues in Continuus Professional Services. They introduce an alternative process for release management in CM Synergy that is more suited to RAD development environments than the official process taught by training and shown in the product documentation. The Services organization maintains the scripts and has implemented it at a number of clients.

My contributions were to make the changes necessary to implement the scripts with Continuus CM Synergy versions 5.x and Windows based clients. The changes and new features made to the Continuus Task Based Methodology between version 4.5 and 5.x required some modifications to the command syntax. The scripts were also originally written solely for Perl 5.0x running on a Unix environment. I ported them to also run against Perl 5.5 running in a Cygwin shell environment under Windows NT. They may also run with a Windows 9x version of Cygwin, but I did not have a requirement to test this.