Why I 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
• 50 + Years of Computing
• 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.

Mitsui Computers, who we were buying the computers we sold from, were part of Mitsui & Co . Somehow because of that relationship we go to do some software development for Mitsui & Co that had an office somewhere in the Melbourne CBD.

They had a Sord computer and wanted to do something about import and export and multiple exchanges rates using PIPS They were told I was the “expert” on PIPS, so got me to write applications specifically for them.

Unfortunately, or perhaps fortunately for us, they never explained what they wanted to achieve. As as a consequence they went through a number of iterations of me writing exactly what they asked me to write, realizing it did not give them what they wanted and got me to modify it. The benefit for us was they spent more than they would have, had they told me what they wanted to accomplish in the first place.

I'm not sure if they did it that way because they did not want me no how ther business operated, they did not no themselves how ther business operated or it was a Japanese cultural thing.

I was aware that the Japanese has a different way of doing business than Australin companies and that ther was a very strict corporate hierarchical order, but I learned quite a bit more whilst dealing with the Mitsui Management.

One of our customers was selling above ground pools from multiple locations around Melbourne. I can't remember the business name, but the owner was Paul Waller.

He brought a friend, who was a computer programmer,with him, to the demonstration. She a mainframe programmer and was amazed what I could do with PIPS.

As Paul was a smart guy, that new what he wanted to achieve in his business, he learn how to use PIPS and came up with multiple uses for for it. However he had limitations for which would seek advise from me. We agreed on an hourly rate to do so, $35, which was quite a lot in those days.

I realized that getting paid to do training or providing advise was better than selling complete systems every now and then. We stated to pursue that idea.

As he started to use the computer more he decided to buy a second one. He was a better wheeler and dealer than we were. One of my business partners was with me, Paul said to him, how about we flip a coin and if I win I getting such and such discount on the price. My partner said yes, lost the coin flip and we lost the discount amount on the deal. My business partner tried to backout by using a best of three coin flips. Paul did not accept that, so got the discount. We new he water the computer, we were the only ones selling it, so ther was no need to give a discount. Paul was definitely a better sales person than we were.

Pauls business eventually went broke and he ended up working for a business doing short term executive accommodation. He convinced his boss that he should be using PIPS. By that time Sord had gone from PIPS III to 4G PIPS. We sold it to him but he could not handle the transition to it, so the deal fell through.

As a way to bring in a more constant income it was decided to sell annual support Contracts for our software. This was not particularly well though through. There was no legal document associated with it, no limits were put on it, so that it was just whatever was said by the person selling it as to what it actually was. Usually something pretty crude like you pay us some money and we'll support this Software.

We didn't sell very many of them and after the experience of the first few, I made the decision to discontinuous selling them.

Initially the customers that bought them would ring up and ask how to do such and such. Usually very simple things. They would be told what to do and they would do it. A few minutes later that would ring back and ask another very simple question. Often we didn't have anybody at the office to tell them what to do. When I was answering the questions, I usually directed them to the manual or help screen, ask them to read out what it said and told them to do what they had just read. They would do so and the process would be repeated.

I suggested that we should tell those customers that we would not privide support for things that were written in the manual or help screens. That would cost them extra. Because there was no agreement we couldn't go back on some of what was verbal said.

This was a large well known furniture retailer with multiple stores. Not sure if they'll only in Victoria or Australia wide.

I remember talking to one of the staff who was praising ther founding CEO. How he had taken the business from something relatively small to what it was at the time.

They bought one of the new Sord Computers The M68. One of the first things that they did with it was run a creditor system. What would normally happen is after entering all the take on data the total of all outstanding creditors would be compared with their old system. Trouble is they didn't have a total for their old system. The system we put in did not total the creditors correctly because it did not go beyond a million dollars. We quickly made the change and found they owed ther creditors millions of dollars. That was a complete Revelation to them. Basically their business was insolvent and had been for quite some time. They were taking deposits from customers without supplying the goods. They went into receivership and this was all revealed on a TV current affair program. Luckily for us, they had financed the computer purchase and we got paid. Then at the liquidators sell up of the business we bought back that same computer at a fraction of the price that we sold it for. We used it for future development.

Ther were other businesses that we're going belly up at the time. We were just lucky that none of them owed us a big amount of money. Usually it was only from the stationary side of our business. We never sold a computer on credit.

I had a conversation with one of the executives of the Bedding Bazzar at that time. I think he might have been their accountant. He said he had been on the board of directors of multiple companies and in every case none of them new anything at all about computing. This just confirmed my belief from when I was at Olivetti that that nobody that were purchasing computers knew what they were doing, at that time. We at Chantaneale definitely did not no what we were doing, so it was a mater of the blind leading the blind.

Although things that now changed, I feel some of that still exists.

Sord S-Net

The story and explanation of why I left Chantaneale is described here

I initially started teaching part-time at Preston TAFE then later at Broadmeadows TAFE . One of the teachers thet new I was a programmer. Her father worked for a division of Containers Limited called Servepack, They made plastic packaging trays and the like. It was originally a privately owned business which had been bought out by Containers. Someone had written some software for them to keep track of their production processes and efficiencies. It wasn't working very well and they wanted something new. I wrote a specification for them, quoted them a price which they accepted. My previous work in cost accounting ment I knew what production systems were about. I asked if they wanted to do it single user or multi user. They said multi user. They had a network of about half a dozen PCs. That meant I couldn't do it in PIPS.

My now ex-business partner, Eric, has just discovered and was using a new programming language called Magic. It allowed for rapid application development of multi user applications.

I had told Servpack I would have the application for them in a couple of weeks. But I had to learn the language before writing anything. I did a couple of sessions of 18 hours straight over those weeks and deliver the system on time.

Magic was completely different from anything else I'd ever used and I can honestly say I did not understand what I was doing while writing the applications. Everything was just trial and error. A couple of months after I'd written that system I finally worked out how magic operated. It's an engine based programming language that cycles around and all you do is put in the parameters, It doesn't generate any code. Ther is no code. It has a runtime engine. The closest thing to it is the engine based IBMs RPG or a spreadsheet.

It had a lot of functionality built into it, allowing end users to do things without writing any code at all. Searchs, sorts and a built-in report generator, all whilst within ther application. No need to use anything separate.

Just like any other of the customers I ever had, they did not know what they wanted and as a consequence wanted lots of changes. But the changes were so easy in Magic. Typically I made them within a day.

Servpasks accountant rang me one day and asked if I had a stock control program. I said no but asked him what he wanted it to do. Just Stock in and out and a few reports,he said. I asked how much he wanted to pay for it and he said a couple hundred dollars. I said I could have it for him in a few hours. Which I did. I ended up getting paid more for writing the operating instructions than for the application itself. Such was the power and versatility of the magic programming language.

I was still teaching at Broadmeadows TAFE and picking the kids up and dropping them off from school. I have plenty of spare time.

I noticed at the time that a lot of people were doing consulting work. Most likely because most businesses new absolutely nothing about computing. So they would hire a consultant to help them out.

I started doing my normal sales person thing of telephone canvassing for, this time, consulting work.

I rang this business called dreamhaven furniture in reservoir. Did my speal to the MD. they had multiple divisions, one of which was the furniture manufacturing business. The guy that ran that, a divisionak manager, wanted to buy a hundred thousand dollar computer system. Only because he thought you had to pay a lot of money to get a good system. The MD ask if I could give him an evaluation of what type of system they needed. I gave him a quote for doing that. He accepted.

I spent quite a bit of time going through each of their divisions and finding out how much data they needed to process and what ther requirements were. I wrote up a systems requirement document. The MD was impressed that I was able to come up with a requirement that could be fulfilled without having to spend $100,000.

He then asked me to look at vendors that were able to provide such a system and evaluate each one an make recommendations. Great more consulting work for me.

I did that. Got 4 vendors to put in quotes. They were Chantaneale, Skemac, the mob who had previously proposed hundred thousand dollars system, and one other whose name I can't remember.

I wrote up my recommendations and went to a directors meeting. Dreamhaven were a listed Public company. The chairperson dismissed my first recommendation, Chantaneale, because he felt a public company could not deal with a business that was so small.

They ended up going for the one I recommended the least. The one that had originally proposed a hundred thousand dollar system. However the new proposal was only 20 or 30,000 dollars. They signed up with them.

It turned out to be a disaster. It got very close to them sueing the supplying company. The system was written in pick basic. It was overseas software that looked and demonstrated very well but didn't actually work. Dreamhaven hed checked references from ther other users who seem to be satisfied. But after things went pair shape and they rang back those references they found none of them were using the more advanced functions of ther software that dreamhaven we're using.

Dreamhaven severed the relationship with that company and ended up employing their own programmer to try and fix the software. That was a disaster as well as they had no idea what requirements they should have for a programmer. The programmer, they employed, could not understand how the software was written or what dream havens management wanted fixed.

I was brought in as a consultant again to interview the programmer. Eventually the program got the sack because he was not actually doing any programming, rather he just did work arounds of bugs. Dreamhaven battled on using the software as best they could.

One of the things this programmer got them to do was re index the whole database every day. He showed ther accountant how to do it. Later the same accountant thought my software was not as good as this one that he reindexed every morning because he could not reindex mine. He did not realise that having a system you have to re-index every day is not a viable system. Reindexing was completely unnecessary. That was one example of the naivety that was going on.

I realise I've done a double up here. I also wrote a bit about consulting here

As I had to pay for the development license in Magic I thought on might as well develop other applications. Based the previous accounting systems I had written I wrote the same thing, actually a better thing in Magic.

I thought I might as well sell it. I started canvas local businesses and one just around the corner was Peter Gibb stockfood. I made a conscious decision to only have customers that were within bicycle riding range of home. This one was.

I think I charged them $3,000 for a debtors invoicing stock control and credited system.

It was ther first ever computer system.

As they had a retail section as well as their wholesale business They asked me to write a point of sales system integrating with my stock control system. That was run on a separate computer. That's when windows 3 had just come out and I think it had built in networking. Might have been windows 3.1. the system ran great

I emphasise to them the importance of keeping backups. They appreciated that and did it festively. When they added the second computer for the point of sale system I got them to also run a batch task that copied the whole of the database from the main computer to the point of sale computer. Considering there was enough space to do so

One morning I got a phone call to say that their main computer had been stolen. Rather than having to quickly purchase another compute, install all the software and do a recovery from the backup, with very little effort I just got them to use the point of sale computer as the main computer. Had them going again in about half an hour.

I realised the benefits of having multiple computers and doing normal backups and copies to other computers across a network.

I wrote a fair bit about this in my work history. Some of the things I didn't write.

I wrote a lot of functionality into the students records system som of it:

The ability to no at any time, via an information dashboard without producing reports, what the total student contact hours were. It could be seen at any time by calling up one screen. No processing was involved. It would just display one record in a file. So virtually instantaneous. Then being able to drill down to see that total split up into its component sections, whatever they may be, departments, courses, subjects, classes or individual students. Again without any processing.

It was able to do that because I developed it as an interactive system. Every time as enrollment was entered it would add it to the total enrollment hours as well as all the other categories. It took a few seconds longer for each entry, but did not require any batch processing to get total results. A bit like having a running total in a spreadsheet.

Unfortunately because the management of the college did not use the system they were not aware of that capability. Management people of those days did not use computers. They just add other people that produced reports for them and had no idea how much effort it took to get the report. The old batch systems could take hours to produce such a report. Then after any enrollments or adjustments the same hours of processing would have to be done again. Like counting all the people in the world and then when anybody is born or dies counting them all up again rather than keeping a running total.

I had it set so it would update the dashboard screens every 30 seconds. Whilst enrollment were being input on multiple computers anyone else on another computer could see total contacts hours as they accumulated.

Years later I did the same thing for a general ledger system, so anyone using it could see the bottom line profit change as accounting transactions were taking place.

I dont no if modern systems do that.

In the middle of any data entry function, any of the master file processing could be performed, be it creating, modifying, deleting or looking up. Like a new student, course, subject or whatever, could be entered, details of an existing one modified such as phone numbers, or a check made to see if the student or whatever already existed via name lookup, all as part of the data entry functions

At the time Windows was not popular but when it became available multiple instances of the Magic runtime could be run at the same time. This ment that no matter what a user was doing they could start another session either full screen or in another window so have multiple processes operating at the same time. Like part way through data entry for one student, do data entry for another student, and switch back and forth between the two. This could be done with any part of the system.

If multiple students were enrolling in the same course and subjects, I provided the functionality to copy a previous enrollment so as reduce the amount of data entry. Also to save a enrollment as a profile so that future similar enrollments could be processed automatically.

Someone from the Central TAFE office came out and saw what I had developed and suggested I attend a upcomming student records officers conference and speak about what I have done. Rather than only talking about itI actually took a desktop with transparent LCD screen that could be put over an overhead projector so show what was normally on a computer screen as a projected screen, and demonstrated the application. Laptops and projector screens what available at the time.

A lot of the people there were astounded as to what could be done. They were all using Vax mini computer Batch based systems, which were very data entry intensive, and took ages to come up with reports.

I had a few people come up to me after the presentation asking how they could get the system that I had written. Unfortunately nothing ever came of that. Sometime later the TAFE head office had put out request for development of a student record system, not knowing that one had been fully developed an implemented. A bit of the left-hand not knowing what the right hand was doing. As far as I know my whole system was trashed.

The TAFE head office requested that TAFE colleges provide additional information to them. Student background information to do with Aboriginal and Torres strait islander categorization as well as student results.

I built that into the system and had it operational in less than a week. All the other colleges reckoned it would take the months to get the changes made.

The Management at Melbourne college of textiles had no idea of how good of system they had. That I could have been implemented statewide and even sold internationally.

For some reason or other, I found out that a UK software company that we're Magic developers we're looking for a student record system. I emailed them and actually sent them a copy of the system I wrote. I figured that the TAFE college was a government institution and it didn't bother me whether I gave away the software or not. No one told me I couldn't do it.

Sometime later, when the internet started to develop, I saw a UK business selling a student record system that looked very close to what I had written. I'm sure it was my system.

I have written this in my work history but it needs to be repeated here.

When I started working at textiles, I was given free rein as to how a student record system could be implemented. I was told that box Hill TAFE had developed a student record system so went to have a look at it. They had been working on it for so time with three programmers. It was a batch system that was nowhere near as good as the system I ended up writing. But there was no one that could compare the systems. They simply didn't have the expertise working in TAFE to no, even though TAFE ran computing programming courses.

Textile College wanted to get a new payroll system. I new my ex business partner Eric had one, written in Magic. But being part of government I new I should look around at other sources. They were heaps more expensive and nowhere near as flexible as Magic. We bought Eric's payroll on the understanding that I will be able to modify it. But to get it initially started we asked him to give us a quote on making some modifications about Aboriginal classifications and certain standards

He faxed my the quote, which was far too low. I rang him and asked had he thought about this that the other thing. He had not. I asked him to re-quote based on those facts which he did.

I had a number of questions about the Magic development system. I sent a Fax to Magic Corporation in Israel. I got a reply which did not answer my questions but referred me to a person called a Ilan Gross, who was in New Zealand and was somehow the person that was selling Magic software in Australasia. I tried contacting him to no avail. Sometime later I met him and struck up a business relationship with him.

When I was at Chantelle we sold a system which I had written in PIPS III to Andrew engineering. Other than the normal accounting applications it also had a specific job costing that integrated with the rest of the system. We had not heard from them for a number of years. That's sort of indicated how robust the systems I was writing, were.

I cant remember how it happened but they wanted to move away from the Sord computers to a new PC network system. They had approached another company who had written something for them that just did not work.

The MD said it annoyed him every time he looked at my original PIPS system that the word maintenance was spelled incorrectly on the main menu. Crazy thing was that PIPS was completely open. Anybody could have gone in and changed any of the text including the writing of the word maintenance. But end users either didn't know that, or were afraid to do it.

I used my base accounting system and wrote a revamp of the job costing system. Again only in a few weeks. They also wanted a general ledger. I was in the process of writing one for another client. Dream Haven furniture.

I made it so that it would show the Profit at any stage without having to run any reports. Initially I did not have any debits and credits. Debits were pluses and credits were minuses. Andrew engineering being a engineering business were quite happy with that. But the MD for Dream Haven was an accountant and wanted to see his debits and credits. In accounting you can have minus debits and credits. But it does not reverse what the debits and credits are. So I changed it. Andrew engineering didn't like it like that but put up with it.

Network person Mover to Qld still supposed it