Legacy LSAM connectors (UNIX/Linux, Windows, IBM i, and SQL)

Behavior-level reference.

Task walkthrough: Run commands on legacy LSAM machines. This page is the full configuration and troubleshooting reference.

These connectors run commands on existing legacy LSAM agents — the agents many customers already run before moving to the Universal Agent. They let an OpCon Continuum workflow drive UNIX/Linux, Windows, IBM i, and SQL LSAM machines without rebuilding that automation.

Connector	Job type	Agent type	Purpose
UNIX/Linux LSAM (opcon.lsam.unix)	UNIX Command (unix-command)	UNIX LSAM	Run a command or script on a UNIX/Linux LSAM machine
Windows LSAM (opcon.lsam.windows)	Windows Command (windows-command)	Windows LSAM	Run a command on a Windows LSAM machine
Windows LSAM (opcon.lsam.windows)	Windows - WS_FTP Pro (windows-wsftp-pro)	Windows LSAM	Run a WS_FTP Pro file transfer on a Windows LSAM machine
Windows LSAM (opcon.lsam.windows)	Windows - Command: File Copy / Move / Rename / Delete (windows-file-copy / -move / -rename / -delete)	Windows LSAM	Copy, move, rename, or delete files on a Windows LSAM machine
Windows LSAM (opcon.lsam.windows)	Windows - Corelation (windows-corelation)	Windows LSAM	Submit and monitor a Corelation batch job on a Windows LSAM machine
Windows LSAM (opcon.lsam.windows)	Windows - Fiserv DNA (windows-fiserv-dna)	Windows LSAM	Run a Fiserv DNA SQT job on a Windows LSAM machine
Windows LSAM (opcon.lsam.windows)	Windows - Fiserv DNA (File Loader) (windows-fiserv-dna-fileloader)	Windows LSAM	Load a file into Fiserv DNA from a Windows LSAM machine
Windows LSAM (opcon.lsam.windows)	Windows - File Arrival (windows-file-arrival)	Windows LSAM	Wait for a file to arrive on a Windows LSAM machine during a time window
Windows LSAM (opcon.lsam.windows)	Windows - Embedded Script (windows-embedded-script)	Windows LSAM	Run a script from the script library on a Windows LSAM machine
Windows LSAM (opcon.lsam.windows)	Windows - Web Services (windows-web-services)	Windows LSAM	Run a multi-step HTTP/REST sequence through the SMA Web Services connector on a Windows LSAM machine
IBM i LSAM (opcon.lsam.ibmi)	IBM i (AS/400) Batch Job (ibmi-command)	IBM i LSAM	Submit a batch job on an IBM i (AS/400) LSAM machine — enablement in progress, see below
SQL LSAM (opcon.lsam.sql)	MS SQL Script (sql-script)	SQL LSAM	Run a T-SQL script, or inline statements, on a SQL LSAM machine

One legacy job type is documented separately

SMAFT File Transfer (opcon.lsam.smaft) also runs on legacy agents through the relay, but it belongs to none of the per-platform sections below: a single job names a Windows and a UNIX machine, and which of the two runs the job is derived rather than assigned. It has its own page — SMAFT File Transfer job.

Windows LSAM — Embedded Script

The Windows - Embedded Script job type (windows-embedded-script) runs a script held in the script library rather than one pasted into the job. On the job you choose the script, the version to run, the runner that launches it, and any arguments:

Field	Notes
Script	The library script to run. Only scripts whose language has a Windows runner — built-in, or one your tenant added — are listed. See below.
Version	Latest (track the newest version) or a specific pinned version number.
Runner	The program that starts the script on the agent. The choices depend on the script language, so pick the script first.
Arguments	Optional arguments passed to the script.

Because the job holds a reference rather than a copy, fixing the script in the library reaches every job that tracks Latest; a job pinned to a version keeps running that version until you change it. A script cannot be deleted while a job references it. See Script library.

The Script list is filtered to what a Windows agent can actually run. A script whose language has no Windows runner is not offered, because choosing it would leave the required Runner list empty and the job could never be saved. The filter is fixed on the job type, so you do not have to pick an agent first, and it is worked out from the runners your tenant can see — so a Windows runner you add changes what this list offers.

Two consequences for scripts and jobs that predate this:

• A script you expect to see is missing from the list. Its language has no Windows runner — in the built-in catalog that means Shell and Bash. Library scripts carried over before script types were introduced default to Shell, so this can affect a lot of them at once. Either change the script's type in the library, or add a Windows runner for that type, which makes every script of that type available here.
• An existing job already points at such a script. The job still shows the script by name rather than a bare identifier, and the Runner field explains the dead end instead of reading as an empty list. Point the job at a Windows-runnable script, or add the missing runner, to make it saveable.

The script and the runner are checked when the workflow is saved, so a pair that does not go together is named on the save rather than failing on the job's next run — see Script and runner are checked when the workflow is saved. If the script or the runner a job holds has since been deleted, the field says This script is no longer available. Choose another. instead of showing an identifier with no explanation.

Windows LSAM — Web Services

The Windows - Web Services job type (windows-web-services) runs a sequence of HTTP requests through the SMA Web Services connector installed on the Windows LSAM machine. A value extracted from one response is available to every later step, so one job can authenticate, submit work, poll for completion, and download a result.

Like WS_FTP Pro, this type has no startImage/parameters — the relay assembles the connector command line from the form fields.

Core parameters

Parameter	Required	Limits	Notes
machineName	Yes	1–24 chars	Target Windows LSAM machine; must match the registered agent name.
batchUserId	No	a saved connection	The Windows account the job runs as. Blank runs it as the agent's service account. See Batch User.
connectorLocation	Yes	1–252 chars, no "	Folder containing SMAWSConnector.exe. It is also the job's working directory, which is where the connector looks for config\Connector.config — so it is load-bearing, not cosmetic. Note the cap is 252, one lower than the other Windows types, because this type appends a trailing backslash.
templateId	No	≤128 chars	A free-text label for your own naming convention. The connector never reads it; it appears in the connector's log.
steps	Yes	1–50 steps	The requests to run, in order. See below.
variables	No	≤99 entries	Template-wide name/value pairs substituted into any URL, header, or body. Names conventionally start with @ (for example @Url).
environmentVariables	No	—	Environment variables set for the connector process. Any name starting with @ is imported into the connector's variable map and overrides a template variable of the same name.
exitCriteria	No	≤20 conditions	Conditions tested against the job's exit code — but read the caution below first, because this job type does not exit 0 on success. See Exit criteria.
exitCriteriaResult	No	Fail / Finish OK	What a match decides. Default Fail.
properties	—	—	Not supported. A job with any Property Update on Completion entry is rejected before dispatch.

Set an exit criterion, or every successful job fails

The connector exits with the raw HTTP status of the last step, so a successful call exits 200, not 0. Leave exitCriteria empty and the default — fail on any non-zero exit code — fails every job that worked.

Either of two single-row tables fixes it, and they mean the same thing:

Exit Criteria Result	Row	Reads as
Fail (the default)	Not Equal To 200	Fail when the code is not 200
Finish OK	Equal To 200	Finish OK when the code is 200, fail otherwise

The first is enforced by the agent; the second is enforced by OpCon Continuum after the agent reports, because Finish OK is not something the legacy wire can carry. See Exit criteria for what that difference means on the job.

Credentials

Keep credentials out of the job definition by supplying them as environment variables rather than template variables. A name starting with @ overrides the template variable of the same name, which is the supported way to provide @User, @Password, and @Domain. An environment-variable value may be an <SmaEncrypt> token; the agent decrypts it and masks it in the job log.

The relay's own LSAM Connector log redacts a legacy job's command line, environment values and script body, so a secret passed that way is not readable there — but that was not true of earlier relays. See the connector log before relying on a log written by one.

Authentication mode is chosen from the prefix of a request header's value — Basic, NTLM, CERT, or SOAP each trigger special handling using @User / @Password / @Domain. Any other header value is sent verbatim after variable substitution.

Step parameters

Each of the 1–50 steps carries a request and a response definition.

Parameter	Required	Values / limits	Notes
function	No	GET (default), POST, PUT, PATCH, DELETE	The HTTP method. Case-sensitive.
url	Yes	1–2000 chars	May contain @variables. Required — a step with a blank URL is rejected rather than silently discarded.
proxyServer	No	—	Proxy for this step; overrides the connector's configuration file.
tlsVersion	No	TLS (default), TLSv1.0–TLSv1.3	The connector as shipped does not enable TLSv1.3, even though it is offered here.
request.contentType	No	see below	Defaults to application/json. An unrecognised value is treated as application/json.
request.body	No	—	Request body; may contain @variables.
request.fileName	No	—	Body From File — read the body from this file on the agent instead. Takes precedence over body, except for multipart/form-data and application/octet-stream POSTs.
request.fileSeperator	No	CRLF (default) / LF	Line separator used when reading Body From File. (The spelling matches the connector's wire format.)
request.headers	No	≤50 entries	Name/value pairs. The value's prefix selects the authentication mode — see above.
response.contentType	No	see below	Expected response content type, used to parse extracted values.
response.stepCompletionCode	Yes	100–599, default 200	Expected Status. The comparison is exact equality, not a 2xx class — a 201 where 200 was expected is a failure.
response.variables	No	≤50 entries	Values to pull out of this response for later steps. Extract From is a JsonPath (for example $.id) or an XPath; prefix with # to read a response header; or use TEXTSTRING for the whole body.
response.fileName	No	—	Save Response To — write the response body to this file on the agent. An existing file is overwritten.
response.ignoreResult	No	boolean (default off)	Continue to the next step even when this step's status does not match.

Both content-type lists offer application/json, application/json-patch+json, application/xml, application/x-www-form-urlencoded, application/octet-stream, multipart/form-data, text/xml, and text/plain.

Response data check and polling

A step can optionally inspect a value in its response, and poll until that value appears. attributeToCheck is the switch — leave it blank and the whole check, including polling, is skipped.

Parameter	Values	Notes
attributeToCheck	JsonPath or XPath	The value to inspect. Blank disables the entire check.
goodFin	slash-separated list	Values that mean success, compared case-insensitively (for example COMPLETED/SUCCESS).
badFin	slash-separated list	Values that mean failure.
poll	boolean (default off)	Repeat the request until Good Finish or Bad Finish matches. GET steps only — polling on any other method is rejected at dispatch.
pollDelay	seconds, default 3	Wait before the first poll.
pollInterval	seconds, default 2	Wait between polls.
pollMaxTime	minutes	Give up after this long. Note the unit differs from the two fields above. Leave it blank and the connector polls indefinitely.

Characters the relay rejects, and why

The connector's job document is single-quoted, and the Windows agent rewrites some sequences on the command line. Rather than let either corrupt a request silently, the relay refuses the job at dispatch. The job saves cleanly and fails when it runs, like every legacy LSAM type.

Rejected	Where	Why
An apostrophe (')	Any step or variable value — including the URL	It terminates a string in the connector's single-quoted document and corrupts the whole document. The one exception is a body whose content type is application/json or application/json-patch+json: those are the only content types whose quote transform the connector reverses.
The sequence \*	Any field	The Windows agent replaces it with the machine's hostname anywhere on the command line — including deep inside a JSON body — so the corruption would be silent.
A double quote (")	connectorLocation	The working directory is quote-wrapped for transport.

Quotes in a body are also transformed for transport: for content type exactly application/xml, every double quote becomes the five characters u0022; for every other content type, every single quote becomes u0027. A body that legitimately contains that literal text is therefore altered. Use Body From File when you need the bytes to arrive untouched — it bypasses the transform entirely.

IBM i (AS/400) Batch Job

Newly added — enablement in progress

The IBM i (AS/400) Batch Job job type is registered and appears in the job type catalog, but enablement is still in progress and its end-to-end run path has not been verified. Confirm availability with your Continuous contact before planning work around it.

One blocker has been removed. Every IBM i job dispatched to a real LSAM used to fail immediately with Initialization error: the name Continuum sent contained a hyphen, which an IBM i job name cannot hold, so the agent refused the submission. The name is now built from letters, digits and underscores only. This needs a current relay — see Keeping a relay current.

The IBM i LSAM connector (opcon.lsam.ibmi) submits a batch job on an existing IBM i (AS/400) LSAM machine, dispatched through the relay like the UNIX and Windows LSAM job types. It brings IBM i work that already runs on an LSAM into an OpCon Continuum workflow without rebuilding it.

One difference matters for how you detect failure: this job type has no exit-criteria setting. IBM i does not expose an exit-code field for the relay to translate, so the exitCriteria you would set on a UNIX or Windows LSAM job are not available here, and OpCon Continuum's own central evaluation excludes IBM i deliberately — the agent's reported status is the authority on this platform. Detecting failure from IBM i job messages is a separate piece of work and is not available yet — until it is, treat the job's completion as the only signal, and check the IBM i job log on the machine when you need the reason.

An IBM i job's output no longer reports a signal it never received. An IBM i agent reports its outcome as an IBM i message ID — SMA0036, or SMA0023-CPF0006 — where a UNIX agent reports a numeric exit code. That field used to be read as though it were the UNIX one, so digits inside the message ID were reported as a Signal: line in the job's output: a job that failed with CPF0006 claimed to have been stopped by signal 6. The field is no longer parsed on this platform, and the message ID is what the job records.

IBM i — core parameters

Parameter	Required	Limits	Notes
machineName	Yes	1–24 chars	Target IBM i LSAM machine. Comes from the job's agent assignment, and must match the agent name registered with the relay.
command	Yes	1–2000 chars	The Call — the CL command or program to run.
batchUserId	No	a saved connection	The IBM i user profile the job runs as — an IBM i Batch User connection. Blank uses the job description's default user. See Batch User.
preRun	No	≤2000 chars	A command run before the job itself.

IBM i — batch environment

These map to the IBM i batch attributes you would set on the machine, and each defaults to the IBM i convention. Leave them alone unless the job needs a specific batch environment — the defaults reproduce what the job description already does.

Parameter	Default	Common values
currentLibrary	*	*, *CRTDFT, *USRPRF, or a library name
initLibraryList	*	*JOBD, *, *NONE, *SYSVAL, *CURRENT
jobDescriptionName	*	*, *USRPRF, or a name
jobDescriptionLibrary	*	*, *LIBL, *CURLIB, or a library
jobQueueName	*	*JOBD, *, or a job-queue name
jobQueueLibrary	*	*, *LIBL, *CURLIB, or a library
outputQueueName	*	*JOBD, *, *CURRENT, *USRPRF, *DEV
outputQueueLibrary	*	*, *LIBL, *CURLIB, or a library
jobDate	*JOBD	*JOBD, *SYSVAL, *SCHEDULE DATE
jobQueuePriority	*	*, 1–9
accountingCode	—	Any value up to 15 characters
messageLoggingLevel	*	*JOBD, *, 0–4
messageLoggingSeverity	*	*JOBD, *, 00–99
messageLoggingText	*	*JOBD, *, *MSG, *SECLVL, *NOLIST
logCLCommands	*	*JOBD, *, *NO, *YES
inquiryMessageReply	*	*JOBD, *, *RQD, *DFT, *SYSRPYL
joblogRetentionOccurrences	0	0–999
joblogRetentionDays	0	0–999

Good to know

A field you never touch is still sent with its default. The job editor doesn't store an untouched default, so a value you leave blank is filled in on the way to the machine rather than being sent empty — an IBM i batch job would reject an empty attribute.

SQL LSAM — MS SQL Script

The SQL LSAM connector (opcon.lsam.sql) runs a T-SQL script on an existing SQL LSAM machine, dispatched through the relay like the other legacy job types. It brings SQL Server work that already runs on an LSAM into an OpCon Continuum workflow without rebuilding it.

The machine runs the script with sqlcmd, and most parameters below map directly onto a sqlcmd switch — which is what makes Other Options usable.

SQL — core parameters

Parameter	Required	Limits	Notes
machineName	Yes	1–24 chars	Target SQL LSAM machine. Comes from the job's agent assignment, and must match the agent name registered with the relay.
batchUserId	No	a saved connection	The account the job runs as — a SQL Batch User connection. Blank runs it as the agent's own service account, with no impersonation. See Batch User.
serverName	Yes	1–255 chars	The SQL Server host, optionally HOST\INSTANCE for a named instance.
databaseName	No	≤255 chars	The initial database. Left blank, the server's default for the login applies.
windowsAuthentication	No	default off	On, the job authenticates to SQL Server as the impersonated Windows account rather than with a SQL Server login and password.
encryptConnection	No	default on	Encrypts the connection to SQL Server.

SQL — the script

Supply exactly one of these two. Neither, or both, is rejected at dispatch — the form will let you save it.

Parameter	Limits	Notes
scriptStatements	≤4000 chars	Inline T-SQL, typed into the job.
scriptPath	≤255 chars	Path to a .sql file on the agent machine — for example D:\scripts\nightly.sql. This is not a script library reference, unlike Windows - Embedded Script.

SQL — output and options

Parameter	Limits	Notes
useScriptExitCode	default off	Returns the script's own result as the job's exit code. Applies to inline statements only — it has no effect when scriptPath is used.
exitCriteriaResult	Fail / Finish OK	What a match decides for the criteria table. Default Fail.
exitCriteria	≤20 conditions	Conditions tested against the job's exit code. See Exit criteria.
redirectFilePath	≤255 chars	Writes the script's output to this file on the agent.
otherOptions	≤255 chars	Additional sqlcmd switches, appended verbatim — for example -t 300.
environmentVariables	name/value pairs	Environment variables set for the sqlcmd process.

Two things about the parameters above are worth setting deliberately:

• Exit criteria are available here, and OpCon Continuum always evaluates them. The SQL agent has no way to receive a criteria table, so the table is applied centrally to the exit code the agent reports rather than on the machine — see Exit criteria. This is the only legacy platform where that is true of every table, including a plain one-row table.
• Know which code you are writing conditions against. With Use Exit Code From Script Result off, sqlcmd exits 0 on success and 1 on an error, so that is the whole range a table has to work with. Turn it on and the script's own result becomes the exit code, which is what makes a criteria table worth having on this type.
• An environment variable with an empty value is not sent. Both halves of a pair have to carry a value to reach the machine, so a name with a blank value is dropped as a pair rather than arriving with an empty value or shifting the variables after it.

Encrypt Connection is on by default, and SQL Server has to hold up its end

With Encrypt Connection on, sqlcmd requires SQL Server to present a certificate the agent trusts. Against a server that has no trusted certificate the job fails when it tries to reach the database — after a clean dispatch, so it reads as a job failure rather than a routing problem. Either install a trusted certificate on SQL Server or turn Encrypt Connection off.

Good to know

• A SQL machine cannot be either end of a file transfer. It is the one legacy platform with no file-transfer capability at all, so it has no file-transfer endpoint and never appears in a SMAFT File Transfer job's machine pickers.
• A legacy agent group can be of type SQL, and routes like any other group. Adding an agent of a different type to it is rejected.
• Job output files are retrievable for a SQL job the same way as for the other legacy job types — what the script printed is available from the job's output.

How it works

Unlike built-in jobs, these don't run on a Universal Agent. The platform dispatches the job through the relay, which forwards it to the legacy LSAM machine; the LSAM runs the work and reports completion back.

Every hop is the relay's; no Universal Agent appears anywhere in the path. Two consequences matter:

• A working relay and reachable LSAM machines are required. "No agent available" for an LSAM command points at the relay or LSAM connectivity, not the Universal Agent.
• The job is routed by machineName, which must match the LSAM agent name registered with the relay. A mismatch means the job can't be placed.
• Legacy agents are now registered in-product, on the Agents page, on its Legacy Agents & Groups tab (a sibling of the Agent Pools tab): register, edit, or delete a legacy agent there. The relay hot-reconciles its LSAM connections within one heartbeat of a change — no relay restart needed. Agent names are unique per relay (a duplicate is rejected).
• A legacy agent's status can be ONLINE, OFFLINE, or UNKNOWN. UNKNOWN (amber) means the relay went stale, so the agent's reachability can't be confirmed — distinct from OFFLINE (the agent itself is down). On relay recovery, agents leave UNKNOWN within a heartbeat. See Agents and pools.

The schedule date every legacy job is sent with

Every legacy job carries the schedule date of the workflow instance it belongs to — a plain calendar date, with no time and no time zone, exactly as Classic sends it. The agent reads it as a local date, and two things on the machine depend on it:

• the File Arrival watch window, whose day offsets are counted from midnight of this date — see Authoring the watch window;
• %SMA_MSLSAM_SCHEDULE_DATE%, which a Windows agent substitutes into paths for you, including the paths it reads exit criteria and failure criteria from.

On an older relay this was the relay's own UTC date

The relay used to stamp this field from its own clock in UTC rather than from the job's schedule date. For any agent west of UTC, an evening dispatch therefore carried tomorrow's date — so a File Arrival job watched the wrong day's window, and a path built from %SMA_MSLSAM_SCHEDULE_DATE% named the wrong day's file. Agents east of UTC were unaffected in the evening and affected in the early morning instead.

The relay sends the workflow's schedule date now. It needs a current relay for this: an older one still uses its UTC clock — see Keeping a relay current. If the platform cannot supply the date for a particular dispatch, the relay falls back to the UTC date and records a warning in its log rather than refusing the job.

The Batch User — the account the job runs as

Every legacy job type has a Batch User field (batchUserId). It names a saved connection of its platform's batch-user type, and that connection is where the account and — on Windows and SQL — its password live. The job definition holds only a reference; no credential is stored in the workflow.

Platform	Connection type to pick from	Blank means
Windows	Windows Batch User (batch-user-windows)	The job runs as the agent's own service account. A legitimate, deliberate setting.
UNIX/Linux	UNIX Batch User (batch-user-unix)	Not allowed — a UNIX job must name a batch user.
IBM i	IBM i Batch User (batch-user-ibmi)	The job runs under the job description's default user.
SQL	SQL Batch User (batch-user-sql)	The job runs as the agent's own service account and does not impersonate — whichever way the job's Windows Authentication setting is set.

A job takes one batch user. The picker offers only connections of the matching type, and a connection of the wrong platform's type is rejected at dispatch (RC_WRONG_CONNECTION_TYPE) rather than degrading to the service account — so a mismatch fails loudly instead of running under an identity nobody chose.

The field values, character rules, and password rules for each type are in Connections. To vary the credential per environment, transform the job's connection reference — not the Batch User parameter, which is a display mirror that no transformation rule may change. See Versions and deployments.

This replaces the old free-text run-as fields

Earlier builds took the run-as identity from the job's own parameters: Windows accepted only the literal Use Service Account, and UNIX and IBM i carried free-text user, groupId, and user fields. Those fields are gone. A UNIX or IBM i job saved before the change keeps its orphaned value in the stored configuration, but nothing reads it — re-pick the account from the Batch User field, or a UNIX job will fail at dispatch with RC_NO_UID.

Shared parameters

Parameter	Required	Limits	Notes
machineName	Yes	1–24 chars	Target LSAM machine; must match the agent name registered with the relay.
batchUserId	See Batch User	a saved connection	The account the job runs as. Every legacy job type carries this field.
startImage	Yes	1–4009 chars (Windows: 1–4000)	Path to the program or script to run.
parameters	No	≤2005 chars (Windows: ≤2000)	Command-line arguments, appended to startImage with a space.
preRunImage	No	≤2005 chars (Windows: ≤4000)	A prerun command run before the main job.
exitCriteria	No	≤20 conditions	Conditions tested against the job's exit code. Leave empty for the default: fail on any non-zero exit code. See Exit criteria.
exitCriteriaResult	No	Fail / Finish OK	What a match decides for the whole table. Default Fail. See Exit criteria.

Windows length limits match the legacy Windows job. On Windows, the startImage/parameters/workingDir/preRunWorkingDir/preRunImage max-lengths follow the legacy Windows job limits (command line 4000, directories 255). The UNIX limits differ — see the table above.

Exit criteria — deciding what an exit code means

Left alone, a legacy job finishes OK on exit code 0 and fails on anything else. Exit criteria replace that default with a table of your own conditions, so a program whose codes do not follow that convention still reports the outcome you mean.

Five job types offer the table: UNIX/Linux - Command, Windows - Command, Windows - Embedded Script, Windows - Web Services and SQL - MS SQL Script.

Every other legacy type carries none at all — IBM i, WS_FTP Pro, the four file operations, Corelation, Fiserv DNA, File Arrival and SMAFT File Transfer. For those the exit code the machine reports decides the outcome on its own.

The table

Field	Limits	Notes
Exit Criteria Result	Fail (default) / Finish OK	What a match decides — one setting for the whole table, not one per row.
Criteria rows	≤20	Each row is an operator, a Value, and — for Range only — an End Value.
Operator	Equal To, Not Equal To, Less Than, Greater Than, Less Than or Equal To, Greater Than or Equal To, Range	Range is inclusive at both ends: it matches when the exit code is between Value and End Value.
Value, End Value	-2147483648 to 2147483647	Whole numbers. End Value must be greater than or equal to Value.

End Value appears only when the row's operator is Range. On every other operator the field is hidden, because it has no meaning there — the row keeps its place in the table rather than reflowing when you change the operator.

The rows are an OR — the exit code matches the table when it matches any one row.

Exit Criteria Result then says what a match decides, and a code matching nothing takes the opposite. There is no third "nothing matched" outcome:

Exit Criteria Result	A row matched	No row matched
Fail (the default)	Failed	Finished OK
Finish OK	Finished OK	Failed

Leave the table empty and the default stands: fail on any non-zero exit code. Leave Exit Criteria Result unset and it means Fail, which is how every job saved before the setting existed behaves — so adding the setting changed no existing job.

Good to know

Reach for Finish OK when the list of good codes is shorter than the list of bad ones. "Finish OK on 0, on 3, or anywhere from 10 to 20" is three rows and one setting; written as failure conditions it cannot be expressed at all.

Where the table is evaluated

Two layers can decide a legacy job's outcome, and which one does depends on what the table needs:

• The agent decides when the installed LSAM can enforce the table itself — that is Exit Criteria Result Fail, no range row, and no more than five rows. The table travels to the agent with the job, exactly as it always has.
• Continuum decides, after the agent reports, for anything else: Finish OK, a Range row, or rows six through twenty. The agent is sent the platform default instead (fail on a non-zero code), and Continuum then applies your real table to the exit code the agent reported.
• SQL - MS SQL Script is always decided by Continuum. The SQL agent has no way to receive criteria, so central evaluation is the only route to a criteria table on that platform.

When Continuum decides, three things are visible on the job:

• The termination text reads Finished OK (Exit Criteria) Return Code='N' or Failed (Exit Criteria) Return Code='N'.
• Job History records an Exit criteria evaluated entry holding the exit code, the Exit Criteria Result in force, which row matched (or that none did), the verdict, and the status the agent had reported.
• The agent's own log reaches the opposite conclusion on a job that finished OK by criteria, because the agent was given the default. That is the reason the termination text says which layer decided.

Two outcomes Continuum never overrides, both deliberate:

• A job an operator killed. A Kill is never undone by a table that finishes everything OK.
• A completion that carried no exit code — an agent that reported none, or a relay-side infrastructure failure. With nothing to test, the reported verdict stands.

The advanced forms need a current relay

Finish OK, a range row, and rows beyond the fifth are all carried by relay changes. A relay on an older build refuses the dispatch rather than sending a table it cannot represent, so the job does not start — which is the safe direction, but it does mean the job stays un-run until the relay is upgraded. Tables of up to five plain conditions with the default Fail are unaffected and dispatch on any relay build.

What is rejected

The table is validated when you save the workflow and again at dispatch. Rejected outright:

• more than 20 conditions — the twenty-first is refused rather than silently dropped;
• a missing or unrecognised operator, or a value that is not a whole number in range;
• a range row with no End Value, or with an End Value below its Value. Either shape can never match anything, so the inverse rule above would quietly hand the job the opposite outcome. The workflow refuses to commit and names the row: Range criterion #2 needs an End Value.

note

On UNIX, signalCriteria is a separate table and did not change: still five rows, still the six basic operators, no range operator and no Exit Criteria Result. It tests the signal that stopped the process, not an exit code.

UNIX exit codes of 128 and above arrive negative

Unless the LSAM's LSAM_0_255 option is enabled — it is off by default — a UNIX exit code of 128 or more reaches OpCon Continuum as a negative number. Write the criteria against the value the agent actually reports, which is visible as the job's Return Code.

The exit code is also the job's termination description

A Windows, UNIX/Linux or SQL legacy job that reports an exit code now carries that code as its termination description, whether it finished OK or failed — the same thing Classic records for these jobs.

This is what makes an Exit Description workflow event usable on a legacy job. The trigger compares the termination description, and until now a legacy job had nothing to compare: a successful job's description was blank, and a failed one read Job failed. A trigger written for 0 therefore never fired, on any legacy job. Writing the exit code there fixes that, so a trigger can key off a specific code.

One case keeps its text instead: a failure with no exit code — the relay could not reach the agent, or the job never produced one. The message describing that failure is more use than a blank, so it stays.

A job whose outcome exit criteria decided keeps its exit code too. Deciding the verdict centrally used to replace the description with Finished OK (Exit Criteria) Return Code='N' / Failed (Exit Criteria) Return Code='N', which overwrote the very code an Exit Description event compares — so such an event could never fire on a job with an exit-criteria table, including an EqualTo 0. The exit code now stays, on either outcome, and the exit-criteria line is recorded in the job's log rather than over the description. Classic behaves the same way.

For a job type that is not one of the three above, exit criteria still writes that line as the description, except on a failure where the agent gave a reason of its own — an OpCon MFT failure message, say — which is kept.

SMAFT file-transfer and IBM i jobs are not included in the exit-code-as-description rule. Their Classic termination text has not been confirmed, and writing a plausible value would be worse than writing none.

UNIX/Linux LSAM — additional parameters

Parameter	Required	Limits	Notes
batchUserId	Yes	a saved connection	The UNIX user and group the job runs as — a UNIX Batch User connection. A UNIX job must name one; without it the dispatch fails (RC_NO_UID). See Batch User.
niceValue	No	-20 to 19	Process priority (-20 highest, 19 lowest).
signalCriteria	No	≤5 conditions	Signal conditions that mark the job failed (same operator/value form as exitCriteria).
coreDumpFlag	No	Y / N	Whether a core dump fails the job.
environmentVariables	No	—	Environment variables to set for the job.

Watching for a file is its own job type now

The command job used to carry a jobSubType field whose F value meant file watcher. It has been removed. Waiting for a file on a UNIX agent is the separate UNIX - File Arrival job type, which has its own fields and needs no command line.

UNIX values reach the agent exactly as you typed them

A UNIX job's values — start image, parameters, environment variables — are sent to the agent unaltered. Quotes, ampersands and angle brackets arrive as the characters you wrote, so /bin/sh -c "exit 3" runs the command you meant.

This is a correction. The relay used to convert those five characters to XML entities on every platform, and a UNIX agent does not convert them back — so the shell received the entity text itself. A command containing a double quote exited 127 with the agent reporting quot: not found, and the same went for &, <, > and '. Windows, IBM i and SQL jobs are unaffected: those agents do decode the entities, and their values are still escaped for transport.

Sending a value untouched means two character sequences can no longer be carried, because the agent would read them as part of the message rather than as your text. Both are refused at dispatch, naming the field code, and the job fails without running:

Rejected in a UNIX value	Why
</F>	The agent finds where a value ends by looking for the first </F>, so the value would be silently truncated there — you would get a shortened command with no indication anything was lost (RC_FIELD_VALUE_CONTAINS_FIELD_TERMINATOR).
<F I=	It looks like the start of another field. The agent takes the first match for each field it wants, so text like this in an earlier value could stand in for a later field — overriding, for instance, the account the job runs as (RC_FIELD_VALUE_CONTAINS_FIELD_TAG).

Both matches are case-sensitive, as the agent's own search is. Neither sequence has a use in a shell command; if you need the characters for something else, put them in a script on the machine and run that.

Windows LSAM — additional parameters

The Windows LSAM job is at functional parity with the legacy basic Windows job. In addition to the shared parameters above:

Parameter	Required	Limits	Notes
batchUserId	No	a saved connection	The Windows account the job runs as — a Windows Batch User connection. Blank runs the job under the LSAM's own service account. See Batch User.
workingDir	No	≤255 chars	Working directory for the job.
preRunWorkingDir	No	≤255 chars	Working directory for the prerun command.
runInCommandShell	No	boolean (default off)	Run the command inside a command shell (relay emits FC 3030 only when enabled).
environmentVariables	No	—	Environment variables (Name=Value) to set for the job. Supported on Windows as on UNIX — the relay emits FC 3036.
outputParsing	No	≤5 rules	Scan the job output for text and set an exit code when it matches. Each rule is a searchOperation (Contains / Does Not Contain), a stringToFind (1–255 chars), and an exitCodeToSet (relay FCs 3032/3033/3034).
customLogFilePath	No	≤255 chars	Log file that output parsing scans. Defaults to the job's standard output (relay FC 3035). It is presented with the Output Parsing rules in the job editor rather than as a field of its own, because it only affects what those rules read.

Windows LSAM limitations — read before troubleshooting. On Windows LSAM today:

• A job runs as the Windows Batch User connection attached to it, or as the LSAM's own service account when none is attached — see Batch User.
• Embedded scripts are not supported — the jobSubType field is not available on the Windows job; use startImage + parameters or a script already on the machine.
• Windows returns a single integer exit code, so signalCriteria and coreDumpFlag do not apply.
• environmentVariables are supported on Windows, the same as on UNIX.

Windows LSAM — WS_FTP Pro file transfer

A second Windows LSAM job type, Windows - WS_FTP Pro (windows-wsftp-pro), is registered alongside windows-command on the same opcon.lsam.windows plugin (Windows LSAM agents only). It runs a WS_FTP Pro file transfer on the machine.

WS_FTP Pro has no dedicated LSAM field codes. The transfer runs as an ordinary Windows Run Program job: the relay assembles the form fields into a wsftppro.exe command line (FC 3003) plus a working directory (FC 3004). There is no startImage/parameters on this job type — the command line is built entirely from the fields below.

Authentication is delegated to WS_FTP Pro site profiles configured on the agent. The job references a source and a destination profile by name only and carries no credentials; the named profiles must already exist in the WS_FTP Pro installation on that machine.

Parameter	Required	Limits	Notes
machineName	Yes	1–24 chars	Target Windows LSAM machine; must match the registered agent name.
batchUserId	No	a saved connection	The Windows account the job runs as. Blank runs it as the agent's service account. See Batch User.
wsFTPProLocation	Yes	1–253 chars, no "	Folder containing wsftppro.exe. Capped at 253 so the quote-wrapped working directory (FC 3004) stays within its 255 cap.
sourceProfile	Yes	no " or :	WS_FTP Pro site profile name for the source.
sourceFile	Yes	no "	Source file to transfer.
destinationProfile	Yes	no " or :	WS_FTP Pro site profile name for the destination.
destinationFile	Yes	no "	Destination file to write.
fileTransferOptions	No	free text	Extra wsftppro.exe command-line switches (e.g. -binary -delete); appended verbatim, only when non-empty.

Validation happens at the relay, not the form. Plugin job-schema patterns and lengths are UI render hints only — a job is not checked against them when you save it, so a job with a bad value saves cleanly and then fails when it runs. The relay is the enforcement point and rejects: a missing required field (RC_MISSING_WSFTP_FIELD); a double quote in any of the five required text fields, or a colon in either profile field (RC_INVALID_WSFTP_FIELD — : delimits profile from file in the assembled command line); a command line over 4000 chars (RC_CMDLINE_TOO_LONG); or a working directory over 255 chars (RC_WORKDIR_TOO_LONG). A trailing backslash in sourceFile/destinationFile (e.g. C:\archive\) is preserved losslessly — the relay doubles it so it can't escape the closing quote and swallow later options.

Windows LSAM — file operations

Four more Windows LSAM job types cover routine file housekeeping, registered alongside windows-command and windows-wsftp-pro on the same opcon.lsam.windows plugin (Windows LSAM agents only):

Job type	Name	Underlying command	Purpose
windows-file-copy	Windows - Command: File Copy	xcopy	Copy one or more files (wildcards allowed).
windows-file-move	Windows - Command: File Move	move	Move one or more files, overwriting the destination without prompting.
windows-file-rename	Windows - Command: File Rename	rename	Rename a single file (cannot overwrite an existing name).
windows-file-delete	Windows - Command: File Delete	del	Delete one or more files or directories (wildcards allowed).

As with WS_FTP Pro there is no startImage/parameters on these job types — the relay assembles the whole command line from the fields below and runs it through the Windows command shell. Each of them runs under whichever Windows Batch User connection is attached, or under the LSAM's own service account when the Batch User field is left blank.

All four also take machineName (required, 1–24 chars), which must match the registered Windows LSAM agent name.

File Copy — additional parameters

Parameter	Required	Notes
sourceFile	Yes	Directory and file(s) to copy. Wildcards copy multiple files.
destinationFile	Yes	Destination directory and/or file name.
destinationType	No	File (default) or Directory — answers the file-vs-directory question xcopy would otherwise prompt for.
verifyDestinationFiles	No	Verify each copied file (default on).
useShortNameFormat	No	Use the short (8.3) name when copying a non-8.3 file (default off).
copySubdirectories	No	Copy subdirectories, skipping empty ones (default off).
otherOptions	No	Extra xcopy switches. Run xcopy /? on the machine to list them.

File Move — additional parameters

Parameter	Required	Notes
sourceFile	Yes	Directory and file(s) to move.
destinationFile	Yes	Destination directory and/or file name. Existing files are overwritten without prompting.

File Rename — additional parameters

Parameter	Required	Notes
currentFileName	Yes	Drive, full path, and file to rename.
newFileName	Yes	New name for the file. Rename cannot overwrite an existing name.

File Delete — additional parameters

Parameter	Required	Notes
fileToDelete	Yes	Comma-separated list of one or more files or directories; wildcards allowed. Naming a directory deletes every file in it.
forceDeleteReadOnlyFiles	No	Delete read-only files too (default off).
deleteSpecifiedFilesFromAllSubDirectories	No	Delete the named files from all subdirectories (default off).
Attribute filters	No	Read Only, Not Content Indexed, Archive, Hidden, System, and Reparse Point — set each to Include (delete only files carrying that attribute) or Exclude (skip them). Leave a filter unset to ignore that attribute.
otherOptions	No	Extra del switches. Run del /? on the machine to list them.

Good to know

• These are the first relay-assembled command lines that run through a shell, so an operand containing a space or a shell metacharacter (&, |, <, >, ^) is quoted automatically. A trailing backslash is doubled first so it can't escape the closing quote.
• File Delete quotes each entry separately, because fileToDelete is a list — quoting the whole value would collapse it into one file name that doesn't exist.

Windows LSAM — Corelation batch job

A seventh Windows LSAM job type, Windows - Corelation (windows-corelation), registered alongside the other Windows types on the same opcon.lsam.windows plugin (Windows LSAM agents only). It submits and monitors a Corelation batch job through SMA's Corelation connector (SMARunCorelationJob.exe) on the machine.

Corelation has no dedicated LSAM field codes. As with WS_FTP Pro and the file-operation types, the relay assembles the form fields into a SMARunCorelationJob.exe command line (FC 3003) plus a working directory (FC 3004) — there is no startImage/parameters on this job type. The SMARunCorelationJob.exe connector, and a configuration file holding the Corelation connection details, must already be present in the connector folder on that machine. The job runs under whichever Windows Batch User connection is attached, or under the LSAM's own service account when the Batch User field is left blank.

Parameter	Required	Limits	Notes
machineName	Yes	1–24 chars	Target Windows LSAM machine; must match the registered agent name.
batchUserId	No	a saved connection	The Windows account the job runs as. Blank runs it as the agent's service account. See Batch User.
connectorLocation	Yes	1–253 chars, no "	Folder containing SMARunCorelationJob.exe; also the job's working directory. Capped at 253 so the quote-wrapped working directory (FC 3004) stays within its 255 cap.
type	No	Job Name (default) / Job Serial	Whether Corelation Job below is a job name or a job serial.
corelationJob	Yes	no "	The Corelation job name or serial to submit.
configurationFile	No	≤255 chars, no "	Connector configuration file with the Corelation connection details. Defaults to .\SMARunCorelationJob.ini; a relative path resolves against the connector folder.
batchServer	No	no "	Corelation batch server name. Leave blank to use the connector's default (Batch Server).
batchQueue	No	no "	Corelation batch queue. Defaults to leastbusy, which picks the least-loaded open queue.
formatAs	No	Batch Options (default) / Parameters	How the runtime parameters below are passed to the connector.
propertyOwner	No	no "	Parent property that wraps the batch options. Applies only when Parameter Format is Batch Options; ignored otherwise.
parameters	No	≤99 entries	Runtime parameters as Name/Value pairs. Neither name nor value may contain a double quote (") or a pipe (|).
includeXMLInOutput	No	boolean (default on)	Log every Corelation request and response XML to the job output.
showViewSubmitResponse	No	boolean (default off)	Log the VIEW_SUBMIT response.
includeJobDetailsInOutput	No	boolean (default off)	Retrieve job details only — the Corelation job is not run.
showJobList	No	boolean (default off)	List the available Corelation jobs in the job output.
includeDebugMessages	No	boolean (default off)	Verbose connector debug output (also logs the XML).

Validation happens at the relay, not the form — the same rule as WS_FTP Pro and the file operations. A bad value saves cleanly and then fails when the job runs. The relay rejects a missing required field (RC_MISSING_CORELATION_FIELD); a double quote in any text field, a pipe in a parameter name/value, an unrecognized type/formatAs value, or a blank parameter name (RC_INVALID_CORELATION_FIELD); more than 99 parameters (RC_TOO_MANY_CORELATION_PARAMETERS); a command line over 4000 characters (RC_CMDLINE_TOO_LONG); or a working directory over 255 characters (RC_WORKDIR_TOO_LONG). A trailing backslash in a value (for example C:\Reports\) is preserved losslessly — the relay doubles it so it can't escape the closing quote and swallow the switches that follow.

Windows LSAM — Fiserv DNA jobs

Two more Windows LSAM job types cover for running Fiserv DNA jobs, registered alongside the other Windows types on the same opcon.lsam.windows plugin (Windows LSAM agents only):

Job type	Name	Purpose
windows-fiserv-dna	Windows - Fiserv DNA	Run a DNA SQT job — a DNA application (APPL), optionally scoped by cycle codes.
windows-fiserv-dna-fileloader	Windows - Fiserv DNA (File Loader)	Load a file into DNA — the PS_FILELOADER application with file batch/record counts and control totals.

Both run a job through SMA's DNA connector (SMARunDNAJob.exe) on the machine. Like WS_FTP Pro, the file-operation types, and Corelation, DNA has no dedicated LSAM field codes: the relay assembles the form fields into a SMARunDNAJob.exe command line (FC 3003) plus a working directory (FC 3004), so there is no startImage/parameters on either job type. The SMARunDNAJob.exe connector, and a configuration file, must already be present in the connector folder on that machine. Both types run under whichever Windows Batch User connection is attached, or under the LSAM's own service account when the Batch User field is left blank.

Credentials live in the configuration file, not the job. The DNA/SQT (Oracle) user name and password are read — and decrypted — by the connector from the [SQRT Parameters] section of the configuration file. They are deliberately not job parameters, so a DNA job carries no credentials of its own.

Common parameters (both types)

Parameter	Required	Limits	Notes
machineName	Yes	1–24 chars	Target Windows LSAM machine; must match the registered agent name.
batchUserId	No	a saved connection	The Windows account the job runs as. Blank runs it as the agent's service account. See Batch User.
connectorLocation	Yes	1–253 chars, no "	Folder containing SMARunDNAJob.exe; also the job's working directory. Capped at 253 so the quote-wrapped working directory (FC 3004) stays within its 255 cap.
configFile	No	≤255 chars, no "	Connector configuration file (holds the [SQRT Parameters] credentials). Defaults to .\SMARunDNAJob.ini; a relative path resolves against the connector folder.
applicationName	Yes (SQT)	no "	DNA application (APPL) name; also names the connector's log file, so avoid characters that are invalid in a file name. On the File Loader it defaults to PS_FILELOADER (the fixed DNA application for file loads).
applicationNumber	No	no "	DNA application (APPL) number. The connector prefers it over the name for the database lookup.
effectiveDate	No	no "	Run date of the request. The connector requires exactly 10 characters and otherwise doesn't validate the format; leave blank to let it derive the date from the DNA BANKOPTION table.
effectiveDateOffset	No	-365 to 365	Day offset applied to the effective date.
parameters	No	≤99 entries	Runtime parameters as Name/Value pairs (see Runtime parameters below). Neither name nor value may contain a double quote (") or a pipe (|).

Fiserv DNA (SQT job) — additional parameters

Parameter	Required	Limits	Notes
cycleCodeNotRequired	No	boolean (default off)	Skip the connector's check that the application has cycle codes.
cycleCodes	No	≤99 entries	Cycle codes to run (for example EOM, EOQ). No entry may contain a double quote (") or a pipe (|); a blank entry is rejected.

Fiserv DNA (File Loader) — additional parameters

The File Loader always runs the PS_FILELOADER application, so it takes the file's identity and control totals instead of cycle codes. Each value may be a literal or the name of an OpCon property to resolve at run time.

Parameter	Required	Limits	Notes
fileName	Yes	no "	Name of the file to load, matched against DNA's EXTFILE table.
fileBatchCount	Yes	no "	Batch count.
fileRecordCount	Yes	no "	Record count.
credits	Yes	no "	Total credit amount.
debits	Yes	no "	Total debit amount.
fileNumber	Yes	no "	File number.

Runtime parameters

parameters is a list of Name/Value pairs (up to 99). Each pair may optionally carry date handling:

• Date type — Business date (B) or Calendar date (O); required before an offset or a date format can be set.
• Offset — a day offset (-365 to 365); requires a date type.
• Date format — honored only with Calendar date (O) and an offset set; it is ignored on the Business date (B) path, so setting it there is rejected rather than silently dropped.

Neither the name, the value, nor the date format may contain a double quote (") or a pipe (\|) — the pipe delimits the parts of a parameter internally. A blank value is allowed (the connector maps it to a database NULL); a blank name is not.

Validation happens at the relay, not the form — the same rule as WS_FTP Pro, the file operations, and Corelation. A bad value saves cleanly and then fails when the job runs. The relay rejects a missing required field (RC_MISSING_DNA_FIELD); a double quote in any text field, a pipe in a cycle code or a parameter name/value/date-format, a blank parameter name or cycle code, an unrecognized date type, an offset or date format without the date type it requires, or a value of the wrong type (RC_INVALID_DNA_FIELD); more than 99 parameters (RC_TOO_MANY_DNA_PARAMETERS); more than 99 cycle codes (RC_TOO_MANY_DNA_CYCLE_CODES); a command line over 4000 characters (RC_CMDLINE_TOO_LONG); or a working directory over 255 characters (RC_WORKDIR_TOO_LONG). Every value is quoted for you, and a trailing backslash in a value (for example C:\DNA\) is preserved losslessly — the relay doubles it so it can't escape the closing quote and swallow the switches that follow.

Windows LSAM — File Arrival

The Windows - File Arrival job type (windows-file-arrival) is registered alongside the other Windows types on the same opcon.lsam.windows plugin (Windows LSAM agents only). It waits for a file to appear on the machine during a time window and succeeds once the file has arrived and stopped changing, so a downstream job can depend on it and only run after the file is really there.

Unlike the other assembled-command-line Windows types (WS_FTP Pro, the file operations, Corelation, and Fiserv DNA), File Arrival needs no connector installed and no command line: the LSAM agent's own built-in file watcher does the watching. You only describe what to watch for and when to watch. The job runs under whichever Windows Batch User connection is attached, or under the LSAM's own service account when the Batch User field is left blank.

Parameters

Parameter	Required	Limits	Notes
machineName	Yes	1–24 chars	Target Windows LSAM machine; must match the registered agent name.
batchUserId	No	a saved connection	The Windows account the job runs as. Blank runs it as the agent's service account. See Batch User.
fileName	Yes	1–4000 chars, no "	Full path and file name to watch for. Wildcards * and ? are allowed in the file name part; the directory part must already exist, or the job fails. UNC paths and %ENVVAR% references are allowed; double quotes are not.
startOffset	No	-142560 to 143999	When to start watching, relative to midnight of the job's schedule date. Authored as a Day Offset plus a Time — see Authoring the watch window. Defaults to 0.
endOffset	No	-142560 to 143999	When to stop watching, relative to midnight of the job's schedule date. Must not be earlier than startOffset. To watch across midnight, use a later day rather than an earlier time. Defaults to 0.
fileSizeStableTime	No	1 to 999	Seconds to wait before re-checking the file, to confirm it has been completely written. The file counts as complete once its size, creation time, and last-write time are all unchanged across the interval. Defaults to 5.
includeSubdirectories	No	boolean (default off)	Also watch subdirectories of the given path.

Leave both offsets at zero to check whether the file already exists right now and finish immediately, rather than waiting for a window.

Watching is a long wait

A File Arrival job stays running for the whole window, which can be many hours, and finishes as soon as the file arrives and settles. Size the window with the start and end offsets to match when you actually expect the file.

Authoring the watch window

Both offsets are authored as a pair of controls — a Day Offset box and a Time picker — rather than as a raw minute count:

Control	What it takes
Day Offset	Whole days from the job's schedule date, -99 to 99. 0 is the schedule date itself, -1 the day before, 1 the day after. The sign lives here: this is the only one of the two controls that accepts a negative value.
Time	A 24-hour clock time, 00:00 to 23:59, on that day.

So a window of 08:00 on the schedule date to 00:45 the following morning is Day Offset 0 / Time 08:00 to Day Offset 1 / Time 00:45. That is the same stored value the platform has always held — a single count of minutes from midnight of the schedule date — presented as the day and the clock time it works out to. Nothing about an existing job's saved window changes, and neither does what reaches the agent.

Good to know

Day Offset is days, not minutes. The pair replaces a single box that took the whole offset in minutes, so 480 meant 08:00. Typing 480 into Day Offset now asks for a window 480 days out — and because that is still inside the stored range, nothing downstream objects. The box refuses any day outside -99 to 99 and snaps back to the stored day when you leave it, so a rejected entry never looks accepted.

An offset the pair cannot express — a value outside the range, or a property reference standing in for the number — falls back to the plain numeric box, still in minutes, and is left exactly as stored.

Outcome and exit codes

The job succeeds when a matching file arrives and stops changing within the window, and fails otherwise. The specific reason is preserved as the job's exit code, visible on the job's Completion and Output detail:

Exit code	Meaning
0	A file matched. The job succeeds.
1	The window elapsed with no match.
2	The monitored directory doesn't exist.
3	A candidate file's creation time predates the start of the window.
4	A network path was still unreachable at the end of the window.
-1	An argument or range error.

Only 0 is a success — every non-zero code is reported as Failed — but the number stays on the job, so you can tell why it failed after the fact.

Validation happens at the relay, not the form

The same rule as the other Windows LSAM job types: a bad value saves cleanly and then fails when the job runs. The relay rejects a missing file name (RC_MISSING_FILEARRIVAL_FIELD); and a double quote in the file name, a file name over 4000 characters, an offset or stable time that isn't a whole number in range, an endOffset earlier than startOffset, or a non-boolean "include subdirectories" (RC_INVALID_FILEARRIVAL_FIELD). A trailing backslash in the file name is preserved losslessly — the relay doubles it so it can't escape the watcher's closing quote.

UNIX/Linux LSAM — File Arrival

The UNIX - File Arrival job type (unix-file-arrival) is registered alongside UNIX/Linux - Command on the same opcon.lsam.unix plugin (UNIX/Linux LSAM agents only). Like its Windows counterpart it waits for a file to arrive during a time window and succeeds once a matching file has arrived and stopped growing, so a downstream job can depend on it and only run once the file is really there.

It needs no command line: the LSAM agent watches for the file itself. You describe what to watch for and when to watch.

Parameters

Parameter	Required	Limits	Notes
machineName	Yes	1–24 chars	Target UNIX/Linux LSAM machine; must match the registered agent name.
batchUserId	Yes	a saved connection	The UNIX Batch User connection the job runs as. As with every UNIX job type it is required — there is no "run as the agent's own account" option the way there is on Windows — and the account it names has to be able to read the arrived file. See Batch User.
fileName	Yes	1–255 chars	Absolute path of the file to watch for. See What the path may contain below.
startOffset	No	-142560 to 143999	When to start watching, relative to midnight of the job's schedule date. Authored as a Day Offset plus a Time, the same pair as the Windows type — see Authoring the watch window. Defaults to 0.
endOffset	No	-142560 to 143999	When to stop watching, relative to midnight of the job's schedule date. Must not be earlier than startOffset. 0 means that midnight, not now. To watch past midnight, use a later day rather than an earlier time. Defaults to 0.
fileSizeStableTime	No	1 to 999	Seconds to wait before re-checking the file's size, to confirm it has been written completely. Defaults to 5.
includeSubdirectories	No	boolean (default off)	Also search every subdirectory of the given directory.

Leave both offsets at zero to ask whether a matching file exists right now and finish immediately, rather than waiting for a window.

A file counts only if it was last modified inside the window. A file that keeps growing keeps the job waiting — even past the end of the window — until its size holds steady across fileSizeStableTime.

Stability is judged on size alone here

The Windows type treats a file as complete once its size, creation time and last-write time are all unchanged across the interval. The UNIX agent compares size only. A file whose timestamps move but whose length does not will satisfy a UNIX watch and not a Windows one.

What the path may contain

The file-name part may use the wildcards *, ? and [...]. Matching is case-sensitive, and files whose names begin with a dot are ignored.

The directory part is taken literally — no wildcards — must already exist, and must not contain spaces. A directory that doesn't exist is the job's exit code 2 rather than a wait that never matches.

These characters are refused anywhere in the path, as are control characters:

` $ " \ ; | & < > ( ) '

The refusal is stricter than Classic's, on purpose

Classic accepts those characters; Continuum does not, on any agent. Older UNIX agents match files by handing the name to a shell, so a crafted file name could run commands as the account the agent runs under. Newer agents never reach a shell, but an agent does not reliably report its version, so the restriction applies to every agent rather than only the ones that need it. If you need one of these characters in a watched path, you cannot use this job type for it.

Outcome and exit codes

A matching file makes the job succeed; anything else makes it fail. The reason survives as the job's exit code:

Exit code	Meaning
0	A file matched. The job succeeds.
1	The window elapsed with no match, or the file could not be read.
2	The directory being watched doesn't exist.
3	A candidate file was last modified outside the window.
-1	The end offset was earlier than the start offset.

No exit criteria on this job type

Neither File Arrival type offers an exit criteria table. The watcher's own exit status is the verdict, so there is nothing for a table to reinterpret — only 0 is a success. The exit code still stays on the job, so you can tell which failure you had.

Validation happens at the relay, not the form

As with the other legacy job types, a bad value saves cleanly and then fails when the job runs. The relay refuses a missing file name (RC_MISSING_FILEARRIVAL_FIELD); and a file name over 255 characters, one holding a refused character, whitespace in the directory part, an offset or stable time that isn't a whole number in range, or an endOffset earlier than startOffset (RC_INVALID_FILEARRIVAL_FIELD).

The file that arrived is available to later jobs

Once a File Arrival job matches — Windows or UNIX — the path it matched is recorded on the job instance. It shows on the job's Summary tab as Arrived File, and five properties carry it and its parts into the events and notifications that job fires, so a downstream job can be handed the actual file name rather than the pattern that found it.

The recorded path belongs to the attempt, not the job. A new attempt clears it when it starts, a job that fails before it is dispatched carries none, and a recurrence or a container's nested child starts each run clean — so an event can never be handed the previous run's file. A job parked between a failure and its retry keeps the failed attempt's file, because a File Arrival job can fail after matching and that attempt's events should still name what it found.

UNIX/Linux LSAM — Embedded Script

The UNIX - Embedded Script job type (unix-embedded-script) runs a script held in the script library rather than one pasted into the job — the UNIX counterpart of Windows - Embedded Script. On the job you choose the script, the version to run, the runner that starts it, and any arguments:

Field	Notes
Batch User	Required. It is also the account that owns the script file the agent writes for the run.
Script	The library script to run. Only scripts whose language has a UNIX runner are listed — Shell, Bash, Perl and Python in the built-in catalog, plus any script type your tenant has added a UNIX runner for.
Version	Leave empty to always run the latest version, or pin a specific version number.
Runner	The program that runs the script on the agent. The choices depend on the script's language, so pick the script first.
Arguments	Optional, up to 2000 characters.

It carries the ordinary UNIX job settings as well — exit criteria, signalCriteria, the core-dump flag and environment variables.

Arguments are not quoted for you

Arguments are inserted unquoted into the runner's command line, so the agent's shell interprets quotes, $VAR references and metacharacters such as ; | & and >. Quote them yourself if you mean them literally. This is the same rule as UNIX values reach the agent exactly as you typed them.

As on Windows, the job holds a reference rather than a copy: fixing the script in the library reaches every job that tracks the latest version, and a script cannot be deleted while a job references it. The script and the runner are also checked when the workflow is saved, and a job whose script or runner has been deleted says so on the field rather than showing a bare identifier. See Script library.

The built-in UNIX runners name their interpreter by absolute path — /bin/sh, /bin/bash, /usr/bin/perl, /usr/bin/python3 — and a host without the interpreter at that path fails when the script starts. If your machines keep an interpreter somewhere else, add a runner that names the path they actually use; a UNIX command format is limited to 127 bytes and $FILE has to be its own space-separated word. See Runners.

UNIX/Linux LSAM — Episys (RSJ) job types

Seven job types drive Symitar/Episys core banking on a UNIX LSAM machine through the RSJ utilities installed there. Each one is a form that builds the RSJ command line for you, so there is no command-line field to fill in.

Job type	What it does
UNIX - Episys: Run JobFile (unix-episys-run-jobfile)	Runs a batch job file from the partition's BATCH directory.
UNIX - Episys: Answer Prompts (unix-episys-answer-prompts)	Fills in the prompts in a batch job's control file.
UNIX - Episys: Compare ACH Totals (unix-episys-compare-ach-totals)	Compares a FED ACH file's totals against an Episys batch output.
UNIX - Episys: Find Batch Output Sequence Number (unix-episys-find-batch-output-sequence)	Finds a job's batch output sequence number and writes it to a property.
UNIX - Episys: Find Report from RSJ Output (unix-episys-find-report-rsj-output)	Finds a report by title in a job's RSJ output and writes its sequence number to a property.
UNIX - Episys: Find Report from Episys Reports (unix-episys-find-report-episys-reports)	Finds a report by title in the partition's report directory and writes its sequence number to a property.
UNIX - Episys: FTP all Reports in List (unix-episys-ftp-reports)	Sends every report listed in a file to an FTP destination.

Fields every Episys type shares

Field	Notes
Batch User	Required. RSJ and the Episys utilities run as this UNIX user.
RSJ Path	Where RSJ is installed on the machine. It defaults to [[RSJPATH]], which reads a global property of that name — the job fails before it starts if that property does not exist. Create RSJPATH once and every Episys job picks it up, or type a path on the job to override it.
SYM Number	The Symitar partition number, such as 001. The SYM prefix is added for you.

Episys Job, where the type takes one, names the batch job file. Run JobFile allows up to 30 characters, because that is RSJ's own limit; the others allow 32.

Per-type fields worth knowing

• Run JobFile takes an optional Restart Point (a label in the job file to resume from), an optional Edit File, a Multi-thread switch that runs without RSJ's partition lock, and Delete edit file to remove the edit file when the job succeeds. Edit File and Multi-thread cannot be combined.
• Answer Prompts takes one row per prompt, each a Prompt and a Response; at least one row is required. A prompt may not contain a colon or a double quote, and a response may not contain a double quote. A response may end in :N to change the Nth occurrence instead of the first. Update First Match Only is on by default. Extract Daily/Monthly Group List in Use converts ^ to , in each response before it is applied.
• Compare ACH Totals takes the FED File and the Batch Output File. A bare name is looked up in the partition's own directories rather than requiring a full path.
• The three Find types write their answer to the Property Name you give, and take a MSGIN Directory used when the utility cannot reach the agent directly. The two report-finding types take a Report Name and an optional Occurrence To Search For (1–99; the first, if empty).
• FTP all Reports in List takes the list file as Report Name, a Destination Host Name, a Port Number (21 by default), a Destination Folder, and an optional Extension added to each remote file name.

Report Name is sent unquoted

On the two report-finding types, Report Name is passed to the utility without quoting. For a title containing spaces, type the quotes yourself — "ACH REPORT".

Episys credentials

Four of the seven types need a credential of their own, on top of the batch user, and it is held as a saved connection rather than typed into the job:

Connection type	Used by	Holds
Episys External Event Credential (episys-event-credential)	The three Find types	The OpCon user and External Event Password the utility sends the property update with.
Episys FTP Credential (episys-ftp-credential)	FTP all Reports in List	The FTP user and password to log in with.

On both, leave the password blank when editing to keep the one already stored. The External Event Password is sent in double quotes, so it may not contain a double quote. The FTP user and password are passed unquoted and may not contain spaces; on an agent that runs jobs through the shell — the default — characters such as $ ` \ & and ; in the FTP password are interpreted by the shell.

An Episys credential appears in the job's output

The UNIX agent prints the full command line at the top of every job's output, and for these four job types that command line contains the password. Anyone who can read the job's output can read the credential, and it stays in the stored output until the job is rerun or the instance is deleted — refreshing the output re-reads the same text rather than clearing it.

Treat these credentials as visible to everyone who can see the job, and give them the narrowest rights that let the utility do its work. There is also no per-connection permission on picking one: anyone who can author an Episys job can select any Episys credential saved in your tenant.

Outcomes

Result	When
Success	The exit code satisfied the job's exit criteria — or, with no table, was 0 — and no UNIX signalCriteria/core-dump condition marked it failed.
Failed — by criteria	The exit code resolved to failed against the job's exit criteria, or a UNIX signal/core dump matched a failure condition.
Failed — dispatch rejected	The job couldn't be dispatched (e.g. the attached batch user is of the wrong platform's type or is incomplete, or machineName doesn't match a registered LSAM agent).

Troubleshooting

Symptom	Likely cause	Resolution
"No agent available" for an LSAM command	The relay is down, or the LSAM machine is unreachable	Check the relay and LSAM connectivity (Administrator) — this is not a Universal Agent issue.
Legacy agent shows UNKNOWN (amber)	Its relay is stale/down — reachability can't be determined (not the same as the agent being down)	Check the relay; agents leave UNKNOWN within a heartbeat once it recovers (Administrator).
Newly registered legacy agent isn't picked up	Relay hot-reconcile hasn't run yet, or registration failed (e.g. duplicate name per relay)	Wait one heartbeat; confirm the agent was registered on the Legacy Agents page with a name unique to that relay (Administrator).
Job can't be placed / unknown machine	machineName doesn't match the LSAM agent name registered with the relay	Correct machineName to the registered agent name (Builder/Administrator).
Windows job rejected at dispatch: no login name / no password (RC_NO_RUNAS_LOGIN / RC_NO_RUNAS_PASSWORD)	The attached Windows Batch User is a named account missing its login name or password	Complete the connection, or turn Use Service Account on (Administrator) — see Connections.
UNIX job rejected at dispatch: RC_NO_UID / RC_NO_GID	No batch user is attached, or its user or group is blank	Attach a complete UNIX Batch User connection (Builder/Administrator).
Any legacy job rejected at dispatch: RC_WRONG_CONNECTION_TYPE	The job's connection is of the wrong platform's type — usually from a hand-edited config, an import, or a transformation rule	Re-pick the account in the Batch User field (Builder).
File operation (Copy/Move/Rename/Delete) rejected at dispatch	A required field is blank, an attribute filter value is invalid, or the assembled command line or working directory is too long	Fill every required field and shorten the command. The form won't catch these — they surface only at dispatch (Builder).
File Delete removed the wrong files, or nothing	The comma-separated file list or an attribute filter doesn't match what you intended	Re-check the list and the filters: Include deletes only files carrying that attribute, Exclude skips them (Builder).
Windows job ignores an embedded script	Embedded scripts (jobSubType) are not supported on Windows LSAM	Use startImage + parameters, or a script already on the machine (Builder).
WS_FTP Pro job rejected at dispatch	A required field is blank, a required text field contains a ", a profile field contains a :, or the assembled command line/working directory is too long	Fill every required field; remove " from all five text fields and : from the profile names; shorten the location/options (Builder). The form won't catch these — they surface only at dispatch.
WS_FTP Pro transfer fails to authenticate	The referenced source/destination site profile doesn't exist on the agent, or its stored credentials are wrong	Create/repair the named profiles in the WS_FTP Pro installation on that machine (Administrator); the job carries no credentials of its own.
Windows job ignores environment variables	The relay or agent is running an older build that doesn't emit them on Windows	Confirm the relay and agent are on a current build; env vars are emitted as FC 3036 (Builder/Administrator).
Job ran but is marked failed	An exitCriteria (or UNIX signalCriteria/core-dump) condition matched	Confirm the criteria match the program's real success/failure codes (Builder).
Windows job now fails (or succeeds) where it didn't before	Its exitCriteria are being evaluated. Earlier builds discarded them and failed on any non-zero exit code, so criteria that were configured but ineffective now take effect	Re-check the criteria against the program's real codes — this is the criteria doing what they say, not a new fault (Builder).
Job rejected at dispatch on its exit criteria	More than 20 conditions, a missing or unrecognised operator, or a value that isn't a whole number in range	Use up to 20 conditions, each with a valid operator and a whole-number value in range (Builder).
Job with Finish OK, a range row, or more than five conditions never starts	The relay serving that machine predates those forms and refuses the dispatch rather than sending a table it cannot represent	Upgrade the relay. Until then, express the table as up to five plain failure conditions with Exit Criteria Result Fail (Administrator).
Job finished OK but the agent's log says it failed	Its table was evaluated centrally, so the agent was given the platform default and reached the opposite conclusion	Read the job's termination text — Finished OK (Exit Criteria) Return Code='N' names the layer that decided — and the Exit criteria evaluated entry in Job History (Operator).
File Arrival job rejected at dispatch	The file name is blank, over 4000 characters, or contains a "; an offset or stable time isn't a whole number in range; or endOffset is earlier than startOffset	Give a valid file name without "; use whole-number offsets and stable time in range, and keep endOffset at or after startOffset. The form won't catch these — they surface only at dispatch (Builder).
File Arrival job fails with exit code 2	The directory in fileName doesn't exist on the machine — only the file name part may use wildcards	Point fileName at a directory that already exists on the LSAM machine, creating it first if needed (Builder / Administrator).
File Arrival job never finds the file	The window (startOffset / endOffset) closed before the file arrived, or the path or wildcard pattern doesn't match	Widen the window to when the file really appears, and check the path and pattern. Check the Day Offset boxes too — a minute count typed there reads as days. For a bare "does it exist now?" check, set both offsets to zero (Builder).
UNIX job fails with a permissions error	The attached UNIX Batch User's user or group lacks rights to run startImage	Attach a batch user whose user/group has the right permissions on the LSAM machine (Builder/Administrator).

Contact support when

• The relay and LSAM machine are confirmed healthy and machineName is correct, but jobs still can't be dispatched or never report completion.
• Exit/signal handling doesn't match what the LSAM machine actually returned.

Include the connector (UNIX/Windows), machineName, startImage/parameters, the configured exitCriteria, and the relay/LSAM status.