WORKLOAD AUTOMATION COMMUNITY
  • Home
  • Blogs
  • Forum
  • Resources
  • Events
    • IWA 9.5 Roadshows
  • About
  • Contact
  • What's new

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

7/30/2021

0 Comments

 
Picture
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
Picture
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.
​
View my profile on LinkedIn
0 Comments

Your comment will be posted after it is approved.


Leave a Reply.

    Archives

    March 2023
    February 2023
    January 2023
    December 2022
    September 2022
    August 2022
    July 2022
    June 2022
    May 2022
    April 2022
    March 2022
    February 2022
    January 2022
    December 2021
    October 2021
    September 2021
    August 2021
    July 2021
    June 2021
    May 2021
    April 2021
    March 2021
    February 2021
    January 2021
    December 2020
    November 2020
    October 2020
    September 2020
    August 2020
    July 2020
    June 2020
    May 2020
    April 2020
    March 2020
    January 2020
    December 2019
    November 2019
    October 2019
    August 2019
    July 2019
    June 2019
    May 2019
    April 2019
    March 2019
    February 2019
    January 2019
    December 2018
    November 2018
    October 2018
    September 2018
    August 2018
    July 2018
    June 2018
    May 2018
    April 2018
    March 2018
    February 2018
    January 2018
    December 2017
    November 2017
    October 2017
    September 2017
    August 2017
    July 2017
    June 2017
    May 2017

    Categories

    All
    Analytics
    Azure
    Business Applications
    Cloud
    Data Storage
    DevOps
    Monitoring & Reporting

    RSS Feed

www.hcltechsw.com
About HCL Software 
HCL Software is a division of HCL Technologies (HCL) that operates its primary software business. It develops, markets, sells, and supports over 20 product families in the areas of DevSecOps, Automation, Digital Solutions, Data Management, Marketing and Commerce, and Mainframes. HCL Software has offices and labs around the world to serve thousands of customers. Its mission is to drive ultimate customer success with their IT investments through relentless innovation of its products. For more information, To know more  please visit www.hcltechsw.com.  Copyright © 2019 HCL Technologies Limited
  • Home
  • Blogs
  • Forum
  • Resources
  • Events
    • IWA 9.5 Roadshows
  • About
  • Contact
  • What's new