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

Current-State Design: Coordination, Consistency and Coupling

Diagram coverage

Design shape and responsibility boundaries

The current implementation is organized as a menu-driven desktop application whose coordination is centered on D4_Main. D4_Main.main creates the application through AppFactory.create("D4_Main", args), selects the stores7 database through _app.getDB("stores7"), initializes the shared environment, and exposes Customer, Orders, Stock, Reports, and Exit commands. The configured entry point is com.ais.fc.ix.swing.application.GUIApplication, so the supplied Java evidence supports a Swing-oriented runtime, although the framework implementation itself is not included. E0001 E0002

The application’s business areas are represented by D4_Cust, D4_Orders, D4_Stock, and D4_Report, with interfaces such as ID4_Cust, ID4_Orders, ID4_Stock, and ID4_Report defining the visible operation surface. These are functional responsibilities rather than proof of independent deployable components: the modules obtain shared application services and global records through the framework. D4_Globals retrieves values through Application.GLOBALS_KEY, including p_customer, p_orders, arrays for p_items, p_stock, and p_state, counters, and print_option. E0002 E0012

This arrangement gives the application a controller-and-shared-state style. D4_Main selects a module, the selected module gathers input through generated forms and framework controls, and the module then performs database or report operations. Record classes such as Customer, P_Orders, P_Stock, P_Items, R, SQLCA, and X_Invoice provide Java-side representations of business and reporting data. The separation between forms, record classes, module methods, and framework services is evidenced; a formal layered architecture or independent component deployment is not. E0006 E0013

The Java target should be distinguished from the original Informix-4GL programs rather than treated as a single interchangeable implementation. For example, D4_Orders.java contains implemented order addition and customer-based order viewing but leaves update_order() and delete_order() as error-message stubs. By contrast, the separately named ordmenu.4gl.main contains Modify and Delete paths for orders. The evidence therefore describes related artifacts or variants with different behavior, not proof that the Java entry point has the full behavior of ordmenu.4gl.main. E0002 E0009 E0012

End-to-end coordination of a customer and order

The implemented Java order-add path coordinates several responsibilities. D4_Orders.add_order() first obtains or creates a customer, collects order-header values, and accepts line items through a grid-style input structure. Stock lookup supplies item description and unit price; a valid quantity then permits calculation of the line total. The module begins a database transaction, inserts the order header, retrieves the generated serial value, inserts item rows, commits, and then generates an invoice. This is a coordinated journey across customer selection, stock reference data, order records, item records, and reporting output. E0002 E0007

The order-entry forms expose the same relationship at the presentation level. Orderform.java and orderform.per associate customer identity and address fields with customer, order header fields with orders, and line-item fields with items and stock. The line structure contains item number, stock number, manufacturer code, description, quantity, unit price, and total price. X_Invoice combines order, item, stock, and manufacturer information for invoice output. These associations show how the current design joins business data at runtime, while the supplied schema evidence does not establish all database keys or constraints. E0006 E0009 E0013

Customer maintenance follows a similar module-local flow. D4_Cust supports add, query/browse, update, and delete operations in the Java evidence. Query browsing orders results by lname and provides First, Last, Next, Previous, Select, and Quit choices. Updates target customer using customer_num; deletion first counts related rows in orders and then requires confirmation. The deletion message refers to “active orders,” but the reported SQL counts all orders for the customer, so the current design’s exact deletion rule remains unresolved: the source does not show whether order status or payment state is represented elsewhere. E0002 E0007

Customer selection and state selection are coupled through the query/input framework. The source material describes query-by-example criteria including literals, ranges, lists, relational operators, and wildcards. State lookup can open State_List when a code is invalid or missing, with state.code and state.sname displayed for selection. The Java and 4GL evidence agree on the existence of this interaction, but the Java callback wiring and the framework’s validation semantics are not fully available. E0005 E0009

Consistency and transaction boundaries

The clearest consistency boundary is order creation. D4_Orders.add_order() commits only after both the order header and item insertion report success, and it attempts rollback when either operation fails. The corresponding 4GL documentation and d4_orders.4gl also describe BEGIN WORK, rollback on insertion failure, and commit after all items have been inserted. This supports a transaction boundary around creation of the order and its line items, rather than separate committed writes for each record. E0002 E0007

That boundary is not fully guaranteed by the supplied Java evidence. The explicit rollback branches depend on status reporting through ErrorHandler and database helpers. In the broad exception path, the reported D4_Orders.java code calls _eh.handleException(_e) but does not visibly call rollback. Framework behavior may provide cleanup, but that is not shown. The unresolved question is specific: does the implementation of _eh.handleException or the database framework automatically roll back a transaction after an exception outside the explicit failure branches? E0012

Customer creation, customer update, and report generation do not have the same demonstrated transaction envelope. The 4GL input_cust() inserts a customer and reads SQLCA.SQLERRD[2], but the supplied source does not show an explicit status check or transaction around that insert. The Java implementation is more substantial, but its complete behavior is not independently cross-checked because some reports identify missing or locally unavailable customer evidence. Consequently, order atomicity is better evidenced than general application-wide atomicity. E0007 E0012

The original 4GL order-maintenance variant introduces additional consistency concerns that must not be projected automatically onto Java D4_Orders. In ordmenu.4gl.main, delete_order() reportedly deletes the parent row in orders before deleting rows in items, without visible transaction handling. That could conflict with a foreign-key relationship, but the schema is absent. Similarly, change_order() replaces items without a demonstrated transaction. These findings apply to that named 4GL program, not necessarily to the Java menu path. E0010

Shared state, coupling and cross-cutting effects

D4_Globals is a central coupling point. Modules retrieve the same mutable customer, order, item, stock, state, and print-option objects rather than exchanging all values through narrow method contracts. This simplifies movement between menus and supports workflows such as selecting a customer and then adding an order, but it also means that a later operation can observe values left by an earlier operation. The evidence does not establish whether module use is strictly single-threaded, so concurrency and cross-session isolation remain open questions. E0002 E0012

Reference data is loaded into bounded arrays during startup. get_states() retains at most 50 state records and get_stocks() at most 30 stock records; excess rows are not retained in the in-memory arrays. The source does not show a user-visible overflow error. This creates a cross-cutting dependency between startup loading and later stock selection or state selection: those journeys can only use the retained subset, even though the database may contain more rows. E0012

The report subsystem also depends on shared state. print_option controls file, printer, or screen output for implemented mailing-label and accounts-receivable reports. The report framework’s start, row-output, execution, and finish behavior is external to the supplied source, so the design shows a report-producing call sequence but not a fully verified output contract. Backlog and stock-list report methods exist as menu surfaces but explicitly display “This option has not been implemented.” E0002 E0007 E0012

Query construction is another cross-cutting dependency. Customer searches and mailing-label selection concatenate a Construct-generated predicate into SQL before preparing the statement. The use of a prepared-statement API does not by itself establish parameter binding because the predicate is already part of the SQL text. Whether Construct.getQuery() safely restricts the expression is unresolved and belongs with the interface and security treatment in C08 and C09. E0002 E0012

The bang command creates a separate trust-boundary concern. D4_Main.bang() accepts a user-entered command and passes it to _app.execute(true, Str.valueOf(cmd)); no allowlist is visible in the supplied code. The exact authority of Application.execute() is unknown, but the call couples the interactive menu to command execution and should be considered alongside the security constraints in C09 and operational concerns in C10. E0001 E0012

Known functional boundaries and unresolved design questions

The current Java design exposes more menu entries than it implements. Stock add, find, update, and delete handlers in D4_Stock are stubs; order update and delete are stubs in D4_Orders; and backlog and stock-list reports are stubs in D4_Report. The help material independently marks these capabilities as not implemented. The design therefore contains intentional-looking navigation surfaces that terminate in warnings rather than state changes; a rejected operation must not be described as a lifecycle transition. E0002 E0003 E0012

Order totals illustrate a cross-module semantic dependency. order_total() applies a 1.1 multiplier, while invoice generation separately calculates 6.5% sales tax and 3.5% shipping. The figures suggest an intended 10% relationship, but the source does not establish whether the interactive total is display-only, whether invoice rounding differs, or whether any amount is applied twice. The precise business rule belongs in C05 and the field/representation detail in C06. E0002 E0012

Finally, the current design is best understood as a partially implemented migrated application whose organization is clear but whose framework, schema, and artifact relationships are not fully proven. The Java modules, generated forms, 4GL sources, help text, and binary form artifacts contain both reinforcing and conflicting perspectives. The consequential open questions are whether the Java target is semantically equivalent to any particular 4GL program, which configuration governs the active database connection, how framework exceptions affect transaction rollback, and which forms and report lifecycles are actually active at runtime. These questions should remain explicit in C14, C15, and C16, rather than being resolved by assuming that similarly named artifacts are the same system path. E0004 E0008 E0010

Component / dependency view

Browse diagrams and evidence gaps.