![]() |
![]() |
![]() |
![]() |
![]() |
•
•
• TuxJES is an Oracle Tuxedo application. Most of the TuxJES components are Oracle Tuxedo client or Oracle Tuxedo servers. You must first configure TuxJES as an Oracle Tuxedo application. The environment variable JESDIR must be configured correctly which points to the directory where TuxJES installed.Listing 1 shows an Oracle Tuxedo configuration file (UBBCONFIG) example segment for a TuxJES system.The following TuxJES servers should be included in the Oracle Tuxedo configuration file (UBBCONFIG):
Note: For the TuxJES administration server ARTJESADM, a TuxJES configuration file should be specified using the -i option. In the Oracle Tuxedo configuration file (UBBCONFIG), ARTJESADM should be configured in front of ARTJESCONV, ARTJESINITIATOR, or ARTJESPURGE servers.TuxJES uses the Oracle Tuxedo /Q component, therefore an Oracle Tuxedo group with an Oracle Tuxedo messaging server TMQUEUE with TMS_QM configured is required in the UBBCONFIG file. The name of the /Q queue space should be configured as JES2QSPACE.For job operations (except for job submission), you can specify the number of timeout periods for blocking messages and other system activities by setting the SCANUNIT and BLOCKTIME parameter. The value you assign must be a positive multiple of 5.
Controls the granularity of checking intervals and timeouts. SCANUNIT must be a multiple of 5 and between 0 and 60 seconds.Example: SCANUNIT 20The default is 10. BLOCKTIME controls how much time can a message block before it times out.SCANUNIT * BLOCKTIME must not exceed 32767.The default time of SCANUNIT * BLOCKTIME is approximately 60 seconds.Listing 2 Example SettingsSCANUNIT 20For job submission, timeout is not controlled by BLOCKTIME and SCANUNIT, it is specified in the artjesadmin command line, for example:In this example, if submission of JOBA cannot be finished in 60 seconds, timeout will be returned.TuxJES relies on /Q to store or retrieve messages which represent jobs. The timeout mechanism for /Q operations inside TuxJES is only controlled by MAXTRANTIME in UBBCONFIG RESOURCES section.You should explicitly specify the MAXTRANTIME in UBBCONFIG; otherwise, Tuxedo automatically uses the default value (this value may vary depending on Tuxedo release).Set this MAXTRANTIME value based on the specific system loading. The following example sets MAXTRANTIME to 5 minutes.For more information about MAXTRANTIME in UBBCONFIG RESOURCES section, see UBBCONFIG(5) in Tuxedo documentation.If any timeout occurs on /Q operation, like tpdequeue() or tpenqueue(), you can adjust MAXTRANTIME to accommodate it.A /Q queue space with name JES2QSPACE must be created for a TuxJES system (some /Q queues should be created within this queue space). TuxJES provides a sample shell script (jesqinit) to create the queue space (JES2QSPACE) and the queues. For more information, see the Oracle Tuxedo Application Runtime Batch Reference Guide.A configuration file can be specified for the TuxJES administration server ARTJESADM. The following parameters can be configured in the configuration file:The root directory to store job information. It is a mandatory attribute. If this directory does not exist, ARTJESADM creates it automatically.The default job class if the job class is not set in JCL. It is an optional attribute. The default job class is A if this attribute is not set.If it is not set, only one job can be in execution status for a job name. NODELAY will remove the dependency check. The default value is delay execution.If it is not set, NJE support will be disabled and thus jobs cannot be run on the specified server group by Batch Runtime API m_JobSetExecLocation. The default value is OFF.S: Job submission event.C: Job conversion complete event.E: Job execution complete event.P: Job purge event.L: Job cancel completed event.A: all supported eventsIf EVENTPOST is not specified, no events are posted. The data buffer with event post is FML32 type and the fields are defined in tuxjes/include/jesflds.h.The full path of job access authorization configuration file. This file can be plain or encrypted, see JES_ACL_FILE_TYPE for more information.The format of JES_ACL_FILE file. It can be set as PLAIN or ENCRYPTED (case insensitive). The default value is PLAIN.The action when no matching rule is found for the tuple of user, operation, and job in JES_ACL_FILE. It can be set as MAC (Mandatory Access Control) or DAC (Discretionary Access Control). The default value is MAC.JCL or KSH.
JCL: support JCL job, user can only submit JCL job.
KSH: support KSH job, user can only submit KSH job.
Not set: act as if KSH is set.The path of the job repository where jobs are stored. The script file path inputted in job submitting may be a relative path in JOBREPOSITORY if it is set.
You can specify multiple path names, delimit them with a colon (:). For example,
JOBREPOSITORY=<path1>:<path2>:<path3>
To find job to submit, Batch Runtime searches from these paths in the order that you specify (in JOBREPOSITORY). When finding a job name match, Batch Runtime stops searching, and submits this matched job.Specifies whether and how to enable the user substitution (See TuxJES User Substitution). The values are:NONE: Default value. Indicates jobs are executed by the OS user who starts JES system. This is compatible with all previous implementations on JES system.USER_IDENTICAL: Indicates jobs are executed by the Oracle Tuxedo user with which JES client joins JES system. Make sure that each Oracle Tuxedo user corresponds to an existing OS user before you choose this value.USER_MAPPING: When this value is specified, the JES system looks up the TuxJES user mapping file and finds out the OS user corresponding to the Oracle Tuxedo user with which JES client joins JES system, and then appoints this OS user as the job executor.If it is set to Y, TuxJES COBOL server (ARTJESCOBOLDB2MF/ARTJESCOBOLDB2CIT) invokes user program; if it is set to N or if it is not set, TuxJES COBOL server does not invoke user program. USE_COBOL_SERVER configuration is only supported for JCL job in Database mode.The full path where TuxJES user mapping file is stored. It is used along with PRIVILEGE_MODE when its value is USER_MAPPING.ORACLE or DB2.
ORACLE: Use Oracle Database to store job management data.
DB2: (not supported) Use DB2 Database to store job management data.
Not set: Use /Q to store job information.OFF: Specifies no logs.ON: Specifies writing to SYSLOG. Default value. The SYSLOG is entitled "jessys.log". You can change its path from the default "$JESROOT/jessys.log" to other directories by using SYSLOG_PATH.DAILY: Specifies writing to SYSLOG. A new log file is created daily. The SYSLOG is entitled "jessys.log.<mmddyy>". For example, the SYSLOG entitled "jessys.log.032715" stands for the log file created for the day of March 27, 2015. You can change its path from the default "$JESROOT/jessyslog/jessys.log.<mmddyy>" to other directories by using SYSLOG_PATH.WEEKLY: Specifies writing to SYSLOG. A new log file is created weekly. The SYSLOG is entitled "jessys.log.<mmddyy>", where the "dd" means the first day of current week (Sunday is the first day of the week). For example, the SYSLOG entitled "jessys.log.032215" stands for the log file created for the week from March 22, 2015 (Sunday) to March 28, 2015 (Saturday). You can change its path from the default "$JESROOT/jessyslog/jessys.log.<mmddyy>" to other directories by using SYSLOG_PATH.MONTHLY: Specifies writing to SYSLOG. A new log file is created monthly. The SYSLOG is entitled "jessys.log.<mmddyy>", where the "dd" means the first day of current month. For example, the SYSLOG entitled "jessys.log.030115" stands for the log file created for the month of March 2015. You can change its path from the default "$JESROOT/jessyslog/jessys.log.<mmddyy>" to other directories by using SYSLOG_PATH.Specifies the path of SYSLOG files.When SYSLOG=ON is set, you get the SYSLOG entitled "$SYSLOG_PATH/jessys.log" and located in the directory where you specify through this SYSLOG_PATH.When SYSLOG=DAILY,WEEKLY,MONTHLY is set, you get the SYSLOG entitled "$SYSLOG_PATH/jessys.log.<mmddyy>" and located in the directory where you specify through this SYSLOG_PATH. The "jessys.log.<mmddyy>" confirms to the naming rules for SYSLOG=DAILY,WEEKLY,MONTHLY.If you do not specify SYSLOG_PATH, the SYSLOG files are still located in $JESROOT/jessyslog (when SYSLOG is set to DAILY, WEEKLY, or MONTHLY) or $JESROOT (when SYSLOG is set to ON) by default.0: Disable the automatic purging. Default value.N(>=1): Enable the automatic purging and purge the first finished N Jobs one time.ON: Backup folder <JESROOT>/<JOB_ID> to <JESROOT>/<JOB_ID>.bak while automatic purging, just delete the relevant message from "OUTPUT" queue.If AUTOPURGE=0, this item is ignored. Default value.OFF: Delete all the files belong to the job (in folder <JESROOT>/<JOB_ID>) while automatic purging.Listing 4 jesconfig Example
Notes: For the automatically purged job, all the files in folder “<JESROOT>/<JOB_ID>" is backed up as " <JESROOT>/<JOB_ID>.bak"TuxJES Security ConfigurationTuxJES leverages the Oracle Tuxedo security mechanism to implement authentication. If authentication is enabled, a security profile should be generated using the genapprofile utility and it should be used as a artjesadmin parameter to access the TuxJES system. The user used in the profile will be the job owner. A job only can be administrated by its owner, such as cancel, purge, hold and release. A job can be viewed by everybody. If a job is without owner, it can be manipulated by everyone.Even if an Oracle Tuxedo application does not have security configured, the genjesprofile utility still can be used to enforce job owner permission checking and store the database connection MT_DB_LOGIN.Based on this security mechanism, ART for Batch provides a lightweight job access authorization mechanism to control user's job operation actions. This authorization only needs simple configuration without involving any authorization server or even third-party security product. For more information, see Authorizing TuxJES Job Access.User mapping file is loaded and takes effect when PRIVILEGE_MODE value is specified to MAPPING_CREDENTIAL. It defines the mapping relationship between Oracle Tuxedo users and OS users. Every line in the mapping file is in the format as below:It is recommended that the owner of user mapping file is root and the file permission is "-rw-------".Listing 5 shows a segment example of user mapping file for the TuxJES system.TuxJES uses Database to store jobs rather than /Q; therefore, you do not need to use group for /Q and server TMQUEUE/TMS_QM any more. All other servers and groups are not impacted.A new configuration item named USE_DB is added in JESCONFIG file to enable Database usage. Table 2 lists USE_DB values. Listing 6 shows an example.
Table 2 USE_DB Values
• autopurge is not supported in Database mode; all the setting for autopurge will be ignored.Listing 6 JESCONFIG ExampleWhen using Database as storage, connection information is necessary. It is encrypted and stored in a separate hidden file under JESROOT directory (JESROOT/.jessysprofile). gensysprofile utility is used to generate this file.When gensysprofile is launched, you are prompted to enter the user name, password, (Database) server name, and DB schema. Show prompt on the screen:Listing 7 Screen Prompt(Database) Server name string indicates the location where Database server can be found and is normally the name of the Database instance. The syntax is the same as the one used to set the TWO_TASK environment variable. Its format is either of the following:
• If your Database does not exists at the location and must go through SQLNET to connect to it, you should specify host, port, and server_name in the format of //host:port/server_name.
• Only JES administrator or OS root user can run gensysprofile.To use Oracle Database to store job management data, you must first create table JES2_JOBNUM and JES2_JOB_PARAM. Two external shell scripts are provided for you to create and drop these two tables. The two scripts are located at $JESDIR/tools.This shell script creates table JES2_JOB_PARAM and create index on field JOBNAME, CLASS, PRTY, STATUS, SUBMITTIME, GRPID, and SRVID; it also creates table JES2_JOBNUM and initialize the record in the JES2_JOBNUM. Schema name is an optional parameter. If schema name is specified, table JES2_JOBNUM and table JES2_JOB_PARAM are created in specified schema. Its usage is:This shell script drops table JES2_JOBNUM and table JES2_JOB_PARAM. Schema name is an optional parameter. If schema name is specified, table JES2_JOBNUM and table JES2_JOB_PARAM are dropped in specified schema. Its usage is:For TAF configuration, see Oracle Database documentation for more information. The following is simple description of TAP.Configure TAF on the client side by including the FAILOVER_MODE parameter in the CONNECT_DATA portion of a connect descriptor.Configuring TAF option on the client side requires you to add Oracle Net parameters to tnsnames.ora file. The parameter that drives the TAF option is the FAILOVER_MODE under the CONNECT_DATA section of a connect descriptor. FAILOVER_MODE may contain the following parameters.
Table 3 tnsnames.ora File Parameters Listing 8 shows a sample. In this sample, failover type session and method basic are configured for FAILOVER_MODE.Listing 8 Sample Configuration for Failover
Note: When using Database as storage, connection information is necessary. It is encrypted and stored in a separate hidden file under JESROOT directory (JESROOT/.jessysprofile). Use gensysprofile utility to generate this file.Listing 9 shows a sample.Listing 10 shows a sample for creating tables in DB2.Listing 10 Sample for Creating Tables in DB2DB2 environment must be ready before you boot JES domain. Suggest using db2profile, such as $source /home/db2b004/sqllib/db2profile, or setting LD_LIBRARY_PATH and PATH (and other DB2 environment variables one by one). See DB2 documentation for more information.
Note: When using Database as storage, connection information is necessary. It is encrypted and stored in a separate hidden file under JESROOT directory (JESROOT/.jessysprofile). Use gensysprofile utility to generate this file.Because there is no username and password in BDB, you should leave the username field and the password field blank and directly press ENTER. For the instance name filed, you should input the file name of BDB DB file (and do not include path). For example, if BDB DB file is "/home/testuser1/appdir/jesroot/jesbdb", the corresponding database instance name should be "jesbdb".Being shared by all the servers on different machines in a TuxJES domain, the data of jobs should be located on a shared storage (NFS), and can be accessible by all machines in the domain. In addition, the NFS should be mounted with the same mount point on all machines. Finally, JESROOT should be configured correctly on each node to point to the shared JES Root Directory. During runtime, all the TuxJES servers on any machine would write data to or get data from such shared JESROOT.For the details of configuring EJR in MP mode, see “Configuring Batch Runtime in MP Mode” under “Using Batch Runtime”.After the TuxJES system starts, you can use the artjesadmin utility to submit a job, hold a job, release a job, cancel a job, purge a job, display the job information, or subscribe event for job status change.-i scriptfilename: The script file.-I scriptfilename: The option specified to submit JCL jobs.-t timeout: Specifies to control the timeout threshold when submitting a job.-o ejr option: Specifies the options passed to the EJR script file.For more information, see artjesadmin in Oracle Tuxedo Application Runtime for Batch Reference Guide.You can display the information of a job or a series of jobs using the artjesadmin subcommand printjob:-n jobname: Display jobs with given job name-j jobid: Display a particular job information-c job_class: Display a particular class jobs information-a: Display all jobs-v: Verbose mode-m: Print the CPU time usage of each step in one JOB-l: Display the number of jobs for each job class in each job status type
Note: -l option is not supported when you use /Q to store and manage metadata of Batch jobs.The output of the printjob subcommand includes:EXECUTING: a job is runningCONVING: a job waiting for conversionWAITING: a job waiting for executionDONE: a job finished successfullyFAIL: a job finished but failedHOLD_WAITING: a job is in hold state after conversionHOLD_CONVING: a job is in hold state without conversionINDOUBT: a job is in doubt state due to its initiator restartedCANCELED: a job is canceled
• Type Run: The TYPRUN definition of the job.
• For more information about how to set block time, please refer to Block Time in UBBCONFIG for TuxJES.You can get job status synchronously by using artjesadmin in the following format:-p and -j
Table 4 Exit Code Job status = DONE Job status = FAIL Job status = CANCEL Job status = CONVING Job status = EXECUTING Job status = HOLD_CONVING Job status = HOLD_WAITING Job status = WAITING Job status = DISCARD This status will occur if tpenqueue() fails. Job status = INDOUBT When a job is running, if JES server ARTJESINITIATOR is shutdown and then restarted, the job status will be INDOUBT. Information shown in Table 5 is printed to stdout in the following format.
Table 5 Standard Output Listing 11 Sample: Job has been Finished Normally00000002,JOBA,DONE,C0000Listing 12 Sample: Job is Finished but Fails00000002,JOBA,FAILED,U0568Listing 13 Sample: Job is Running00000002,JOBA,EXECUTINGYou can hold a job or a series of jobs which are in CONVING or WAITING status using the artjesadmin subcommand holdjob:-n jobname: hold jobs with given job name-j jobid: hold a particular job-c job_class: hold a particular class jobs-a: hold all jobsYou can release a job or a series of jobs which are in HOLD_WAITING or HOLD_CONVING status using the artjesadmin subcommand releasejob:-n jobname: release jobs with given job name-j jobid: release a particular job-c job_class: release a particular class jobs-a: release all jobs-n jobname: cancel jobs with given job name-j jobid: cancel a particular job-c job_class: cancel a particular class jobs-a: cancel all jobs-n jobname: purge jobs with given job name
-j jobid: purge a particular job
-c job class: purge jobs with given job class
-s job status: purge jobs with given job status
-a: purge all jobsCompleted jobs in the DONE or FAIL status are moved to the purge queue. For other jobs, purgejob has same effect as canceljob. The purgejob command does not purge the job directly. The ARTJESPURGE server deletes the job from the TuxJES system.You can display the number of maximum concurrent ARTJESINITIATOR server executing jobs using the artjesadmin subcommand printconcurrent:You can change the number of maximum concurrent ARTJESINITIATOR server executing jobs using the artjesadmin subcommand changeconcurrent:-n concurrent_num: the number of maximum concurrent executing jobsYou can display the number of ARTJESINITIATOR server executing jobs using the artjesadmin subcommand showjobexec:The Tuxedo logic machine name running ARTJESINITIATOR server.The Tuxedo group id of the ARTJESINITIATOR serverThe Tuxedo server id of the ARTJESINITIATOR server
Note: If no option is specified, executing jobs for all ARTJESINITIATOR servers are displayed.You can stop ARTJESINITIATOR servers from picking up a new job to execute; however, servers continue finishing current jobs.The Tuxedo logic machine name running ARTJESINITIATOR server.The Tuxedo group id of the ARTJESINITIATOR server.The Tuxedo server id of the ARTJESINITIATOR server.
Note: If no option is specified, all ARTJESINITIATOR servers stop picking up new jobs.You can resume ARTJESINITIATOR server pick up and new job execution.The Tuxedo logic machine name running ARTJESINITIATOR server.The Tuxedo group id of the ARTJESINITIATOR serverThe Tuxedo server id of the ARTJESINITIATOR server
Note: If no option is specified, all ARTJESINITIATOR servers resume.Displays the number of executing jobs for all ARTJESINITIATOR servers, logical machine servers, servers by group id, or servers by group id and server id.Stops pick up of new jobs to execute for all ARTJESINITIATOR servers, logical machine servers, servers by group id, or server by group id and server id.Resumes pick up of new jobs to executefor all ARTJESINITIATOR servers, ogical machine servers, servers by group id, or server by group id and server id.C: job conversion complete eventE: job execution finish eventP: job purge eventL: job cancel completed eventA: all supported events. If the event is set to "on", A is the default.on |off: The submission is on or off. the "on" setting can be used with the -t option.After subscribing to an event, you are notified on the artjesadmin console when the corresponding event is generated.If an Oracle Tuxedo user is mapped to (or identical with) Unix/Linux root, it would be treated as a super user. This super user is allowed to do any job operation with no authorization checking performed.
• If JES_ACL_FILE cannot be opened successfully, or it contains invalid format rules, ARTJESADM cannot boot up.
Note: Do not configure JES_ACL_FILE if you want to use other authorization servers such as EAUTHSVR or if you do not want to use any kind of authorization, because the configuration for the job access authorization mechanism has higher precedence than other standalone ACL authorization servers.
Note: Besides the above JES_ACL_FILE configurations, you should set other configurations to enable TuxJES security mechanism. For example, set PRIVILEGE_MODE to USER_IDENTICAL or USER_MAPPING in JESCONFIG, and set SECURITY to USER_AUTH, ACL, or MANDATORY_ACL in UBBCONFIG file.
• Set JES_ACL_FILE_TYPE to PLAIN (default) or ENCRYPTED in JESCONFIG to specify whether the JES_ACL_FILE is plain or encrypted.
• Set JES_ACL_MODE to MAC (default) or DAC in JESCONFIG to specify the action when no matching rule in the rule file is found. See Example for Using JES_ACL_MODE for an example.Also, we use genjesacl tool to generate the encrypted rule file for TuxJES system.
• Set job operation authorization rule in the plain text file that JES_ACL_FILE specifies. Use the following CSV format:
• Listing 14: In this example, user tpuser1 is authorized to perform any kind of operation on any jobs.
• Listing 15: In this example, user tpuser2 is authorized to operate on jobs with the JOBZ prefix in their name.
• Listing 16: In this example, no user is authorized to purge any jobs.Listing 14 Example for Setting RulesListing 15 Example for Setting RulesListing 16 Example for Setting RulesSpecifies Oracle Tuxedo user name. When specifying user name, you should not only follow Oracle Tuxedo's naming requirements but also follow the below requirements.
- User name should not contain a semicolon (;).
- User name should not be just an asterisk (*).
Multiple users are separated by ":". An asterisk (*) means all Oracle Tuxedo users. Wildcards are not supported in this field. For example, tpuser* does not mean all users that have name starting with tpuser.
For Oracle Tuxedo's naming requirements, see Oracle Tuxedo Command Reference.Specifies job operations. The job operations could be SUBMIT, CANCEL, PURGE, HOLD, and RELEASE.
Among these five kinds of job operation, SUBMIT is the most important one and is the prerequisite of the following four kinds of job operation because if a user wants to cancel, purge, hold or release a job, TuxJES firstly checks whether the user is the owner of the job (only if the user is granted as SUBMIT and successfully submit a job, that user becomes the owner of this job and will own this job until it is purged out of TuxJES system).
Multiple operations are separated by ":". An asterisk (*) means all of these operations (equals to SUBMIT:CANCEL:PURGE:HOLD:RELEASE). Wildcards are not supported in this field. This field is case insensitive.Specifies job names. The job name is not the file name of the job; it is the internal job name specified in m_JobBegin and translated from //<NAME> JOB statement in JCL.
Multiple job names are separated by ":". Wildcards "*" (for zero or more characters) and "?" (for only one character) are supported.If you set JES_ACL_FILE_TYPE=ENCRYPTED, you must configure the JES_ACL_FILE file as an encrypted file. This encrypted file can be generated by the genjesacl tool.If no rule is found to match the user, operation and job, the configuration of JES_ACL_MODE in JESCONFIG file takes effect. If JES_ACL_MODE is not set, its default value JES_ACL_MODE=MAC takes effect, meaning that the operation is denied.Listing 17 shows an example.Listing 17 Example for Processing RulesThough the above two rules are both matching rules, the first matching rule takes precedence, meaning that user tpuser1 is authorized to operate on JOBA and the second matching rule does not take effect.If you want user tpuser1 to operate all the jobs except for JOBA, exchange the sequence of the above two rules.The lines (ignoring leading space) starting with character # are considered as comments. For example:Do not write comments right after the rule in the same line. For example, the #C in the following line is not considered as a comment.Suppose jobs whose names start with JOBAA, JOBBB and JOBCC need to be protected. You want to grant tpuser1 and tpuser2 for jobs whose names start with JOBAA, and grant tpuser3 and tpuser4 for jobs whose names start with JOBBB and JOBCC. All other jobs do not need to be protected.Suppose there are three Oracle Tuxedo users in the system: tpuser1, tpuser2, tpuser3; there are 30 jobs in the system: JOBX01-JOBX10, JOBY01-JOBY10, and JOBZ01-JOBZ10.You want to grant tpuser1 and tpuser2 to operate all jobs, and grant tpuser3 to only operate 12 jobs: JOBX10, JOBY10, and JOBZ01-JOBZ10.If user tpuser1 wants to submit JOBB and user tpuser2 wants to submit JOBA, there is no matching rule for these requirements; then the settings for JES_ACL_MODE take effect.By default, JES_ACL_MODE is MAC, meaning that these actions would be denied; however, if you specify JES_ACL_MODE to DAC, the above operations will be allowed.You can dynamically change job access authorization, using artjesadmin command.You can also use artjesadmin sub command.For example, to change the rule file of job access authorization to another file (aclrule.new) with DAC mode, you can use artjesadmin command as Listing 18 or use artjesadmin sub command as Listing 19.
The default directory is ${APPDIR}/Logs.
• ERROR or error: TuxJES outputs error messages only.
• WARN or warn: TuxJES outputs error messages and warning messages.
• INFO or info: TuxJES outputs error messages, warning messages, and information messages.
• DEBUG or debug: TuxJES outputs all messages.The default value is WARN.If JESTRACE is not defined or if it is specified with none of these values above, TuxJES assumes that JESTRACE is specified with WARN - TuxJES outputs error messages and warning messages.By default, JES trace files are stored in ${APPDIR}/Logs directory; before running Batch Runtime, you can change the directory by setting the environment variable JES_TRACE_PATH.A TuxJES server's trace file is named with the combination of server name, group ID, server ID, and a fixed-suffix "jestrace". For example,
• ARTJESADM.1.1.jestrace is the jestrace file name of a ARTJESADM server; this server belongs to group 1 and its server ID is 1.
• ARTJESCONV.1.20.jestrace is the jestrace file name of a ARTJESCONV server; this server belongs to group 1 and its server ID is 20.A TuxJES client's trace file is named with the client name and a fixed-suffix "jestrace". For example,
• artjesadmin.jestrace is the jestrace file name of a TuxJES client.
Table 7 TuxJES Trace Message Format You can use environment variable JESTRACE to set the TuxJES trace message level, or use command artjesadmin to dynamically change it, determining which level of messages will be displayed.You should set environment variable JESTRACE before running Batch Runtime. Once you set JESTRACE, it will set the TuxJES trace message level of all TuxJES clients and servers that your UBBCONFIG SERVERS section specifies.You can dynamically change TuxJES trace message level, using artjesadmin command:You can also use artjesadmin sub command:The parameter trclvl and -t can be set as 0, 1, 2, or 3. 0 indicates ERROR level; 1 indicates WARN level; 2 indicates INFO level; 3 indicates DEBUG level.If none of the machine, groupid, and serverid parameter is specified, the artjesadmin will change the TuxJES trace message level of the current client and all servers that your UBBCONFIG SERVERS section specifies. Once you specify one or more parameters, the artjesadmin will only change the TuxJES trace message level of the servers that you specifies; the current client will not be changed.
• Example A: Change TuxJES trace message level to DEBUG for the current client and all servers that your UBBCONFIG SERVERS section specifies. You can use artjesadmin command as Listing 20 or use artjesadmin sub command as Listing 21.
• Example B: Change TuxJES trace message level to ERROR for the TuxJES servers which are running on SITE1 machine. You can use artjesadmin command as Listing 22 or use artjesadmin sub command as Listing 23.
• Example C: Change TuxJES trace message level to INFO for all TuxJES administration servers that belong to group 1. You can use artjesadmin command as Listing 24 or use artjesadmin sub command as Listing 25.
• Example D: Change TuxJES trace message level to INFO for a TuxJES administration server; this server belongs to group 1, and its server ID is 1. You can use artjesadmin command as Listing 26 or use artjesadmin sub command as Listing 27.For more information, see artjesadmin in Oracle Tuxedo Application Runtime for Batch Reference Guide.Listing 20 Example A: artjesadmin CommandListing 21 Example A: artjesadmin Sub CommandListing 22 Example B: artjesadmin CommandListing 23 Example B: artjesadmin Sub CommandListing 24 Example C: artjesadmin CommandListing 25 Example C: artjesadmin Sub CommandListing 26 Example D: artjesadmin CommandListing 27 Example D: artjesadmin Sub Command