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. 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:3 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 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…

Assembler to get name of current address space

  • Post category:Assembler
  • Reading time:1 min 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 EQUATES SAVE (14,12),,TST/NDG/&SYSDATE/&SYSTIME/ USING ASCBNAME,R12 SET UP BASE ADDRESSABILITY 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 L R1,ASCBJBNS GET ADDRESS ADDRESS SPACE NAME 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 OUTREC DS CL80 ORG OUTREC ADDRSPC DC CL8' ' REST DC CL72' ' OUT DCB DDNAME=OUT, * DSORG=PS, * MACRF=(PM) * IHAASCB DSECT=YES IHAPSA END , 

ABENDIT – simple assembler to create an ABEND

  • Post category:Assembler
  • Reading time:1 min 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. ABENDIT CSECT EQUATES SAVE (14,12),,ABENDIT/OURDEPT/&SYSDATE/&SYSTIME/ USING ABENDIT,R11 SET UP BASE ADDRESSABILITY 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 RETURN EQU * L R13,4(R13) RETURN (14,12) RETURN TO CALLER LTORG SAVE DS 18F END ABENDIT Happy ABENDing!