Automic Workload Automation

Hi.

Quick question to those with possibly inside knowledge:

The Agent has a "temp" directory. It contains, as far as I know, among other things reports which are above the limit to go into the database, and .sts files, which I assumed means "status" and seem to be used for the resuming of JOBF.

I wonder specificially though how those files are cleaned. For instance, if a JOBF aborts but nobody ever resarts it: Does the agent clean up the old .sts file after a while, or would an unchecked agent temp directory grow indefinetly?

I ask this specificially because we have Windows servers where JOBF could not be restarted (roughly three weeks after it failed) because it was lacking the .sts file. I am unable to tell thus far whether this is explainable behaviour due to some cleanup process by Automic, or one of the many other people with admin access to that server messing with "my" files :)

Cheers,
Carsten

Hi Carsten_Schmitz_7883

May be incomplete, but here's what I know...

Files that should stay in the temp directory

• Agent logs [, traces if activated]
• Job reports, if configured to be stored locally.

Files that should not stay in the /temp directory

• Jobs whose reports' size exceed the limit set in UC_HOSTCHAR_DEFAULT > MAX_REPORT_SIZE/REPORT_BLKSIZE. Because these reports exceed the size limit they cannot be saved in the DB, and will stay in the /temp folder. More details inthis discussion.
  

Their naming convention is 'O<XXXXXXX>'.txt, where 'XXXXXXX' is a transcription of the RunID in letters. You can use ALPHA2RUNNR script function to convert those characters to a RunID. More details in this post.

• When a job is run on an agent, the Automation sends a 'compiled' set of actions to be performed on the host. '.Txt' (UNIX) / '.bat' (Windows) files will be created in the temp directory during the task's execution, and be deleted once the run has completed. Should the run fail then this temporary file may not be deleted.

Their naming convention is J<XXXXXXX>.<bat/txt>
Just like for the reports <XXXXXXX> corresponds to the RunID.

Maintaining the 'temp' directory

Agents do not do automatically maintain the contents of their /temp directory, but you can run a clearing job / a file EVNT to perform this task. This was already discussed in this topic.

Hope this helps.

Best regards,
Antoine

Hi Antoine_Sauteron ,

Many thanks, that is valuable information. I'm still looking for some info on the .sts files specificially though, if anyone knows more about those and their life cycle, it would be much appreciated.

Cheers,
Carsten

Hi Carsten,

not a detailed explanation, but something regarding the JOBF file transfer protocol: https://docs.automic.com/documentation/webhelp/english/AWA/12.0/DOCU/12.0/AWA%20Guides/help.htm#AWA/Objects/obj_File_Transfer_Procedure.htm%3FTocPath%3DUser%2520Guide%7CProcess%2520Assembly%2520Perspective%7CDefining%2520Objects%7CFileTransfer%7C_____3

Regading life span of sts files: my experience is that the files are deleted as soon as the JOBF object is no longer active.

regards,
Peter 

Hi Peter,

thanks again, but the original question still remains: If a JOBF is not deactivated, because it failed and is waiting to be either deactivated or restarted: Should the .sts file be around virtually forever, or will it be cleaned up by the agent at some point based on it's age? I.e. what is the way UC4 is expected to behave?

Again, I ask this because we've seen some ".sts file not found" style errors when users try to restart JOBF after a couple of weeks. I'm trying to figure out whether the absence of the .sts file in those cases is expected behaviour (because maybe a few weeks is simply too long to take to restart a JOBF, and stuff gets cleaned in between by Automic), or unexpected behaviour.

Best,
Carsten

Hi Carsten_Schmitz_7883

The handling of status store (sts) and report store (ftx) files is described here at:
User Guide > Objects > Alphabetical Listing > FileTransfer - Execution > Temporary Files On the Source Agent's File Structure

Summery:

After a successful transfer (ENDED_OK) they will be deleted immediately.
After a failed transfer (ENDED_NOT_OK) they well be kept for 2 weeks (default) and deleted afterwards automatically.

KR, Josef

 

 

Perfect, thanks a lot Josef_Scharl_103.

Our FT_RESTARTINFO_LIFETIME is indeed set to 14 days, thus perfectly explaining why thus far, three-week-old FTs can not be restarted. We'll look into tweaking this value now.

Best,
Carsten