Tips and Techniques: Getting Started with Procedures

[Guest.Visitor]

Tips and Techniques: Getting Started with Procedures

** This thread discusses the article: Tips and Techniques: Getting Started with Procedures **
yes, David, but the data has to be read in, linked to other databases, interpreted by a program. I'm saying for a given business rule, do that in one callable program, not 10. Here are some examples: o Get warehouse hierarchy quantity available for a part o Find "x" business working days out from a starting date o Generate a new part o Generate a part BOM o Search for out-of-stock components in a BOM o See if user is authorized to do whatever (see actual costs) o Schedule a work order into an open date o etc Chris

[David Abramowitz]

Tips and Techniques: Getting Started with Procedures

** This thread discusses the article: Tips and Techniques: Getting Started with Procedures **
I will agree to disagree here. It has been my experience that a single given business rule is rarely if ever used in multiple locations. For example, generating a new part (or item or whatever) would only be used in part maintenance. Checking user authorization would be a security function. Your example of finding "X" working days would be applicable, but that is only one example. Over the course of thousands of mainline programs qualifying and quantifying the use of called programs, procedures or whatever may not end up being a savings at all. For instance if you find 30 instances where you could create a routine that could be used in less than three programs would it be worth the effort. OTOH if you found a single instance where a called whatever could be used in 30 programs, that would be worthwhile, but just for that instance. Dave

[Guest.Visitor]

Tips and Techniques: Getting Started with Procedures

** This thread discusses the article: Tips and Techniques: Getting Started with Procedures **
It has been my experience that a single given business rule is rarely if ever used in multiple locations. For example, generating a new part (or item or whatever) would only be used in part maintenance. Checking user authorization would be a security function. Ha my friend, if it were only that easy. Parts can be generated via incoming EDI (can actually see if part# is possible), order entry, part configurators, simple part maintenance, etc. And if you have different classes of users (employee, customer, store manager, regional manager, etc), one inquiry program might show slightly different data on the screen. Do you want the customer to be able to see the actual cost to build their part in part inquiry? Would you code 10 different inquiry programs that essentially work the same just to display slightly different information on them? I hope not. I'm not talking about OS/400 object security, I'm talking about row and field security. Warehouses, customers, sales offices, order types (can just anyone issue credit?), etc. Sure, SQL constraints can help, but what if you need to change user security to a warehouse in the middle of the day while the file is in use? What about a utility program that pops up a window with message text in it? Maybe asks for a Yes/No response? Sends the response back to the calling program. Suppose you want to tell the user who has the record locked, either systemically or logically? What about a utility program that verifies the syntax of an email address entered on a green screen? Customers (sales, claims, etc), employees, company groups, etc all have email addresses. Do you code that syntax logic in each interactive program? What about logic that determines the net price of a part? Suppose the customer has a quoted price? EDI needs to determine the net price, order entry, part inquiry, etc. What about a PF trigger program? That could get called from hundreds of places. What about a program to determine if an IFS root system file exists? What about a program that checks for a recursive BOM? What about simple things like verifying that a warehouse # is valid, order type is valid, customer number is valid, etc. You need to make sure those EDI purchase orders are valid before plugging them into your live production files, right? And sales order entry, purchase order entry need those same edits, right? So... What about a scrubber that checks every name entity that can be entered to see if that entity is a "bad guy" like OSAMA BIN LADEN? Uncle Sam requires this in some cases, up front, unless you like paying million dollar fines per occurrence. I could go on and on... Chris

[R.Daugherty]

Tips and Techniques: Getting Started with Procedures

** This thread discusses the article: Tips and Techniques: Getting Started with Procedures **
Chris, I want to respond to the many good points you and Hans raise in your posts. I'm not able to access to post during the day and have to post before and after work. Sorry for the delay in the coming response. Ralph

[R.Cozzi]

Tips and Techniques: Getting Started with Procedures

** This thread discusses the article: Tips and Techniques: Getting Started with Procedures **
Actually I was talking about what the compiler generates under the covers.

[R.Daugherty]

Tips and Techniques: Getting Started with Procedures

** This thread discusses the article: Tips and Techniques: Getting Started with Procedures **
Chris wrote: Honestly, this is programming 201. Any business rule that needs to be shared across applications such as "get the warehouse hierarchy quantity available for part" (or could be in the future) gets put into a callable program "black box widget". Otherwise, if you have that business rule redundantly coded in 10 different programs and the rule changes, you get to find all 10 programs and modify all of them in the same way and test all 10 and install all 10. What if the next programmer only find 8 of those 10 programs? And the next programmer only finds 7 of those programs? You get the idea. Which method do you use? Please answer. Since you don't know anyone that uses this encapsulation, I think you've excluded yourself too. Hi Chris. What I said was that I've heard the talk talked since the early 90's but I've never seen or read of enterprise business logic servers implemented. I also asked if you had been involved in implementing the equivalent of business logic extracted and called from multiple ERP modules. The latest version is SOA, but it's the same talk for the last 15 years. If you check my posts, you should see that I didn't criticize the concept, I said I hadn't seen it implemented after all these years, "it" being an enterprise business logic server implementation I was posting about. I also referred to many failures of the talk along the way. I am sure that others besides me notice the chasm between the talk and any actual enterprise implementation of the talk, with massive failures such as San Francisco and anything else generated by the talkers that lie at the bottom of that chasm. My contention is that we've done the fundamentals all along in RPG on the AS/400. There are tradeoffs, and we took the optimum tradeoffs through the years, but we still did all along what is attempted to be redone with SQL and Java and web pages now. In another words, no one is showing us anything we don't know. Memory and CPU is cheaper now so the tradeoffs are changing, but many of our AS/400 RPG strategies still have benefits. The equivalent of service program encapsulated logic is calling small programs, often leaving *INLR off and passing data in a data structure to be moved into different data structures based on the parm. Yes, service programs provide a unique call per routine, but there is the tradeoff of how large the service program is and the links to all those routines when it's brought into the job. A case can be made that we haven't done badly all these years by calling small focused programs within the job instead. I'm a litle jaded on all the talk about parm validation or whatever as justification for other drawbacks in the latest twist on what we've been doing so well all along. Of course as much more of a veteran than myself on both sides of the issue, you have a clearer picture than me on those tradeoffs, and I'm not saying service programs (or DLL's in Windows talk) shouldn't be used, I'm just saying that AS/400 programmers have been a pragmatic bunch and if something was that compelling over what we already do then it'd be used. After job hunting for the last year and a half, finally working recently, I encountered no one that used service programs to the degree that it was even mentioned, much less discussed as an enterprise business logic server architecture. As for what I've done in this area, I was the project manager for an online shop floor interface to BPCS commissioned by SSA because they had their hands a little full at the time implementing their own business logic server architecture, another massive disaster that along with others such as demanding that everyone move off green screens bankrupted them. But prior to that we delivered a working online interface to SmithKlineBeecham's shop floor control system for transaction processing via SQL over DRDA to insert transaction records in a file on the AS/400 to be processed against BPCS in real time. One of the important transactions was an inventory move, a complicated thing with BPCS' extensive support for lots and containers. The program to do that was an online subfile program, INV510. I extracted all the business logic from INV510 into business logic servers oriented around the files used such as warehouse, location, item, etc, and provided them as calls to the INV510 subfile program. When I was done INV510 only had one file in it, the DSPF. All logic and the file specs were in servers, that is, RPG programs with business logic routines and *INLR left off until it got a CLOSE parm. Standard stuff for all the RPG veterans reading, and the equivalent of service programs minus this parm checking business that justifies all else apparently. It's a tradeoff, but just one tradeoff. So what did I do with those business logic servers with all the logic of INV510 in them? When item location moves came up from the shop floor, it was processed in real time instead of rekeyed into a subfile, but if moves were keyed into the subfile program it also called the same business logic servers. So yes, I am aware of the concept. I did that ten years ago. Extracted and centralized business logic, but just from one program, and the code rode in a library above BPCS so that further mods to their own BPCS was not needed. I would have added more but SSA wasn't too happy we succeeded in delivering a working shop floor interface on schedule to one of their largest customers as they asked us to do. They had a new greenless system to sell that was, to get back to my point, all talk. Sorry for the delay getting back to you, Chris. Ralph