50+ years as a software designer, programmer, and computer scientist,
first at the Institute for Mathematical Machines (Warsaw, Poland),
then at IBM Laboratories: Lidingö (Sweden), Vienna (Austria), Toronto (Canada),
then Ericsson (Stockholm, Sweden), and finally on my own under the logo "Giraf's Research".
Design, implementation, and documentation of basic software
(operating systems, programming languages, databases, database-based tools).
Programming in C++, Java, SQL, PL/X, Assemblers, REXX, PL/I, APL,
for Hewlett-Packard workstations with HP-UX, Sun workstations with Solaris,
IBM mainframe with MVS and VM, IBM RS/6000 with AIX, IBM 8100 with DPPX.
Research into programming languages and concurrent processes.
Open source projects "Mouse" and "Units".
The IMM Experience 1959-1965
IMM - the Institute for Mathematical Machines in Warsaw - has evolved from a group
of enthusiasts that constructed the first digital computer in Poland.
(See here for its early history.)
The computer, named XYZ (see picture), was followed by ZAM-2, ZAM-3, and IMM-41.
The pioneering spirit at IMM was very like that found in the book about early computer
enthusiasts at MIT.
Many among the programmers at the Institute were excellent mathematicians, winners of
One of them, Antoni Mazurkiewicz, has since became known for his theory of traces.
Wrote first program (punched on cards in binary, one hole at a time).
Design of a language for digital control of machine tools.
A very primitive predecessor of today's CAD-CAM.
Design and implementation of assembler for a special-purpose computer SKRZAT.
The computer used base minus 2 for number representation,
which resulted in a number of interesting problems.
My algorithm for converting numbers to minus-2 base used a biased division
with asymmetric remainder.
Design and implementation of supervisor (operating system kernel) for multiprogrammed computer ZAM-3.
Work on architecture for multiprogrammed computer IMM-41.
Design and implementation of its operating system.
Design of a compiler for ALGOL.
The IBM Experience 1965-1996
IBM Nordic Laboratory was created in 1961 with a mission to develop hardware and software
for process control.
After success of IBM System/360 (the grandmother of today's "mainframe"),
it expanded and moved in 1965 to its own building
in Lidingö - a suburb of Stockholm (see picture).
I worked there for 31 years,
with breaks for Ph.D. studies in Denmark
and guest performances at IBM Vienna Lab (Austria) and IBM Toronto Lab (Canada).
During that time, the mission of the Lab changed many times, and the hardware
part was lost, leaving it a purely software lab.
Most of that period was at the times when IBM lived up to the principle that
"our employees are the company's most valuable resource".
This gave a sort of family feeling, good team spirit, and very little personnel turnaround.
It persisted even after IBM radically changed its attitude in bad times.
In 1995 Mother IBM decided to close down Nordic Lab as a software development centre,
and turned it into Software Technical Centre, with the
job of serving OS/2 installations.
The Centre was closed down a year later.
The building was converted into school.
A collected expertise of over 100 people dissipated into the environment.
Working on Process-Control Multiprogramming Supervisor for System/360 (PCMS).
PCMS was a multi-thread modification of an early, single-thread version of DOS/360,
and was designed specifically to support process-control hardware
developed at Nordic Laboratory.
One of the sites using PCMS was the nuclear installation in Windscale,
Great Britain (now Sellafield). Note that it was after, not before,
the radioactive incident there.
The Supervisor was written in Assembler and punched on cards.
It filled two card boxed and occupied 10 Kbytes of memory.
Developing a supervisor (operating system kernel) for IBM 18T4.
18T4 was a programmable terminal under development at Nordic Laboratory.
The supervisor, named SERVANT, included a device
for synchronization of concurrent processes just invented by Dijkstra: the "semaphore"
Co-operating Sequential Processes).
The supervisor was completed and tested, but the work on the terminal was discontinued
after building a prototype.
Somehow, the semaphore remained unknown to the IBM programmers for the next 15 years.
Advanced Technology project: Assembler Generator -
a toolkit for quick construction of high-quality assemblers.
The project was code-named "Hundskärsknuv" after a lighthouse in the Stockholm archipelago.
Abbreviated to HSK, it became the official name of the Generator.
Under this name, the Generator was used in the following 10-15 years to produce assemblers for new processors.
It was one of the main tools in the development of microcode for System/38 and AS/400.
Under the work on HSK, we gradually changed our medium
from punched cards to CRT terminals with rows of 80 green characters on a black screen.
We also moved from Assembler to PL/S ("Programming Language for Systems").
PL/S was initially a subset of PL/I, but then began living its own life, generating a highly optimized
An assembler constructed with the help of HSK was a cross-assembler
running on System/360 and consisted of two parts:
a number of standard components independent of the target machine, and the target-dependent code.
The standard components: the macro processor, file management, cross-reference processor, etc.,
were taken from the best System/360 assembler of the time.
The target-dependent code was written using extensions to PL/S, and translated to pure PL/S
with the help of the
ML/1 macro processor
developed by P.J. Brown.
One important lesson from the development of HSK was that any advanced product has to be
developed twice: the first time you discover what you are really trying to do;
the second time you (hopefully) do it right.
The success of HSK was a result of this two-stage process, although the second stage
was not always supported by the management.
My colleagues in the HSK project were:
Olov Hansson, Robert Maddock, Olov Pettersson, Bertil Steinholtz, and Lars Östlund.
In 1975 we received
the IBM’s Outstanding Contribution Award for our work on HSK.
Developing assembler for
IBM Future Systems
(at Vienna Laboratory).
Future Systems was to be a new generation of IBM computers with a totally new architecture
and operating system.
Originally, it was not supposed to have any assembler, but accept programs directly
in a high-level language (PL/I?).
This was the reason for closing down the "Assembler Mission" at Lidingö Laboratory.
As the high-flying ideas came closer to the ground,
I ended up in Vienna using HSK to build an assembler for Future Systems.
Several versions of assembler were produced, but the whole Future Systems effort was abandoned
on the Valentine's Day 1975.
In that period, Vienna Laboratory had neither CRT terminals nor an own computer.
We used typewriter terminals connected by telephone lines to computers in Germany 700 km away.
The printouts (we used large memory dumps for debugging) were transmitted as magnetic tapes
via wideband to IBM Vienna Headquarters, printed there, and delivered to us by car.
A study for PL/I Decompiler.
The Decompiler was supposed to convert S/360 Assembler code to equivalent PL/I code
for porting to new hardware. Discontinued after initial study:
a manual decompilation of selected typical programs has shown a 10-fold increase in program size.
A manual decompilation to the internal language PL/S, on the other hand,
produced a smaller program, due to an excellent optimizing compiler.
Unfortunately, PL/S was top secret.
Developing assembler for a microprocessor (IBM 5090) using the HSK Generator.
Designing parts of an IMS-based internal order-entry and reporting system (at Toronto Laboratory).
Not a very amusing job.
for IBM 8100 (DPPX APL).
IBM 8100 was a "minicomputer" with a modern multiple-user operating system named DPPX,
intended for distributed computing (the "D" in "DPPX").
The APL interpreter was inherited from another project,
and the work consisted of placing it on a new platform, in a multiple-user environment.
My main contributions:
Apparently, the Dijkstra's work on
co-operating sequential processes
did not yet reach the designers of DPPX.
They provided three different sychronizing primitives, but none of them sufficient
for storage management of the multi-user APL.
Annoyed by this fact, I simulated Dijkstra's semaphores within the APL implementation.
- Interface to the operating system, design and implementation.
- Concept of a universal Auxiliary Processor for calling non-APL programs.
- Porting of mathematical subroutines (exponential, log, trigonometric functions)
from FORTRAN and VS/APL.
As APL was originally designed for typewriter terminal,
and you communicated with the 8100 via CRT terminals,
we planned a full-screen editor for the programs.
Kenneth Iverson, the APL's father, who came to review the project, vetoed the idea,
with the argument that "APL is so good that it does not need a full-screen editor".
He authorized me to quote this opinion.
Unfortunately, the 8100 was a bit behind its time.
It looked like a washing machine.
When you opened the front door, you found a large hard disk hanging in place of the usual
The CPU was not much to boast about;
we called the whole thing "a Jaguar powered by rubber string".
By the time 8100 was completed, it could do no more
than a couple of smaller and cheaper
minicomputers that just started making their appearance.
Which means DPPX APL was not much used.
Developing full-screen editor for IBM PLANCODE.
PLANCODE was a predecessor of today’s spreadsheet programs (running on IBM mainframe under MVS).
Originally designed for typewriter terminals, it lacked facilities for full-screen data entry.
The editor partially filled that gap.
Working on new version of Service Level Reporter (SLR).
SLR was a tool developed by Nordic Laboratory
to report utilization and performance of different parts of large computer installations.
It read logs produced by various applications, extracted performance data from them,
and stored the data in a database.
These logs usually had a very complex format.
This format and the processing of data were defined by means of assembler macros.
SLR had a non-SQL relational database, developed by Nordic Laboratory before the appearance of SQL.
It had an internal compiler to produce machine code for frequently repeated operations.
My main contributions:
The overall result of the development was patented (patent nr. B8601973-4,
"Data base processor and its use in a data processing system").
- Enhancing performance of database access.
- Modifying the internal compiler to produce more efficient code.
- Implementing new functions, such as regression analysis and interpolation.
Designing SQL for QUERY.DL/I. QUERY.DL/I was a window-driven system for interactive queries
to IMS databases.
The goal was to extend QUERY.DL/I so that it would also accept queries in an SQL-like language.
It amounted to presenting a relational view of a non-relational database.
My main contributions:
The design was completed, but not implemented.
The project was killed by internal politics.
- Detailed specification of syntax and semantics for the intended language.
- Definition of algorithms for translating the language into DL/I queries.
- Representing the project at the SQL Language Council.
Working on a run-time environment for PL/X.
Experimenting with OO facilities for PL/X using ideas from Objective C.
PL/X (earlier called PL/S) was an internal
IBM language for programming of basic software,
on a slightly higher level than C, but much better.
Unfortunately, it was one of the best guarded company secrets
("so that competitors would not copy our operating system").
If IBM dared to release it then, the world would now use PL/X instead of C.
Developing Log Collector for Enterprise Performance Data Manager (EPDM).
EPDM (later renamed IBM Performance Reporter) was a second-generation
tool to report utilization and performance
of different parts of large computer installations.
The job of Log Collector was
to read logs produced by various applications, extract performance data from them,
and store the result in a database.
The format of the logs, and the processing of data were defined
in an SQL-like language developed for that purpose.
The tool ran on IBM System/390 under VM and IBM RS/6000 under AIX.
It could use DB2, Oracle, or Sybase as database.
My main contributions:
When Nordic Laboratory was closed,
its products were taken over by Tivoli laboratory in Rome.
The mainframe version of Performance Reporter has been widely used under its Tivoli trademark.
- Design of the language.
- Coding of central parts.
- Writing large part of manuals.
- Porting to AIX, Oracle, and Sybase.
The news reached me that EPDM is still alive in 2019.
It is maintained by 21st Century Software under the name IBM Z Decision Support (IZDS).
Subjected to crash education on OS/2,
an operating system developed jointly by IBM and Microsoft for PS/2, the new version of Personal Computer.
The education resulted in the glorious title of
a "certified OS/2 engineer".
Not very useful in view of OS/2 being soon totally eliminated
from the market by Microsoft Windows - originally only a poor copy of OS/2.
The Ericsson Experience 1996-2002
During final disintegration of Nordic Lab, I followed some of my colleagues to
a company called Ericsson Hewlett-Packard Telecom (EHPT),
a joint venture of the two companies identified in the name.
I was followed there by more of my colleagues,
so at the end we were 14 ex-Nordic Lab people at the same place.
The purpose of EHPT was to produce network management software for telecom operators.
As the telecom business went bad,
EHPT was bought out by Ericsson in 2001 and its projects distributed over different
This was followed by a series of reorganizations and massive personnel cuts.
When I reached the compulsory retirement age in 2002, I was glad to leave it all behind me.
Adding a multi-vendor capability to EHPT Performance Manager.
The Performance Manager was a tool for collecting measurement data from a telecom network,
originally designed to work only with Ericsson equipment.
The addition enabled it to collect data also from other equipment.
This project was a futile exercise in the bureaucratic activity that
goes under the name "standard development process".
Two of us worked for 7 months and produced 14 versions of a proposal,
responding to comments and petty requirements of reviewers.
The final implementation took two weeks, and had little to do with the proposals:
there were problems with the existing code, not discovered by the 14 reviews
due to poor documentation.
Starting instead with a prototype (strictly verboten by the "process"!) would give an immediate result.
Developing Aggregation Engine for EHPT Analyzer.
Aggregation Engine was the central part of a new reporting and monitoring tool developed by EHPT.
It was a program that read measurement data from a telecom network and processed it.
The result of the processing could be either stored in a database, or used to detect
abnormal conditions and produce alarms.
The processing was defined in a special language with SQL-like syntax.
The language was compiled with a compiler built with YACC++.
The tool ran under UNIX on Hewlett-Packard and Sun workstations.
The database was Sybase or Oracle.
My main contributions:
In 2002, the whole project was transferred to India.
Thus, for the second time my baby was taken from me to substitute parents,
and I could leave the company without regrets.
- Design and documentation of the language.
- Coding central parts of the Aggregation Engine.
M.Sc. in Mechanical Engineering. Technical University of Warsaw, Poland.
7 months at Computing Machines Laboratory of the University of Manchester,
the Atlas computer,
studying Atlas Supervisor and
developed by the Laboratory together with Ferranti Ltd.,
was one of the most advanced computers at the time.
It was probably the first to implement the concept of virtual storage.)
No formal degree.
Ph.D. (teknisk licentiat) in Computer Science. Technical University of Denmark, Lyngby.
Thesis: The theory of general events and its application to parallel programming.
The main subject was proving correctness of programs for loosely interacting parallel processes,
such as used in operating systems.
The thesis used concepts from automata theory to capture infinite behavior such as
dynamic blocking, and introduced a calculus for analyzing behavior of a system
of parallel processes.
The study was financed by a scholarship from IBM Research Foundation at North Europe Computing Centre.
Latest change 2019-05-26