🔄 AutoSys Cross-Instance Scheduling

Cross-instance scheduling in AutoSys refers to the capability of triggering or coordinating jobs that exist across different AutoSys instances (schedulers), typically between PROD, DEV, or DR environments.

• Used when jobs from one instance depend on jobs in another instance
• Common in enterprise architectures where business flows span environments
• Requires shared communication protocols and security configurations

• Uses sendevent -E SET_GLOBAL and sendevent -E FORCE_STARTJOB to interact with remote instances
• Typically enabled via Remote AutoSys Instances setup in configuration
• Jobs can be linked using condition: global_variable logic

Note: Requires precise naming and well-defined global event variables.

• Instances must trust each other (via certificates or network rules)
• Shared ports and connectivity (e.g., TCP/HTTP/HTTPS)
• Admin access to define cross-instance relationships
• Remote instance name must be registered via autosys_secure or equivalent

Triggering a job in another instance:

sendevent -E FORCE_STARTJOB -I REMOTE_INSTANCE -J remote_job_name

Setting a global condition:

sendevent -E SET_GLOBAL -G GLOBAL_VAR=success -I REMOTE_INSTANCE

Instance 1: Which is built with r11.x

        /* ----------------- I12 ----------------- */
        insert_xinst: I12
        xtype: a
        xmachine: r12_primary_scheduler,r12_shadow_scheduler
        xport: 9000
        xcrypt_type: DEFAULT
      

Instance 2: Which is built with r12.x

        /* ----------------- I11 ----------------- */
        insert_xinst: I11
        xtype: a
        xmachine: r11_primary_scheduler,r11_shadow_scheduler
        xport: 9000
        xcrypt_type: DEFAULT
      

Instance 1: Which is built with r11.x

        /* ----------------- job_on_I11_scheduler ----------------- */
        insert_job: job_on_I11_scheduler
        job_type: CMD
        command: sleep 30
        machine: localhost
        owner: autosys
        permission:
        date_conditions: 0
        alarm_if_fail: 0

        /* ----------------- job_waiting_on_I11_scheduler ----------------- */
        insert_job: job_waiting_on_I11_scheduler
        job_type: CMD
        command: sleep 30
        machine: localhost
        owner: autosys
        permission:
        date_conditions: 0
        condition: s(job_on_I12_scheduler^I12)
        alarm_if_fail: 0
      

Instance 2: Which is built with r12.x

        /* ----------------- job_on_I12_scheduler ----------------- */
        insert_job: job_on_I12_scheduler
        job_type: CMD
        command: sleep 30
        machine: localhost
        owner: autosys
        permission:
        date_conditions: 0
        alarm_if_fail: 0
        alarm_if_terminated: 0

        /* ----------------- job_waiting_on_I12_scheduler ----------------- */
        insert_job: job_waiting_on_I12_scheduler
        job_type: CMD
        command: sleep 30
        machine: localhost
        owner: autosys
        permission:
        date_conditions: 0
        condition: s(job_on_I11_scheduler^I11)
        alarm_if_fail: 0
        alarm_if_terminated: 0
      

• Use meaningful naming conventions for global variables (e.g., PROD_DB_SUCCESS)
• Implement retry logic for transient failures in communication
• Monitor global variable events using job status dashboards
• Avoid over-coupling environments—use APIs or messaging queues if scalability is needed