Module Communication Question

[R.Daugherty]

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

[bchinowth@werner.com]

My company wants to make a conscious effort to move to a more moduluar Programming Design Using Bound Programs, and Sub-procedures. (this is to hopefully move us into EJB design in the Future). We currently have very old Code, and a few major concerns about how to achive this goal of a more modular design. I will give a few examples of Issues that we have the need to address and see if anyone could give some ideas of how to handle them. We have a Program that will open a file for Update. This Program Is very large. There are processes that happen within this Program, that other very large programs use as well, so we want to start our Modular Design here. In these processes Information needed will have already been Read (Locked) by an earlier process in the Program (this ensures that no one will try to update any information in this record while we are making changes). Ex. We have a Sales Order that needs a Worker Assigned to Fill it, once we pull up the Original Sales Order, we don't others to be able to go in and Assign an Employee. Once we Decide what Employee should work on the Sales Order (Selection Program) We have to update mulitple Files (along with other Programs to call) that do things like, Payroll time updating, Work Flow Processing, Inventory, etc. (that would be the Modules that would be Called) Issue #1. If we are going to use a Module to do the Processing of the record. How do we avoid A.) Record Locked to this Job Already Errors if we try to re-read the Record for Update in the Module. B.) If we unlock the record before entering the Module, another Process in Lock Wait could pick up our record and update the inforamation we are trying to update causing headaches in the Data Integrity of our Files. How Does ILE Concept Programming Handle Module to Module Commincation? Issue #2. Okay so we let the Main Program Lock the Record (again to keep others out after we pull it up) and we decide to change Other Files based on this File (reason for the Modules), Can we use another way to comminicate between the Program and the Module so Each process is using the Same record already locked to our job (Pointers Maybe?) I know the Design of the Program seems a little wierd, but with Thousands of "Sales Orders" being Processed at once, and Mulitple "Zone" Planners assigning Workers to a Order with a Single Zone, if one Person pulls up the Sales order for Input, then wants to assign a Worker to it (letting the Module lock the Record) then another "Zone" planner could assign some one else to it already. Granted I could code for such instances in the Procedures (Modules) and handle accordingly, but These programs are old and large and Major Development costs would occur if we had to re-design everthing from Scratch just to move to a more Modular desgin. I am open to any suggestions anyone would have as to how to achive this, and I thank you in advance for your help.

[B.Morris]

"Can we use another way to comminicate between the Program and the Module so Each process is using the Same record already locked to our job (Pointers Maybe?)" In general, you don't need pointers for intermodule/interprocedure communication. Ordinary parameters work fine, and much more safely. Ralph is right - passing parameters is the same whether you're calling a program, a procedure in the same module or a procedure in a different module. If you use externally-described data structures to hold the record information, these structures can be passed as parameters between procedures and modules. Fmyfile uf e disk * When myfile is read in, the data will go into the fields * in this data structure d myfileRec e ds extname(myfile) Using a data structure as a prototyped parameter is a bit awkward before V5R1. Here's how can you do it in V5R1. P someProc b D someProc pi D rec likeds(myfileRec) c if rec.custname <> *blanks c .... P e Here's how you can do it before V5R1: P someProc b D someProc pi D recParm like(myfileRec) D rec e ds based(pRec) extname(myfile) D pRec s * c eval pRec = %addr(recParm) c if custname <> *blanks c .... P e (I know I said pointers aren't required for passing parameters, but this is a local pointer within a subprocedure, not a shared pointer. The pointer is just used to redefine a local parameter as a data structure.)