The IBM i LFTA has retired: It’s time to move to the Dynamic Agent!

The IBM i Limited Fault-tolerant Agent or Lightweight Fault-tolerant Agent, as it is often called, is no longer available starting with the 9.5 General Availability release. Support for this agent ends collectively with the end of support for the version 9.4 product release, yet to be announced. 

So, now is the time to plan for the migration of Limited Fault-tolerant agents to dynamic agents!

This Blog provides some guidelines on how to approach the migration.

Which agents on IBM i?
IBM Workload Scheduler provides two types of agents supported on the IBM i platform, which are the same agents available on other platforms: one is based on the fault-tolerant technology, and the other on the dynamic agent technology.

The main characteristic of a Lightweight (or limited) Fault--tolerant Agent (LFTA) is receiving a copy of the Symphony file every day. The local availability of the plan means that any jobs in the READY state can be executed, as well as any jobs that have a dependency on objects running on the local machine, even if the connection to the master is lost for a period of time.

Over the years, the LFTA didn’t follow the same development cycle as the fault-tolerant agent (FTA) running on other platforms (Linux, Windows, AIX, etc.) and, its functionality remained at the version 8.5.1 level that was released at the end of 2009. Subsequent LFTA releases contained just a few fixes.

The story of dynamic agents is different. It is continuously enhanced and supports the latest functionality.

A dynamic agent does not receive a copy of the Symphony file, but it needs to remain connected to the Broker, a component running on the master domain manager, to be able to execute jobs. The Broker component is automatically installed together with the master domain manager installation.

How to migrate from an LFTA to a DA?
The easiest approach to the migration is the installation of a dynamic agent on each machine having an LFTA installed. Jobs can be migrated from an LFTA to a dynamic agent, a few at a time, changing the workstation, modifying how the job is defined using the JSDL format, and finally, testing the new dynamic agent. The availability of the old agent and the old job definitions guarantee that the jobs can still be executed in case of problems with the new agent and definitions.

When all the jobs have been migrated from LFTAs to dynamic agents, the LFTAs can be uninstalled.

The First Step: the dynamic agent installation

The dynamic agent installation procedure is described in the “Planning and Installation” guide:

https://www.ibm.com/docs/en/workload-scheduler/9.5.0?topic=components-installing-agents-i-systems

At the following link, you can find an example of the syntax used to install an agent on IBM i systems:

https://www.ibm.com/docs/en/workload-scheduler/9.5.0?topic=systems-example-installation-agent-i

After the installation completes successfully, the agent automatically registers itself with the master and you can see its definition.
 
The Second Step: defining the old jobs on the new agents

Consider the following sample job definition for the MYLFTA agent:

MYLFTA#MYJOB
SCRIPTNAME "SUBMIT: CMD(CALL PGM(MYPGM)) INQMSGRPY(*RQD) JOB(MYJOB) JOBD(*USRPRF) JOBQ(*JOBD) USER(MYSER) INLLIBL(*JOBD)"
STREAMLOGON MYUSER
DESCRIPTION "My description"
TASKTYPE OTHER
RECOVERY <RECOVERY_OPTION>
In this sample definition, replace SUBMIT: with SBMJOB, and add the resulting SCRIPTNAME string in the new job definition so that it looks like the following:

MYDA#MYJOB
TASK
<?xml version="1.0" encoding="UTF-8"?>
<jsdl:jobDefinitionxmlns:jsdl="http://www.ibm.com/xmlns/prod/scheduling/1.0/jsdl" xmlns:jsdlibmi="http://www.ibm.com/xmlns/prod/scheduling/1.0/jsdlibmi" name="ibmi"> <jsdl:application name="ibmi">
    <jsdlibmi:ibmi>
        <jsdlibmi:IBMIParameters>
            <jsdlibmi:Task>
                <jsdlibmi:command><command executed by the job after required changes>               
                </jsdlibmi:command>
                <jsdlibmi:commandTypeGroup>
                    <jsdlibmi:otherCommandType/>
                </jsdlibmi:commandTypeGroup>
            </jsdlibmi:Task>
                <jsdlibmi:credential>
                    <jsdlibmi:userName>MYUSER</jsdlibmi:userName>
                </jsdlibmi:credential>
        </jsdlibmi:IBMIParameters>
    </jsdlibmi:ibmi>
</jsdl:application>
</jsdl:jobDefinition>
DESCRIPTION “<My description>”
RECOVERY< RECOVERY_OPTION >

If the LFTA job is defined in normal mode, you can simply use the SCRIPTNAME content in the new job definition.

The Third and Final Step: Test the modified job definitionsAfter defining the job on the dynamic agent, it is ready to be tested. 

How to complete the entire process in just a few steps?After testing a few jobs, you can perform the migration on all of the remaining jobs/job streams using the following procedure:

• Identify the jobs and job streams to be migrated:
  • composer create job.txt from job=MYLFTA#@
  • composer create jobstream.txt from sched=@#@
  • (adapt the commands if you are using folders)
• Change the job definitions as described in How to complete the entire process in just a few steps?.
• Replace the MYLFTA job with the MYDA job in the job stream definitions.
• Import the new definitions:
  • composer replace job.txt
  • composer replace jobstream.txt
    
    
• Set the limit of the old workstation to 0 to be sure that everything is executed on the new workstation.
• Once you are sure that the new jobs work as expected, you can uninstall the old agent.

Which features are available on dynamic agents?
After completing the migration which includes defining the old jobs on the new agent, you can consider the new features available on the dynamic agent and evaluate possible changes to your workload. Dynamic agents on IBM i support:

• The specific IBMi job type

          Using this job type you can:

• Use a simplified interface to define jobs started with SBMJ.
• Choose to monitor child jobs or not.
• Answer system messages or select to automatically reply to them.
• Specify an LDA (Local Data Area) source (library name/name) to be passed to a job.

 

• Additional job types
  • Web services jobs
  • File transfer jobs
  • J2EE jobs
  • Database jobs
  • Java jobs
  • Executable jobs
  • Remote command jobs
  • Provisioning jobs
  • IBM WebSphere MQ jobs
  • IBM Sterling Connect:Direct jobs

 

• Increased level of security

          To increase the level of security you can disable the possibility to run jobs as QSECOFR user. 

You can find a more detailed description of the newly supported features in the User’s Guide and Reference, in the chapter “Managing an IBM i dynamic environment”:

​​www.ibm.com/docs/en/workload-scheduler/9.5.0?topic=reference-managing-i-dynamic-environment

What about migration in an End to End environment?If the LFTA is connected to an IBM Z Workload Scheduler Controller, the approach to the migration is the same and differences are limited to the job syntax.
In case of LFTA, job definitions are like the following:
//JOBREC
JOBCMD(SCRIPT)
JOBUSR(michele)
JOBPWD(YES)
//END JOBREC
SUBMIT: CMD(CALL PGM(MYPGM)) INQMSGRPY(*RQD) JOB(MYJOB) JOBD(*USRPRF) JOBQ(*JOBD) USER(MYSER) INLLIBL(*JOBD)"

You need to convert the specific IBM command as described in the previous sections and create an IBM i job using the Dynamic Workload Console or editing the JSDL.

---

Authors Bio

Enrica Alberti, ​Advisory Software Engineer at Workload Automation 

Enrica is an Advisory Software Engineer at Workload Automation L3 support team. After 20 years spent developing several software products she joined the Workload Automation development group in 2011 and L3 support team in 2013. Currently, Enrica supports several areas of the product and is the reference for problems on iSeries.
​