IBM celebrates 35 years of #ibmi on June 21 2023. The career of Kisco Systems founder and IBM i wizard, Rich Loeber, goes all the way back to the 1960s. In this retrospective, Rich explores the evolution of IBM computing platforms and the business he created, Kisco Systems.
The Beginning
My career began on November 8, 1965, in the New York Central Railroad computer room on Lexington Avenue in Manhattan. My second day on the job was the day of the Great New York Blackout of 1965. Already learning about disaster recovery at a young age!
“Idiot” Tables
For that first job I worked as a computer room clerk. Since then, I've learned that we were providing an input/output control function; but everyone in the computer room referred to my work area simply as the "Idiot Table." The job was to look through manually prepared records of train movements that had been mailed into the computer room and then match them up with piles of computer printouts of train movements, looking for "missing trains." Missing in the sense that the computer did not know about the train movements even though they actually occurred in the real world.
Keypunch
The railroad sent me to IBM keypunch school for a whole week to learn how to operate the machine. Part of the class involved programming the keypunch machine and I found that to be the most interesting. After a week of training they put me on the midnight shift.
The job had two facets: One was to take transaction rejections in the form of a stack of punched cards and find/correct the errors so they could be reprocessed. The other was to listen to tape recorded telephone calls from small regional rail yards and prepare punch cards to process their train movements through the system. I also learned how to operate the card sorter machine, the gang punch machine, and an aging IBM 407 computer that was programmed on a wiring board (an early version of RPG?).
IBM 1401
In those early days colleges did not offer any curriculum for information technology. Most employers who were implementing computer systems had to train their own people to do the programming. I took the “Programming Aptitude” test and ended up scoring the highest score the railroad had ever gotten on the test. (Two years later, after I'd been working successfully as a programmer, I took the same test again at Reader's Digest and failed it miserably) The railroad offered me a job as a programmer trainee and I accepted.
The only place to learn was from the computer manufacturer. So, the New York Central sent me off to IBM's programming school in Manhattan, where I started out my programming career by learning "1401 Autocoder." At the end of the class, I started programming on the railroad's IBM 1401 computer system. This first computer was quite different from what we think of today as a computer. It was the size of two desks stacked on top of each other and came from the factory with all of 4K of memory. On that machine, 4K of memory meant 4,000 characters of storage, not the 4096 bytes that we think of today. The machine I worked on had a "caboose" on it with an optional additional 4K so we had the huge amount of 8K of memory to work with. That machine also did not have any operating system installed on it (they were another couple of years in the future) nor did it have any disk drives or tape drives. The input unit was a punched card reader where you loaded your programs to run along with your input data. The output units consisted of a line printer and a card punch unit that was integrated with the card reader.
The IBM 1401, first introduced in 1959, and its later cousin the IBM 1410, were variable word length machines. The size of each word, rather than today's standard 4 bytes, was determined by the placement of a wordmark bit. This was a part of the 8-bit character coding known as Binary Coded Decimal (BCD). The character was comprised of 6 bits (4 numeric bits and 2 zone bits) and the other two bits were for the wordmark and parity check. The memory on these systems was actually made up of magnetized "cores" or very small circles that could be charged in one direction or the other (on or off) - hence the term "core storage.”
IBM 7010
After six months or so, I graduated to programming on the "big machine" in the computer room. This was an IBM 7010 (a grown up version of the IBM 1410) which had 100K of memory, 6 tape drives, a very early disk drive unit and an interactive console which looked an awful lot like an IBM Selectric typewriter. It also had a very early form of an operating system and could actually run two programs at the same time. The railroad used this system to keep track of its rolling stock in files on the disk drive. We actually worked on developing the idea of indexed-sequential files on this system and this is one of the applications I worked on.
The disk drive, an IBM 2302, was huge with platters that were about 6 feet across and 8 pneumatic access arms. I remember that if it ever got turned off, like after the blackout, it took at least 30 minutes to warm up and get back up to speed before it could be used. Since there was no operating system to manage the disk contents, we had to keep the disk layouts all mapped out so that every area of the disk that was used was pre-assigned a space.
This system was also the basis for the first commercial application of CRT devices. The railroad had a communications network that connected a series of CRT's made by Hazeltine. These devices could be used at various locations around the railroad system to inquire as to the exact current location of any freight car, engine or caboose on the rail line. This same communications network was used to transmit train movement information between stations using automated keypunch machines that read punch card information from one station and then duplicated those cards down the line at another station. In the process, all of this train movement information was captured in New York by a Collins communications computer and stored on tape so that our disk database could be constantly updated.
System/360
After I had been with the railroad for a little more than two years, we went through a merger with the Pennsylvania Railroad and I was put on the new Penn Central's data integration team, based in Philadelphia. The merged data operation was going to be implemented on IBM's brand new line of System/360 computers that came complete with an operating system and embodied many of the concepts of computers still in use today. I found that not only did I have to learn a new programming language, Basic Assembler Language (BAL), but I also had to learn to work within the confines of the operating system. Not only did this new operating system support indexed-sequential file formats, it also had partitioned data sets and program files that were independent of the physical files on the computer so that you could reference the same file layout for different actual physical files.
System 32/34/26
After working on the merger project for a year, I left the railroad and embarked on a 16-year career with PepsiCo back in the New York metropolitan area. Initially, I worked with their auto leasing subsidiary in Great Neck on Long Island. It was here that I finally started working in a high-level language and taught myself COBOL, the language that I describe as my "native" language to this day. While learning COBOL, I spent a lot of time examining compile listings to see what assembler instructions were generated by the various COBOL code constructs and learned a lot about how high-level languages get implemented at the machine level.
When the auto leasing company was sold, I transferred to a heavy equipment leasing subsidiary located in Lexington, Massachusetts. It was here that I spent a short stint working on a Honeywell mainframe. My assignment, along with a few friends from New York, was to help get this subsidiary ready so that PepsiCo could divest the company. I was there about a year, then transferred back "home" to New York and got the job of Data Processing Manager at PepsiCo Wines and Spirits, where I remained for the last nine years of my PepsiCo career. It was here that we started to finally move away from punched cards and into a more contemporary setting of CRTs on everyone's desk and direct entry to the computer files to be processed.
PepsiCo Wines and Spirits was my first introduction to the IBM line of minicomputers. We implemented distributed application running at an office in Bermuda on an IBM System/32. This system, about the size of an office desk, had a 5 MB disk drive, a built-in communications port, printer, display, and keyboard, and was an early form for a PC. We followed this on quickly with a System/34 for the offices in Purchase, New York, where PepsiCo had finally landed its headquarter offices. The System/34 gave the division some real autonomy in their processing needs and integrated well with both the corporate 370 environment and the System/32 in Bermuda. This soon moved to the System/36 platform as a natural upgrade.
It was shortly after the System/36 implementation that I finally decided to part ways with PepsiCo. I started Kisco Information Systems in June of 1984 and am still doing this today.
Kisco started with general use utility software for the System/36. That platform had a loyal following and there were thousands of small software developers writing packages for it. I joined the group and soon had several software products on the market. I quickly learned that writing an application for a single user and writing for a broad range of users are two very different things. To this day, I am constantly astounded by the ways customers find to use the software that we sell; ways that we never imagined when we started out.
AS400/iSeries
When the AS/400 was announced in 1988, I got my order in right away for one of the new B10 systems. I ended up taking delivery of the first customer AS/400 installed in our county. I then quickly moved one of our most popular System/36 applications over to run on the AS/400 and entered into the AS/400 software market as well. I soon found, however, that the AS/400 was vastly different from the System/36. IBM did a nice job of making the System/36 customers feel at home, but I found that I needed to learn a new skillset to work successfully with this system.
One of the things that I have really liked about working with the IBM midrange systems is that code that I’ve written is able to survive down through the years. I don’t know of any other set of platforms where this is possible. When I first started out as a programmer, I wrote a date conversion routine for converting dates from Gregorian to Julian and back. It was initially written in 1401 Autocoder and when the System 360 came out, I converted it into Basic Assembler Language. Some years later, I converted it one last time into COBOL. For the entire life of the System/36 and well into the life of the AS/400, I was able to use this routine without having to touch it once. I only abandoned it when IBM added this function directly into the OS. In other cases, I have software product code that was written in the late 1980's for the AS/400 that is still running today without a recompile along the way. My congratulations to the folks at IBM for recognizing this very real need down through the years.
Today, the AS/400 hardware is known as the IBM Power System and can run multiple operating systems. The original operating system for the AS/400, known as OS/400, has gone through several name changes along the way and is now known as the IBM i OS. Also along the way, this proprietary OS has adapted and opened up to allow open source solutions to be run alongside home grown solutions. The IBM i is now exploring uncharted territory of longevity with few, if any, other OS's that can claim this kind of long life.
Kisco Systems at 39
Our business is evolving too. Now called “Kisco Systems” we are entirely focused on the security market with software solutions for monitoring, security controls, and audit. Our ability to deliver value to our customers grows with the IBM operating system. Native support for API integrations allows us to add powerful capabilities with minimal changes to core code. Features like SMS integration, MFA with mobile authenticator apps and more are all facilitated by the modern IBM i OS releases.
On June 21 2023 IBM will celebrate the 35th anniversary of the iSeries. As we look back on 35 years (and more) on this platform, we also look ahead with great anticipation. Kisco has been part of the IBM i community since the beginning and we’re not slowing down now! Our product roadmap has never been more robust. We are committed to constant innovation in monitoring, data protection and audit solutions delivered with exceptional support and unbelievable value.
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online