Do poeple prefer arsload or use STRMONOND??

[cmballer35]

Is there new server code supposed to fix issues with STRMONOND?? Anybody know?

[Darrell Bryant]

What type of problems are you experiencing with STRMONOND?  There have been PTFs for STRMONOND during this year, but without knowing your problems I can't make a recommendation.

[cmballer35]

By using STRMONOND using Ascent Capture documents per my class at IBM training, it was recommended using arsload.  Word is now that this is corrected and you no longer have to worry about using arsload in server code V5R4.  Is this true? 

[Darrell Bryant]

For storing documents from Ascent Capture, STRMONOND is the easiest of the two commands to use.  It provides options to keep processed files and also to end the monitor automatically.  You can also use ENDMONOND to end the monitor, versus having to perform an endjob in order to cancel an arsload job.

The arsload command provides the option to monitor multiple directories with one job.

I hope this is helpful.

[cmballer35]

So can we just remove out arsload jobs and transfer our job schedules over to use STRMONOND? 

[Darrell Bryant]

Yes, can remove the arsload job schedule entries and add new entries with the matching STRMONOND *DIR commands.

[Carol Allen]

Hi, I just found out about this forum and figured I should reply, since I used to teach the IBM courses.  I know which problem you're referring to, and I thought until recently that it had been corrected, but it hasn't.  STRMONOND does work with directories, but the problem is that as soon as it sees a .ind file it looks for the associated .out file.  That means that there can be a timing problem -- the Kofax release script sends the files, and the .ind file can end in error (and the file changed to .err) before the .out file reaches the directory.  One of the ptf cover letters seemed to imply that this was no longer true, so that's probably the information you saw.  What the cover letter was referring to, however, was a file locking problem with the .ind file.  I know because I had a PMR on this issue.  The arsload program works differently -- it looks for an .ard file (not an .ind file), which is not sent by the release script until both the .ind and .out files have been sent.

Based on your note, I'm going to submit a request for the STRMONOND program to be changed so it will work the same way as the arsload program. 

You CAN use the STRMONOND program on a directory if you schedule it so that it's run only when users are not scanning -- at the end of the day, for example.  Then it works quite well.

[Carol Allen]

Hi, sorry for the delay -- I made the request a long time ago and got an answer, but then forgot to update my Forum response.  The problem is that there are OD for iSeries now who use STRMONOND and expect to find .ind and .out files, so OD development doesn't want to change the program or those customers would start having problems.  So if instead you want to trigger the load by finding a .ard file, you need to use arsload.  Or you could change the Kofax Release Script code to keep the .ind file open until the other files were sent.  The monitor bypasses open files.  But I think it would be easier just to use arsload.