LPARs and all things end user

[J.Pluta]

The new application is a full ERP, and so has a lot more flexibility and stores a lot more data. It also has a lot mre checking and verification. So it will run slower for the equivalent function. For example, in the legacy application, stock levels, allocations, and current pricing are all held on one record on the item/warehouse file with no date differentiation. In the ERP package, stock levels are held on the item/location file, pricing on the item price file with date differentiation etc. The legacy applictaion doesn't really cope with multiple users either - the programs assume that only one user is updating an order at a time whereas the new application has all the checking to detact and avoid concurrent updates etc. What we are trying to prevent is the users getting a performance boost on the legacy application, and then complaining about the performance under the new application. We can explain till we are blue in the face about the improved management information, the better security, the more functionality, the less program bugs etc, but the fellow who picks the parts and then confirms the pick doesn't care about any of that - he just complains about the fact that "he used to be able to pick-confirm an order in 5 seconds and it now takes 2 minutes". The times would actually be 30 seconds and 50 seconds, but he will quote his perceived times and create a negative attitude to the new package. It is a problem everywhere where a mickey-mouse, hard-coded, minimalistic legacy application is being replaced with a full-featured, configurable, flexible ERP package. Lots of "coal face" users aren't interested in the long term benefits for the company, just in getting their job done (there is nothing wrong with this, it just makes it more difficult to justify change in their eyes). What we are wanting to do is to reduce the actual performance difference between the applications, so that the perceived difference is less and therefore the negatives reduced. Call it "management of perceived differential", or "control the negatives before they occur", or "prevent negatives - don't try to cure them afterwards". So, is it dishonest? No more so than the government refraining from mentioning things to protect the people "what they don't know won't hurt them". No more so than taxes being already included in the price of the goods so that you don't "see" them because they aren't obvious even though you know they are there. A lot less than "pre-Christmas sales" where the price is 10% higher than the rest of the year except for the week immediately preceeding the sale (where they put the price up 20%) so they can prove they DID reduce the price. This is such an interesting and very real issue, but not really apropos anything technical, that I thought I'd move the discussion over to Shooting the Breeze. Russell, your points are valid and make a lot of sense, at least at first glance. I won't try to diminish the very real problem of end user perception, but something in this whole line of reasoning is bothering me, so please allow me to just do a bit of free association, if you will. If at any point this sounds at all combative, please don?t take it that way. I'm just trying to feel my way through what seems to me to be almost an ethical issue. It seems that there are a lot of assumptions and a decision or two that have led up to your quandary. Let me address the decisions first. The most obvious is the fact that you've decided you need more features, that your old package wasn't up to snuff. To me, this is a decision that affects everyone and one that should be made with full buy-in from the end users, not simply sent down from on-high. If the end users had some stake in this decision, the chances are that they would be more likely to accept some of the tradeoffs. Why that might not have been practical in your case is not at issue; instead, I'm simply making the point that end user buy-in should be an essential part of any IS decisions. The second decision was on the choice of package and the sizing of the machine. If the issue is that the response time will be faster with the new system than the current speed of the old system, then that should be a very simple public relations campaign. If the system is going to run really fast for a little while and then back to something that's slower, but still better than before, you should have no problem. If on the other hand the decision was made to size the machine so that the new package runs more slowly than the old package did even on the smaller machine then, well, in my opinion you've made a bad IS decision, or at least one that negatively impacts the people you're supposed to be supporting and the end users have a right to squawk. And that brings me to the first of the assumptions. Who says that a fully-featured package has to run slower than a less-featured package? That's been a bone of contention with me for some time now, and is simply another way in which the Microsoft development model has tainted the industry. There was a time when new releases of software ran faster than the previous ones, and with more features and functions to boot. As we learned to take advantage of new advances in the operating system and the languages, we were able to add things that weren't available before. Now of course you're going to have some slowdown when you add some serious overhead. For example, some batch functions may run longer as you add more features. But why should a simple pick and confirm double in time? Order picking hasn?t changed all that much over the years, and even a fairly hefty allocation module shouldn't affect allocation times that much unless you're talking about lot expiration (and even that can be coded efficiently using a view by expiration date; I've done those in the past). And if you didn't have lot expiration processing and you do now, that's something you should be able to tell your end users. (We're back to the buy-in issue again, as well.) My overall point is that picking a package by features alone isn't enough. The fact that the package is slow and bloated pretty quickly offsets the feature/function advantages, at least in my book. You can design a good, feature-filled package that still performs very quickly. It's when you start getting into packages with excess overhead, either from generated code or poorly designed databases or "platform independence features" that you find yourself having to justify the lack of performance or, worse yet, disguise it. And by buying these packages, it's the IS community that's telling vendors it's okay to deliver this kind of software. Ugh. Finally, there's an assumption that the "coal face" users don't care about the company. Well, that is an issue that's brought on by management, not by the end users. You can easily manage employee participation into the process, and you can just as easily manage it out. But by managing it out, you create an environment where IS is perceived as the problem, not the solution, and in my experience, that's an unstable and ultimately untenable relationship. The best environments are when the end user and the IS department are a team working toward the same goals, which should ultimately be to enable the end user to do their job the most successfully. And finally, just a quick and perhaps Pollyanna-ish look at the ethics of the situation. At times it seem to me that we've become a society where we measure our ethics by the fact that we?re not as bad as the other guy. And frankly, the other guy, especially as portrayed in films, television and popular literature, is a pretty darned bad individual. Am I as bad as Gordon Gekko? I sure as heck hope not. But that's not really the point. The point is, am I being the best I can be today? When confronted by a decision, do I do the next right thing? Or do I take the road that's most expeditious, content that at least I?m not as bad as John Milton? I'm not saying this with any sort of judgment, Russell, I'm just not comfortable comparing deceiving my end users with pre-Christmas sales prices. I guess I'm thinking this way just because it's Thanksgiving time and time to count my blessings, and one of those is the blessing to have choices and especially to have the opportunity to live life today a little better than I did yesterday. Thanks for letting me air my thoughts. Happy Holidays everyone! To you and yours: the best of times, the best of opportunities, and the best of memories. Joe

[Guest.Visitor]

Joe, Okay. Let me put some quantitative analysis to the picture. We currently run a 720. The legacy application keeps minimal historical information, and has minimal fields on each and every data file. A pick-confirm currently takes about a minute. If anyone has updating the order in any other way during the pick-confirm, the program doesn't detect anything because it doesn't check for concurrent updates etc. And the whole suite of programs works in one way only - no configuration flexibility etc. There are clones of programs and files to provide minor change of function (e.g. there are 3 separate invoice systems depending on whether the invoice is for equipment, parts or servicing!). We are changing to the Movex package, but it wouldn't matter if it was JDE, BPCS, PRMS or anything else for that matter. The new package has at least 10 times the number of fields in the files, has processes that are soft configurable (do you want stock soft or hard allocated at order entry etc.), and has much more checking for error prevention and detection. The new package also runs in either client-server or green screen across the same database using the same base programs. The package is written to suit many customers by the use of the configurable processing, which imposes a lot of background and overhead program statements. And it doesn't use hard coding (e.g. if this is account 123456 give 5% discount) but uses soft coding held in various files. Nothing new in what I have said above, but the additional checking, the soft configuration, and soft coding add up to a lot more I/O and a lot more CPU cycles for any given user task. We all want the additional I/O and CPU cycles because the end result is an application that is better and more flexible for the users, has better quality data, has analysable data, and therefore has management information as a result of the analysis. So, there is quite a lot more overhead which equates to lower performance. The new package also stores a lot more data and carries a lot more control and reporting fields. It isn't a new release of the software - it is an ERP package replacing a home-grown order entry and invoicing suite of programs (effectively). It isn't that the package is "bloated", but that it is a proper package and not just a collection of poorly (if at all) designed files and programs. We are moving up to an 830. This is going to give us response times on the new application that are better than the current response times on the legacy application - even with the extra overhead. BUT There is about 12 months from the delivery of the new box till the cut over while we configure, modify and enhance, train, migrate etc. We have about 750 users in 35 locations to cover. With the new application, there is more functionality and so a number of currently manual or PC tasks also become application tasks, and the number of users becomes about 900. Now, the new box is an upgrade - in IBM terms. That is, we keep the disk drives and the metal surround and everything else inside is replaced. So, for about 12 months, the users are going to be running the legacy application on an 830. When we cutover, they are not going to remember that the old box took twice or three times longer and so the new app is faster - they will just see that the new app is slower on the new box than the legacy app was. I have seen the same situation last year with the implementation of JDE at another site. The old E60 was wheeled out and replaced with a 170, and the legacy app absolutely screamed on the 170. The JDE package ran at least twice as fast on the 170 as the legacy app had done on the E60, but the users only remembered that the lagacy app was quicker on the 170 than JDE. Do we have user buy-in? At senior and middle management levels the answer is an emphatic "YES". At the "coal face", the answer is still "YES", but all 900 people weren't involved in the selection, they didn't ask for a new package - just less problems with the old. They are expecting to get benefits from the new package, and know that they might have to input a little more detail because of it, and they are happy with that IN CONCEPT. It doesn't matter to most staff that the new app will allow management to improve the ROI - their interest is in doing their job, and knowing that when a customer orders a widget that we will have some in stock, and the computer can tell him where it is, and when he says he has put it in the order that the computer will invoice the customer and order more stock because that will improve his job. I am not denigrating the "coal face" worker, just pointing out that his "buy in" is a lot less intense than the financial controller's. This replacement is being driven by the business, not by IS, but different levels of the business will always have different expectations and tolerances of change. My comments re taxes and Christmas sales were meant solely to demonstrate that we are surrounded by omission and "dishonest" practise. I am not intending to "deceive the users" for gain or commission, but to permit them to be impressed with the new package when it goes live rather than have them negative towards it. The total functionality will impress senior users, the information will impress management, but the "coal face" worker who only uses the computer as an adjunct to what he perceives as his job (he perceives that he is a parts picker and despatcher who also has to tell the computer what he has done so it will print the invoice) is likely to be disenchanted if the new Pick Confirm process is slower than the old - faster than the old used to be, but slower than it was last Thursday. By the way, I am not taking umbrage at your comments, but I felt that if you were questioning and still unconvinced with my previous comments, that I had better try to explain more succinctly. If you still disagree with my motives (and you are entitled to) then so be it. If all the world agreed with me we wouldn't need politicians and armies and theft insurance. Hope this explains it better, Russell

[J.Pluta]

By the way, I am not taking umbrage at your comments, but I felt that if you were questioning and still unconvinced with my previous comments, that I had better try to explain more succinctly. If you still disagree with my motives (and you are entitled to) then so be it. If all the world agreed with me we wouldn't need politicians and armies and theft insurance. Russell, thanks for taking the time to answer. I appreciate your problem. It's not a pretty one. I wish you the best with managing your users' expectations. As you say, this isn't an upgrade, it's a change in IS philosophy from a custom no-frills solution that you've outgrown to a commercial package. That's inherently going to add overhead. But that gives me pause to think; with Java, it's quite easy to configure software so that you can avoid certain types of overhead by having streamlined versions of classes where certain functionality is not needed. You may want to investigate the possibilities there: if you're not using a certain feature, you may be able to remove the overhead with a simple adapter class. In fact, this can be done in any language, though it's much harder. The ill-fated SOM project at SSA was just such a project: the user could define a sequence of "steps" for a given task, and the steps were configurable. For example, one customer might always order the same blanket order; the system could be configured to fastpath that customer through the process. Another customer might require detailed configuration of items, prices, ship-to information and so on; that customer would execute a different series of steps. One size fits all is a bad concept in anything more sophisticated than a desktop utility (in fact, you've probably run into situations where that philosophy has caused you grief even in your word processor or spreadsheet). The ability to configurably process a given task should be built into the very infrastructure of any business system. Java lends itself very well to that concept, through interfaces and overloading. I need to think about this a bit more. Regardless, I again appreciate your taking the time to respond. It was enlightening to say the least, and gave me an even better understanding of issues that I'll have to face as I upgrade my clients from their legacy systems to web-enabled applications. My focus has always been on making sure that the web interface is as productive as the old green screen; now I know that that particular focus is a good one (even though most of the GUI vendors don't seem to realize that simple fact). Thanks again, Russell - and Happy Holidays! Joe http://www.java400.net http://www.edpeloyment.com http://www.plutabrothers.com

[Guest.Visitor]

Joe Pluta wrote: "Russell, thanks for taking the time to answer. I appreciate your problem. It's not a pretty one. I wish you the best with managing your users' expectations." This is a response to both you and Russell, Joe. Russell is implementing MoveX, which is available in Java, but by describing the interface as available in green screen I'm assuming he's implementing the RPG version. I'm also assuming that he installed it, tried it out, found it ran like a dog on his box for some reason, and upgraded to the 830. I do not agree with Russell's description of multi-user processing as slower than single user processing. It's a red herring as he practices his sham pitch on us before he runs it by the "coal faces", pity them. It sounds reasonable, but only if two people were updating the same record at the same time, and the ERP software keeps the record locked during screen update for the first person who accessed it , and the second person is waiting while the ERP software neither informs them of the situation nor times out and so has this alleged "slow processing" as they wait for the record to become available, none of which is normally the case. Of course, not being locked during screen update allows retrieval for update after the first one was retrieved. I have seen many discussions on the merits of different approaches on handling this synch problem, but the issue is a red herring as the same record is rarely retrieved for update simultaneously and thus cannot be attributed as the source of slowness. As for soft coding, configuration tables, error checking, and general robustness, all RPG ERP's have this level of capability and are not slow. Russell mentioned close to a minute to perform a transaction. My first thought is that Intentia may have converted all I/O to SQL to make it easier to keep RPG and Java code bases in synch, and I think I have read where they have made noises about their Java MoveX being cross platform now which rules out that they ported their RPG I/O to Toolbox record level I/O classes. But I have never been able to glean the technical details of their port from what they publish. I'm going to assume they kept their RPG version with record level I/O, but if they went to a universal SQL I/O model then some speed would be lost there, but still nothing like a minute. Intentia may be shipping Java back end software as a replacement for some of their processing so that they could add features to only their Java codebase and not have to retrofit the enhancements to their RPG codebase. Java is 20 times slower than RPG on I/O intensive computing such as transaction processing and this would account for it runnng like a dog, Again, I reject the contention that RPG ERP's are noticeably slower than custom, hardcoded RPG systems, although of course the additional I/O performed by an RPG ERP is measurable at some level. There's no way it adds up to several seconds. The SOM white paper that you wrote up, Joe, was an interesting architecture. My mind reeled as I considered the consequences of code smart enough to know which processes had been enabled in what order and the ramifications of knowing what data should be retrieved from what files based on what has or has not been done or will never be done with this person's configuration. Ah, the complexity. But when I went through SOM orientation at SSA and asked how do we know how to code with configurable processing, nobody knew what I was talking about. Gus, Ben, Bill, Mike, Purple, Ian.... all had no clue. Found out a few weeks later it was a big TBD, where D could be Designed, Developed, or Determined, take your pick. Anyway, it was a lot of food for thought. Don't know if anybody has done it successfully yet at the level you proposed. Ralph ralph@ee.net

[J.Pluta]

The SOM white paper that you wrote up, Joe, was an interesting architecture. My mind reeled as I considered the consequences of code smart enough to know which processes had been enabled in what order and the ramifications of knowing what data should be retrieved from what files based on what has or has not been done or will never be done with this person's configuration. Ah, the complexity. But when I went through SOM orientation at SSA and asked how do we know how to code with configurable processing, nobody knew what I was talking about. Gus, Ben, Bill, Mike, Purple, Ian.... all had no clue. Found out a few weeks later it was a big TBD, where D could be Designed, Developed, or Determined, take your pick. Anyway, it was a lot of food for thought. Don't know if anybody has done it successfully yet at the level you proposed. The problem was one of politics, actually. I suppose I'm no longer talking out of school, now that SOM is quite cold in the ground and all the major players have moved on. What happened was that once the architecture was designed and implemented (the CPR architecture), SOM became a sort of political football. It eventually fell under the auspices of a group of people who had never designed a client/server system and had no idea what they were getting themselves into. The design of a client/server architecture is very much like the design of an object hierarchy; you have to have a clear idea of what you're trying to accomplish, and you have to leverage common code wherever possible. This is quite possible, even in RPG III, but you have to be prepared to do it from the start. Otherwise, you end up duplicating code, and of course the duplicated code quickly becomes out of sync, debugging becomes a nightmare and so on. Unfortunately, the only person who had ever designed a mission critical client/server architecture was unceremoniously removed from the project (yeah, that would be me) in a very political furball. And so the application design portion was run for all intents and purposes without a lead architect. The result was pretty predictable. Now, however, I'm thinking it may be time to revisit that whole architecture. As I alluded to in my earlier post, Java is MADE for configurable programming - to the point of being able to add new modules after the original system has been implemented without rewriting a single line of code! The beauty of programming to an interface is the fact that ANY class that fulfills the contract of the interface can be used - even if it's written after the fact. The possibilities for system development are staggering. All you need to do is have a clear understanding in your mind of what an interface is, and you're free to implement a simple solution today and a more complex one tomorrow. Let's take a case in point, pricing. If you were to simply reimplement an existing pricing methodology, you might want to create a method on the Item class called getPrice() that does some magic, and then code your order entry program to call that method. But really, are you pricing an item? No, if you think about it, you're pricing an order line. So the next design iteration might be to create a price() method on the OrderLine class. Since OrderLine has a link to the OrderHeader object, you could also get customer number and a number of other things necessary for a good, flexible pricing system. And this would probably be as far as most designs would go. But there's an inherent flaw in this scenario. It means that any time I want to enhance my pricing method, I need to change my OrderLine class. And that's not a good separation of duty, especially if I'm using a distributed processing environment. I need to think ahead... in the best possible world, I'd want a fully featured pricing server that could accept a getPrice() message; this would isolate the pricing logic from the order processing logic (which would be more involved in things like order status, picking, shipping and the like). So instead, I have a PricingServer object that supports a getPrice(OrderLine orderLine) message. So far, so good. But here's where the rubber hits the road. We've now got a highly bound relationship - PricingServer to OrderLine. While it's good enough for right now, it's not very flexible or extensible. We have a class with a method that returns a single price, and it's tied to an OrderLine object. We'd have to subclass this class if we wanted to change the pricing methodology, and while that's not all bad, it would be better if the details of the pricing logic were left to the implementation. More importantly, we can only price OrderLines; in order to price other things (QuoteLines? SpecialLines?) those things would have to subclass the OrderLine class. This could cause some serious inflexibility later on as our system becomes more sophisticated. So we need to generalize yet one more step. We need to create a Pricer INTERFACE, as well as a Priceable INTERFACE. The Pricer interface is very simple; it defines the setPrice(Priceable priceable) method, whose sole purpose is to set the price in the priceable object. The Priceable interface isn't much more complex. There are several ways to implement it, but one way would be to support two methods: getPricingData and setPrice. The getPricingData method returns a data bean with the appropriate fields to determine the pricing information (such as customer, item and quantity, for example). The setPrice methods accepts a data bean with the new price data, extracts the appropriate price and stores it in the order line. Why this approach? Because the two data beans are subclassed from PricingData and PriceData adapters, which can grow as the requirements grow. The OrderLine class will implement an OrderLinePricingData class and an OrderLinePriceData class which subclass the two adapters. But if another class is defined someday which requires more fields in those two beans, they can be extended without in any way affecting the OrderLine interface. Whew. Gone on a while here, but let me hit the final piece to the puzzle, and the one that really makes this whole concept shine. Let's say company A wants this new ERP package, but they don't want the overhead of a fancy promotions and deals database with all kinds of customer-based pricing and such. They are a straight Mom and Pop retail shop with no discounts, what you see is what you get. They don't need all the trappings and don't want to pay the performance penalty. So guess what? You design a Pricer subclass to simply access a database keyed by item number, and their pricing logic is complete. Note: there is NO overhead from having the capability to add promotions and deals. If Mom and Pop grow to need promotions and deals, they can add it by simply plugging in a new Pricer object, with the associated performance penalty. But if they don't need it, they don't have to pay for it. And THAT, folks, is configurable processing at its finest. Joe http://www.java400.net http://www.edeployment.com http://www.plutabrothers.com

[Guest.Visitor]

Joe wrote: "If Mom and Pop grow to need promotions and deals, they can add it by simply plugging in a new Pricer object, with the associated performance penalty. But if they don't need it, they don't have to pay for it." Same thing is accomplished by calling an RPG program with a set of parms and having the program check configuration flags to see if Promotions and Deals is installed and applicable. oops... RPG ERP's already do that. A program parm interface is no less flexible than the Java Interface type; a change in either requires a recompile of all referring to them. Ralph ralph@ee.net

[J.Pluta]

Same thing is accomplished by calling an RPG program with a set of parms and having the program check configuration flags to see if Promotions and Deals is installed and applicable. oops... RPG ERP's already do that. A program parm interface is no less flexible than the Java Interface type; a change in either requires a recompile of all referring to them. Not true. They have to check parms, Ralph. And where are the parms? In a configurable ERP system, processing parms are at one of many different levels. For example: system, customer, item and item/location, each which may override the other. So for each line you have to do four different reads. Now you may be able to cache the system flag, but what if you're running a 24/7 shop? Then you need to be able to update your cache in case the system flag changes. It's even more problematic as you drop down levels of granularity. And this is just the pricing flag. You may have an allocation flag, and a kits and assortments flag, and a lot tracing flag and an FDA licensing flag. Conditional processing requires extra overhead on each line for each flag, and this can really add up for large transactions. This is exactly the type of feature bloat that I was talking about. Subclassing avoids all of that. So we're talking not about a "configurable" ERP system, but in essence a "conditional" ERP system. The software is not configured, the processing is conditional based on a myriad of flags. And because of that, you have the possibility of SETTING THE FLAG WRONG. In conditional ERP systems, the most common user problem is the simple act of setting a flag incorrectly. The most common programming bug is testing such a flag incorrectly. If there is no such flag, if instead the software is configured rather than conditional, then that simultaneously removes the most common sources of both user error and programmer error. No, configured software is far more robust than conditional software. Joe http://www.java400.net http://www.edeployment.com http://www.plutabrothers.com

[Guest.Visitor]

"So we're talking not about a "configurable" ERP system, but in essence a "conditional" ERP system. The software is not configured, the processing is conditional based on a myriad of flags." Whatever we're talking about, the same thing is accomplished by replacing a business logic module having the same parm interface with a new module containing additional functionality. This is done by copying in the new RPG program to replace the old RPG program as an implementation of the new business module. All this does of course is keep the initial versions lighter in not carrying around the logic that has not been key enabled, plus a very good added benefit of business logic that does not try to be all things to all people by constantly checking flags to switch in and out of these configurable modes. This stuff is extremely error prone, as we have all seen as we work with ERP logic. But it doesn't take Java, the Interface, and subclassing. Just a good old in place program replacement where the parm structure is the same for all levels of the module functionality, just as a Java Interface would be. And we have all the modularity capability we need in ILE RPG. Java is not required. Ralph ralph@ee.net

[J.Pluta]

A program parm interface is no less flexible than the Java Interface type; a change in either requires a recompile of all referring to them. One other thing on this particular issue. I used a little shorthand when I described Pricer and Priceable interfaces. I said: "(...)the two data beans are subclassed from PricingData and PriceData adapters(...)". Note the word "adapter". This is a shorthand that implies a class that implements all of the methods of an interface. Let's say I start my PricingData interface with only the methods getItem/setItem and getQuantity/setQuantity. My PricingDataAdapter will provide the setter and getter methods. In my OrderLine class I instantiate a OrderLinePricingData class (which subclasses PricingDataAdapter) and set the item and quantity fields. This is what is passed to the Pricer object from the getPricingData method, and everything works just fine. Okay, let's say I decide to extend the pricing system to allow pricing of a different type of line, such as a freight charge line. This line is priced not by item but by zipcode. I can add a zipcode attribute to the PricingData interface and the associated methods to the adapter. I create a FreightLine class which in turn uses a FreightLinePricingData subclass. But the OrderLine class doesn't change! It doesn't need to be "recompiled", because the class loader is smart enough to use the new PricingDataAdapter definition when it loads the OrderLinePricingData class. The OrderLine and Pricer have been successfully decoupled through the use of the PricingDataAdapter. Java interfaces and RPG parameter lists are VERY different things. Properly used, you can provide much more flexibility with interfaces than you can with parameter lists. You can simulate some of the features of subclassing in a non-OO language, but you had better do a LOT of thinking beforehand. For example, to simulate what I've just outlined above, you're going to need to support a wide variety of different parameter lists. How do you do that without recompiling? You can go to an externally described data structure, but you'll need a different one for each parameter list. So now you'll need a parameter defining the type and a parameter defining a "variable" data structure. All doable, but not without some prior preparation on your part. Java is designed to do this stuff. Non-OO languages are not. Joe http://www.java400.net http://www.edeployment.com http://www.plutabrothers.com

[J.Pluta]

But it doesn't take Java, the Interface, and subclassing. Just a good old in place program replacement where the parm structure is the same for all levels of the module functionality, just as a Java Interface would be. As I've just pointed out, it doesn't REQUIRE Java, but it's much easier to implement in Java. If your programs allow variable data structures to be passed as parameters, which is essentially what a Java adapter class is, then you can do it. But that's not what you're saying. You insist on using a parameter list. That won't work because RPG (like any other non-OO language) doesn't support method overloading. Without it, you must have "the parm structure ... the same for all levels of the module functionality". Well, unless you're an oracle, that can't work, because that would imply you know what the future requirements are. The beauty of O-O is that you don't need to know things in advance, you simply need to understand how programs are built and how they communicate, and learn how to design adaptive interfaces. Again, this can be done in RPG, but not easily and definitely not with parameter lists. Joe http://www.java400.net http://www.edeployment.com http://www.plutabrothers.com