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

10. Deployment and Operations

Diagram coverage

Runtime entry and operating modes

The supplied runtime declarations describe a desktop application rather than a service or scheduled batch process. The Java entry point is com.ais.demo.D4_Main, and rundemo.sh launches it with java; rundemo.bat provides the corresponding Windows command. The Java runtime classpath includes demo/bin, libs/swingx-all-1.6.4.jar, libs/ifxjdbc.jar, libs/jfclix.jar, and libs/itext-2.1.7.jar. The application configuration also names com.ais.fc.ix.swing.application.GUIApplication, although the framework implementation is not included in the supplied evidence. E0001 E0014

The legacy source describes the same business application as an interactive Informix-4GL program. demo/source/d4_main.4gl initializes the help file and reference data, then enters the main menu; demo/source/menu1.4gl.main and demo/source/ordmenu.4gl.main likewise wait for user commands, form input, and menu selections. No supplied evidence identifies a cron entry, enterprise scheduler, recurring batch job, unattended posting cycle, or timer-driven report process. Operational execution should therefore be understood as user-initiated desktop activity in the evidenced current artifacts, while any other scheduling mechanism remains an unresolved question rather than an established absence. E0007 E0009 E0014

At Java startup, D4_Main.main creates the application through AppFactory.create("D4_Main", args) and starts the D4_Main module. D4_Main.run() sets the Swing look and feel, obtains the stores7 database through _app.getDB("stores7"), and presents Customer, Orders, Stock, Reports, and Exit commands. Before the main menu is usable, the application initializes shared global state and loads state and stock reference rows into bounded arrays. E0002 E0011 E0012

Build and launch prerequisites

The repository includes a workspace-oriented setup rather than a separately evidenced production installer. .gitpod.yml selects a custom Dockerfile and runs install_informix.sh; the Dockerfile uses a Gitpod VNC workspace image and installs supporting libraries. install_informix.sh creates an informix directory, downloads ibm.ids.14.10.FC5.LNX.tar, extracts it, and runs the Informix installer in silent mode after accepting the license. These declarations establish setup actions for the supplied demonstration environment, not proof that the application is deployed to a particular operational host. E0014

The README describes starting an ibmcom/informix-developer-database:latest container, mapping ports and supplying environment variables, then installing the demonstration database with ./dbaccessdemo7 stores7. It also identifies informix as the default database user and [credential redacted] as its password. dbaccess is identified as a way to verify database installation. These are documented prerequisites and procedures; the evidence does not show that the container is running, that the database is reachable, or that the Java client has successfully connected in a live environment. E0014

The translation project configuration in demo/source/demo.properties identifies source, work, and target paths as .\\source, .\\work, and .\\target, uses the com.ais.demo package prefix, selects Informix as the database target, and configures a server port of 7082. It also indicates that generated Java is the target of the migration project. A configured source or target path is a build/resource dependency, not evidence that the resulting component is installed on a particular host. E0007

Database and environment configuration

Two supplied configuration files contain materially different database settings. demo/bin/default.properties defines the stores7 JDBC URL as jdbc:informix-sqli://localhost:9088/stores7:informixserver=informix, with user informix, password [credential redacted], and STMT_CACHE='1'. demo/source/demo.properties instead specifies host [internal hostname redacted], port 1526, server ol_informix, database user informix, and password [credential redacted]. The evidence does not establish precedence, whether these files belong to separate runtime and translation contexts, or which configuration rundemo.sh ultimately consumes. This configuration ambiguity is operationally significant and should be resolved before treating either endpoint as authoritative. E0008

The Java source independently selects the logical database alias stores7, and default.properties names the Informix JDBC driver com.informix.jdbc.IfxDriver. The source also contains SQL references to customer, orders, items, stock, manufact, and state, while the actual schema definitions are not supplied. Consequently, the database name, driver, and referenced tables are evidenced, but connection success, schema compatibility, credentials, server reachability, and version compatibility remain unconfirmed. Detailed data and interface implications belong in C06 and C08. E0001 E0007 E0013

The active-looking configuration files contain plaintext database credentials. The supplied evidence does not establish how file permissions, secret injection, or credential rotation are handled. The command path in D4_Main.bang() is also security-sensitive: user input is passed to _app.execute(true, Str.valueOf(cmd)), with no visible allowlist in the supplied method. These operational security concerns are discussed in C09; they are included here because they affect safe operation and environment preparation. E0002 E0012

Normal operating cycle

After startup and reference-data loading, the operator selects a module from the main menu. Customer operations include adding, finding, updating, and deleting records in the Java target evidence. Order entry selects or creates a customer, collects order header information and line items, looks up stock information, inserts the order and items, and generates an invoice. Reports support mailing labels and accounts receivable with file, printer, or screen destinations; backlog and stock-list report methods are present but explicitly display “This option has not been implemented.” Stock add, find, update, and delete methods are likewise stubs. E0007 E0012

The startup loaders impose in-memory limits: p_stock retains at most 30 stock rows and p_state at most 50 state rows, while p_items has capacity for 10 line items. The loaders stop when their limits are reached and reset the counters to the retained maximum. The supplied source does not show an operator-facing overflow warning, so a database containing more reference rows may result in truncation of the data available to selection screens. The exact status semantics of the error handler remain unresolved. E0012

Report operation depends on the global print_option, using "f" for file, "p" for printer, and "s" for screen. File output prompts for a filename and supplies defaults such as labels.out or ar.out when the response is null; printer output targets PRINTER; screen output may pause between rows. The report framework’s start, execution, buffering, and finish semantics are external to the supplied source, so successful completion and physical delivery to a printer or file cannot be confirmed solely from the call sites. E0007 E0012

Failure handling and recovery

Order creation visibly begins a transaction, inserts the order header, obtains the generated order number, inserts item rows, and commits only after the required operations succeed. Explicit rollback is attempted when the order insertion reports failure or item insertion returns failure. The broader exception path calls _eh.handleException(_e) but does not visibly call rollback. Whether the framework or exception handler performs recovery for exceptions outside the explicit branches is unresolved. Operators should therefore treat an interrupted or exceptional order entry as requiring verification rather than assuming that every partial change was automatically removed. E0012

Customer deletion checks for related orders before deletion, but the Java evidence counts all matching rows with SELECT COUNT(*) FROM orders WHERE customer_num = ? while displaying a message referring to “active orders.” The source does not establish whether all rows are intended to be active or whether completed orders should permit deletion. This affects operational recovery and manual intervention when a deletion is refused; the precise business rule belongs in C05. E0002

The legacy 4GL report routines contain a possible interruption-handling flaw: they reset int_flag before leaving the row loop and then test it afterward, which may prevent the final “printing aborted” path from recognizing an interruption. This is a reported source analysis claim, not independently established 4GL semantics. The Java report behavior should not be assumed equivalent without framework or runtime verification. E0008

Migration warnings identify additional operational limitations, including untranslated PAUSE, unsupported fgl_drawbox, color warnings, and report-to-file warnings. These indicate that screen behavior, pauses, command execution, and file/report output may differ from the original Informix-4GL application. They are evidence of migration risk, not proof that a particular runtime operation fails. E0002

Deployment and operational questions

The supplied declarations establish launch commands, library dependencies, Informix setup procedures, database aliases, and configuration values, but they do not assign every Java class or database component to a production host. In particular, classpaths and project paths show how the demonstration is launched or built; they do not prove deployment to a specific workstation, container, server, or database host. The actual precedence between default.properties and demo.properties, the intended database endpoint, the handling of credentials, and the recovery procedure after an uncaught transaction exception remain consequential unresolved questions for operations. E0008 E0014 C14

Expandable topic detail

Browse all topic detail.

Deployment / runtime targets

Browse diagrams and evidence gaps.