RPG and DB2: The Future Is Now

[Guest.Visitor]

RPG and DB2: The Future Is Now

cdr5000 said: "I don't see ERP programmmers as some sort of superior ruling class. I've worked around enough coders to know better." I only see programmers. In a small shop like mine where I only have 8 AS/400 programmers they'd better be able to do it all. No room for specialists. I think my shop is more mainstream in the AS/400 world than larger shops where there are specialists. chuck Opinions expressed are not necessarily those of my employer.

[dacust]

RPG and DB2: The Future Is Now

You are missing my point. I say get away from the green screen. Let the X86 people do the screens and reports. I agree that OMW can do reports better, more efficently and more pleasing than the big iron. I have repeatedly in my posts said the different platforms should do what they are best at. And I have repeatedly hinted that there is no one platform that is best at everything. I agree with most of the things you have pointed out as strengths of the X86 technologies. I still maintain that there are strengths in RPG and the 400 that have yet to be met by other platforms. Each has it's place. -dan

[dacust]

RPG and DB2: The Future Is Now

To agree with you: To the people not familiar with One World, like I said in a previous post, I think it's a brilliant design. It does give the end user more ability to do their own reports than most anything I have seen on the 400. That is, I've seen things like it on the 400, but the performance of 400 implementations have mostly had been poor. One World was ahead of it's time when it was released almost a decade ago, but probably was released too soon. But IMO it's the shape of things to come. In the past coupla years they have improved it tremendously. The performance is now getting better when using a 400 as the database. Previously, depending on configuration, it was dismal with the 400. And as I said, I couldn't find anyone within their company that understood the 400. But it is the first real step I've seen (other than some X86 front end report writers) in combining the real strengths of various platforms. -dan

[dacust]

RPG and DB2: The Future Is Now

I should have also said, One World probably works much better with some other platforms. It may be one of the first applications of this magnitude that can run solely on X86 platforms. At least the first I am aware of.

[M.Savino]

RPG and DB2: The Future Is Now

I was wondering who'd be the first in the Forums to invoke the name of Harry Chapin. And that's a pretty good clip Daniel, even if you did mean 12 objects (3 files, nine pgms, Right?). At our shop the paperwork alone would take about 3 hours per object. And being a Pharmaceutical Mfg, a one line change to a program that touches the Lot Master will keep 2 people busy for a week. I used to live by the motto "Test it in Production. 'Cause if it doesn't work in Production it'll never work in Test." But I just can't get 'em to see it my way around here. But getting back to your discussion, while I agree with CDR that you can quickly throw together a simple Inquiry or Report that looks really slick using OneWorld Event Rules programming, that's exact what you've got.... a simple Inquiry or Report. If you want to add business functions or enforce business rules, I don't think you can do it any faster with Event Rules or VB than you could with RPG. And the performance of RPG (IMO) is going to be a lot better. To illustrate, the local college brought in a JDE Business partner to demo OneWorld for a graduate level ERP class. I got to sit in because I was freinds with the instructor and was teaching an AS400 class at the time. The students were "wowed" by the GUI nature of the product and the guy doing the demo was good. He was demoing Order to Cash and was at the point where he was going to print the pick list. He explained that OW gave the user the ability to Order Reports in any way they wanted. Since the Pick List was a Report, it could be Ordered in a way that would make it most efficient for the Warehouseman to pick the Order. So he chose to Order the Pick List by location and printed a very attractive looking Report in .PDF format. He explained that using the Pick List, the Order Picker would need to make only a single pass through the Warehouse since the Items on the Report appeared in location sequence. The students were duely impressed and he continued. Now you and I know that any MRP system from the 70's would be able to Order a Pick List by Location. If it couldn't do at least that, no one would buy it. It adds no competitive advantage because absolutely everyone can do it that way. A Food Distributor I once worked for was known for their innovation and wrote their own Warehousing system. Food is a little different than non-perishables. Some of it has to be kept dry, some refrigerated and some frozen. Many of their delivery trucks were compartmentalized so that they could use a single truck to deliver an entire customer order. Here's how their Pick List worked. First, they didn't pick for a single Order. Each truck had a Route that serviced certain customers. All Orders on the Route were taken into consideration when the Pick List was created, along with the Stop number of the Customer and whether the Item was Dry or Refrigerated. Partial case quantities were also taken into consideration so that a single case could be divided between customers without having to return to that location. The Order Picker pulled a train of dollies through the Warehouse and at each location picked all the product needed to fullfill all the Orders on the Route. The Pick List told him/her what quantity of product went on each dollie and labels were provided. In a single pass through the warehouse, all the product needed to load the entire truck was picked, labeled and in the proper order to be loaded. That kind of stuff adds value and that system was written in RPGLE. The complexity is in the business logic (where it belongs). I've got limited experience with OneWorld Event Rules but I've done quite a bit of coding in VB. IMO, no amount of pointing and clicking is going to make that kind of application any faster or easier to develop or run. Now.... back to Harry Chapin. Mike

[dacust]

RPG and DB2: The Future Is Now

I wondered if anyone would comment on the bananas. I explained the truck race since I thought that was WAY to obscure. Actually, for each file there's a CL, RPG and DSPF for the recap selection screen, an RPG for the maintenance, and for the listing, a CL, PRTF and RPG. So that'd be 21 objects for 3 files. As to all your other comments, it all sounds reasonable to me. Probably said a little better than it's been said in here so far. One little point: Printing the pick list by location may not be inovation, but being able to produce the report in a couple of minutes is. However, to what you were trying to say, what if the layout is such that picking by location would be inefficient? How do the numbers run up and down the isles? And if the isles run in different directions? Now it gets more complicated. Years ago I worked on a pick system in a warehouse where the product could be placed in any empty location. No order at all to where it went. You only cared about where it was when picking to ship. It was rolls of fabric, varying numbers of yards, stacked 3 wide in a cross stack pattern. The goal was to try to pick the entire order from one location. The customer's contract stated that they would pay for exact yards +-10% of the order. So if we could ship +10% the company made more money. The algorithm looked starting from the top of the pallet going down, and if it was almost done, it might have anywhere from 1 to 3 rolls on the layer to pick the last roll from. It checked each location the same way and found the place it could pick as close to +10% of the order that it could. OK, that story was WAY too long, but my point is, there is NO WAY that someone could create that with a point & click interface. -dan

[dacust]

RPG and DB2: The Future Is Now

NOW you've written a post that I can agree with almost everything in it. My personal opinion is that putting a GUI screen/scrape (or the like)front end on a green screen app is only valid to extend it's life like you said. I'm for moving those functions off the 400 and giving the user a total GUI interface. I should NEVER need to pay IBM for an interactive machine. A transactional machine is all I should ever need (except maybe for my development machine). In my shop we are already moving much of the reporting for upper management of my division to the Intranet. We have a separate 400 that consolidates the info and a SQL/HTML server that grabs the info and presents it to the user. Once again, I think it's the best of both worlds. But it requires me programming the RPG functions of the production boxes and the consolidated box, and a VB programmer programming the HTML server. I don't see that as a problem that it's more than one platform with more than one set of programmers. I see it as taking advantage of the best ways to do different functions. -dan

[David Abramowitz]

RPG and DB2: The Future Is Now

CDR5000 wrote: To be blunt, only an idiot would go this direction if there was a reasonable option available to simplify things. As the sole person working in a smaller shop with limited resources, I would be interested in a reasonable simplification. How much does One World cost? Dave

[J.Pluta]

RPG and DB2: The Future Is Now

It still does not negate the concept of fewer programmers, not more, and less IT, not more. Nor does it change dismal future awaiting the coder who embraces spaghetti technology. It's statements like this, laden with implication, innuendo and incompleteness, that weaken your more cogent points. There is the implication that multiple technologies is "spaghetti" technology, and that's simply not true, any more than your automobile, or even your workstation, is spaghetti technology. The implication is that multiple technologies is bad, and you're just plain wrong on that point. A properly designed multi-tier application is anything but spaghetti; it is instead a powerful synergy of multiple technologies. There is the innuendo that IT is bad in and of itself. This isn't true either. Without the IT department providing the capabilities to enter and validate data, all of your data extraction tools are meaningless. I don't care how smart your end users are, GIGO applies and bad data means bad reports. The trick of getting good data into the system is, was and for the foreseeable future will be the domain of the professional business programmer, not the "occasional developer". That will change only when there are tools that allow an end user to quickly develop an MRP generation or a shop floor production post. Finally, the statement is incomplete in that it doesn't embrace the biggest challenge to any IT department: changing business rules. If you have 20 users with 200 custom queries on your database, and you have to change the layout of the database, then those users have to change all of their queries. Without centralized control of those queries, you have no way to assess the impact of such a change. Similarly, if your tool doesn't have excellent backup and change control features in place, you run the risk of breaking things and being unable to restore them. Many of these issues can be resolved with a centralized messaging system, while others are procedural issues that need to be addressed... issues that the IT department may understand better than the end user. Other issues also rear their heads as you deploy outside a centralized IT environment: security, Sarbanes-Oxley, Section 508 and any of a number of other complex problems that become more complex as you distribute the workload. This is not to say the decentralization is a bad thing! The problem is that it must be done intelligently, and with the recognition that there is no silver bullet. Centralized business rules are a good thing, and centralized data access is key to system integrity. Most of this work will be done by business programmers, not tools. Joe

[M.Savino]

RPG and DB2: The Future Is Now

Ask Gateway.... It only cost them about $300 million. Before they decided to pull the plug. Ouch!!

[M.Savino]

RPG and DB2: The Future Is Now

Daniel, You knew that once you said 21 Objects in three hours, that someone was going to try and beat that mark. But 21 Objects in 30 minutes.... Wow !! Sounds like we're playing "Name that Tune". I can write that program in ..... I just checked our turnover logs. It's somewhere between 40-50 programs per month. Since we include PRTF's, DSPF's and Database Files with the RPG program Documentation, I'm going to assume that the total number of objects is about twice that, so let's say 100/month or 1200/year. And that includes Mods as well as new stuff. Now... at the rate you guys write them, even slow pokes like Daniel, that's 3 hours / 21 objects = 180 min/21 objects... Lessee, that's about an Object every Nine minutes.... So about 6 Objects per hour, * 500 man hours per quarter gives us about 3000 Objects per programmer per Quarter. Not Bad !! So Chuck, do you tell your 8 programmers that they need to produce 100,000 Objects per year to meet their quota ?? And do you wait for User Requests.... Or do you just write 'em in advance ?? I wonder what my bosses will say when I tell them that You Guys are 80 times more productive than We are ?? On second thought .... Mike

[Guest.Visitor]

RPG and DB2: The Future Is Now

The number of objects is meaningless. I can create a hundred of them in Progen in 30 minutes. The functionality is what's important. As I recall there was an update program and two inquiry programs. Should be a snap to do in Progen or WebSmart in 30 minutes. "mikejsavino" wrote in message news:6b16df97.64@WebX.WawyahGHajS... > Daniel, > > You knew that once you said 21 Objects in three hours, that someone was going to try and beat that mark. But 21 Objects in 30 minutes.... Wow !! Sounds like we're playing "Name that Tune". I can write that program in ..... > > I just checked our turnover logs. It's somewhere between 40-50 programs per month. Since we include PRTF's, DSPF's and Database Files with the RPG program Documentation, I'm going to assume that the total number of objects is about twice that, so let's say 100/month or 1200/year. And that includes Mods as well as new stuff. > > Now... at the rate you guys write them, even slow pokes like Daniel, that's 3 hours / 21 objects = 180 min/21 objects... Lessee, that's about an Object every Nine minutes.... So about 6 Objects per hour, * 500 man hours per quarter gives us about 3000 Objects per programmer per Quarter. Not Bad !! > > So Chuck, do you tell your 8 programmers that they need to produce 100,000 Objects per year to meet their quota ?? And do you wait for User Requests.... Or do you just write 'em in advance ?? > > I wonder what my bosses will say when I tell them that You Guys are 80 times more productive than We are ?? On second thought .... > > Mike

[David Abramowitz]

RPG and DB2: The Future Is Now

Mike asked: How much money have you got, Dave ?? For this purpose?? A reasonable amount. Dave

[Guest.Visitor]

RPG and DB2: The Future Is Now

cdr5000 posted: "Moving IT jobs out of IT and closer to the user base is on the way, like it or not. Next will come the easy development tools." For those of us who have been in this business for along time this shouldn't be a shock. When I started my IT career everything was done in the IT department then called Data Processing or Electronic Data processing. We did all of the input all of the programming and all of the printing. Eventually that changed. When a computer could support more than one printer we often put that printer in the user department. Later when on-line systems arrived we put data entry in the user departments. Most IT shops now no longer have any printers or any data entry personnel anywhere near the computer. About 10 years ago I started recruiting "power users" to create queries using IBM's query tool. That was hit and miss since IBM's query is difficult for an end user. In the past 5 years I've been deploying ASC's Sequel to the end users. That product is highly successful and we have a half a dozen power users in various departments that reduce the workload on the programming staff. However, as I preach around here, the primary job of the IT department is to be "the keeper of the data." Our job is not any more glamorous than that. So, to keep the data safe and to maintain integrity of the data I won't deploy any tools to users outside the IT group that allow them to modify, delete or alter the data unless they use a program written by the IT department. We're a private company with only 1 shareholder so I don't have to worry about SOX compliance but I still treat the data as holy. chuck Opinions expressed are not necessarily those of my employer.

[Top Cat]

RPG and DB2: The Future Is Now

Many young college graduates don't code anymore. They are just taught theory. Check out UCLA for example. Also, if a company needs coders, they just go to India. If they don't have enough, they go out in the street and pull somebody out of a cab and teach them programming. (I didn't make this up, it's true.) I've seen code written by Indians such as a WRITE statement, and the next line they coded was MOVE "00" to STATUS-CODE. This is America's answer to cut programming costs. Get used to it!