Artificial Intelligence is often discussed in extremes: either as a revolutionary force that will replace software engineers or as an overhyped technology with little practical value in serious enterprise environments. For HPE NonStop systems, neither position is useful.
NonStop environments are built around stability, predictability, and operational trust. In manufacturing, payments, banking, logistics, and other mission-critical sectors, systems are expected to work continuously, often for decades. TAL, TACL, NonStop COBOL, SQL/MP, TMF, EMS, and Guardian operations are not experimental domains. They are production realities.
This is precisely why AI should be approached pragmatically.
The question is not whether AI can “transform” NonStop. The real question is where AI can reduce operational effort without increasing operational risk.
In our case, the starting point was simple: too much time was being spent searching manuals.
Every experienced NonStop engineer knows this problem. The required information often exists—somewhere—in SQL/MP manuals, TACL references, spooler documentation, EMS guides, TMF references, or subsystem-specific operational documents. The challenge is not the absence of knowledge, but the time required to retrieve it.
That became the practical starting point for AI-based support.
Rather than pursuing abstract automation goals, we focused on three measurable objectives:
- faster code review
- better documentation of legacy applications
- improved operational analysis of EMS events
The result was not autonomous programming. The result was operational acceleration.
Start with the Problem, Not the Tool
Many AI projects fail because they begin with tool selection.
“Which AI platform should we use?” is usually the wrong first question.
The correct starting point is an operational audit:
- Which legacy systems are poorly documented?
- Where do support teams repeatedly lose time?
- Which EMS incidents occur repeatedly?
- Which programs are understood by only one senior specialist?
- Where does third-level support spend most of its analysis time?
In our manufacturing environment, the answer was clear:
TAL-heavy systems and long-lived COBOL applications created a significant review bottleneck. Understanding existing modules often took longer than correcting them.
This is especially common in mature NonStop installations. The code is stable, but institutional knowledge becomes concentrated in a small number of experienced engineers. Retirement risk then becomes a technical risk.
AI is useful here—not because it replaces expertise, but because it helps preserve and distribute it.
That distinction is critical.
AI-Based Programming: Prompt Chains, Not Magic Prompts
One of the first productive use cases was programming support.
Many users begin with prompts such as:
Write a COBOL program.
This usually produces generic results that are technically plausible but operationally unsuitable.
A better approach is prompt chaining.
Example: COBOL with Embedded SQL
Initial request:
Design an SQL table containing the most important customer data and create a COBOL program to maintain this data.
Second step:
File access should be via SQL.
Third step:
Adapt the COBOL program using the syntax described in the HPE NonStop SQL/MP Programming Manual for COBOL.
Final correction:
COMMIT WORK and ROLLBACK WORK are present, but BEGIN WORK is missing.
This last point is important.
This is why AI must be treated as an assistant, not as an authority.
The engineer provides architectural correctness. The AI accelerates structure, syntax preparation, and first-pass generation.
Bad prompt:
Write a COBOL program.
Useful prompt:
Use SQL/MP syntax according to the HPE NonStop SQL/MP Programming Manual and include proper TMF transaction handling.
That difference determines whether AI produces noise or value.
The Biggest Immediate Benefit: Faster Code Review
The strongest operational improvement was not code generation. It was code review.
In legacy TAL and COBOL environments, the first challenge is usually not fixing the code—it is understanding what the code does.
A review of a typical TAL module previously required approximately one hour simply to understand:
- procedure structure
- transaction boundaries
- data dependencies
- operational side effects
- likely failure points
Only after that could meaningful review begin.
Using AI-assisted first-pass analysis, this initial understanding could often be reduced to approximately five minutes.
That is the most important metric.
The AI generated structured summaries of:
- procedure flow
- file access patterns
- SQL dependencies
- transaction handling
- probable risk areas
- interface relationships
Senior engineers could then focus immediately on concurrency risks, correctness, recovery behaviour, and production impact.
This was particularly valuable in third-level support, where rapid understanding of unfamiliar legacy modules directly affects incident resolution time.
That is where AI creates real value.
Ask Your Manuals
Another high-value use case was manual interaction.
Most NonStop organizations possess decades of technical documentation, but manual retrieval is often inefficient.
Examples include:
- SQL/MP Programming Manuals
- SQL/MP Performance and Tuning Guides
- TACL Reference Manuals
- Spooler and Spooler Plus documentation
- TMF operational guides
- EMS references
- security documentation
Instead of manually searching hundreds of pages, engineers can ask structured operational questions.
Examples:
Why should I use the print spooler?
What is the difference between Spooler and Spooler Plus?
Explain SPOOLSTART, SPOOLWRITE, and SPOOLEND
What are the ten most important SQL/MP tuning recommendations?
The manual remains the authority. AI improves accessibility.
This reduces onboarding time significantly and helps younger engineers access knowledge that previously required years of experience to navigate efficiently.
The original trigger—too much time spent searching manuals—was therefore also the first successful AI use case.
Unexpectedly Strong: Security Review
One surprising result was the strength of AI-assisted security review.
Many engineers assume AI is strongest in code generation. In practice, structured security review was often more valuable.
Example:
Read the TACL reference and identify security-relevant control questions.
The result was a highly practical audit framework:
- What is the value of #TACLSECURITY on production admin TACLs?
- What default security applies to newly created files?
- Is #CHANGEUSER allowed?
- Where are OBEY, LOAD, TACLCSTM, and ?TACL files used?
- Is _DO_NOT_PROMPT_TACL_STOP enabled?
- Is REMOTEPASSWORD still in use?
This was unexpectedly strong.
Instead of generic security advice, the output became an audit-ready checklist for real operational meetings.
For compliance reviews and privileged access validation, this saved significant preparation time and improved consistency.
EMS Analysis: Start with History
If a NonStop customer wants to begin practical AI adoption next Monday morning, the recommendation is simple:
Start with EMS history.
This is usually the safest and most immediately valuable entry point.
Operations teams often review large volumes of repeated EMS events:
- spooler messages
- disk subsystem warnings
- TMF aborts
- OSM alarms
- transient Guardian events
The challenge is not receiving the messages. It is identifying patterns and priorities.
In one example, hundreds of EMS events over several hours were grouped into categories and summarized:
- spooler failures caused by offline devices
- disk warnings related to inconsistent DP2 state
- TMF aborts caused by process failures
- OSM alarms indicating probable hardware or software issues
This reduces operator fatigue and improves escalation quality.
AI is especially useful when it converts repetition into operational interpretation.
That is why EMS history is the best first step.
It is concrete, low-risk, and immediately useful.
Governance: The Real Boundary
The most important governance rule was simple:
No production data is allowed outside the company.
This rule matters more than tool selection.
AI adoption in NonStop environments must begin with governance:
- where data is processed
- what data may be exported
- what must remain internal
- who validates outputs
- where human approval is mandatory
This is not optional.
Production-critical environments cannot tolerate uncontrolled experimentation.
Interestingly, the greatest resistance did not come from engineers. It often came from management expectations.
Management frequently expected unrealistic levels of automation—assuming AI would “replace” specialist support rather than support specialists.
That expectation is dangerous.
AI is strongest where understanding is expensive. It is not strongest where accountability is required.
That boundary must remain clear.
Trust Boundary: TMF and Final Decisions
Would I trust AI for production-critical decisions?
Only with strict limits.
For example, AI can be useful in interpreting TMF aborts:
- identifying likely causes
- reconstructing failure sequences
- highlighting recurring operational patterns
But final production decisions must remain with experienced engineers.
No AI should independently decide:
- privilege changes
- recovery strategy
- transaction rollback policy
- production security settings
Interpretation is useful.
Authority must remain human.
That is the correct boundary for mission-critical systems.
Final Observation
AI in HPE NonStop environments is most valuable where understanding is expensive.
Not where marketing expects disruption.
Not where management expects autonomous operations.
But where experienced engineers lose time reconstructing intent from old code, repeated incidents, and fragmented documentation.
That is where the value is immediate.
Faster code review.
Better documentation.
Stronger audit preparation.
Improved EMS interpretation.
Better knowledge transfer.
These are not theoretical benefits. They are operational improvements.
In our case, reducing first-pass TAL understanding from one hour to five minutes was more valuable than any “AI-generated application.”
That is the real lesson.
AI does not replace the NonStop engineer.
It helps the engineer spend time on judgment instead of reconstruction.
And in mission-critical systems, that is exactly where technology should help most.
Be the first to comment