run_journal.exe Facts: It IS the Session Process, and How Batch Licensing Actually Behaves

Operational facts about run_journal.exe that matter when orchestrating it from other software, verified on NX 2606.

The process model

• run_journal.exe is the NX session process. The journal executes in-process: os.getpid() inside the journal equals the run_journal.exe PID, and that PID lives exactly as long as the session. There is no handoff to ugraf.exe — any ugraf.exe you see belongs to interactive NX sessions. Consequences: monitor/adopt the session by that PID; killing it kills the session and everything unsaved in it.
• It self-locates. Run from a bare shell with no NX environment variables set, it boots fine (it establishes UGII_BASE_DIR etc. in-process — which the Python side needs, since NXBIN\python\ sitecustomize.py resolves the NXOpen*.pyd modules via UGII_BASE_DIR).
• Boot time is ~4-10 s on a warm NVMe machine, minutes under heavy disk contention (and see the separate article on the inherited-stdin stall).

Journal languages

Playback accepts .py, .vb, and .cs sources. Java and C++ are record/translate targets only (-r=out.py,lang=py rerecords a journal into another language while replaying — also a handy corpus-conversion trick). -args a b c arrive in Python as sys.argv[1:]. -pim (plus -u/-p/-g) runs the journal against Teamcenter-managed NX.

Licensing: gateway + lazy per-module checkout

Watching the vendor-daemon log (saltd.log) during batch runs shows each session checks out the gateway feature at start, then pulls module features on first use (solid_modeling when modeling, assemblies, step_ap214/step_ap242 at export time, ...). The classic failure string when the server is unreachable or exhausted is "No Gateway license to obtain a NX Open session." Python journal playback needs no author license (author features matter for compiled/signed apps, not journals).

Concurrency: DUP_GROUP makes batch sessions ~free

With the common DUP_GROUP=UHD license attribute (User+Host+Display), every NX session launched by the same user on the same machine shares one seat — verified here with two interactive NX sessions, a persistent batch worker, and one-shot batch renders/index builds all running simultaneously against a 3-seat gateway while consuming one. So orchestration designs can freely spawn short-lived helper sessions (isolated renders, translators, index builds) without license anxiety — on one machine. Fanning out across hosts costs real seats.