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:
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:
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
0 Comments
Your comment will be posted after it is approved.
Leave a Reply. |
Archives
May 2023
Categories
All
|