Setting Up and Managing Command Interpreters

Configuring shells and custom programs to run batch jobs

Understanding Command Interpreters

Every Xi-Batch job runs under a command interpreter - a program that reads commands from standard input and executes them.

Default setup:

When Xi-Batch installed, typically one command interpreter exists:

Name: sh
Program: /bin/sh (Bourne shell)
Arguments: -s
Load Level: 1000
Nice: 24

Command Interpreter Components

Each command interpreter has these parameters:

Name : Unique identifier used to reference interpreter : Examples: sh, ksh, perl, sh_high

Program : Full path to interpreter program : Must read commands from stdin : Examples: /bin/sh, /bin/ksh, /usr/bin/perl

Arguments : Predefined arguments passed to interpreter : Prepended before job arguments : Common: -s for shells (prevents treating first arg as filename)

Load Level : Default load level for all jobs using this interpreter : Only users with special create privilege can override : Used to classify job types by resource usage

Nice : Unix nice value for jobs : Default: 24 (slightly lower priority than interactive) : Lower numbers = higher priority : Normal login processes run at nice 20

Argument 0 : Controls process name in ps output : Off: shows interpreter name (e.g., /bin/sh) : On: shows job title instead

Expand args : Controls where $ variable expansion occurs : Off: shell expands variables (normal) : On: Xi-Batch expands before passing to interpreter

Why Multiple Command Interpreters?

Different shells:

Support multiple shell environments:

bash

# Bourne shell
Name: sh
Program: /bin/sh

# Korn shell  
Name: ksh
Program: /bin/ksh

# Perl
Name: perl
Program: /usr/bin/perl

Different priorities:

Same program, different nice values:

bash

# Normal priority
Name: sh
Nice: 24

# High priority
Name: sh_high
Nice: 10

Different load levels:

Classify jobs by resource usage:

bash

# Light reports
Name: reports
Program: /bin/sh
Load Level: 1000

# Heavy updates
Name: updates
Program: /bin/sh
Load Level: 3000

# Admin tasks
Name: admin
Program: /bin/sh
Load Level: 1500

Users without special create privilege inherit load level from interpreter - this is how you control job resource limits.

Viewing Command Interpreters

In btq:

Press X from jobs screen
View list of interpreters
Press q to return

Command line:

bash

btcilist

Example output:

Name    Program      Args    Load    Nice
sh      /bin/sh      -s      1000    24
ksh     /bin/ksh     -s      1000    24
perl    /usr/bin/perl -      1000    24

Adding Command Interpreters

In btq (requires special create privilege):

Press X from jobs screen
Press A (add)
Enter name (e.g., ksh)
Enter program path (e.g., /bin/ksh)
Set arguments (e.g., -s)
Adjust load level if desired
Adjust nice if desired
Press q to save

Command line:

bash

btcichange -n ksh \
           -p /bin/ksh \
           -a "-s" \
           -l 1000 \
           -i 24

Common Shell Setups

Bourne Shell (sh)

bash

Name: sh
Program: /bin/sh
Arguments: -s
Load Level: 1000
Nice: 24
Arg 0: No
Expand args: No

The -s argument prevents shell from interpreting first job argument as script filename.

Korn Shell (ksh)

bash

Name: ksh
Program: /bin/ksh
Arguments: -s
Load Level: 1000
Nice: 24
Arg 0: No
Expand args: No

C Shell (csh)

bash

Name: csh
Program: /bin/csh
Arguments: -s
Load Level: 1000
Nice: 24
Arg 0: No
Expand args: No

Perl as Command Interpreter

Perl can read script from stdin:

bash

Name: perl
Program: /usr/bin/perl
Arguments: -
Load Level: 1000
Nice: 24
Arg 0: No
Expand args: No

The - argument tells Perl to read from stdin.

Submitting Perl jobs:

bash

# Create Perl script
cat > process.pl << 'EOF'
#!/usr/bin/perl
print "Processing data...\n";
# Perl code here
EOF

# Submit as batch job
btr -i perl process.pl

AWK as Command Interpreter

AWK can also read from stdin:

bash

Name: awk
Program: /usr/bin/awk
Arguments: -f -
Load Level: 1000
Nice: 24
Arg 0: No
Expand args: No

The -f - tells AWK to read program from stdin.

Submitting AWK jobs:

bash

# Create AWK program
cat > getxi.awk << 'EOF'
/xi/ {print $1}
EOF

# Submit with file argument
btr -i awk -a datafile getxi.awk

SQL Command Interpreters

Database programs that read from stdin work too:

bash

# PostgreSQL psql
Name: psql
Program: /usr/bin/psql
Arguments: -f -
Load Level: 2000
Nice: 24

# MySQL
Name: mysql
Program: /usr/bin/mysql
Arguments: --batch
Load Level: 2000
Nice: 24

Submit SQL job:

bash

cat > query.sql << 'EOF'
SELECT * FROM customers WHERE status = 'active';
EOF

btr -i psql query.sql

Priority-Based Interpreters

Create multiple interpreters with different nice values:

bash

# Low priority (high nice value)
Name: sh_low
Program: /bin/sh
Arguments: -s
Load Level: 1000
Nice: 30

# Normal priority
Name: sh
Program: /bin/sh
Arguments: -s
Load Level: 1000
Nice: 24

# High priority (low nice value)
Name: sh_high
Program: /bin/sh
Arguments: -s
Load Level: 1000
Nice: 10

Use case:

bash

# Background cleanup - low priority
btr -i sh_low cleanup.sh

# Normal processing
btr -i sh process.sh

# Urgent task - high priority
btr -i sh_high urgent.sh

Load Level Classification

Create interpreters to classify job types:

bash

# Light jobs (reports, queries)
Name: light
Program: /bin/sh
Arguments: -s
Load Level: 500

# Medium jobs (data processing)
Name: medium
Program: /bin/sh
Arguments: -s
Load Level: 1500

# Heavy jobs (large batch processes)
Name: heavy
Program: /bin/sh
Arguments: -s
Load Level: 5000

Users inherit load level from interpreter - prevents resource abuse.

Submit with specific interpreter:

bash

# Light report
btr -i light generate-report.sh

# Heavy processing
btr -i heavy process-warehouse.sh

Argument 0 Option

Controls process name visibility:

Argument 0 disabled (default):

bash

ps aux | grep sh
# Shows: /bin/sh (interpreter name)

Argument 0 enabled:

bash

ps aux | grep backup
# Shows: backup-job (job title)

Enable Argument 0:

In btq: select interpreter, press 0 to toggle

Use case:

Makes identifying jobs easier in process lists.

Expand Args Option

Controls where variable expansion happens:

Expand args disabled (default):

Shell expands variables:

bash

#!/bin/sh
echo $HOME  # Shell expands

Expand args enabled:

Xi-Batch expands before passing to interpreter:

bash

# Xi-Batch expands $HOME before shell sees it

Warning: Be very careful with this option for shells. Can cause unexpected behavior with quotes and special characters.

When to use:

Non-shell interpreters that don't expand variables
Special preprocessing requirements
When you need Xi-Batch environment variables expanded first

Modifying Command Interpreters

In btq:

Press X from jobs screen
Navigate to interpreter
Press appropriate key:
- L - Change load level
- a - Change arguments
- n - Change nice value
- N - Change name
- P - Change program path
- 0 - Toggle arg 0
- e - Toggle expand args

Command line:

bash

# Change load level
btcichange -n sh -l 1500

# Change nice value
btcichange -n sh -i 20

# Change arguments
btcichange -n sh -a "-s --"

Deleting Command Interpreters

In btq:

Press X from jobs screen
Navigate to interpreter
Press D (delete)
Confirm

Cannot delete if jobs still using it.

Command line:

bash

btcichange -n old_interp -d

Using Command Interpreters in Jobs

Specify at submission:

bash

btr -i ksh script.ksh
btr -i perl script.pl
btr -i awk program.awk

Change existing job's interpreter:

bash

btjchange -x ksh <job_number>

# Or in btq: select job, press 'x'

Custom Command Interpreters

You can create custom interpreters:

Bypass/Dummy Run Interpreter

Makes job appear to run without executing commands:

bash

#!/bin/sh
# /usr/local/bin/bypass-interpreter

# Read script from stdin but don't execute
cat > /dev/null

# Always exit successfully
exit 0

Setup:

bash

# Add interpreter
Name: bypass
Program: /usr/local/bin/bypass-interpreter
Arguments: (none)
Load Level: 100
Nice: 24

Use for testing:

bash

# Test job schedule without running commands
btr -i bypass production-job.sh

Logging Interpreter

Wrapper that logs all commands:

bash

#!/bin/sh
# /usr/local/bin/logging-sh

LOGFILE=/var/log/xibatch-scripts/$(date +%Y%m%d-%H%M%S).log

# Log script
tee "$LOGFILE" | /bin/sh -s

# Save exit code
EXIT=$?

echo "Exit code: $EXIT" >> "$LOGFILE"
exit $EXIT

Setup:

bash

Name: sh_log
Program: /usr/local/bin/logging-sh
Arguments: (none)
Load Level: 1000
Nice: 24

Best Practices

Use meaningful names:

Good: sh, ksh, reports, updates, perl
Avoid: interp1, test, x

Document interpreters:

Maintain list of interpreters and their purposes:

sh - Standard Bourne shell, general use
sh_high - High priority shell for urgent jobs
reports - Light load (500) for reports
updates - Heavy load (3000) for database updates
perl - Perl interpreter

Start conservative:

Begin with standard shell interpreters, add custom ones as needs arise.

Test new interpreters:

Create test job before production use:

bash

# Test new interpreter
btr -i new_interp test.sh

Match load levels to reality:

Profile jobs to determine appropriate load levels for each type.

Don't over-complicate:

Only create interpreters when there's clear benefit (priority, load control, different shell).

Restrict special create privilege:

Only give to administrators - prevents users creating high-load interpreters to bypass limits.

Labels

Xi-Batch arguments load-level shell

Configuring Holidays for Job Scheduling

Setting up and maintaining the holiday calendar

Can't see the article that you are looking for? Get in touch!

Your Name *

Your Email *

Your Company *

Area of interest *

More about the article that you would like to see *

Submit