Is there a MAX Processing per Event Rule?

DBohner-(db)

Legendary Poster
Those of you that follow the happenings of 'Dan's World' - know that we are
ever trying to do thing different from base JDE...

Thus, today's question. Is there a maximum number of ER that that can be
processed within an Event? Here's the situation. We have a couple programs
that we have placed an enormous amount of ER logic within one or two events.
We are finding that we get more 'invalid overwrites/reads' within these
expanded events.

One of our consultants suggested breaking apart the ER such that we split it
between the two events.

Logically, I find it frustrating that there might be a magic number of ER or
I/Os within an event.

Anyone else run into such an issue?




Daniel Bohner
[email protected]
www.existinglight.net
JDE - XE, SP 18 & AS/400 V4R5.0
JDE - B7331 & MS SQL 7x
 
If you look at Sales Order Processing, you'll see that several events have more than 500 lines of code (which is the max lines per event displayed in BrowsER, and why you get the 'not all nodes displayed' message) so I haven't seen any kind of limit. I have yet to solve a 'invalid overwrites/reads' error that DIDN'T turn out to be related to a bsfn. They may show up sporadically but have always been a bsfn, and one that doesn't handle the memory too well. The Whipping Boy could probably talk better to that problem.

Ben again
 
I'm going to amend Dan's question here a little:

We have a heavily modified P4210 application. At the Post - OK Button clicked
event, there is a ton of Table I/O occuring using the engine and not bsfns. The
users will encounter the Read/Write Invalid error after processing numorous
records in somewhat rapid succession.
My question is two-fold:
1. Would the amount of table i/o possibly be causing a build up and cause the
crash?
2. Would writing bsfns to accomplish the table i/o in any way benefit us
besides the amount of times the tables are opened and closed?

I'm currently trying to consolidate some of the I/O and have written the
functions that will accomplish a lot of the I/O to custom tag files. I'm also
moving some of the functionality from the post clicked event.

Thanks, Mike
OW XE SP18 AS400



__________________________________________________
 
Well, 'GuitarMan' (if indeed that is your real name)

Consider this:

Do your Table I/Os interact with anything EndDoc might touch? Recall that EndDoc is run asynchronously.

You may try considering NER since it's compiled C code and not the odd hybrid that application ER is. It would be easier to translate your APP ER to NER than converting to standard C BSFNs. Also, you can call this asynchronously, so you don't punish your users with slow performance.

Lastly, you can rewrite the functionality in C where you have control over what's going on back there. Personally, I don't like putting the really complex stuff into OneWorld's hands. Keeping that control for myself makes it easier to find the problems.

Good luck!


p.s. Mike is cool. . .rule 10A
 
Hey WB,
I think there might be something in the End Doc and the I/O that is worth
looking into. We do hit F4201 after EndDoc is called. Could be something
going on there. Definitely good advice. Thanks.
And thanks for remembering Rule 10a...;)

Mike
OW XE SP18 AS400


__________________________________________________
 
Your routine should be in a NER if it does any table updates.
The reason, Transaction Processing.

The other "area" it could be in is how JDE sometimes gets confused with table I/O's.
You can try and force an open of these tables at the start of the routine (either use f4201.open, or a f4201.select).

Hope that helps,
 
Back
Top