Agile Scrum, difference between Capacity and Velocity

Agile Scrum, difference between Capacity and Velocity

HPE NonStop Data Definition Language (DDL) dictionary overview and timeline

The HPE NonStop Data Definition Language (DDL) dictionary is a specialized subsystem used to define and manage data objects for Enscribe files and translate those definitions into source code for various programming languages. It serves as a central repository for metadata, ensuring consistent data structures across applications written in C, COBOL, TAL, or TACL. 

Program Summary

The DDL dictionary program functions as a metadata management tool. Key capabilities include: 

  • Centralised Definition: Defines records, fields, and file attributes in a hierarchical structure.
  • Code Generation: Translates DDL definitions into language-specific source code (e.g., COBOL copybooks or C headers).
  • Dictionary Maintenance: Allows users to create, examine, and update dictionaries to reflect changes in data structures.
  • Interoperability: Modern tools like Ddl2Bean convert dictionary files into Java Beans or XML, enabling cross-language and cross-platform use. 

Future Outlook

The future of HPE NonStop DDL focuses on modernisation and integration rather than replacement. 

  • Data Virtualization: Integration with AI factories and object storage platforms to expose legacy metadata in open-table formats like Apache Iceberg.
  • API Centricity: Enhancements to the NonStop API Gateway will likely use DDL metadata to automate REST/JSON service orchestration.
  • Real-time Analytics: Native streaming of NonStop data into platforms like Kafka, using DDL definitions to map real-time changes into analytics-ready formats. 

Internet Links & Manuals

HPE NonStop Data Definition Language (DDL) dictionary overview and timeline

HPE NonStop PATHCOM, interactive management interface, Pathway transaction processing environment

HPE NonStop PATHCOM is the interactive management interface for the Pathway transaction processing environment. It allows administrators to configure, monitor, and control PATHMON-governed objects such as serverclasses, TCPs (Terminal Control Processes), and links. 

Historical Timeline: The Evolution of Pathway & PATHCOM

The history of PATHCOM is inseparable from the Tandem NonStop platform, which pioneered fault-tolerant Online Transaction Processing (OLTP). 

The Tandem Era (1974 – 1997) 

  • 1974 – 1976: Tandem Computers is founded. The first NonStop I system ships in 1976.
  • 1983: Tandem introduces Pathway software alongside the Transaction Monitoring Facility (TMF). This milestone removes the requirement for developers to manually code fault tolerance into applications, as the Pathway infrastructure (managed via PATHCOM) handles it automatically.
  • Early 1990s: The platform migrates from proprietary stack machines to MIPS RISC processors (TNS/R architecture). PATHCOM evolves to manage more complex distributed environments.
  • 1994Open System Services (OSS) is introduced, allowing NonStop to support a Unix-like POSIX environment. 

The Compaq & Early HP Era (1997 – 2014) 

  • 1997Compaq acquires Tandem.
  • 2002HP merges with Compaq.
  • 2005: Migration from MIPS to Intel Itanium (Integrity NonStop) begins.
  • 2010s: Pathway evolves into HPE NonStop Pathway with TS/MP (Transaction Services/Massive Parallelism), enabling near-linear scalability for massive OLTP workloads. 

The Modern HPE Era (2014 – Present)

  • 2014NonStop X is introduced, migrating the architecture to Intel x86-64 processors.
  • 2015: Hewlett-Packard splits; the platform continues under Hewlett Packard Enterprise (HPE).
  • 2020 – 2024: Focus shifts toward virtualisation and hybrid cloud. Modern Pathway/TS environments now support massive scaling up to 24,480 cores in a single system image.
Summary of PATHCOM Functionality

Future of NonStop Pathway

HPE’s roadmap for NonStop focuses on integrating mission-critical reliability with modern data centre technologies:

  • Modernisation: Support for Kubernetes Helm deployments and cloud-native frameworks.
  • Hardware Advancements: New NS9 X5 and NS5 X5 platforms offer double the memory capacity and 2x faster system interconnects.
  • Open Integration: Continued emphasis on open application development environments and open-source frameworks.
  • Hybrid Cloud: Positioning NonStop as a key component of HPE GreenLake for mission-critical workloads in the cloud.

HPE NonStop PATHCOM, interactive management interface, Pathway transaction processing environment

HPE NonStop Spoolcom subsystem Spooler Command Language program Overview and Timeline

The HPE NonStop Spoolcom (Spooler Command Language) program is the administrative interface for managing the Spooler subsystem on HPE NonStop systems. It allows operators to configure, monitor, and control print jobs, collectors, and print processes. 

Program Summary

  • Purpose: Used to define and manage spooler objects such as collectors, devices, and jobs.
  • Key Functions: Starting/stopping the spooler, modifying device attributes, and controlling job states (e.g., hold, release, delete).
  • Architecture: Operates within the Guardian environment, communicating with the Spooler supervisor process to maintain 24/7 fault-tolerant printing operations. 

Historical Timeline by Era

1. The Tandem Era (1974–1997) 

  • 1976: Introduction of the Tandem NonStop system; basic spooling capabilities were essential for early OLTP (Online Transaction Processing).
  • 1980s: The Spooler evolved to handle complex routing and multiple collectors to support growing enterprise needs.
  • 1997: Spooler D41 released, providing stable management for the MIPS-based architecture. 

2. The Compaq & Early HP Era (1997–2014)

  • 1999–2000: Release of Spooler D46, enhancing device ownership and virtual device support.
  • 2001–2002: Spooler D48 released during the transition to the HP Integrity NonStop (Itanium) platform.
  • 2012: Major updates to Spooler D48 to support H01 and H02 RVUs, improving scalability for high-end systems. 

3. The Modern HPE Era (2014–Present)

  • 2014NonStop X (x86-64) introduced. Spoolcom adapted to support the new architecture and virtualised environments.
  • 2018–2020: Focus shifted toward modernised interfaces. While Spoolcom remains the CLI standard, graphical alternatives like MultiBatch began gaining traction for batch management.
  • 2023–2024: Continued integration with HPE GreenLake and hybrid cloud models, ensuring spooling services are available in private cloud deployments. 

Futures and Roadmap

  • Modernisation: HPE is pushing toward “modernisation through tradition,” which includes better integration of legacy tools like Spoolcom with modern DevSecOps and cloud-native frameworks.
  • Kernel-Level Threading (KLT): Future updates aim to leverage KLT to improve the performance and scale-up capabilities of management processes.
  • Data-Centric Security: Integration with security platforms like TAMUNIO for field-level tokenization ensures that printed data remains compliant with PCI DSS 4.0 and GDPR. 

Useful Resources

HPE NonStop Spoolcom subsystem Spooler Command Language program – Overview and Timeline

HPE NonStop Inspect debugger Overview and timeline by year

HPE NonStop Inspect is the primary symbolic, source-level debugger for applications running on the HPE NonStop (formerly Tandem) operating system. It allows developers to interactively control program execution, examine and change data variables, and debug complex multi-process applications in both the Guardian and Open System Services (OSS) environments. 

Program Summary

The Inspect debugger family facilitates high-availability software development through several specialized versions: 

  • Inspect (Legacy): A command-line tool for TNS, TNS/R, and TNS/E systems.
  • Native Inspect (eInspect/xInspect): Adapted from GDB for Itanium and x86 architectures; it provides a command-line interface with scripting capabilities.
  • Visual Inspect: A Windows-hosted GUI debugger that provides “point-and-click” efficiency for setting breakpoints and displaying variables.
  • NSDEE (Eclipse): Modern debugging integrated into the Eclipse-based development environment, supporting NonStop Application, Attach Process, and Snapshot debug configurations. 

Historic Timeline by Era

The evolution of the NonStop debugger mirrors the platform’s hardware transitions over five decades.

The Tandem Era (1974 – 1997) 

  • 1974: Tandem Computers is founded; the platform begins with T/16 (NonStop I).
  • 1980s: Inspect is introduced as the standard interactive debugger for the TNS (Tandem Network Strategy) CISC architecture.
  • Early 1990s: Migration to MIPS-based TNS/R systems; Inspect is updated to support RISC instruction sets and optimized compilers. 

The Compaq & Early HP Era (1997 – 2014)

  • 1997: Compaq acquires Tandem.
  • 2002: HP acquires Compaq; migration to TNS/E (Intel Itanium) architecture begins.
  • 2005 – 2010: Visual Inspect becomes a staple for developers seeking a GUI experience on Windows.
  • 2013: Release of the Inspect H01 Manual, documenting full support for TNS/R and TNS/E concurrent debugging. 

The Modern HPE Era (2014 – Present)

  • 2014: Introduction of NonStop X (x86-64 architecture). Native Inspect (xInspect) is launched, based on GDB, to support the move away from Itanium.
  • 2015: HPE is formed; focus shifts to the NonStop Development Environment for Eclipse (NSDEE).
  • 2020 – 2024: Enhancements in NSDEE include improved OSS process handling and support for large-scale application debugging.
  • 2025: HPE celebrates 50 years of NonStop; updates to the OS introduce greater development and debugging flexibility for named processes on NS5 X5 and NS9 X5 platforms

Future Outlook

HPE’s roadmap for NonStop focuses on modernisation through tradition, ensuring that legacy tools like Inspect remain compatible while transitioning to cloud-native and virtualized environments. 

  • Virtualized NonStop (vNS): Debugging tools are being adapted to work seamlessly within enterprise private clouds and HPE GreenLake consumption models.
  • AI Integration: Future enhancements likely include AI-driven diagnostics and automation within the debugger infrastructure to manage the complexity of modern REST/JSON API gateways and Kafka messaging buses.

HPE NonStop Inspect debugger Overview and timeline by year

Jackson Structured Programming JSP is a program design methodology, overview and timeline

Jackson Structured Programming (JSP) is a program design methodology developed by British software consultant Michael A. Jackson in the 1970s. It focuses on mapping the structure of a problem—specifically its data structures—directly onto the structure of the program used to solve it. 

Overview of Jackson Structured Programming

JSP is designed to create programs that are easy to maintain and modify because the program’s control structure naturally handles the input and output data structures. 

  • Core Principle: Requirement changes are typically minor tweaks to existing data structures. By aligning program structure with data structure, small changes to inputs or outputs translate into small, manageable changes in the code.
  • Methodology: The technique involves analyzing the structure of input files and output files, constructing diagrammatic representations of these, and then creating a program structure that handles both.
  • Key Constructs: JSP utilizes three basic structures for both data and programs, which can be visualized as a form of regular expression:
    • Sequence: A series of operations performed in order.
    • Iteration: The repetition of operations until a specific condition is met.
    • Selection: Choosing between different operations based on a condition.
  • Diagrams: JSP uses structure diagrams rather than flowcharts to represent the design, breaking down complex tasks into smaller, simpler parts. 
Excerpts from my HND project which made use of Jackson Structured Programming (JSP) as part of the program design phase

Detailed Historical Timeline

Early Years (1960s–1974): Conceptualization and Founding

  • 1960s: Michael A. Jackson works in data processing, encountering limitations in program reliability and seeking more systematic approaches to software design.
  • 1968: Jackson contributes to the early modular programming movement, collaborating with other pioneers.
  • 1970: Jackson leaves John Hoskyns & Company to found Michael Jackson Systems Limited, aimed at fully developing a new design methodology.
  • 1971: JSP becomes the core product of Michael Jackson Systems Limited, offering consultancy and training services.
  • 1974: The name “Jackson Structured Programming” is coined by a Swedish licensee of the company.

Established Method (1975–1979): Documentation and Adoption

  • 1975: Jackson publishes “Principles of Program Design,” the definitive text documenting JSP.
  • 1975: Michael Jackson Systems Ltd. begins offering software tools to support JSP design for COBOL programs.
  • 1977: JSP is widely recognized and adopted in Europe, the US, and Asia.
  • Late 1970s: The UK government adopts JSP (under the name “SDM” – System Development Methodology) as its standard program design method.
  • Late 1970s: The World Health Organization adopts JSP as a standard for program specification. 

Evolution into System Design (1980s): JSD

  • Early 1980s: Building on the principles of JSP, Jackson develops Jackson System Development (JSD) to address the design of entire information systems, not just individual programs.
  • 1983: Jackson publishes “System Development,” formally introducing JSD.
  • 1983-1989: JSD continues to evolve, with new features introduced in subsequent publications and manuals. 

Maturity and Retrospective (1990s–Present)

  • 1990s: Jackson develops the Problem Frames Approach, his third major methodology focusing on requirements analysis.
  • 1997: Jackson receives the Stevens Award for Software Development Methods.
  • 1998: Jackson receives the British Computer Society Lovelace Medal.
  • 2001: At a conference, Jackson provides a retrospective analysis of JSP’s driving forces and its relevance to modern software engineering.
  • Present: While overshadowed by object-oriented and agile methods, JSP principles remain useful for programming “in the small” and handling specific batch processing or embedded software tasks.

Jackson Structured Programming JSP is a program design methodology, overview and timeline

Stakeholder Requirements and Clarifying what is required

Stakeholder Requirements and Clarifying what is required

Daily Planning for Agile Scrum Teams on a page

Daily Planning for Agile Scrum Teams on a page