Vincent J. Wallace

 

Software Development and Support

Shirley, MA

 

 

Introduction:

            I have 30 years’ experience in a very wide range of software development and support – from the low level stuff (I’ve twice had my hands on a PCI bus analyzer) to the high level stuff (I did a prototype of a model based network management GUI).  I’m most comfortable in a Unix environment, having worked at both the application and kernel levels.   I also have extensive embedded software experience.  I have strong design, organizational, debugging, and writing skills.

 

Keywords:

            C, C++, Unix, Linux, Refactoring, Network Protocols, Network Programming, Kernel Programming, Object Oriented Design, Embedded Systems, ATCA, IPMI, HPI, Cellular, CDMA,  X Windows, Clearcase

 

One Select Project:

Implemented a portable version of DEC’s cterm protocol that ran on 6 different OS’s (ultrix, SCO-UNIX, Tru64-UNIX, Microsoft Windows, OS2, & VMS) and on 4 different CPU’s (VAX, MIPS, ALPHA, & X86).  Total time to port to all the above was about a month.  OS/hardware specific code was about 5% of the total.

 

Protocols:

Implementation: CMIP, CTERM

Debugging/Analysis: TCP, IP, DDCMP, LAT, Ethernet, X.25, DECnet Routing (phase 4 & 5), NSP, OSI Transport, NICE, DNA Session, DAP, Telnet, ftp, mail11, SMTP, ARP, BER, MOP, RFC1006, RFC1859

 

Languages:

C, C++, Pascal, Perl, FORTRAN, Motif, HPGL, PL/1, LISP, BASIC, APL, sh, LISP

Assembly Languages: 370 BAL, CDC6400, HP1000, PDP-11, 8080, Alpha, PowerPC, Mips

 

Operating Systems:

RSX, Unix, PSOS, vxWorks, Linux

 

Education:

MS Computer Science, 1981, SUNY Binghamton (3.8/4.0 GPA)

BA Chemistry, 1976, SUNY Buffalo (3.6/4.0 GPA)

Regents Scholarship Winner (full tuition)

High School Valedictorian

 

Quiz:

 True or False: Implementation language is a determinant of software quality.

 Where is the goto in the following: for (ii=0; ii<7; ii++) { array[ii]=ii; }

 Name three software engineering techniques besides OOD.

 Why is unstructured C++ code better than unstructured FORTRAN code?

 How do you invoke the write method of a file descriptor?

 

Work History:

Raytheon: Software Engineer: 07/81 – 06/84

·       My first task out of college was to complete an inventory control system which had been done by contractors in FORTRAN, and which was 'almost' finished. I did get it working after 6 months, but the functionality was so limited management decided (correctly) that it was useless.

·         My second task was to redesign and implement (in Pascal) a working inventory system (this was for the Trident Missile Captive Line program). This version was successful and was used for the duration of the program.

·         Produced numerous data reduction programs (analyzing results from semiconductor tests).

·         Wrote a disassembler for HP1000 object modules (this was in the good old days, when it paid to spend a lot of time to figure out how to save a few bytes of memory or a few CPU cycles).

·         Cut the execution time of some subroutines in half, by careful counting of clock cycles. Same parenthetical comment as above.

·         Designed & implemented a code generator, which took a specification for a character cell data entry form, and generated the code necessary to produce the form.

·         Enhanced a public domain graphics package (BRUNO) to handle a larger number of objects.

·         Designed & implemented a software package for producing line graphs, histograms, and pie charts from numerical data.

·         Wrote a business program in SAS to catch duplicate invoice payments.

 

Digital: Principal Software Engineer: 06/84 - 11/96

·         Analyzed many system crashes on RSX, Ultrix, and Digital-UNIX (memory corruption, timing issues, smp problems). This has involved such things as manual stack trace analysis, modifying the clock interrupt handler on the fly, and dynamically check summing stack frame contents.

·         Analyzed an intermittent network failure (router wars) related to the behavior of DECnet's phase 4 routing algorithm as used on large Ethernets.

·         Debugged some assorted RSX device drivers (dz, dmc, deqna, dmp).

·         Implemented a portable remote login application, which included within itself an implementation of the VMS terminal driver.

·         I was project leader for several maintenance release of the DECnet for UNIX product. I've also been head of a small department (2-9 people in a factory). I was also chair of the Town of Shirley Planning Board for 4 years.

·         I've worked on innumerable network protocols, from data link level to applications (see list above).

·        I've worked on application gateways mapping between protocols in the TCP/IP and DECnet protocol suites (file transfer, remote login, & mail).

·         Took a buggy (needlessly) threaded program, and restructured it so it no longer used threads (and ran much more reliably).

·         Took a single threaded event logger and made it threaded, to eliminate delays due to blocking on system calls.

·         Designed & implemented a trace collector and analyzer for DECnet on Digital-UNIX.

·         Manual stack backtrace analysis: I have resorted to this with corrupted stacks that the debuggers can't  handle. It is also sometimes possible to reconstruct not just the current sequence of subroutine calls, but earlier sequences as well.

·         Code Base Management: For more years than I care to remember I've been involved in managing the code base for DECnet-UNIX. This is about 2 million lines of 'stuff' - C code, shell scripts, man pages, makefiles. Managing this has involved everything from point fixes, to major code restructuring, to complete rewrites. This has also involved increasing the degree of automation to the extent that going from source pool to a final kit ready for submission to manufacturing is a single command. I also turned on every conceivable compiler diagnostic, and reduced the number of warning and informational messages from ~17,000 to 0 (this actually uncovered about a dozen latent bugs).

·      CLI – designed and implemented a database driven CLI for parsing network management commands.  At the terminal level, it included command line recall & sophisticated command line editing.  At a semantic level, it could handle arbitrarily complex data structures (EG an array of structures containing substructures containing arrays, etc).

·         Designed & implemented a local reliable datagram delivery system (used for network management purposes).



EDS: Technical Lead / Consultant: 11/96 – 6/02

·     Helped transition the monitoring of the EBS (Electronic Broking Service) network from Digital to EDS. This essentially involved salvaging the work done by the engineering firm (Cap-Gemini) to recreate a custom network monitoring system within a TeMIP framework.

·        Evaluated whether HP OpenView could be used as a replacement for a current network monitoring setup using TeMIP (answer: in theory, yes; practically speaking, no).

·         Developed & taught a 3 day course on DECnet problem solving, involving both lecture and lab work.

·         Analyzed & rewrote CitiCorp's proxy-autoconfig CGI scripts and their netscape server security plugin.

·         Wrote some network backup & restore scripts for CitiCorp for their i500 and Entrust databases.

·         Added support in DECnet to run over NetRAIN (Redundant Array of Independent Network adapters).

·       Integrated the DECdns code pool into the DECnet code pool. This was fun because DECdns is one of the most fragile code pools ever created. I finally ended up verifying the correctness of the merge by writing scripts which:1) dbx'ed both old & new executables, extracted the definition of every data structure, and verified that they were the same, 2) took every .c file, in both the old and new pools, and ran it through the C preprocessor, a C formatter, and some custom code to separate out each subroutine, so the old & new versions could be diff'ed for changes.

 

 Lucent: Principal Software Engineer: 06/02 – 1/03

·         Was part of a team tasked with restructuring the code base for the Cascade ATM / Frame Relay switches.   This involved revamping the message delivery system and the task scheduling strategy. A significant part of this was adding instrumentation: EG: how many tasks are waiting to run; how long are messages delayed in various queues; are timers firing on time (ie what’s the delta between when a timer is supposed to fire and when it actually does); are any callback routines which are forbidden to block, ever blocking; how many messages are arriving per second; how many are being delivered per second?

·         Developed a proposal to move the inter-card messaging system to being TCP based in a way that supported priority.

·      Worked on some build process improvements:  Created a system where the specification of which files were compiled into which module on which card was specified in a generic “Files” file, rather than in the makefiles themselves.  This meant that adding a new source file only required a single edit, rather than ~26 (the number of card images).  Also, worked on “group builds” -  compiling an entire directory with a single compiler invocation (which cuts build time by about 50%, and catches some inconsistencies in globals & subroutine usage).

·         Worked on the software upgrade strategy for Lucent’s next gen switch.

·         E1 IMA card – worked as part of the systems team, getting the software to boot on this new card.

·      Worked as part of the team porting the Cascade code base to the Nexabit hardware platform.   In the process, all  #ifdef’s were removed from the code, taking a major step towards converting the software into truly generic, reusable modules (EG ospf, vnn (virtual network navigator), vcmgr (virtual circuit manager)).


Airvana/Ericsson: Principal Software Engineer: 01/03 – present

·      Made reliability & performance improvements in many systems areas – redundant storage, system  boot-up, debugging tools, build environment.

·         Implemented a replacement logging framework with improved performance and ease of use – and decoupled the framework from the rest of the system (for example – in the old framework, a change in the internal workings of logging could force a recompilation of topology-manager – not a good thing.  That is no longer true in the new framework).

·         Developed several “backdoor” communication channels for obtaining core dumps from line cards.

·         Gained some familiarity with the 3G CDMA based cellular air link.

·       Worked on the company’s last project – an ATCA based system.  Involved in managing and maintaining the 22 pieces of firmware present on the system.

 

 

 

Resume Home