This is the essence of going forward, chinobob. Great questions. I can start the ball rolling with a couple of comments. A major theme in the scenarios was locking a master record during all processing and updates before updating with eventual assigned status, etc. One way this is handled is a field in the master record that is an allocated status field. Rather than using the database to lock the record so no one else can try to read with lock to start their own assign process, the field is read for update, checked for available status, and then updated with an allocated status. The software has to follow the protocol, but the alternative of very many attempts (such as many customer service rep screens scanning for available record at same time) to read a locked record during a relatively long process (many I/O's in the logic during lock) is not a pretty scenario in any event. This approach is very quick and clean in my opinion. I'll leave it to others far more knowledgeable than me on ILE to comment on module to module communications, but my experience is that there is essentially no difference between prototyped internal subprocedure calls, prototyped external subprocedure calls to bound ILE modules, and prototyped external calls. To me, the parms are passed as always and as in other languages, but validated at compile time. I did one major project along the lines of what you're talking about. I provided an online interface between BPCS and a shop floor control system at SmithKline Beecham, and the BPCS CIM600 transaction processing equivalent to INV500 lacked the inventory transfer transaction. I broke up INV510 Inventory Transfer program into a number of functional based servers that also served the original green screen program. When INV510 was done, it had no F specs except for the display file! Plus the server modules were then available to call from other programs as well as the INV510 green screen and online transaction processing program, in other words, a consolidation of logic. I happened to use a long buffer that was read into different data structures based on the first few characters that defined the type of transaction, but I've also seen more or less the record layout of a primary file the server is handling plus some additional structures passed back and forth regardless of the server transaction being requested (for example, CASEing to different subroutines based on ADD, CHANGE, INQUIRY, etc.). The project worked real well, SKB was quite pleased, but more advanced signalling from modules to the work process wasn't involved. Perhaps some others have ideas on that. Hope that helps, Ralph
No announcement yet.
Module Communication QuestionPage Title Module
Move Remove Collapse