Preservation of History

I was having difficulty the other day trying to get a simple two condition if statement to work. One of those days where you spend hours trying to get something to work and find out it was not working because there are four paths for a two conditions if statement and you were assuming the wrong two.

After beating myself over the head in disgust about not getting this to work, I went back to history and remembered AFOLDS, DUEL, DAD, and Frames

I will not go into detail because I’m not an expert and can’t remember it all.

AFOLDS

AFOLDS stands for Air Force On-lined Data System. This was the Air Force’s attempt to transition from a card punch data system to one that used terminals. It only ran on Burroughs main frame computers and I think was written in assembler. Since COBOL was the only language allowed (except for the real system coders who could use assembly), it had a lot of COBOL traits (sections, division, etc).

There were 3 or 4 parts to AFOLDS

  • DAD - Data Division. Like COBOL, all variables had to be typed in a data division. AFOLDS was based on a ISAM (Indexed Sequential Access Method) file structure an each element of a record had to be described. I think there were a few reserved name variables (IDX, IDX1). All local variable also had to be defined in the DAD - I think!

  • DUEL - Data Update Edit Language. This was the procedure division and what I’ll concentrate on

  • Frames - This was the primary method of input and output on the terminal. Lets just say it was nothing more than an HTML form!

  • Retrieval - A report writer that could be used by the end-user to extract data out of an AFOLDS system. This is were I first ran across AFOLDS

DUEL

Now DUEL was one of the strangest languages I ever wrote in - but when I look back at it - it taught me more about logic than a lot of other things. This was a 80 column COBOL like input. I don’t remember it all, but maybe something like this:

12345678901234567890123456789012345678901234567890123456789012345678901234567890
######*Conditions                                              ################*

Where

  • columns 1 through 6 were the card sequence numbers (in case you dropped your cards, you could sort them with a card eater - opps, card sorter - that often ate you cards and your work!)
  • column 7 was some kind of flag, probably defining a section or divison.
  • columns 8 through 73 is where you wrote your code
  • colums 64 through 79 is where you defined your logic!, more on that in a second
  • column 80 was some other kind of flag, maybe continuations or something.

I’ll leave off the line numbers in this example, and I know I don’t have everything right (can’t find any historical documentation). I’ll just document my own version of the language based on how I remember it. There were two main sections (paragraphs) in the code:

  • Conditions - only contained boolean conditions
  • Actions - assignment, branching, etc

I think each of these section had a section number. You can almost think of the as a simple if statement, but probably closer to a case statement.

Lets say I have two string variables Foo and Bar and based on the content of those strings I’ll do certain actions. Now Foo and Bar had to be defined in the DAD, but lets just assume they were, maybe even set to a default condition.

12345678901234567890123456789012345678901234567890123456789012345678901234567890
      *100 Conditions                                          ################*
       Foo = "start"                                           YN-
       Foo = "stop"                                            NY-
       Bar = "car"                                             Y--
       Bar = "engine"                                          -Y-
      *Actions
       goto 101  # start the car                               x
       goto 102  # start the engine                             x
       goto 103  # error condition                               x
      *101 Conditions                                          ################*
       actions and conditions to start car
      *102 Conditions                                          ################*
       actions and conditions to start engine
      *103 Conditions                                          ################*
       actions and conditions for error

The logic area had three options:

  • Y or true
  • N or false
  • - don’t care or nil

The compiler or interpreter looked at the boolean conditions (up to 16) and look for the first true path. If it found one would go to that action line and do the code there (where the x pointed to). If it didn’t find a true path, it would fall through to the next paragraph - often not what you wanted. This is a simple representation. I think the old COBOL periods (.) came in to play on each line. If the code did not end in a period, it would continue on the next line. I guess in Ruby this could be something like:

case foo
when "start"
  if bar == "car"
    startCar
  elsif bar == "engine"
    startEngine
  else
    handleError("bad bar")
  end
else
  handleError("bad foo")
end

Now like all languages, there is a lot of room for error. The nil conditions were often misguided - you often cared about something and a misplaced - could kill you. You could forget that a condition existed and the code would go to the next paragraph, which is not where you wanted to go etc.

This history lesson goes back to my Nil post. Everything is either True, False or Nil and you have to handle all of them. Considering we are generating booleans, there is only true and false. If I have a boolean “ok”, a simple DUEL condition would show the two paths

ok      YN
-------
action1 x
action2  x

If I am looking at two booleans, there are 4 possible actions

ok      YYNN
fo      YNYN
-------
action1 x
action2  x
action3   x
action4    x

If I am looking at three booleans, there are 8 possible actions

ok      YYYYNNNN
fo      YYNNYYNN
ba      YNYNYNYN
-------
action1 x
action2  x
action3   x
action4    x
action5     x
action6      x
action7       x
action8        x

This should tell you that you should never have a conditional statements that contain more than 1 “and” or “or” condition. Sometimes we think we are God and don’t need all the details = broken code.

In my problem the other day, I though I was looking for action1 or action4, but when I mapped it out with the Y’s N’s and x’s, I was really looking for (action1 or action4) or (action2 or action3). Well, not the actions, but the conditions.

History has a way of repeating itself.

By the way, my short cut example above should of been written as follows: (I didn’t try it on purpose, I just threw something together and forgot the stop condition. That means if foo was stop, it would probably fallen through to action 101 and started the car - without the engine running)

12345678901234567890123456789012345678901234567890123456789012345678901234567890
      *100 Conditions                                          ################*
       Foo = "start"                                           YYNN-
       Foo = "stop"                                            NNYY-
       Bar = "car"                                             YNYN-
       Bar = "engine"                                          NYNY-
      *Actions
       goto 101  # start the car                               x
       goto 102  # start the engine                             x
       goto 103  # stop the car                                  x
       goto 104  # stop the engine                                x
       goto 105  # error condition                                 x
      *101 through 105 conditions and actions                  ################