Exstream engine ignores a switch: how control file precedence actually works

Symptom

A switch is configured, but the production run behaves as if it is not there. Variants of the same underlying confusion:

• A switch set in the application settings has no effect at run time.
• The message file reports a file cannot be found or created after a control-file change.
• A packaging switch is handed to the engine, or an engine switch is supplied only during packaging.
• Similar names such as DRIVERLISTFILE and DRIVERFILELIST lead to repeated "unsupported switch" searches.

Cause

Classic Exstream has separate packaging and engine phases, each with its own executable and its own set of applicable switches. A switch that is valid in one phase is silently useless, or an error, in the other.

An engine control file is a line-oriented text file where each switch is prefixed with - or / depending on platform syntax. Relative paths inside it resolve from the process working directory or the switch's documented path rules, which is why a control file that works interactively can fail under a scheduler or service account.

Fix

Diagnose with everything explicit:

1. Run the exact engine executable with -CONTROLFILE=<fileName>.
2. Use fully qualified paths for package, message, report, input, and output files while diagnosing.
3. Put one switch per line and verify each spelling against the switch reference for your release, not against a forum memory of a similar name.
4. Keep package control files and engine control files separate, and confirm which executable consumes each.
5. Capture the generated message file and the process working directory in the job record.

Separate phase, path, and precedence errors

An application setting only overrides a run-time control file when the documented precedence says so. A path error can look like a switch failure. A control file can also be syntactically valid but intended for the other phase.

The mechanism and the CONTROLFILE switch are still current in the classic switch reference, but containerized deployments add argument limits and different operational boundaries, so do not assume interactive behavior carries over unchanged.