Why I love progamming (since then)

Why I love progamming (since then)

Power, immediacy and correctness. As we learned in my Why I love programming (then); those were the three critical ingredients that caused me to fall in love with programming.

It took me a couple of months but I landed my first programming job with Albany Savings Bank and I immediately lost one of the critical ingredients. Yep, back to keypunch. The bank was too afraid of OLPD (On-line Program Development) to allow us to use it. We did it all by keypunch cards, handed them in to an operator who would then run it (eventually) and give us back our output (along with the keypunch cards).

I learned NCR’s (formerly National Cash Register)  mainframe language called NEAT/3 and there was 2 levels to it. Neat/3 Level 1 was like cryptic COBOL with only 8 character names. Level 2 was basically NCR’s assembler.

I used Neat/3 for my first 3 years of programming. For the bank I did mostly report generation, for Victory Markets it was mostly inventory tracking and for Shoney’s South it was mostly General Ledger and Tax Tracking and Payroll. I’ve always enjoyed meeting new people so moving once a year into a new situation was part of the fun.

In each job, I quickly became the main debugging expert because I’ve been doing puzzles since I was in kindergarten and debugging is just puzzle solving. While in Memphis, I also started leaning Basic and I wrote my first little game that allowed to people to play Othello easily. It was crude but fun. I also did some consulting on the side in Memphis (for Peachtree Software, again mostly debugging other people’s programs).

Moving to California and working for Triad Systems; I became the only non-COBOL programmer in a COBOL group. I learned some COBOL but mostly learned Texas Instruments JCL (called “procs”). I ended up becoming a data conversion expert and eventually wiped-out Triad’s field service organization by making installation and maintenance of it’s systems so easily.

I was just starting to get bored with the COBOL and non-COBOL stuff when Unix appeared on the horizon. Unix, Pipes, Awk, Vi, E-mail, Grep; it was all an amazing new way of computing. Shortly thereafter I started hearing about C and realized that was the language I needed to learn.

In my spare time from about 87 to 91 – I decided to learn C on my own and I wrote my first shareware game called Modern Problems. In the middle of that, I switched jobs from Triad Systems to Tandem Computers, working in their TMF QA department. Writing programs to test and break their Transaction Monitoring Facility.

With Modern Problems, I got my first taste of Graphics Programming but it was Dos based and their weren’t a lot of helpful libraries. As much as I resisted the Windows trend, that was the next big paradigm shift for me.

And that’s a good place to get to the point of this blog. There is always something new to learn, especially new languages, new libraries, new paradigms, etc…etc…

And that’s why I’ve continued to love programming for these past 30 years.

I’ll close with a bullet list of things I’ve left out.

  • Direct-X and Full Screen game development.
  • SDL and iWin’s Framework of CastMembers (almost like sprites) running around.
  • Fake C++ (just used as “A Better C”).
  • Real C++
  • Upper Memory DOS (can’t even remember what we called it).
  • MASM
  • Interactive Network’s proprietary C masquerading as Pop-Code/Assembler.
  • The joy of Sockets
  • Creating Mah Jong from scracth.
  • Creating Small Games.
  • Creating larger Casual Games.
  • Designing a complete User Experience.
  • The Joy of creating my own Art – especially the Joys of Bevel in Paint Shop Pro.
  • Front Page 2000
  • Java + Java Beans
  • Word Press
  • Word, Excel, VPN, SVN, CVS, Vim, MKS Toolkit, etc…etc…

I’m sure I’m missing stuff here. On the horizon is Unity, Android, iPhone, iPad or all of the above. Working with real 3-D instead of 2.5D (I will enjoy the day I start doing Camera tricks with real textured surfaces).

Still to come – Why I love programming (now) (only hinted at here) and What have I learned about non-programming business related stuff in the last 30 years.

 

 

9 Comments

  1. Robert G Wade says:

    Didn’t know there was a level 3!
    But think the Centuries must have had 32 bit words as we used to clear a print line by moving four spaces to the end(?) & then moving the line over itself at an offset of 4.
    Had to maintain some COBOL code (on a Criterion in NYC) and had it print the object code & was horrified to see that when performing binary arithmetic the compiler first converted to unsigned decimal, did the arithmetic & then converted back.
    Whether the compiler was improved later?

    Learnt NEAT/3 level 2 in the mid 1970s & as well as two Century 100s (one with 64K memory used for online data entry via dumb terminals) the company had a 315 (using NEAT – 7bit ascii) and no disk drives, just a half dozen(?) mag tapes and a much more impressive array of lights on the console…was still used for printing as it had a couple of ‘fast’ (600lpm?) printers.

    Later acquired a PDP 11/34 programmed in MUMPS for (static) data entry which then emulated a terminal on one of the Centuries which wrote out a mag tape for the 315….suddenly no more rejected client data!

    In the mid 1990s I worked for an insurance company in Switzerland which still used NEAT/3 code!
    But I didn’t even see the NCR computers let alone program them….by that time I was working with relational databases.

  2. John Stewart says:

    NEAT/3
    National Electronic Auto coding Technique
    Used it and loved it over 20 years in the Kansas City area.
    Paid for my retirement.
    Learned it at Sugar Camp in Dayton.

  3. Greg says:

    I always wrote in NEAT/3 Level 3. (I am a control freak) I had to know exactly what I was doing. Sometimes the MOVE command would change a decimal field to an integer, when what we really wanted was the BITS moved for checking later (TESTCE/TESTCU) Then there was the LOGIC command to turn bits on and off. You could have 8 switches in 1 byte by using LOGIC and TESTCE/U. Unfortunately, some programs I created that wrote directly to the IOWRITER failed and often caused systems crashes! I was at the Dayton Data Center trying to debug one of my programs and literally blew up an online processor with 15 banks online. DEAD! I was lucky I wasn’t fired. I had converted an old 315 NEAT IRS system to Centrury NEAT/3. It was one of the smoothest installations ever for 15 data centers across the country. I got several accolades for how well defined the entire system was. In the process I found I serious bug in corporate code that was used by all the data centers. Several years later NCR would take the system I had written for Starcom back in 1977 and converted it to work for CIF. One of the places I would later work was trying to make changes to the program. After looking at it, I said “I wrote that!” “The hell you did!” one programmer said. I told him to look for CHGO77 or GP7xxx (My initials the year (7) and the julian date of the change (xxx). He told me I wrote a piece of crap, however, they were still running that program until 2012! Not many programmers can say they had a program still being used 35 years after it was written! I also figured out how to hack the VRX operating system so I could have up to 16 terminals accessing the VRX system (with security). The existing programs took over the NCR Field Engineers access port, so only 1 person could watch their job at one time. Also, you were literally a second operator’s console, so anything you typed in was just like you were in the computer room and anything you typed that was invalid (anyone remember crtl+G?) could cause the system to crash! What I did was fix it so we weren’t limited to 1 person at a time AND there were safeguards in place, like you couldn’t dink with someone else’s jobs and you couldn’t enter any invalid data. That was filtered. The manager didn’t like the fact that I was playing around with one of his MegaPath queues until one night I left the program running. Our system had this horrible problem (NCR never did figure it out) that the console would just up and die. You couldn’t answer any messages or queue up print jobs. Well one night the operator knew I’d left my program running, so he didn’t have to do a total reboot and restart the jobs from scratch (all our print files were lost during a reboot…) He made it a point to let the manager know that my program saved their bacon that night by allowing them to keep running until all the jobs finished and then they could do a restart. I called it FSALTCNS for FreeStanding ALTernate CONsole. Those were the days! Not many people left who remember the old NCR computers…

  4. Phillip Stanhope says:

    As Joe says, NCR was a cryptic COBOL. This was because NCR designed the Century series – 100, 200, 300 and later 75 and cut-down 101 so as to run COBOL efficiently.
    LEVEL 1 was the basic assembler, with Table-handling macros.
    LEVEL 2 allowed the use of additional assembler commands, which were 1-to-1 with the machine code.
    LEVEL 3 also allowed direct I/O, and indirect addressing (mode 1, 2, & 3 (don’t ask – one was repetitive ad infinitum!).
    They were all options to the compiler, “USE >EXEC.LEVELn”. Any restrictions were those imposed by management.
    If I recall correctly:
    LEVEL 1 – MOVE A,B – Moved data in A to B, data length as defined by B. One machine code if length < 256
    LEVEL 2 – MVAR A,B – Same, 8-bit char by char from Right to left, 4 chars at a time.
    – MVAL A,B – Same, but Left to right, might seem the same but different effects if A.B overlapping!
    Could override length MVAR A, B,22
    e,g. – COBOL: MOVE SPACES to PRINTLINE (length 132).
    L2: MVAR (4 spaces), PL,4 – sets first 4 chars to spaces
    + MVAR PL, PL+4, 128 – ripples the 4 spaces forward!
    L2, allowed you to dynamically create code by patching the following code!
    Great fun, but not easy to maintain!
    Met a number of programmers who insisted MVAR was quicker to excute than MOVE. Had they looked at the code generated by the NEAT/3 compiler they would have seen the same op code "64" for both!
    Another example – once wrote a complex module in COBOL68 (much easier to maintain and understand! )The prog manager was annoyed as he wanted it in NEAT/3 LEVEL 2 as this was supposedly much faster. Not sure if he ever accepted that the compiled code was exactly one machine code half-command longer ( 4 bytes) – because of how the COBOL 68 compiler handled "IF's"!
    Happy memories indeed!

    • joe says:

      I loved the fall-through architecture of the instruction loop.
      Can’t remember specifics….something like QA TB
      Where Q was “Q-Code” and “T” was the length….or something else…and
      if you didn’t specify a new TB….it kept the prior one….which let
      you do some slick stuff….when indexing through a table.

      Also….the compiler listing had the actual assembly code (on the right)….so it
      was a great way to see what was really happening.

      Lot’s of fun….used it for 3 years….before moving on.
      (Bank, Grocery Store Chain, Restaurant Chain). (1 year each).

  5. Tim Jannsen says:

    NEAT/3 also had a Level 3, which was known as “Captain Midnight Code”. It was at the operating system level and handled devices, interrupt processing and the like. As I recall, you had to have been granted special privileges to assemble and run Level 3 code.

Leave a Reply

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