IPA Flow built to recover Jobs in LSF

Hello,

Does anyone have experience building or have a sample IPA flow to monitoring and recovered jobs in Lawson? Looking at automated job recovery and its feasbility. Thanks.

Find more posts tagged with

Process Automation (IPA) - General Discussions

Accepted answers

bhillz

The problem may be more fundamental in the how IPA handles "failed" commands.

The provided syntax are valid Unix/Linux commands, as stated.

Using && would defeat the purpose. Separating the commands as individual, standalone commands would not provide the desired output. The GREP relies on the input from the previous command via the pipe ("|").

The previous commands (SysCommand03 & Syscommand04) successfully demonstrate the desired output. The GREP found a match, output it, and completed successfully.

Note: JQSTATUS always reports success -- it always completes the command (list or none) so the command reports success.

The question in SysCommand05 is: the JQSTATUS output a list (maybe only header if no jobs in Recovery), but the GREP did not find g0numrmd in the list and reported a failure. GREP failed to find the string. This was interpreted by IPA as a failure of the command execution -- rather than NOT finding any jobs by g0numrmd that needed recovery.

This IS actually the desired state: no jobs that need Recovery.

How do you want to trap this execution "failure": Exit the IPA or continue with more checks elsewhere or ??

It's assumed that if SysCommand05 succeeded (job in recovery), you would proceed with additional cleanup/notification steps.

russel-cornelson

In this particular case, I don't believe this is a bug with the IPA product. The grep command you are entering is returning an error/exit code that is not 0. IPA is picking up that error code and telling you that the command was not successful. You can see this by executing "echo $?" after you run your grep command.

->jqstatus -rh|grep astringthatdoesnotexistintheoutput

This returns no text back.

->echo $?

-> 1 <<<<<<< returns exit code 1; aka no zero; aka error

IPA is successfully picking up that exact error code, and is indicating it in the workunit log:

This gets returned to the System Command with the exact same error code:

SysCommand05_errorOutput =

System command error: command returned error code 1

If you want process flow to NOT throw an error when executing this; we need to modify the command you are executing so it does not throw an error when executing the grep. To do this, add || true to your command.

jqstatus -rh|grep -i g0numrmd || true

When a match is found: echo $? will return 0; and the command will return your data

When a match is not found: echo $? will return 0; and the command will return no data

Either way; IPA will pick up that exit code and will not treat it as an error.

bhillz

I'd have to agree with Russel, It's more of a "Feature" that occurs when writing software that runs on different platforms.

How would IPA know when to stop? When IPA receives an error. On Windows, non-successful return status is an error. On Linux, its expected and helpful information.

So you case is to convert a normally expected non-successful status into something that you can use.

For your command try:

rm /tmp/RecoveryList.txt ; jqstatus | grep -i g0numrmd >/tmp/RecoverList.txt ; true

Then in the next IPA step check for the existence of the file /tmp/RecoveryList.txt. If found, the file is a list of jobs to recover. If not, you're done.

All comments

russel-cornelson

If I were to attempt this I would:

1. remote system command prompt on LSF server to execute "jqstatus -r"

For my test system that would be: E: && cd E:lsenv && enter.cmd && jqstatus -r

2. From this I would use Data Iterator to parse the SystemCommand_output variable by line

3. Inside the data iterator I would split each returned line into string variables:

[ntuser,jobname,executionnumber,unknown,jobstatus,starttime,startdate,endtime,enddate] = Dataiterator_outputdata.split(",")

4. From here you could merge jobname and executionnumber to comeup with the examine.log filename:

executionnumber = trimLeadingZeros(trimLeadingSpaces(executionnumber))

recoveryJobName = trimLeadingSpaces( trimTrailingSpaces(jobname)) + "." + executionnumber

5. Now I could read the examine log with a remote file access node:

On my test system that would be: E:lsenvlawsystemjoblog<!recoverJobName>

6. With the file in memory you would then need a list of potential errors where you knew the solution to and essential pattern match to find the error, and pull out the PROGRAM name and PRODUCTLINE.

For example: If I delete the gnt file to simulate the program not being compiled. The job would goto needs recovery and the examine log would say program doesn't exist.

In this case, I would branch out when I found that error, then execute qcompile <PDL> <SYSCODE> <PROGRAM>

.... to find the system code; my test system is on windows so I would probably use command line: I know the program name from the examine log so I could add PD to in and search via command line:

dir CU201PD /s

This returns:

E:lsenvlawlsapps>dir CU201PD /s

Volume in drive E is Data_1

Volume Serial Number is 36B2-7559

Directory of E:lsenvlawlsappsifsrc

- since I know the system code has a directory here, with src added to the end of it I would just pull IF out of IFSRC for the system code. Now I could execute qcompile.

NOTE: The problem with this sort of problem is there is alot of different reasons a job could go into recovery. For an unknown problem I would likely send the jobowner an email that includes the examine log ... bonus points I would do this by spawning a new workunit and sending a user action which sends the email with the log. The user could fix the issue, then take the recover action from either their inbasket or via the email attachment.

I would likely tie this to a reason code / comment so when they click recover they would be prompted to add what steps were taken to recover the job. This flow could then continue on and send me an email that included the examine log's error along with the implemented solution.

That information would help in programming additional automated job recovery logic for future versions.

At a bare minimum it would give my users an email whenever a job they submitted failed that includes the examine log which has to save someone time. I think you could embed a link in that email that would take the user directly to that job as well.

unknown

Thanks Russell,

A follow-up then - I put together a flow to test various unix commands (AIX) using both shell and no shell options in IPA, the commands worked for the most part except for a particularly problematic one >> jqstatus -rh | grep -i g0numrmd

For that command (jqstatus -rh | grep -i g0numrmd) – it’s either I get a system command error (Log1) or a syntax issue (Log2). This is odd because I was able to use the ps, pipe and grep commands successfully in the previous two nodes (see logs). Wondering if you had an inkling as to what I may be experiencing here. Thanks.

P.S. Can you enter multiple commands in a single SysCmd node??

[View:/cfs-file/__key/communityserver-discussions-components-files/57/Log1.txt:320:240][View:/cfs-file/__key/communityserver-discussions-components-files/57/Log2.txt:320:240]

russel-cornelson

You can enter multiple commands in a single system command node by separating them by &&

Example:

Change to drive letter E, set my environment variables, then execute a landmark command

Windows:

E: && cd E:lmrk && enter.cmd && dbcount prod PfiWorkunit

UNIX

. cv && dbcount prod PfiWorkunit (I don't have a unix test system; but should work)

bhillz

Copyright © 2025 Infor. All rights reserved.