Why wrote this?

• Because I want to have a record of it
• To share it with other people
• So when I talk about computing, others may have an appreciation of how Ive got the knowledge and understanding of computing and IT that I have.

Because I have previously written about my:

• Educational history
• Working history
• Many other things

I am generally not going to repeat them here. Rather I will link to what I have previously written.

Typically my link to something else it will be show in a different color text.

When I was about 10 years old I have a recollection of reading an adversement in a newspaper about a computer system. I must have known what computers were to be able to appreciate it, but it's set off a sense of curiosity in my mind.

1962 NCR 390 Computer Advertisement Newsweek November 19 1962. Not the add I read or the paper, but something of that era

That would have been in about the early 60s, when computers were around but were not commonplace, based upon what I have more recently read.

See history of Australian computing and Trevor Pearcey and CSIRAC and COLOSSAL 1st Electronic Computer

Me in front of CSIRIC at the Melbourne Museum 30/12/2014

The first time I ever programed and used a computer was in 1967 when I was at high school.

I have previously written about that here and also hear

In 1970 I enrolled in a diploma of business studies accounting and EDP at Preston institute technology in St George's road Northcote.

Here is part of what I wrote about that and some more as well

On reflection I often wonder how well we were taught programming, considering that the teachers we had were not professional programmers, as far as I know. Can't be sure of this part, but if they had a been professional programmers they could have made more money programming than teaching programming. And even if teaching programming they would have made more money in a commercial environment than in a educational environment.

I really enjoyed programming. It came pretty natural. I had a bit of an aptitude towards it. However at a later time I sat for an aptitude test with the Commonwealth government as a prerequisite in getting a programming job. As I never was offered the job I get the impression I didn't have the aptitude that they required. However there were hundreds of people going for I assume very few jobs.

Some other time I also remember having to do an aptitude test to get a job as a computer salesperson. I didn't get that job either. Why they wanted somebody with programming aptitude to be a computer salesperson is beyond me. Years later when I started working as a computer salesperson most of the sales people had no idea of computing at all let alone programming.

In later years when I became a teacher of computer studies and taught computer programming they never had aptitude tests. Hence a lot of people enrolled in computer programming subjects only to be very disillusioned in not being able to learn how to write computer programs.

When I taught at broadmeadows TAFE I had one student who was doing the second subject in programming who had passed the primary subject by writing code line by line as directed by the teacher. When he got to my class and started failing tests we sat down and discussed why. I showed him an error in his logic in using a particular programming instruction. To that he said to me, you have never taught us how to use that instruction that way, hence it was unfair for me to fail him on that program. It then took me quite some time to explain to him that computer programming was mainly about solving logic problems that had never been encountered before. If he wanted a career as a programmer he would be constantly solving problems that he had never encountered before.

Whilst I was learning to program at Preston Institute, another student was having a lot of difficulty learning to program. I remember him saying to me that he would go back and rewrite all his notes and see if that would solve the problem, as that is what here previously done when he had problems learning. I knew it would not solve his problem. Like many other people, he thought learning was all about just remembering. He probably could have recited all the programming syntax instructions, from memory, but was not able to put the instructions together to form a working computer program.

The programming language we were taught at Preston institute was initially, cobal. It is a very verbose language such that it was very easy to make what would now be called keying errors. However as described in the above links we would hand right the instructions out on coding sheets and have a key punch operator punch the code on to punch cards.

ICL cobal programming sheet

ICL Punch card

Manual ICL Card punch machine

An ICL Punch card and verifier bring used

We could write down the wrong things on the coding sheets and those that were punching it on to the punch cards could get it wrong. To overcome the punching errors we would have to check what was written at the top of each card against our coding sheets. If there was a mistake we had separate hand punch machine to punch one card at a timme. All very laborious tasks.

Ther was also the possibility that you could drop a stack of cards and have to resort them into order, manually. There would be a number on each card.

Once all that checking was done you could submit your program to be what's called compiled. This is where the computer would check to make sure that it understood every word of every instruction and they were in the syntax it expected. If it was not, then a list of errors would be printed out. Of course, next to no one, would get the initial code error free, the first time. So the whole process would have to be repeated.

Some of the students took their own initiative and when the word “program” was used, as it is was in cobol, they would write it the UK English way of “programme”, because the computer was a ICL (British company) computer. This would cause an error. The teachers pointed out, that although it was a British computer, the programming language of cobal is a US invention, and as such “program” would be spelt the US way.

I was able to work out a lot of the problems with the syntax errors myself, but many students had to refer to the teachers. There was often a long queue of students lined up to seek help from teachers.

We were told we had to buy a cobal programming manual, from ICL. It was quite expense, went 100s of pages and was written in computer engineering speak. Today you would have to run a whole course on just how to read a programming manual. I don't remember anyone telling us how to read the manual.

Basically the teaching was writing instructions up on a blackboard with students copying it down into their notes. What is sometimes called chalk and talk. An extension of the rote learning that had been used in education up until that stage.

All this was completely independent of the logic of what the program was intended to do. The teachers basically wrote the logic and no consideration was ever taken into students having to come up with their own logic. It was just assumed that they would.

Because I had a slight aptitude for programming and had previously done a little bit of programming when it high school I was able to progress in learning to program.

During my second year at PIT I did a second year programming subject. Unfortunately most of it was all theoretical because they didn't have the programming languages that they were teaching, running on the computer they used.

It was completely non interactive. No way to check if you were using the correct syntax. No way of checking if your program logic was correct. I'm not even sure, from memory, if we actually had to write programs. We were just taught some of the idiosyncrasies of the particular programming language and then given a test based on that. Hence it became a test of how much you can remember. I don't have a memory like that and still don't to this day. Hence I did very badly on the tests and exams

To put it in some sort of perspective in later years I learn to program in a particular programming language called Magic. I made a very good living out of writing programs in Magic. At one stage I was the Australian guru for the language. I was able to charge a thousand dollars a day teaching the language. However to be certified as a Magic programmer you have to do a test which is basically all multiple choices theory questions. I am not able to pass that test because I cannot remember some of the wording and descriptions used within the language. You are not allowed to use the language during the test. Yet the many people that I taught, were able to pass the test, because they could remember, but not necessarily write programs as good as I could in Magic.

For about 7 years I did not work with computers as I had met a young lady and we decided to get married.

We thought it would be best if I had a full time job so I started looking for one. As explained here those employing computer programming jobs wanted either people with experience or qualifications, of which I had neither.

If I had of known about it at the time, I should have applied for either computer or accounting machines sales jobs, as they did not require any qualifications or experience, as I found out ,7 years later, when I started working for Olivetti.

I ended up working for 7 years as a cost accountant which I was reasonably good at, but it was not my passion.

The above link describes who I worked for. J Gadsden, Crockford and Robertson and James Hardie.

After reading what I wrote about those jobs, even though I was not doing a computing job I was still learning about the use of computers and calculators. Electronic calculator had started to become popular and Gadsden were using them.

A Burroughs adding machine from about that era

One of world's first electronic calculators, Friden EC-130, with CRT display and mechanical keys ($2100 in 1964, about $20,000 today). Probably the ones they had at Gadsden. Photo from https://www.reddit.com/r/EngineeringPorn/comments/j64h84/one_of_worlds_first_electronic_calculators_friden/

From:http://www.vintagecalculators.com/html/friden_ec-130_-_ec-132.html

Gadsden had a ICL computer somewhere in West Melbourne as we went to see the computer when we submitted stock take data. As my boss, the senior cost accountant new I had experience in programming he mentioned that to the manager of the computer center. Other than me being able to understand what the computer manager was describing of ther computer installation configuration, the incident was not of any benefit in my employment advancement.

It seems common, at that time, that the physical location of computers was often nowhere near the operating locations of business. May be because of the amount of room they took up and that they required special airconditioning. Also because as the processing was all very slow batch based the physical location was irrelevant.

But it was part of what I have written about, that I describe as the invisible Glass technology wall, that still exists today and is becoming thicker.

Crockford and Robertson had ledger machines. It gave me the chance to learn how they worked.

They had been investigating the idea of getting a computer so had brochures about them as well as descriptions of the software they came with. More about that hear

Geoff Crockford the major owner of the business, was very keen about buying a computer. However he had no idea of what it would be involved. As

I have since discovered, even the people that worked within the computer industry had no idea what they were doing. There was next to no software being written in Australia for Australian conditions, it was very expensive to have software purposely written, it would have taken a long time and would have been full of bugs. Because software development was such a new thing there wasn't anyone with long term experience at it. Everything was new to everybody.

They used a computer bureau service for their payroll and part of ther job costing. It gave me exposure as to how dealing with external provider of services worked. Was not much better than having a in a house computer system.

In my work history I have written reasonable extensively about how I sold computers at Olivetti. See it hear

What astounded me when I first started working at Olivetti was how little about computing and accounting that the sales staff knew. And even more so how little our customers, that were running businesses, new about their own business or how to run a business. That not only applied to small businesses but also large multinationals.

Our customers that did no something about running ther own business, admitted to me that they knew nothing about computing. Hence they relied on us salespeople to provide them some information. Of course we were only going to give them information that could possibly lead to us getting a sale.

The guy that was my initial sales manager and later became a business partner of mine, had virtually no idea of the capabilities of the computers and software we were selling. When asked by a customer could it do such and such, he would just say yes.

Hence Olivetti would end up in a lot of legal battles with their customers, so much so that a branch manager told me that I should not be dealing with legal firms.

Ther generally was little communication between the Olivetti programmers and the sales force, because most of the time we were selling standard accounting packages. On the few occasions where a customer had a requirement that could not be handled by the standard accounting packages I would ask the software manager or one of the programmers to give us a quote as to how much it will cost to write a particular program. I can't ever remember a customer accepting a quota, because usually there were very expensive.

Because of my previous programming experience and the very good documentation about the limits of how many customers, products, inventory items, etc the standard accounting packages could handle I often would tell potential customers what could not be done.

One example was Craig and Sealey, chef cookers in Brunswick. They wanted a payroll program for their thousands of employees. Our program only had the capacity for a couple of hundred employers because of the physical floppy disc storage capacity at the time. Also there was a restriction of not having enough time to input the data to be able to calculate the pays on the payday. My solution was for them to buy multiple computers. Which to my astonishment they did. Biggest sale I ever had.

It turned out in the long run it wasn't very successful because they end up spending hours printing out reports because the machine at the time could only print it 16 characters per second.

Eventually they changed to using their parent company ,Volcon Industries, mainframe, on a batch bureau basis. At least at that time Olivetti didn't get sued.

A few years later when I was working at Chantaneale I sold Craig and Sealey a Sord computer to produce sales performance graphs. The person that bought that computer said it resulted in him getting a promotion in the company.

At the time there seemed to be a big misconception as to what computers could or couldn't do. Potential customers would say they wanted to be able to press a button and it did such and such. I had to often point out that the computer could not output something that was never put into it in the first place.

One of the packages that Olivetti sold was invoicing. Of course invoicing would be different for every different type of business that used it. To overcome that, in Australia they invented a system called AIDA, Australian Invoice Debtors accounting. What should have been done was that the software team should have gone to the customer and ask the appropriate questions as to how they wanted their invoice to appear. But for some reason or other, the job was given to the person that made the sale.

It was a series of questions that you would ask the customer how they wanted their invoices to be printed. The answers to those questions would be entered into a program which generated the invoicing program, that the customer would use. It helped me learn how to later write invoicing programs, in a way that was easily modifiable. The concept of soft software rather than being hard-coded.

A side benefit of the AIDA system is that the custom were would have to get pre-printed invoices with their logo and the appropriate positioning on it produce by a printing company. We used to get a lot of kickbacks for referrals to stationery printing companies.

I got to sell or try to sell some vertical market packages. Like real estate, accountants, and milk vendors. That spread my knowledge as to what could be done with computing which later benefited me when it came to developing such software.

As I've written in the link above in my employment history, in the later years at Olivetti, I ended up selling office products which included word processes, in their dealer division. This gave me a knowledge of word processing which was completely different to accounting packages. In those days the physical computer equipment was different for accounting as opposed to word processing.

Just before I left Olivetti they came out with some sort of a software product that could do multiple things. Probably the precursor to spreadsheets and the equivalent of something like Microsoft office. Never heard anything about it afterwards

Probably, like most computer companies, with the possible exception of IBM, Olivetti would employ practically anybody as a salesperson. If they did not succeed they would be given the sack. If they did succeed they would either be promoted to a management position or jumpship to another company. Hence there was a big turnover of sales staff at Olivetti.

When selling in the dealer division I would come into contact with people from other computer companies. I met one guy who had previously been working for IBM who told me all IBM sales personal had to go through three exit interviews to be able to quit IBM. Perhaps one of the reasons for the lesser sales staff turnover at IBM. Not sure how IBM enforced that policy.

The big issue Olivetti had was the physical design of something that sat on a desk that had a screen. Olivetti was very big on the physical looks of a device. They had evolved from a typewriter company where the device sat directly in front of the operator and did not have anything coming away from it. Having a big screen with a separate keyboard just was not what they were all about. The interaction between the operator and the computer was via what was typed on paper.

Ther concept was that of visible record computers, which were basically ledger machines that had information stored on ledger cards. Part of the reason for that was that computer storage was far more expensive than paper, at that time.

Hence when it came time to change to screen based computing, that was completely a foreign concept to Olivetti staff from a usage, design, sales and aesthetics point of view.

Ther first fortay into screens was a one line LCD display just in front of the keyboard.

The sales teanique that was used was to say that because the data, for example finanal account balances and transactions, were on physical ledger cards, that anyone could see them at any time. The practical reality was that only one person could read a ledger card at a time. If the card were taken away from the operater then that operator would not be able to post transactions to the cards.

This was compared to the mainframe computers at the time where reports had to be produced to show the same information. Such reports would often take quite some time to print, especially if it involved a large number of accounts and or transactions. Unless the reports were printed on multi page stationary via the use of carbon paper or transfered to micro film or micro fish. It was not very often, because of processing and timing constraints, that a report would be run multiple times.

If multi user computers were around, such that information could be printed or displayed on demand by multiple people at the same time, they would have been very rare.

Kristi using my Tandy computer about 1981 Me and Glen using my Tandy computer about 1981

Around the time I finished working for Olivetti I bought a Tandy TRS-80 personal computer. You can look them up via a Google search, as plenty has been written about them. They were cheap enough to become a consumer item.

It allowed me to further hone my programing skills. No punch cards, no waiting a day to see if I had made any typing, syntax or logic errors. As soon as I hit the enter key from the program line I had typed, it would show syntax errors if necessary

Programs could be saved or received on cassette tapes. It was a slow process but FAR better than punch cards.

I wrote many programs including a very rudimentary spread sheet and a monopoly game. Neither good enough to share.

Free sharing was common place in those days. Very few programs were sold. The most popular were games. Space invaders was the one we most played.

It was apparent to me that the future was going to be in screen based personal computing with shared free software. The first eventually came to be, but the second, lesser so.

I realise now but was not aware at the time, that the programming language, Basic, severally limited my ability to write the programs I wanted to write. It could be said that it was the limitation of the hardware. But that's not what it was. Later languages have proven to be just as difficult for me to write my software. It's only years later when I started to use beyond 4gl programming languages that I realised that the issue was not me but the language themselves. Software engineers and even end users applications developers tend to develop software from ther perspective rather than from an end users.

Here is were I wrote in my work history about Chantaneale

As described in the above link I came into selling screen based Diablo and Sord computers. Diablo was an American company and Sord Japanese.

The Diablo US software was modified by Mitsui Computers in Australia to meet Australian conditions. It used open transactions in Debtors accounting rather than balance forward. In the balance forward transactions were only stored for one month and only the balance of the debtors account was bought up to the next month. All the transactions were deleted to makes more space for the next months transactions. In open transactions every unpaid invoice was stored in the system until it was fully paid. That meant far more storage was required. The diablo system was the first one I worked on that had an optional hard drive.

Initially the Sword computers we were selling only had floppy disk drives so the debtors accounting system I wrote in PIPS 3 was balanced forward, but when Sord later came out with a hard drive that could be retrospectively added to the original computer, with very little effort, I was able to modify the Debtors program to make it open transactions. So was the ease of modifying programs in PIPS

The PIPS system was similar to a modern spreadsheet in that it had columns and rows but different in that it also had pages. Each Page was limited to 150 characters wide by 60 rows deep. If you wanted more rows you were just add more pages. On one five and a quarter inch floppy disc at the time you could have, from memory, 30 pages. And of course unlimited floppy disks.

One of the first full applications I wrote in PIPS was a payroll. Some pages were for employees, some for weekly pays some for year to date pays, even a page for tax rates as well as a pay sip format page. It was very easy for the end users to use because they were used to using columns and rows on their manual computer system. They just entered the ordinary and overtime hours and it would automatically multiply it by the employees rate, calculate the tax and net pay. This could be done multiple times in case a mistake was made and a separate PIPS program would add the the weekly pay pages to the year to datate pages

All the programs fitted on one unformated (no columns) page. Less that 2000 characters.

Great advantage of the system is that it could be modified extremely easily. I did so for a bus company that had idiosyncrasies in the way they ran their payroll. Something to do with an inside and outside spread of hours. Only took me a few minutes to modify the program. Some users were able a modify it themselves

Unlike a payroll system where our customers would have perhaps only a hundred employees when it came to debtors, they could have thousands. The PIPS system had a sorting function which could be processed across multiple pages, to the maximum capacity of a disc. But even with all the pages sorted, end users would not know which page a particular debtor was stored on. I divised a system that kept track of which pages were used and the last name of the debtor on each used page. The end user could enter a debtors name and my indexing system via what is called a betrieve lookup would no exactly which page the debtor was on, so open that page and then again with a betrieve lookup no exactly which line on that page the debtors in question was on. Read the debtors detail and present it to the operator.

The thing that was quite advanced for my program, at the time, was it was done via the debtors name not by a number. Most other accounting systems you had to no the number of the Debtors to access them. Typically the number was a record number in the file. Record number Access was faster than my system, but users have to have a separate manual system to look up the number of the debtor. Overall the few seconds delay for my system ended up being faster than having to lookup a debors number manually before entering it into a computer system.

Other than my PIPS programs bring far less expensive than other accounting systems this need to not code before data entry help me sell my system.

At a later time Sord came out with 4G PIPS that ran on IBM and compatible hardware. It had a built-in indexing system, more elaborate than mine. It allowed some very sophisticated applications to be developed. Which is what I did.

Because the coding of such programs were so easy, I was able to combine multiple functionality into the one program. For example if you were entering in invoices and you came across a new debtor you could enter it in the middle of the processing function. In other systems you had to exit the existing program and go into another program to create a new debtor and return to the entering invoices program. My system provided a better workflow because of not having the need to do that. The same thing applied to all records in my systems, transactions, creditors inventory, general ledger, etc.

Over a few year period I personally developed probably over 100 different applications Many vertical market applications across a range of industries, such as accounting, financial, manufacturing, vending, point of sale and liquidation, are just a few that I can remember.

At this time I was basically a sales person so most of my time was finding prospects to convert to customers. The programming was just a side function of my basic sales function.

One of the Sord computers we were selling had multiple user/ terminal capabilities with a large enough hard drive to be able to store a substantial amount of data history. More than a month.

When we started using this multiple user computer, especially with PIPS, we discovered if two users tried to access the same PIPS page at the same time, it would take an extraordinary long time to access, far more time than twice a single user accessing it. If we put our hand on top of the hard drive we could feel the drive access arm shuttering. That is moving from one track on the drive to another and then going back to the original track caused by the drive trying to supply data to two users at the same time. Ther was very little hard drive buffering. It took quite a few years before that came along, and even then, that didn't solve the problem completely

The multiple user/terminal functionality ment multiple people could use the computer at exactly the same time. This presented a problem in being able to do record locking. The operating system may have allowed us to lock the files, but in accounting processing the one file, for example customers, would have many customers that could be updated, changed by multiple end user at almost the same time. As both users would retrieve the customer information at the same time, both users would see the initial state of the customer, if one user was changing a customers address whist another user is changing the same customers credit limit, whoever completed the process would have changes that the other person made overwritten. That is lost.

We spent a lot of time trying to decide ways to overcome this problem. In retrospect, we should have just told our customers that the multiple user functionality of these computers was only so one data entry function could be done at a time and other terminals could only be used for data enquiries or report printing. However there was nothing stopping and uses from doing whatever they wanted. They typically had no concept of what possibly could go wrong. And such things do go wrong.

When IBM decided to enter the personal computer market, that changed everything dramatically. Even though the IBM PC was not as good as the computers we were selling , purely because it was IBM, all the novices thought it had to be better. IBM was the biggest computer company in the world therefore they had to have the best computers.

Fortunately for us Sord had made PIPS available on IBM PCs and compatibles as shareware, so I was easily able to convert my PIPS III software to 4GPIPS. I still had the advantage of being able to develop tailor made software faster and less expensive than what else was in the market.

Because of a previous bad experience I decided that before we sold a system I would always document the software specifications of all programs and systems I was going to write. Then based on that specification we would give them a quote to write the software and develop the full system. I would always give them three prices. A price that barely got the job done, one that did most of the functions but not all, and one that did everything with all the bells and whistles. Typically clients would take the cheapest one. Then after the system was delivered they would often say that it didn't do everything they wanted it to do. I could say that that was the more expensive option. Typically they ended up paying for the upgrades that ended up costing them more than the most expensive option.

I found it becoming quite time consuming to write up such specifications so got to the point where I will give them a quote to write the specifications. My argument was that they could use the same specifications to get quotes from other people to write the software. So I started to become a paid for consultant rather than just a salesperson.

I don't remember anybody using my specifications to get other quotes. Even if they did, I'm sure other quotes would have been much more expensive because other poviders would not be using the same fast development languages that I was using.

For many reasons, as can be read in my |employment history, I sold my shares in Chantaneale and ceased being an employee/director.