The personal blog of Steve Alex
Gadsden, Alabama
Everyone knows engineers can’t write! I
is
an
engineeer!
But...
I Wish I Could Write!
Home
About This Site
Articles Categories
All
moneypit
code
thoughts
golf
other
rails
food
vfw
Recent Posts
Rails 8 Basic Auth - Missing Pi
March 20, 2025
test 4 col
March 11, 2025
Just a test
March 08, 2025
Bottom of the Ladder
March 08, 2025
Rail Basic Authorization (after
March 07, 2025
### 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: ``` ruby 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. ``` ruby 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: ``` c 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 ~~~ ruby ok YN ~~~ .markdown
AFOLD and DAD/DUEL
August 10, 2010