The Andon Cord

  • Post category:Uncategorized
  • Reading time:2 mins read

Anyone in the product chain can pull the Andon Cord to stop production when he notices that the product’s quality is poor.

The andon cord

Stopping a system when a defect is suspected originates back to Toyota. The idea is that by blocking the system, you get an immediate opportunity for improvement or find a root cause instead of letting the defect move further down the line and be unresolved.

A crucial aspect of Toyota’s “Andon Cord” process was that when the team leader arrived at the workstation, they thanked the team member who pulled the Cord.

The incident would not be a paper report or a long-tail bureaucratic process. The problem would be immediately addressed, and the team member who pulled the cord would fix it.

For software systems, this practice is beneficial as well. However, the opposite process is likely the practice we see in our drive for quick results.

We don’t stop the process in case of issues. We apply a quick fix, and ‘we will resolve it later’.

The person noticing an issue is regarded as a whistle-blower. Issues may get covered in this culture, leading to even more severe problems.

When serious issues occur, we start a bureaucratic process that quickly becomes political, resulting in watered-down solutions and covering up the fundamental problems.

The backward compatibility conundrum

  • Post category:Uncategorized
  • Reading time:5 mins read

In software systems, backward compatibility is a blessing and a curse. While backward compatibility discharges users from mandatory software updates, it is also an excuse to ignore maintenance. For software vendors, omitting backward compatibility is a means to get users to buy new stuff; “enjoy our latest innovations!”.

1980s software on 64-bit hardware

DS Backward compatilibility
DS Backward compatibility

You can not run Windows 95 software on Windows 11.

You can not Run MacOS X software on a PowerBook G4 from 2006.

You can not use Java version 5 software on a Java 11 runtime.

You can, however, run mainframe software compiled in 1980 for 16-bit hardware on the latest z/OS 64-bit operating system and the latest IBM Z hardware. This compatibility is one of the reasons for the success of the IBM mainframe.

Backward compatibility in software has significant benefits. The most significant benefit is that you do not need to change applications with technology upgrades. This saves large amounts of effort and, thus, money for changes that bring no business benefit.

The dangers of backward compatibility

Backward compatibility also has very significant drawbacks:

  • Because you do not need to fix software for technology upgrades, backward compatibility leads to laziness in maintenance. Just because it keeps running, the whole existence of the software is lost out of sight. Development teams lose the knowledge of the functionality and sometimes even the supporting business processes. Minor changes may be made haphazardly, leading to slowly increasing code complexity. Horrific additions are made to applications, using tools like screen scraping, leading to further complexity of the IT landscape. Then, significant changes are suddenly necessary, and you are in big trouble.
  • Backward compatibility hinders innovation. Not only can you not take advantage of modern hardware capabilities, but you also get stuck with programming and interfacing paradigms of the past. You can not exploit functionality trapped inside old programs, and it is tough to integrate through modern technologies like REST APIs.

The problem may be even more significant. Because you do not touch your code, other issues may appear.

Over the years, you will change from source code management tools. During these transitions, code can get lost, or insight into the correct versions of programs gets lost.

Also, compilers are upgraded all the time. And the specifications of the programming languages may change. Consequently, the code you have, which belongs to the programs running in your production environment, can not be compiled any longer. When changes are necessary, your code suddenly needs to catch up with all these changes. And that will make the change a lot riskier.

How to avoid backward compatibility complacency?

Establish a policy to recompile, test, and deploy programs every 2 or 3 years, even if the code needs no functional change. Prevent a pile of technical debt.

Is that a lot of work? It does not need to be. You could automate most, if not all, of the compilation and testing process. If nothing functionally changes, modern test tools can help support this process. With these tools, you can automate running tests, compare results with the expected output, and pinpoint issues.

This process also has a benefit: your recompiled code will run faster because it can use the latest hardware features. You can save money if your software bill is based on CPU consumption.

Don’t let backward compatibility make you backward.

Assembler to get name of current address space

  • Post category:Assembler
  • Reading time:2 mins read

Assembler program that gets the name of the current address space from the PSA’s current ASCB block.

Documentation: PSA description and ASCB description.

ASCBNAME CSECT                                                          
         SAVE  (14,12),,TST/NDG/&SYSDATE/&SYSTIME/               
         LR    R12,R15                 LOAD BASE REG WITH ENTRY POINT   
         LA    R14,SAVE                GET ADDRESS OF REGISTER SAVE     
         ST    R13,4(0,R14)            SAVE CALLER'S SAVE AREA ADDR     
         ST    R14,8(0,R13)            SAVE MY SAVE AREA ADDRESS        
         LR    R13,R14                 LOAD SAVE AREA ADDRESS           
INIT     DS    0H                                                       
         OPEN  (OUT,(OUTPUT))
DOE      DS    0H                                                       
         SR    R1,R1                   R1 = 0
         USING PSA,R1                  ADDRESS PSA
         L     R2,PSAAOLD              GET ADDRESS CURRENT ASCB
         DROP  R1                      RELEASE PSA ADDRESSING
         USING ASCB,R2                 ADDRESS CURRENT ASCB
         DROP  R2                      RELEASE ASCB ADDRESSING
         MVC   ADDRSPC,0(R1)           GET NAME
         PUT   OUT,OUTREC              SCHRIJF                          
RETURN   DS    0H                                                       
         CLOSE OUT                                                      
         SLR   R15,R15                                                  
         L     R13,4(R13)              LOAD CALLERS SAVE AREA ADDRESS   
         RETURN (14,12),RC=(15)        RETURN TO CALLER                 
         DC     C'**********   ************* WERKGEBIED ******'
SAVE     DS    18F
         ORG   OUTREC
REST     DC    CL72' '
OUT      DCB   DDNAME=OUT,                                             *
               DSORG=PS,                                               *
         END   ,                                                        

ABENDIT – simple assembler to create an ABEND

  • Post category:Assembler
  • Reading time:1 mins read

Not sure what I used it for, but here is a simple program in assembler to create an ABEND with a completion code of your choice.

Look here in the IBM manuals for more specifics on the ABEND macro.

         LR    R11,R15                 LOAD BASE REG WITH ENTRY POINT
         LA    R14,SAVE                GET ADDRESS OF REGISTER SAVE
         ST    R13,4(0,R14)            SAVE CALLER'S SAVE AREA ADDR
         ST    R14,8(0,R13)            SAVE MY SAVE AREA ADDRESS
         LR    R13,R14                 LOAD SAVE AREA ADDRESS
*        Business Logic
         ABEND 4321                    4321 or some other code up to 4096
*        Epilogue
         L      R13,4(R13)
         RETURN (14,12)                RETURN TO CALLER
SAVE     DS     18F
         END ABENDIT

Happy ABENDing!


  • Post category:Principles
  • Reading time:2 mins read

The abstraction principle in software systems allows us to create more generically usable software components.

Abstraction removes details from the problem space and thus makes it easier to think about problems and solutions. This principle lets us focus on problems by reducing complexity.

Abstraction makes software components more reusable: code for specific problems is abstracted to code that applies to a broader class of problems.

The process of abstraction, or generalization, removes specific attributes or functions and replaces these with general counterparts. The abstract components can be made specific through parameters or inheritance.

Abstraction is also a modeling technique that allows logical grouping of software structures so they can be better designed, realized, and maintained. Through this grouping, a complex software solution is methodically chopped up into smaller pieces that can be handled better in all phases of a software system lifecycle.

Examples of abstraction in software systems:

The OSI networking model abstracts communication protocols in functional layers.

Messaging middleware solutions abstract the connectivity logic from the application.

Picasso’s bull

Exchange an MVS dataset with Windows

  • Post category:Utilities
  • Reading time:2 mins read

I have discussed in another article how you can convert data from one codepage to another.

Also I have described a method to copy unix files to MVS datasets.

This article summarizes a method to copy an MVS dataset to Windows, while keeping records and converting from ebcdic to the utf8 codepage.

This job copies the MVS dataset to a UNIX files, indicating to keep record indicators with the Windows CR character (UNIX uses the CRLF typically as record / line separators). The dataset below ‘YOUR.TEST.PS’ should be a PS – physical sequential – dataset or a PDS(E) member.

//STEP1    EXEC PGM=BPXBATCH                                         
//STDOUT   DD SYSOUT=*                                               
//STDERR   DD SYSOUT=*                                                
//* Values in STDENV below are kept but have no meaning for this function                                              
//STDENV   DD *                                                      
//STDPARM  DD   *                                                    
SH cp -v -F cr "//'YOUR.TEST.PS'" /your/unixdir/tst.txt 

You can now convert the EBCDIC data to UTF-8 as follows:

iconv -f 37 -t 1208 /your/unixdir/tst.txt  > /your/unixdir/utf8-tst.txt

Now you can transfer the file to Windows. Transfer the file in binary mode, otherwise another unwanted code page conversion will happen.

The myth of zero data loss ransomware recovery

  • Post category:Uncategorized
  • Reading time:3 mins read

My proverbial neighbor asked me some time ago if he could have a zero data loss ransomware recovery solution for his IT shop. He is not a very technical guy, yet responsible for the IT in his department, and he is wise enough to go seek advice on such matters. My man next door could very well be your boss, being provoked by a salesperson from your software vendor.

What is a zero data loss ransomware recovery solution?

A ransomware recovery solution is a tool that provides you the ability to recovery your IT systems from the incident in which a ransomware criminal has encrypted a crucial part of your IT systems. A zero data loss solution promises to provide such a recovery without the loss of any data. The promise of zero data loss must be approached with the necessary skepticism. A zero data loss solution requires you to be able to decrypt the data that your ransomware criminal has encrypted with the keys that he offers to give you for a nice sum of money. To get these keys you have two options:

  1. Pay the criminal and hope he will send you the keys.
  2. Create the keys yourself. This would require some highly advanced algorithm, possibly using a tool based on Quantum computing technology. This is a fantasy of course. This first person to know about the practical application of such technology would be your ransomware criminal himself, and he will have applied this in his encryption tooling.

So getting the keys is not an option, unless you are in the position to save up a lot of money, or find an insurer that will carry your ransomware risk. Although I expect that will come at an excruciating premium.

The next best option is to recover your data from a point in time just before the event of the ransomware attack. This requires a significant investment in advanced backup technology, and complex recovery procedures, while giving you little guarantee as to what state your systems can be recovered. And, setting the expectations, will come with the loss of all data that your ransomware criminal managed to encrypt. We cannot make it more beautiful.

Programming languages and what’s next

  • Post category:Programming
  • Reading time:7 mins read

My review of programming languages I learned in during my years in IT.


On the Texas Instruments TI99-4a. 

Could do everything with it. Especially in combination with PEEK and POKE. Nice for building small games.

Impossible to maintain.

GOTO is unavoidable.


In various variants.

Z80, 6802, PDP 11, System 390.

Fast, furious, unreadable, unmaintainable.

Algol 68

Loved this language. REF!

Have only seen it run on DEC 10. Mainly used in academic environments (in the Netherlands?)?


Well. Structured. Pretty popular in the early 90s. 

Again is this widely adopted?


Old. Never programmed extensively in it – just for year 2000.

Totally Readable.

Funny (rediculous) numbering scheme.

Seems to be necessary to use GOTO in some cases which I do not believe.


Beautiful language.

Should have become the de facto OO programming language but failed for unclear reasons.

Probably because it was way ahead of it’s time with it’s OO base.


Totally nitty gritty programming language.

Productivity based on frameworks, which no one knows which to use.

Never understood why this language was so widely adopted – besides it’s openness and platform independency.

Should never have become the de facto OO programming language but did so because Sun made it open (good move).

Far too many framework needed. J(2)EE add more complexity than it resolves.

Always upgrade issues. (Proud programmer: We run the application in Java! Fed up IT manager: Which Java?)


Can do everything quickly.

But nothing structurally.

Ugly code. Readable but ugly.

Some very very strong concepts.


Hodge podgy language of programming concepts and html.

Likely high programmer productivity if you maintain a stark discipline of programming standards. Stark danger of creating unmaintainable crap code mix of html and php.


Nice structured language.

Difficult to set up and reuse.

Can be productive if nitty gritty setup issues can be overcome.

Ruby (on Rails or off-track)

Nice, probably the most elegant OO language. Too nitty gritty to my taste still. Like it though.

I would start with this language if I had to start today.

What is next

Visual programming? Clicking building blocks together?

In programming we should maybe separate the construction of applications from the coding of functions (or objects, or whatever you call the lower level blocks of code.

Programming complex algorithms (efficiently) will probably always remain a craft for specialists.

Constructing applications from the pieces should be brought to a higher level.

The industry (well – the software selling industry) is looking at microservices but that gives operational issues and becomes too distrubuted.

We need a way to build a house from software bricks and doors and windows and roof elements.

Probably we need more standards for that. 

Another bold statement.

AI systems “programming” themselves is nonsense (I have not seen a shred of evidence). 

AI systems are stochastical systems. 

Programming is imperical.

In summary, up to today you can not build software without getting into the nitty gritty very quickly. 

It’s like building a house but having find your own tree and rocks first to cut wood and blicks from. 

And then contruct nails and screws.

A better approach to that would help.

What do you think is the programming language of the future? What need should it address?

The Internet of Everything – from toilet seats to human bodies

  • Post category:General
  • Reading time:3 mins read

I walked into the restroom. A mechanic stood at the sink fixing something. It saw him holding a toilet seat. He was fooling around with the wiring of the apparatus. Then he replaced some electronics components and rewired the seat.

Toilet sensors

It never occurred to me that even toilets could be usefully equipped with electronic features. I asked the mechanic. He explained that the toilets in the building are all connected to the Internet. If there is something wrong with the antiseptic fluid produced by the toilet, it starts calling out for help. He told me that the towel dispenser was also connected to the Internet, so that when it runs out, a maintenance operator is called in. Makes sense.

Never has technology so much helped improve the The Loo.

To cell sensors

So all things will be supplied with sensors. And it looks like these sensorized things are getting smaller and smaller and a reaching the nano space.

Sensors are gtheetting so small that they can flow through our blood and mend our bodies. And maybe fix cancer cells in the future. Or detect issues with blood vessels. Or measure the chemistry in our bodies. They can be injected in plants to protect themselves from diseases. Or be used in constructions to measure stability at smaller scales than we had ever assumed possible. Possibilities beyond imagination.

Neb sensors surveilling the body 

Imagine what it would mean if we could instrument every cell we like to. I would like a surveillance team of bot swimming through my body, like the Nebuchadnezzar in the Matrix flows through the sewers and tunnels of the abandoned cities.

To signal when my internals run out of supplies.

The Lindy effect and technology

  • Post category:Modernization
  • Reading time:1 mins read

Stuff that has been around for x years, can be expected to be around for another x years.

That is what the Lindy effect tells us.

Read about Lindy in Nassim Taleb’s Skin in the Game.

This informs how we should approach legacy technology: 

  • Maintain it motherly, or
  • Decommission it aggressively

The Lindy effect also informs us how to approach the adoption of new technology: with care.