Coding at Walker Interactive Systems

My time at Walker Interactive Systems, a now defunct Mainframe financials company, served both as my transition out of the Army and into the civilian world, and as my introduction to life as a professional programmer.  It marked a rapid change in many of my attitudes about life, software, and business.

When I started at Walker, the company had recently gone through a round of layoffs, and was just recovering enough to start hiring again.  Many of the people on staff around me were veterans of the company, somewhat jaded, and ready to move on.  When I started in January of 1997, there were two other developers on my Group:  Laura and Tony.  By the time August rolled around, they were both gone.

I worked in a group developing internal software.  The end users were primarily the consultants of the company who customized the software for the end users.  Overall, the company sold a suite of financial software:  General Ledger, Accounts Receivable, and the like.  The software ran on IBM System 390 mainframes.  Customers were behemoths like AAFES, and one of the Airlines (I think United).  The primary software was designed to run on a 3270 terminal:  a fixed size, fixed font terminal run on a screen by screen basis.  It was an old technology.  Keystrokes were scanned and processed by the terminal software and stayed on the local system until an explicit “Enter” command would send the whole buffer back to the mainframe.

My team was responsible for turning these screens into an API that Visual Basic programmers could use, a process known as screen scraping.  An off line process would read the database of screens, including position and length information, and store it in a database on client side.  Code inside the applications would act like a terminal, buffer up the changed information, and send it back and forth to the mainframe.  The code to execute this was split into two pieces, one for the UI and one for direct communication to the mainframe.  When Laura left, I inherited the front end.  When Tony left, I got the rest.

Microsoft technology was then at the DCOM stage.  What had started as Object Linking and Embedding had evolved into a development philosophy that pervaded the various flavors of the Operating systems at that time:  Windows 95, NT4.  I became a student of the component object model, learned about monikers and marshalling, reflective cross language interfaces, and remote procedure calls.  Wrox Press provided most of the information I needed, and Stacey’s bookstore graciously provided me access to spend a portion of my salary to purchase the books I needed.

The first thing I did was a rewrite of the UI code.  This was less a matter of Hubris and more a matter of it being easier to learn by writing than understanding the existing code base.  The existing code was in C, and I was immersed in C++.  The existing code was a series of dynamic link libraries for the non-preemptive-multitasking version of windows that had been forward ported to Win32, but that had much of the vestiges of the older systems.  The old code was more error handling than anything else.  My version had the benefit of focusing on a single platform.  Since I had the freedom to develop the code from scratch without worrying about backwards compatibility, it made it much easier to make the new code re-entrant, something that the old code had to work to prevent.

One big lesson learned from this effort was to respect the amount of embedded knowledge that there is in a pre-existing code base.  After the first release of my code, I spent a lot of time fielding bug reports from the UI developers about features I had missed.  I learned the value of having a quick-to-run debugging code driver that allowed me to easily reproduce their problems.  The integrated debugger was invaluable in stepping through, viewing what was actually happening, and allowing me to quickly make and distribute fixes.  I got the notion of step through your code drilled into my bones.

When adapting the Gateway code, I had to deal once again with the rapidly changing API from Microsoft.  The older method of remote procedure call was deprecated.  DCOM was the new hotness.   After much trial and error with their Interface Defintion Language (IDL) and SAFEARRAYS I finally got a simple network service to run.  Since my version was expected to be remote, we had reduced licensing from each client machine to a single NT server as well…or at least the potential to do that.  Not sure if the company ever followed up on it.

Of course, all of this distracted me from what I was “supposed” to be working on:  the replacement for the screen scraping which was an asynchronous messaging layer.  This was my first exposure to the recurring theme that I will state here as a rule:  Never name a software project Phoenix.  Really, do you want to imply that your project will go down in flames, dying time and time again?  This project phoenix was no different.  The concept was good:  pull out a section of the cobol code that could be executed as a standalone transaction.  Turn this into an asynchronos message and let the developers send the message to the mainframe.  The reality was that so much of Walkers code would needed to be restructures that even after we got the messaging layer working, the concept was unusable.

One of the end goals of the messaging layer was to work with Data Bound Controls.  There are things like spread sheeets and fields that can be bound to a column from a database query.  Since that meant playing nicely with the Microsfot database technoligies, I dove in and made the messaging layer an OLEDB Provider.  If this doesn’t scare, just be glad and move on with you life.  If this does scare you, then you know way too much about microsoft technologies and I feel somewhat sorry for you.  Basically, I had to learn about the technology that microsoft was then pimping as a replacement for ODBC, a tehcnology which never really should have caught on, and a technology that should be quietly taken out to the back 40 and shot.

One bug while developing the OLEDB provider took me two weeks to track down and fix.  THe mistake was mina and mine alone.  I was apassing in a NULL to a field that required an allocated structure.  THe problem was that, while I owned the calling and implementing code, in the middle it had to go through a microsoft technology called Active DAta Objects (ADO).  This particular API was closed source.  I could see only the disaassembly of the executing code, which didn’t provide the context I needed to deduce my mistake.  This adventure really sold me on the concept of Free (as in Speech) Software and Open Source coding.  I had just started experimenting with Linux, and this really drove home why the development model was so successful.

The very tail end of my time at Walker was spent learning about Java.  IBM was pushing Visual Age, and the company was planning a bitg transition. Walker really suffered from the .com boom:  people fled to cooler, more interesting jobs throughout 1998 and 99.  I left in the summer of 99 to go to Fort Point Partners, a botique services company that was pretty focused on ATG/Dynamo and eCommerce.  Soon after I left, I happened across a group of former co-workers there.  We chatted and they let me know that the company was then very Java and Websphere focused.  Not long after that, Walker was acquired and then passed on to the corporate afterlife.

8 thoughts on “Coding at Walker Interactive Systems

  1. Hi Adam!!! I came across you on Google and actually am looking for a Walker Financials Developer for a contract here in Dallas! Would this interest you… or do you know anyone!?? Looks like you definitely have the expereince needed and this is a tough skill to find! Any assistance is appreciated 🙂 Thanks so much!!!
    Kristin Hughes =)

  2. There is a Walker Alumni group on LinkedIn which is probably your bet place to look. I don’t have the skills you are looking for. A contact of mine there wrote:

    “If all they’re looking for is some documentation, then Infor (the company that took over from SSA Global, which took over from Elevon, which was a rename for Walker) would be the people to contact. If they’re looking for some consulting help, then I may be able to help them. ”

    Find me on linked in and I’ll put you in contact.

    http://www.linkedin.com/in/admiyo

  3. Need u to give me a jingle. Phone number 7325815182, my colleges and I have spent many a 72 hr shifts, working thru this system. All over the US. I need a couple of their stupid manuels for an upcoming project. There are still a couple stupid companies that want this product or cant afford to consider another. Here I am to the rescue, as usual.

  4. What do you do when you try to Resolve on the MTR screen and you get SET BUSY, TRY AGAIN LATER? I’ve got an account that won’t pull into a set for summarization.

  5. Adam,
    It’s remarkable to think that the infrastructure architecture we designed in the late ‘80s is still in use in 2018. I thought most of us ibm assembler programmers are retired or gone. Fun to have run across your old blog.
    John M.

  6. John, it is wonderful to hear from you. I learned so much from you in such a formative time in my development as a coder. Not much assembly these days, but I still refere t back to IBM mainframe technology on a regular basis as we talk virtualization, provisioning, and scale.

  7. Mary Burke if you still need Walker people contact me for a resume and keep me on file. I am busy ’til January 2020. After that I am available. In the past I have worked with Walker GL, AP, PO, et al a lot!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.