3 1 3 Built in Variables

Name

Description

Writeable?

*ACTIVITY_RC

The return code from the last executed Activity.

Yes

*ACTIVITY_SEV

The severity corresponding to the return code from the last executed Activity.

*JOBMODE

Current job mode (B=batch, I=inter)

(Derived directly from the LANSA system variable of the same name)

*JOBNAME

Current job name

(Derived directly from the LANSA system variable of the same name)

*JOBNUMBER

Current job number

(Derived directly from the LANSA *JOBNBR system variable)

*JOBUSER

Current job user name

(On an IBM i server, this may be different to the *USER built-in variable value if the current user for the job changed since the job was started.)

*LANGUAGE

Current LANSA language code

(Derived directly from the LANSA system variable of the same name)

*LANSADTALIB

LANSA system data/file library

(Derived directly from the LANSA system variable of the same name)

*LANSAPGMLIB

LANSA system program library

(Derived directly from the LANSA system variable of the same name)

*LASTERROR.ID

The message id of the error message following the last error.

(This is intended for use in Catch blocks to support further interrogation of the error condition.  The "last" error message is defined as the FIRST error message logged after an activity sets the error (ER) result status,)

*LASTERROR.TX1

The first level message text of the error message following the last error.

(This is intended for use in Catch blocks to support further interrogation of the error condition.  The "last" error message is defined as the FIRST error message logged after an activity sets the error (ER) result status,)

*LASTERROR.TX2

The second level message text of the error message following the last error.

(This is intended for use in Catch blocks to support further interrogation of the error condition.  The "last" error message is defined as the FIRST error message logged after an activity sets the error (ER) result status,)

*NOW_UTC
*NOW_LOCAL

The current UTC and local date and time formatted in ISO format with up to three decimal positions:
YYYY-MM-DD hh:mm:ss.nnn

*PARTITION

Current LANSA partition

(Derived directly from the LANSA system variable of the same name)

*PARTDTALIB

Current LANSA partition's data/file library

(Derived directly from the LANSA system variable of the same name)

*PARTPGMLIB

Current LANSA partition's program library

(Derived directly from the LANSA system variable of the same name)

*PROCESS_ID

The identifier or name of the running Processing Sequence

*PROCESS_II

The unique internal identifier of the running Processing Sequence. (The internal identifier is a 32 character value uniquely assigned by LANSA Composer. You can see the unique identifier for a Processing Sequence on the Audit tab.)

*PROCESS_LOGLEVEL

The logging level in effect for the processing sequence run.  Initially, the logging level is taken from the System Settings but may vary during the run, either automatically following an error or by explicit assignment of a new logging level.  This variable can contain or be set to values corresponding to the logging levels that can be selected as the default in System Settings: *AUTO (Automatic), *MIN (Minimum), *NORMAL (Normal) or *MAX (Maximum).

Yes

*PROCESS_JSMTRACE

Specifies (Y/N) whether LANSA Integrator tracing is in effect for the processing sequence run.  Initially, the value is taken from the System Settings but may vary during the run by explicit assignment of a new value to this built-in variable.  Note that changes to the value will only affect LANSA Integrator sessions begun after the change is effected.  Many activities processors remain active and possibly keep a JSM session open for subsequent use of the same activity.  To be sure of affecting such cases, the change to the built-in value variable needs to be made before the first use of the affected  activity

Yes

*PROCESS_NEST

The nested level of the running processing sequence.  Usually the value of this is 1.  When a processing sequence is run from another processing sequence using the Processing Sequence directive, the value reflects the level of such nesting.

*PROCESS_RC

The return code for the Processing Sequence.

Yes

*PROCESS_RUN

The run number assigned to the current Processing Sequence run.

*PROCESS_RSM_UTC
*PROCESS_RSM_LOCAL

The UTC and local date and time of the last restart for the current Processing Sequence run formatted in ISO format with up to three decimal positions:
YYYY-MM-DD hh:mm:ss.nnn

*PROCESS_SEV

The severity corresponding to the return code for the Processing Sequence.

*PROCESS_STR_UTC
*PROCESS_STR_LOCAL

The UTC and local start date and time for the current Processing Sequence run formatted in ISO format with up to three decimal positions:
YYYY-MM-DD hh:mm:ss.nnn

*SHUTDOWN

The *SHUTDOWN built-in variable yields a value of 'Y' when one of the following is true:

1) the system, or the subsystem or the job in which the processing sequence is executing is subject to a controlled end request - for example, by PWRDWNSYS, ENDSBS or ENDJOB commands or equivalent with OPTION(*CNTRLD)  NB: This applies on IBM i servers only.  There is no equivalent support on Windows servers for this type of "shutdown" request.

2) A LANSA Composer user has requested "controlled end" for an "active" processing sequence run, for example, by using the "End" command or toolbutton in the Processing Sequence Log window

The processing sequence controller does NOT automatically respect such requests.  It is up to the solution designer to build in such support where appropriate by reference to this new *SHUTDOWN built-in variable.  It may not always be necessary, but it is advised for processing sequences that are intended to be long-running processes.  This would usually include, for example, any processing sequence that uses the new WATCH_MSGQ, WATCH_DIRECTORY or WATCH_DTAQ activities, or one that implements similar "monitor" style processing using LOOPs or other constructs.

*SYS_DEFAULT_DIR

The path specified in the LANSA Composer system settings for the default trading partner linked directory.

*SYSTEMTYPE

The server system type (AS400, WINNT or UNIX)

(Derived directly from the LANSA *CPUTYPE system variable)

*TRADINGPARTNER

The current trading partner identifier. This built-in variable may be extended with a range of qualifiers to access attributes and linked directories, Configurations and Transformation Maps for the trading partner.

Note that while the *TRADINGPARTNER built-in variable is writeable, the qualified forms that provide access to the attributes of the current trading partner are not writeable.

Refer to Using the Trading Partner Built-in Variables for more information.

Yes

*TRADINGPARTNERS

The list of active trading partner identifiers.

This built-in variable may optionally be extended with trading partner group qualifiers to access subsets of the trading partners list.  For example, *TRADINGPARTNERS.GROUP.CUSTOMER would provide the list of active trading partners that belong to the CUSTOMER trading partner group.

This built-in variable (or its qualified forms) may be used as the list name for a Loop Directive to create a loop that performs processing for all defined trading partners (or subsets of trading partners).

Refer to Using the Trading Partner Built-in Variables for more information

*TRANSFORM

The current transformation map identifier. This built-in variable may be extended with a range of qualifiers to access attributes of the transformation map.

Note that while the *TRANSFORM built-in variable is writeable, the qualified forms that provide access to the attributes of the current transformation map are not writeable.

Refer to Using the Transformation Map Built-in Variables for more information.

Yes

*TXDOC

The current transaction document identifier (number).  This built-in variable may be extended with a range of qualifiers to access attributes of the transaction document envelope.

Note that while the *TXDOC built-in variable is writeable, the qualified forms that provide access to the attributes of the current transaction document envelope are not writeable.

Refer to Using the Transaction Document Built-in Variables for more information.

Yes

*TZ_ABBR

On IBM i servers, this built-in variables provides the short name of the time zone used by the job – for example, AEST.  On Windows servers, the description for the current time zone is provided (the same value as *TZ_DESC and *TZNAME).

*TZ_DESC

On IBM i servers, this built-in variables provides the time zone description used to calculate job time – for example, QP1000AES3.  On Windows servers, the description for the current time zone is provided (the same value as *TZ_ABBR and *TZNAME).

*TZ_NAME

On IBM i servers, this built-in variables provides the long name of the time zone used by the job – for example, Australian Eastern Standard Time.  On Windows servers, the description for the current time zone is provided (the same value as *TZ_ABBR and *TZDESC).

*TZ_OFFSET

The current offset from Coordinated Universal Time (UTC), formatted as a string in the form +HH:MM – for example, +10:00.

*TZ_OFFSETMM

The current offset from Coordinated Universal Time (UTC), in minutes – for example, 600.

*USER

Current user ID

(Derived directly from the LANSA system variable of the same name)