Scheduler issue

I'm having a wierd thing happen that may or may not be scheduler related. Twice daily I run a posting (R09801) through the scheduler. Sometimes, but not every time, the job will skip batches that are flagged as OK to post. A manual post running exactly the same version used by the scheduler picks up the previously skipped batches without complaint.

The version being run is doing data selection based on the user ID in the batch header. I am using a generic ID created for the scheduler to run the jobs, and I thought that might be the problem. But since the failure does not seem to happen predictably I tend to think it is not some sort of permissions or security issue with the generic ID. Has anyone else experienced this or a similar problem?

You should submit the version specs to the server to be sure they are correct...

Jim, this behaviour could be caused by the posting 'user' not being in the approval group for the user who entered the batch. Suggest you check in P00241.
Regards,
Skipper

Jim,If anyone is inquiring in the batch or the batch header is in use on an inquiry screen, the patch will not post regardless of the approval status. This may account for the randomness of the issue. Instead of running the post manually, watch for te batch and see if it is picked up in the next scheduled run.

tberry6433 <[email protected]> wrote:I'm having a wierd thing happen that may or may not be scheduler related. Twice daily I run a posting (R09801) through the scheduler. Sometimes, but not every time, the job will skip batches that are flagged as OK to post. A manual post running exactly the same version used by the scheduler picks up the previously skipped batches without complaint.The version being run is doing data selection based on the user ID in the batch header. I am using a generic ID created for the scheduler to run the jobs, and I thought that might be the problem. But since the failure does not seem to happen predictably I tend to think it is not some sort of permissions or security issue with the generic ID. Has anyone else experienced this or a similar problem?
Jim Thornberry
AS/400, V5R2, Xe/ERP8, SP20, Update 2
Double-byte, Single-byte
--------------------------
To view this thread, go to:
http://www.jdelist.com/ubb/showthreaded.php?Cat=&Board=OW&Number=53284
+ - - - - - - - - - - - - - - - - - - - - - - - -+
This is the JDEList One World® / XE mailing list/forum.
Archives and information on how to SUBSCRIBE, and
UNSUBSCRIBE can be found on the JDEList Forum at
http://www.JDEList.com

JDEList is not affiliated with JDEdwards®

+ - - - - - - - - - - - - - - - - - - - - - - - -+


---------------------------------
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.


World, OW B733X and Xe

I agree that it could be someone locking the record interactively, but only if the R09801 is set up to check record locks.

A lot of UBE's in Oneworld do not check for record locks, which can be very dangerous. One way to find out for sure would be to look at app P00095 (record locks). If you see any orders out there that are being locked up, check to see if this is during the time when the records didn't post. I tend to think that the R09801 does not use record-locking.

One other thought. Is the number of records you are trying to post very large? By this I mean in the 10's of thousands? We've seen some problems when UBE's run with thousands of records, sometimes some get bypassed seemingly randomly. This happens for us particularly in the backorder release program. I'm not a techie, but one of our techies found the problem a while back, but he said it's very complex and difficult to fix. So what we try to do is to create more versions to limit the records being updated.

One thing you may want to try is to run the same version of R09801 back to back. If some records don't get picked up the first time but get picked up the second time, it may be a good indication that the system didn't "see" all the records the first time.

Good luck!

Thanks everyone for all the suggestions. I've tried to address comments from everyone here.

I think my specs are OK, but it never hurts to submit them again. We just did a full package build and a server build.

The volumes involved do not seem to be that great, certainly not in the thousands or tens of thousands.

The comment about the generic user being in the approval group sounds like a possibility. The users reporting the issue are in a remote office, and I don't think they have paid enough attention for me to know if this is the source. I'm going to work with my support group to test. If this is the issue it should be simple to recreate.