Back to Knowledege base

Setting Up Xi-Batch Network Connectivity

Connecting multiple Xi-Batch hosts for job and variable sharing

Understanding Xi-Batch Networking

Xi-Batch can share jobs and variables across multiple Unix hosts. Jobs submitted on one host can run on another. Variables can be exported across network.

Network mode required for:

  • Multi-host job sharing
  • Remote job execution
  • Exported variables
  • Windows clients
  • API access

Prerequisites

License:

Network-enabled license required. Check with:

bash

xb-checklic

Output shows:

Validated for networks  # Network enabled

TCP/IP network:

All hosts must communicate via TCP/IP.

Services file:

Port definitions in /etc/services.

Network Ports

Xi-Batch uses 7 ports:

xibatch     2050/tcp  # Connection port
xibatch     2050/udp  # Probe port
btq         2150/tcp  # Feeder port
xbnetsrv    2250/tcp  # DOS client enqueue
xbnetsrv    2250/udp  # DOS client enquiry
xbapi       2260/tcp  # API access
xbapi       2260/udp  # API monitor

All hosts must use same port numbers.

Port conflicts:

If ports conflict, move all by adding 1000:

xibatch     3050/tcp
xibatch     3050/udp
btq         3150/tcp
# etc.

Edit /etc/services on all hosts with same values.

Hosts File

Network configuration stored in:

/usr/spool/batch/Xibatch-hosts

Or custom location if set in master config.

Edit with:

bash

hostedit  # Character interface
xhostedit # GTK+ interface (if available)

Adding Unix Host

In hostedit:

  1. Press a (add host)
  2. Press Enter (Unix host)
  3. Enter hostname: server2
  4. Enter alias (or press Enter to skip)
  5. Probe before connecting? [Y] - press Enter
  6. Trust host with user info? [Y] - press Enter
  7. Manual connections only? [N] - press Enter
  8. Default timeout OK? [Y] - press Enter

Probe:

Checks host online before TCP connection. Disable if firewall blocks UDP.

Trust host:

Allows Windows PCs to authenticate once and be trusted across all hosts.

Manual connections:

If N: Connects automatically at startup If Y: Must manually connect with btconn hostname

Result:

Entry added to hosts file. Repeat on all hosts in network.

Example Hosts File

# Xibatch-hosts
# Connection entries

server1 alias=srv1 probe trust auto timeout=30
server2 alias=srv2 probe trust auto timeout=30
server3 probe trust auto timeout=30

Each host needs entries for other hosts.

Starting Network Mode

Ensure network enabled:

Check license with xb-checklic.

Start Xi-Batch:

bash

btstart

Reads hosts file and attempts connections.

Verify connections:

bash

# View connected hosts
btjlist -R  # Shows remote hosts with jobs

# Or in btq
# Remote hosts visible in job/variable listings

Manual Connection

If configured for manual connection:

bash

# Connect to specific host
btconn server2

# Disconnect
btdisconn server2

Use case:

Intermittent connections, WAN links, controlled connectivity.

Verifying Network Operations

Check remote jobs:

bash

btjlist -R

Shows jobs on all connected hosts.

Check remote variables:

bash

btvlist | grep ":"

Shows variables prefixed with hostname (e.g., server2:var1).

Test job submission to remote:

bash

btr -H server2 script.sh

Submits job to server2 from server1.

Troubleshooting Network Issues

Hosts Not Connecting

Check network connectivity:

bash

ping server2
telnet server2 2050

Check firewall:

Ports 2050-2260 must be open between hosts.

Check services file:

Port numbers must match on all hosts.

Check scheduler log:

bash

tail /var/spool/batch/btsched_reps

Look for connection errors.

Jobs Not Visible Remotely

Check job export:

bash

btjlist -v <job_number>

Shows: Export: Local only or Export or Remote runnable

Make job remote runnable:

bash

btjchange -e R <job_number>
# Or in btq: press 'e', select 'Remote runnable'

Variables Not Synchronized

Check variable export:

bash

btvlist -v varname

Shows: Local or Export

Export variable:

bash

btvar -E varname

Check network connection:

bash

# On server1
btvlist | grep "server2:"

If no server2 variables visible, connection issue.

Network Configuration Examples

Two-Host Setup

Hosts:

  • prod1 (production processing)
  • prod2 (production processing)

Configuration:

Both hosts have:

# /usr/spool/batch/Xibatch-hosts
prod1 probe trust auto
prod2 probe trust auto

Result:

Jobs and variables shared. Either host can execute work.

Hub-and-Spoke

Hosts:

  • central (coordinator)
  • worker1, worker2, worker3 (processing)

Central configuration:

# /usr/spool/batch/Xibatch-hosts
worker1 probe trust auto
worker2 probe trust auto
worker3 probe trust auto

Worker configuration:

# /usr/spool/batch/Xibatch-hosts
central probe trust auto

Usage:

Submit jobs to central, they execute on workers. Central coordinates workflow.

Manual Connection for WAN

Hosts:

  • local (office)
  • remote (datacenter, occasional connection)

Configuration:

# /usr/spool/batch/Xibatch-hosts
remote probe trust manual timeout=60

Connect when needed:

bash

btconn remote

Work with remote resources, then disconnect:

bash

btdisconn remote

Network Security

Firewall rules:

Open ports 2050-2260 between Xi-Batch hosts.

Host authentication:

Hosts file controls which hosts connect.

User authentication:

Users must exist on all hosts for proper authentication.

Encrypted connections:

Xi-Batch doesn't encrypt network traffic. Use VPN for untrusted networks.

Best Practices

Consistent configuration:

All hosts must have matching port numbers in services file.

Synchronized hosts files:

Each host knows about all others it connects to.

Network reliability:

Use auto-connect for reliable networks, manual for intermittent.

Monitor connections:

Check btsched_reps log for connection issues.

Test connectivity:

Before production, test job submission and variable sharing between hosts.

Document topology:

Maintain diagram of which hosts connect to which.

Configuring Default Job and Variable Modes for Users
How users' jobs and variables inherit initial permissions