Source-derived document; reported behaviour, inference and evidence gaps are identified in the text.

Hazards, Unknowns, and Backlog

Diagram coverage

This chapter records risks and unresolved questions that affect interpretation or operation of the current system. It distinguishes observed source behavior from documentation claims, inferred defects, and evidence gaps. The most important qualification is that similarly named artifacts do not describe one uniform implementation: the Java D4_* modules, the Informix-4GL programs under demo/source, generated forms, help text, and configuration files provide overlapping but not identical evidence. Related operational rules are described in C05, journeys and state changes in C04, data definitions in C06, interfaces and database exchanges in C08, security-sensitive behavior in C09, and runtime prerequisites in C10.

Capability contradictions and implementation boundaries

The strongest contradiction concerns order maintenance. In demo/target/java/src/com/ais/demo/D4_Orders.java, update_order() and delete_order() display “This option has not been implemented”; the Java D4_Stock.java handlers for adding, finding, updating, and deleting stock do the same, and D4_Report.print_backlog() and print_stock() are also stubs. The Java evidence therefore supports order creation and customer-based order viewing, but not order update/delete, stock CRUD, backlog reporting, or stock-list reporting. E0002 E0012

Other supplied artifacts describe different behavior. demo/source/ordmenu.4gl.main contains Add, Query, Modify, and Delete order flows, including replacement of order items and deletion of an order and its items. These are positive descriptions of a separate 4GL program and must not be silently used to prove that the Java D4_Orders implementation has those capabilities. The specific unresolved question is whether ordmenu.4gl.main is an independently runnable legacy entry point, an earlier implementation, or source material intended to correspond to the Java module. Evidence needed: the execution mapping between ordmenu.4gl.main, D4_Orders.java, and the deployed runtime. E0009 E0010

The same distinction applies to customer behavior. Positive Java evidence exists in D4_Cust.java, including customer creation, browsing, update, deletion, state selection, and database persistence; a separate report locally states that D4_Cust.java was not supplied and therefore could not be assessed. The local omission does not negate the positive description from the other supplied analysis. The remaining question is not whether customer functionality is globally absent, but whether all cited D4_Cust.java behavior belongs to the same build snapshot and has the status contracts expected by callers such as D4_Orders. E0002 E0009 E0012

The help and 4GL documentation also describe update/delete orders, stock maintenance, backlog reports, and stock-list reports as “currently not implemented.” This agrees with the Java stubs for those capabilities, but help entries and embedded examples remain documentary evidence rather than proof of runtime execution. The backlog item is to reconcile menu declarations, help text, Java implementations, and any executable 4GL path before describing those functions as available. E0004 E0006

Data integrity and transaction hazards

Customer deletion has a semantic mismatch. The Java D4_Cust.delete_customer() checks SELECT COUNT(*) FROM orders WHERE customer_num = ?, while presenting the message “This customer has active orders and can not be removed.” The query counts all related orders; it does not visibly restrict the result to unpaid, open, or otherwise active orders. This may be an intentional schema convention or a defect that prevents deletion after completed orders. Evidence needed: the orders status conventions and the business definition of an active order. E0002

Order insertion has visible rollback branches in D4_Orders.add_order(): the code begins a transaction, inserts the order header, inserts items, commits after success, and attempts rollback after reported failure. However, the broad exception path calls _eh.handleException(_e) without visibly rolling back. Whether ErrorHandler or the framework performs cleanup is unresolved. The 4GL source and help text also describe BEGIN WORK, ROLLBACK WORK, and COMMIT WORK, but those examples cannot establish Java runtime behavior. Evidence needed: DBHelper, ErrorHandler, and transaction implementation code, plus an execution trace covering exceptions after beginTransaction(). E0002 E0004 E0012

The order-total calculation is another unresolved business hazard. Java D4_Orders.order_total() multiplies the line-item sum by 1.1, while invoice generation separately calculates 6.5% sales tax and 3.5% shipping. The rates sum to 10%, suggesting intended equivalence, but the interactive path uses Money.valueOf(1.1d) and the invoice path calculates separate components. Rounding may therefore differ, and the source does not establish whether the multiplier is tax, shipping, a combined display adjustment, or an additional charge. Evidence needed: the authoritative pricing rule, Money arithmetic behavior, and sample invoices compared with displayed order totals. E0002 E0012

The 4GL menu1.4gl.main path contains additional integrity hazards. det_ord() calls view_ord() and then unconditionally sets exist = 1, potentially restoring an order-selected flag after an empty result. del_cust() and del_ord() can clear the form and display “Record deleted” even when the user declines confirmation. view_ord() omits t_price in boundary fetches, although privileged display later uses it. These findings apply to that 4GL program, not automatically to Java D4_Orders; the unresolved question is which program, if any, is operationally authoritative. E0010

Query, command, and configuration risks

Customer query and mailing-label reporting build SQL by concatenating a Construct or construct.getQuery() result into the SQL text before preparation. A prepared-statement API is present in the Java report path, but the predicate itself is not visibly bound as a parameter. This is a concrete security review item, not a confirmed injection vulnerability, because the escaping and restriction behavior of Construct is absent. Evidence needed: the Construct implementation, generated predicates for literal, range, list, relational, and wildcard criteria, and tests using hostile input. E0002 E0012

D4_Main.bang() accepts a command and passes it to _app.execute(true, Str.valueOf(cmd)). The visible source provides no allowlist or sanitization. This creates a security-sensitive command-execution path, although the effective permissions and semantics of Application.execute() are unknown. The affected trust boundary and required controls belong in C09. Evidence needed: the implementation of _app.execute, the identity under which the process runs, and confirmation of whether the command is shell execution or a restricted framework operation. E0001 E0012

Configuration is inconsistent across supplied files. demo/bin/default.properties specifies a local Informix JDBC URL on port 9088 with user informix and password [credential redacted], while demo/source/demo.properties specifies [internal hostname redacted], port 1526, server ol_informix, and password [credential redacted]. These may represent runtime and translation-project configurations, but precedence and environment ownership are not established. Both contain plaintext credentials. This is an operational and security hazard, not proof of a particular deployment. Evidence needed: the startup configuration-loading order, environment-specific overrides, and credential-management procedure. E0007 E0008 E0014

Artifact and runtime unknowns

Several .frm files, including order.frm, orderform.frm, state_list.frm, stock1.frm, and stock_sel.frm, were reported as binary or containing NUL bytes and were not semantically analyzed. Their corresponding .per files describe forms, but do not prove that the binary artifacts match them. Calls reference forms such as orderform, state_list, and stock_sel; their runtime presence and compatibility remain unresolved. Evidence needed: the compiled-form loading path and a verified mapping between each .per definition and deployed .frm artifact. E0008 E0009

Generated Java forms also contain constructors that catch Exception with empty bodies, and many controls begin disabled. These observations may indicate suppressed initialization failures or intentional read-only presentation, but neither conclusion is established without framework behavior and runtime interaction evidence. The unresolved questions are which controls are enabled during actual entry and whether initialization failures are logged elsewhere. E0004 E0006

Startup loaders retain at most 30 stock records and 50 state records in D4_Globals; excess rows are stopped and counters reset without a demonstrated user-facing overflow warning. The source does not establish whether these are deliberate demonstration limits or production constraints. Evidence needed: the intended maximum dataset, overflow handling requirements, and a run against more than 30 stock or 50 state rows. E0012

Prioritized backlog questions

The current evidence supports the following questions for resolution:

1. Which implementation is authoritative for order update/delete: Java D4_Orders, ordmenu.4gl.main, or both?
2. Are customers with completed orders intentionally undeletable, or should deletion inspect an active/open status?
3. Does every order-insertion exception roll back the transaction?
4. Are the 10% order-total adjustment and the separate tax/shipping calculations deliberately equivalent, including rounding?
5. Does Construct safely constrain generated SQL predicates?
6. What operations does _app.execute() permit, and under which operating-system identity?
7. Which database configuration is loaded at runtime, and how are credentials protected?
8. Do the binary forms correspond to the supplied .per files and referenced form names?
9. Are the 30-stock and 50-state limits intentional, and what happens when they are exceeded?
10. Do the menu1.4gl.main defects affect a live path, or only a separate historical program?

Until these questions are answered, capability statements should preserve their qualifiers: implemented Java customer and order-entry behavior is evidenced, while several maintenance and reporting functions remain stubs, separate 4GL behavior remains distinct, and framework, schema, configuration, and runtime semantics remain consequentially unresolved.

Expandable topic detail

Browse all topic detail.