Blog › ICP guides

LANSA developer on retainer: RDML FETCH FOR UPDATE lock not released, RDML developer, IBM i LANSA developer on monthly retainer

October 9, 2026 · ~15 min read

A LANSA developer was maintaining a wholesale building materials distributor’s order entry application running LANSA 14 on IBM i. The application had 40 operator terminals, each staffed by a warehouse sales operator taking telephone and counter orders throughout the working day. The core of the application was the OrderEntry RDML function, which issued FETCH CUSTOMERS WHERE CUSTNO = #WCUSTNO FOR UPDATE to retrieve a customer record for credit limit validation before committing an order to the ORDERPRD library on the IBM i. When the proposed order total exceeded the customer’s remaining credit — calculated as credit limit minus outstanding receivables — the validation sub-routine issued CONTINUE, returning control to the order entry screen for the operator to inform the customer and begin a new entry, without issuing ROLLBACK WORK. The IBM i exclusive record lock acquired by FETCH ... FOR UPDATE on the CUSTOMERS physical file was therefore held on those CUSTOMERS records for the duration of the operator’s session. Three operators whose customers failed the credit validation check during a single morning shift held exclusive locks on three separate CUSTOMERS records. Any other operator attempting to FETCH one of those three locked CUSTOMERS records received IBM i escape message CPF5027: “Record 3 of member CUSTOMERS in file CUSTOMERS in library ORDERPRD is locked by job 281874/QUSER/ORDERENT.” Concurrent lock errors recorded per morning shift before the fix: 3. After adding ROLLBACK WORK before CONTINUE on the credit validation failure branch: 0.

The root cause was IBM i commitment control lock semantics and how they interact with RDML’s flow-control statements. When LANSA RDML issues FETCH ... FOR UPDATE, IBM i’s DB2 for i places an exclusive row-level lock on the physical file record within the current commitment control scope. The commitment control scope is established by STRCMTCTL (Start Commitment Control) — either issued explicitly in the LANSA job or inherited from the LANSA activation group that runs RDML programs on the IBM i. The lock on that record is held until one of exactly three events occurs: COMMIT WORK (commits all pending changes to the physical files and releases all commitment control locks); ROLLBACK WORK (discards all uncommitted changes and releases all commitment control locks); or the job ends (an implicit rollback, which releases all locks at session termination). CONTINUE within an RDML LOOP is a pure flow-control statement: it exits the current loop iteration and returns control to the top of the loop or to the next statement after the loop. It has no interaction with the DB2 for i commitment control scope. It does not issue a commit. It does not issue a rollback. The lock on the CUSTOMERS record that was acquired by FETCH ... FOR UPDATE remains held in the same commitment control scope, silently, for as long as the job runs. The developer who originally wrote and tested the OrderEntry function did all testing with a single terminal and always completed the test session by entering at least one valid order that reached COMMIT WORK — releasing all accumulated locks, including any from earlier credit-validation failures in the same session. In production with 40 concurrent terminals, operators frequently hit multiple credit-limit failures in a row during busy periods, or break for lunch mid-session with the terminal left in the order entry screen, holding locked CUSTOMERS records for the full session duration of several hours.

The invisibility of this bug operates at precisely two levels, and both levels are structurally unreachable by standard single-terminal development testing. First, the operator whose session holds the lock never sees any error message. After CONTINUE executes on the credit validation failure branch, the OrderEntry function returns the operator to the order entry DISPLAY_SCREEN normally: the 5250 green-screen terminal clears the entry fields, positions the cursor on the customer number input field, and awaits the next customer number. There is no message in the operator message queue. There is no IBM i system message. There is no LANSA function error. The lock on CUSTOMERS record 3 is entirely invisible to the operator who holds it; they proceed to enter the next order without any awareness that their session has accumulated an exclusive lock that is now blocking access to that customer record for every other operator on the system. Second, the operator who attempts to access the locked record does receive an error — CPF5027 — but this IBM i escape message surfaces inside the LANSA application not as a distinctive “record locked by another job” dialog, but as a generic LANSA function error that returns the operator to the customer inquiry screen. The receiving operator sees a function error, assumes a transient system issue, tries again, and if the lock-holding session is still active (which it is, as the operator went to lunch), receives the same error again. The source of the lock — the credit-validation CONTINUE branch in OrderEntry — is never identified without IBM i WRKOBJLCK diagnosis on the production system. Without that diagnosis, the pattern reads as a mysterious intermittent LANSA function error that resolves itself unpredictably, which is exactly what happens when the lock-holding operator returns from lunch and either completes a successful order (triggering COMMIT WORK and releasing all held locks) or logs out of the system (triggering the implicit job-end rollback). The error correlates with nothing the receiving operators can observe.

LANSA and RDML: IBM i 4GL from Sydney to the global AS/400 installed base

LANSA Pty Ltd was founded in Sydney, Australia in the mid-1980s, initially developing its 4GL toolset for the IBM System/38 — the predecessor architecture to the AS/400 (announced 1988), which subsequently became the iSeries and then IBM i. LANSA entered a market where the dominant development approaches for System/38 and early AS/400 were RPG/400 (IBM’s native record-level-access language for the platform, powerful but requiring field-by-field physical file definitions in every program) and Synon/2E (later Cool:2E after acquisition by Computer Associates), a model-driven development tool that generated RPG/400 source from an entity-relationship model. LANSA’s distinctive architectural contribution was its central Repository, known as the LANSA Repository or LANSA Data Dictionary. Instead of each program defining its own file access specifications and field attributes, all field definitions, validation rules, reference files (lookup tables), and business logic were stored once in the LANSA Repository and applied globally to every RDML program that referenced those fields. A field like CUSTNO (customer number) would be defined once in the Repository with its length, type, heading, validation rules, and reference file lookup; every RDML function that displayed, fetched, or updated CUSTNO automatically applied those definitions without the developer re-specifying them. This Repository-centricity meant that a change to a field definition — extending CUSTNO from 7 to 8 digits, for example — propagated automatically to all RDML programs on the next Repository-driven recompile, rather than requiring a search-and-replace across hundreds of individual RPG source members.

The RDML language (Repository Data Manipulation Language) is LANSA’s procedural 4GL for IBM i-hosted application development. RDML programs use DISPLAY_SCREEN to define and present 5250 green-screen terminal panels to operators; the screen layout, field headings, and input validation are driven by the Repository field definitions. Database access uses English-like verbs: FETCH reads one or more records from a DB2 for i physical file; INSERT adds a new record; CHANGE updates a fetched record; DELETE removes a record; SELECT opens a cursor over a result set. Flow control uses LOOP / ENDLOOP for iteration, CONTINUE to skip to the next iteration, EXIT to leave a loop, IF / ELSE / ENDIF for branching, and CALL for sub-procedures and external program calls. RDML source is compiled by the LANSA compiler into ILE RPG source on the IBM i, which is then compiled by the IBM i ILE RPG compiler into native machine code. This compilation chain means RDML programs run at native IBM i performance levels, not as interpreted scripts. LANSA later introduced RDMLX (RDML eXtended), which added object-oriented features to RDML — classes, properties, methods, events, and inheritance — enabling multi-tier application development beyond 5250 green-screen. Development is performed using the VL IDE (Visual LANSA Integrated Development Environment), a Windows application that connects to the IBM i-hosted LANSA Repository over TCP/IP, presenting the Repository objects, RDML source members, and screen layout design tools in a Windows GUI.

LANSA’s role in the AS/400 and IBM i ecosystem today is defined by the extraordinary longevity of the IBM i installed base. IBM i (the operating system) runs on IBM POWER hardware and continues to be actively developed and sold by IBM; IBM i 7.5, released in 2022, is the current version, and IBM i 7.4 remains in extended support. Industries including banking, insurance, manufacturing, distribution, utilities, and government run production workloads on IBM i that have been in continuous operation since the AS/400 era of the 1990s and early 2000s. LANSA applications built in that era — order entry systems, inventory management systems, accounts receivable and payable systems, manufacturing scheduling systems — are still active production workhorses. The internal IBM i and LANSA developer community has aged and contracted significantly; most IBM i shops today lack an in-house LANSA developer and rely on retainer consultants who know the RDML language, the LANSA Repository architecture, and IBM i system administration. LANSA 14 is the current major version, maintained by LANSA Pty Ltd (now part of Broadcom Inc. following the 2023 acquisition of the CA Technologies portfolio). LANSA 14 also offers a Web Application Framework that enables web UI construction on top of RDML business logic, providing a migration path from 5250 green-screen interfaces to browser-based UIs without rewriting the underlying RDML business logic or the LANSA Repository definitions.

The IBM i commitment control model that governs LANSA record locking is a formal transaction management system directly analogous to SQL transaction semantics. IBM i’s DB2 for i uses commitment control, governed by the STRCMTCTL (Start Commitment Control) command, which establishes a commitment control scope for a job with a specified isolation level. The *CHG (Change) isolation level holds exclusive locks on records that have been changed (updated or inserted) until an explicit COMMIT WORK or ROLLBACK WORK is issued; it does not hold locks on records that were only read without update intent. The *CS (Cursor Stability) isolation level holds update locks on records fetched FOR UPDATE until commit or rollback; it releases read-only locks after the cursor advances. Both isolation levels share the critical behavior that governs the OrderEntry lock bug: FETCH ... FOR UPDATE acquires an exclusive update lock (UPDLCK) on the fetched record, and that lock is held in the commitment control scope until COMMIT WORK releases it along with all other pending changes, or ROLLBACK WORK releases it along with all uncommitted changes, or the job ends and the system performs an implicit rollback. A CONTINUE statement in RDML, no matter how many times it executes or how many loop iterations it traverses, has no effect on the commitment control scope. The locks accumulate silently in the job’s commitment control scope, invisible to the job’s operator, blocking all other jobs that attempt to acquire any lock on the same records.

IBM i commitment control and RDML FETCH FOR UPDATE lock semantics

The precise lock model for RDML FETCH ... FOR UPDATE is grounded in DB2 for i’s row-level locking architecture. When LANSA RDML compiles FETCH CUSTOMERS WHERE CUSTNO = #WCUSTNO FOR UPDATE to ILE RPG, the generated ILE RPG code issues a READ with an update lock to the CUSTOMERS physical file member using the ILE RPG READE or CHAIN operation code with the record lock indicator active. DB2 for i then places an exclusive row-level lock (lock type EXCL, also referred to as an update lock or UPDLCK in IBM i lock terminology) on the specific CUSTOMERS record for customer number #WCUSTNO. This lock is held within the commitment control scope that is active for the LANSA job — established by STRCMTCTL at job activation, inherited by the RDML function’s ILE activation group. The exclusive nature of the lock means that no other job can acquire any conflicting lock on the same record: not a read lock, not an update lock, not a delete lock. Any other job attempting FETCH CUSTOMERS WHERE CUSTNO = #WCUSTNO — with or without FOR UPDATE — will either wait for the lock to be released (if the IBM i file is opened with a lock wait timeout, typically 60 seconds) or immediately receive CPF5027 as an escape message (if the file is opened with no-wait locking). COMMIT WORK releases all locks held in the commitment control scope and writes all uncommitted changes to the physical files permanently. ROLLBACK WORK releases all locks held in the commitment control scope and discards all uncommitted changes — the physical files are restored to their pre-transaction state. CONTINUE in an RDML LOOP is a flow-control statement with no database semantics whatsoever: it transfers execution to the next loop iteration, leaving the commitment control scope — and every lock held within it — completely undisturbed.

Diagnosing an active RDML FETCH FOR UPDATE lock accumulation on a production IBM i system requires two IBM i commands. The first is WRKOBJLCK OBJ(ORDERPRD/CUSTOMERS) OBJTYPE(*FILE), which displays all jobs currently holding locks on the CUSTOMERS physical file in the ORDERPRD library. The output shows, for each locking job: the job name (in the format jobnumber/username/jobname, e.g., 281874/QUSER/ORDERENT), the lock type (EXCL for exclusive, SHR for shared), and the lock state (LCKSTS *HLD means the lock is currently held, as opposed to *RQS for requested and waiting). In the OrderEntry scenario, WRKOBJLCK shows three ORDERENT jobs holding EXCL locks on the CUSTOMERS file with LCKSTS *HLD. The second command is WRKJOB on each lock-holding job (option 12, Work with Locks), which shows all DB2 for i locks held by that specific job — confirming that the lock is on CUSTOMERS record 3 (the specific record for that customer number) and that the lock is held in the commitment control scope, not as an object-level lock. Additional diagnostic commands that inform the picture: DSPJOB option 14 (Display Open Files) shows all files open in the job with their access intent; WRKSPLF on the holding job shows any spooled output from the session; DSPJOBLOG on the holding job shows the complete job log including any messages generated by the RDML function during the credit-validation path. If the lock must be released immediately to unblock production without waiting for the holding operator to return, ENDJOBABN (End Job Abnormally) on the holding job releases all commitment control locks and terminates the session — the operator will need to restart their LANSA session and re-enter any work in progress. ENDJOBABN should only be used after confirming, via the job log, that no active order is in a partially committed state in the holding session.

The fix for the RDML FETCH FOR UPDATE lock accumulation pattern is architecturally simple but must be applied comprehensively to be effective. ROLLBACK WORK must be added on every failure branch that exits the transaction scope without committing — not only the credit validation failure branch that was identified as the immediate cause, but every validation failure path, every user-cancel path (the operator pressing F3 or F12 to abandon the order entry), and every error handler that exits on any LANSA function error. In the OrderEntry function specifically, this means: the credit validation failure branch (IF #ORDERTOTAL GT #WCRLIMIT; ROLLBACK WORK; CONTINUE); the order total calculation error branch; the inventory availability check failure branch if it also issues CONTINUE; the F3/F12 user-cancel handler; and any TRAP_EXCEPTION or ERROR_HANDLER construct in the function. LANSA’s TRAP_EXCEPTION and ERROR_HANDLER constructs intercept IBM i escape messages raised during RDML execution — including CPF5027 itself, which would be raised if the OrderEntry function tried to FETCH a record already locked by another ORDERENT session. An ERROR_HANDLER that simply re-displays the entry screen and continues without ROLLBACK WORK will accumulate a failed-lock attempt in the commitment control scope. The complete audit protocol for an RDML function is: list every FETCH ... FOR UPDATE and every CHANGE verb (which also acquires an update lock on the record it modifies); trace every possible exit path from each of those statements; confirm that every exit path reaches either COMMIT WORK or ROLLBACK WORK before the function terminates or returns control to the caller. Any path that does neither is a lock accumulation vector.

Typical LANSA developer retainer work and what it looks like in a work log

RDML FETCH FOR UPDATE lock not released on the validation failure CONTINUE branch is the canonical invisible LANSA production bug. The pattern is consistent across LANSA order entry and data maintenance applications: the OrderEntry RDML function issues FETCH CUSTOMERS WHERE CUSTNO = #WCUSTNO FOR UPDATE to acquire an exclusive lock for credit validation; the credit validation sub-routine finds #ORDERTOTAL GT #WCRLIMIT and executes CONTINUE without ROLLBACK WORK; the IBM i commitment control scope retains the EXCL lock on that CUSTOMERS record for the full operator session; three such sessions accumulate three locked CUSTOMERS records by mid-morning; a fourth operator attempting to enter an order for one of those customers receives CPF5027 and a generic LANSA function error; the receiving operator cannot identify the cause; the IT helpdesk logs it as “intermittent LANSA error on order entry.” A HourTab work log entry for this investigation: “OrderEntry RDML function (ORDERPRD library, LANSA 14); FETCH CUSTOMERS WHERE CUSTNO = #WCUSTNO FOR UPDATE for credit validation; credit validation failure branch issued CONTINUE without ROLLBACK WORK; WRKOBJLCK OBJ(ORDERPRD/CUSTOMERS) OBJTYPE(*FILE) identified 3 ORDERENT jobs holding EXCL locks LCKSTS *HLD; WRKJOB on each job confirmed operator sessions on credit-validation CONTINUE path; CPF5027 received by concurrent operators attempting FETCH on those CUSTOMERS records; lock count per morning shift: 3 before fix, 0 after fix; fix: ROLLBACK WORK added before CONTINUE on credit validation failure branch; audit of all FETCH FOR UPDATE and CHANGE paths in OrderEntry completed; ROLLBACK WORK added on F3/F12 cancel handler and TRAP_EXCEPTION exit paths; 4h.”

LANSA Repository maintenance is the steady-state work that occupies the majority of hours on most LANSA retainer engagements. A Repository maintenance task might be triggered by a business requirement change: the company acquires a new division and needs to extend the CUSTNO (customer number) field from 7 to 8 digits. In the LANSA Repository, the CUSTNO field definition is updated in the LANSA Data Dictionary: field length changed from 7 to 8, all associated validation rules and screen heading updated. The LANSA Repository then identifies all RDML functions that reference CUSTNO — potentially dozens across the order entry, accounts receivable, customer inquiry, and credit management function groups. Each affected RDML function must be recompiled from the Repository to regenerate its ILE RPG source with the new field specification. The mass recompile is triggered through the VL IDE on Windows, connected to the IBM i Repository over TCP/IP; the recompile job runs on the IBM i and writes a compilation report to the VL IDE. After recompile, every affected 5250 screen layout must be regression-tested: DISPLAY_SCREEN panels that displayed a 7-digit customer number field must now correctly display and accept 8-digit values without field truncation or overlay. A HourTab work log entry for this work: “LANSA Repository field definition update: CUSTNO field (customer number); change: max length 7 to 8 digits; affected RDML functions identified via Repository cross-reference: 12 functions across ORDENTRY, CUSTMAINT, ARAGING, CREDITCHK function groups; mass recompile triggered via VL IDE, compilation report reviewed, 0 compile errors; 5250 screen layout regression test on OrderEntry, CustomerMaintenance, ARAgingInquiry: all CUSTNO fields display and accept 8-digit values correctly; LANSA Repository updated and all 12 affected functions recompiled and tested; 3h.”

LANSA Web Application Framework migration is the largest-scope LANSA retainer engagement category, typically measured in weeks or months of effort rather than hours. A wholesale distributor running 40 operator terminals on 5250 green-screen LANSA applications faces a strategic modernization decision: the terminals are increasingly difficult to source, operators prefer browser-based interfaces, and management wants visibility into order status from outside the IBM i session environment. LANSA’s Web Application Framework (WAF) provides a migration path: RDML functions’ business logic (the FETCH, CHANGE, INSERT, COMMIT WORK, ROLLBACK WORK sequences) can be retained on the IBM i, while the presentation layer migrates from 5250 DISPLAY_SCREEN panels to LANSA WAF web components rendered in a browser. The retainer developer scopes the migration by inventorying: total RDML function count in the application; DISPLAY_SCREEN panel count and layout complexity; FETCH FOR UPDATE patterns that require commitment control (these carry forward to the web layer with the same ROLLBACK WORK requirements on every failure branch); CALL statements to external IBM i programs or service programs; and any hardcoded 5250 screen formatting logic that does not map cleanly to web components. A HourTab work log entry: “LANSA WAF migration scoping for order entry application; LANSA 14 on IBM i 7.4; OrderEntry, CustomerMaintenance, ARAgingInquiry, CreditCheck function groups; 34 RDML functions, 78 DISPLAY_SCREEN panels, 12 FETCH FOR UPDATE patterns (all audited for ROLLBACK WORK on failure branches — 2 additional missing ROLLBACK WORK found during scoping audit, fixed); 8 CALL statements to external IBM i programs requiring API wrapper; estimated migration: 180h; scoping report delivered; 6h.”

How HourTab tracks LANSA developer retainer hours

RDML FETCH FOR UPDATE lock bugs are invisible in development by exactly the same structural mechanism that makes all commitment control lock accumulation bugs invisible in single-terminal testing. With one operator terminal, the only session in the commitment control scope is the developer’s own test session. A test session that hits the credit validation failure branch and executes CONTINUE without ROLLBACK WORK has accumulated a lock — but only on one CUSTOMERS record, held by the only active LANSA job. The developer’s next test cycle enters a valid order that reaches COMMIT WORK, releasing the accumulated lock along with all pending changes. No CPF5027 is ever generated because there is no second job attempting to acquire a lock on the same record. The test session demonstrates the credit validation failure path correctly (the operator sees the entry screen, the order is not committed, the validation logic fires), but the lock accumulation side effect is never observable. In production, with 40 concurrent operator terminals, the probability of three operators hitting credit validation failures within the same shift — without any of them subsequently completing a successful order or logging out — is not low. The three locked CUSTOMERS records will remain locked for however long those three sessions remain active. The receiving operators’ CPF5027 errors will recur with every attempt on those customers until the holding sessions release their locks. The IT helpdesk will log several “intermittent LANSA error on order entry” tickets before any diagnosis reaches WRKOBJLCK.

The work log must name the mechanism precisely to be auditable and defensible. For the OrderEntry RDML FETCH FOR UPDATE lock investigation: the RDML function (OrderEntry, ORDERPRD library, LANSA 14 on IBM i 7.4); the FETCH statement (FETCH CUSTOMERS WHERE CUSTNO = #WCUSTNO FOR UPDATE); the failure branch (credit validation sub-routine: IF #ORDERTOTAL GT #WCRLIMIT, CONTINUE issued without ROLLBACK WORK); the diagnosis commands (WRKOBJLCK OBJ(ORDERPRD/CUSTOMERS) OBJTYPE(*FILE) showing 3 ORDERENT jobs holding EXCL locks LCKSTS *HLD; WRKJOB option 12 on each job confirming commitment control locks on CUSTOMERS records 3, 7, and 19); the CPF5027 message text received by concurrent operators (“Record 3 of member CUSTOMERS in file CUSTOMERS in library ORDERPRD is locked by job 281874/QUSER/ORDERENT”); the lock count per morning shift before fix (3); the lock count after fix (0); and the fix (ROLLBACK WORK added before CONTINUE on the credit validation failure branch; all other failure branches and TRAP_EXCEPTION exit paths in OrderEntry audited and ROLLBACK WORK added on every path that exits without committing); hours (4h). A work log entry that says “fixed record lock issue in order entry, 4h” is not auditable. An entry that names the function, the FETCH path, the WRKOBJLCK diagnosis, the CPF5027 message, and the lock counts is auditable and defensible to the distributor’s IT manager, warehouse operations director, and any subsequent LANSA developer who maintains the function.

Comparative context: the RDML FETCH FOR UPDATE lock not released on failure branch is structurally identical to lock-not-released bugs in other IBM i and non-IBM i platforms where a 4GL or procedural language issues a record-lock acquisition and the failure path does not release it. Progress 4GL developer retainers cover the Progress OpenEdge EXCLUSIVE-LOCK without RELEASE pattern — the same lock not released on a validation failure branch, producing the same invisible lock accumulation in a multi-user Progress 4GL application. Natural developer retainers cover the Natural/Adabas hold queue — the same lock not released on program exit, where an Adabas GET SAME HOLD places a record in the Adabas hold queue and the Natural program exits without BACKOUT TRANSACTION, leaving the held record unavailable to other Natural sessions. RPGLE developer retainers cover the IBM i DB2 for i record lock on the same platform as LANSA — RPGLE programs that issue a CHAIN with update intent on an IBM i physical file and do not release the lock via COMMIT or ROLBK on the failure path, producing the same CPF5027 escape message on concurrent access attempts, diagnosed with the same WRKOBJLCK and WRKJOB IBM i commands.

FAQ: LANSA developer retainers