Of course, I've got to say a word or two here.

[Guest.Visitor]

Joe said: I guess my host-centric nature shows here, but this doesn't seem like an advantage to me. To have non-AS/400 programmers directly accessing the database, even in read-only mode, is a recipe for disaster. If they don't fully understand the relationships between the files, then they have potential for doing some really bad things. That IS an old saw. You'd be surprised that there are non-AS/400 people actually do understand databases and relationships between files. IMO, where the data is stored shouldn't matter to the programmer. chuck Opinions expressed are not necessarily those of my employer.

[J.Pluta]

Of course, I've got to say a word or two here.

This is purely my experience, but many BASIC programmers I have worked with don't understand the fundamental concepts of relational databases. I've also run into this with Lotus Notes developers who are very, very good at designing document workflows, but don't have a good grasp of database relations. In both cases, there is often a large amount of redundant data and extra access required. A very good example: see if they understand the concept of changing a primary key value. Many people who haven't come up through the midrange ranks will design databases where the key values can't be changed (for example, they'll use a customer name as the key for attached data). In that case, you'll either not be able to change a key field, or if you do, you'll lose the dependent data. Concepts like recursive bills of materials or hierarchical header/detail relationships are foreign concepts. This is not to imply that there are no BASIC or Lotus programmers that understand relational data. Programmers vary. Heck, I've known my share of RPG programmers that didn't understand some of these concepts. It's just my opinion that before you open up your database to general free-for-all access, you should make sure that you know who is accessing it. Using a tool that moves business rules off the host is a dangerous proposition at best. Because even if your programmers do understand the data, then you still have the issue of having business logic in more than one place, which is always a bad idea. There are people who insist that it's acceptable to have business logic on the client, but those people can rarely point to a successful large-scale thick-client application. Of course, opinions vary on this subject. My opinions reflect my experiences over the years, and your mileage may vary. Joe

[rdean400@yahoo.com]

Of course, I've got to say a word or two here.

You said:

Many people who haven't come up through the midrange ranks will design databases where the key values can't be changed (for example, they'll use a customer name as the key for attached data).

Is that to say that primary key values should be allowed to change, or that they make the (poor) choice of turning fields that should be allowed to change into primary keys?

[Guest.Visitor]

Of course, I've got to say a word or two here.

Joe, I have to agree with you whole heartedly here. I believe that my past employer's failures wasn't necessarily rooted in the use of Java. After all, a programming language is a programming language. I believe it was rooted in using programmers who knew only Java or C++. Why do I say that? It's because these programmers are generally younger, just out of school and haven't learned a lick about business programming. They spent a huge chunk of each meeting discussing what tools they were going to use. The management was worried that if they didn't get the right tools then the developers would jump ship. In any event, I remember spending hours, over a period of several weeks, trying to explain the concept that when we got a file from a customer (Saturn Automobiles, in this case) where the first 2 bytes represented the record type. I.E. "H" was header, "D" was detail, "T" was trailer, etc. This concept was completely foreign to the Java development group. chuck Opinions expressed are not necessarily those of my employer. "Joe Pluta" wrote in message news:4cf10312.1@WebX.WawyahGHajS... | This is purely my experience, but many BASIC programmers I have worked with don't understand the fundamental concepts of relational databases. I've also run into this with Lotus Notes developers who are very, very good at designing document workflows, but don't have a good grasp of database relations. In both cases, there is often a large amount of redundant data and extra access required. A very good example: see if they understand the concept of changing a primary key value. Many people who haven't come up through the midrange ranks will design databases where the key values can't be changed (for example, they'll use a customer name as the key for attached data). In that case, you'll either not be able to change a key field, or if you do, you'll lose the dependent data. Concepts like recursive bills of materials or hierarchical header/detail relationships are foreign concepts. | | This is not to imply that there are no BASIC or Lotus programmers that understand relational data. Programmers vary. Heck, I've known my share of RPG programmers that didn't understand some of these concepts. It's just my opinion that before you open up your database to general free-for-all access, you should make sure that you know who is accessing it. Using a tool that moves business rules off the host is a dangerous proposition at best. | | Because even if your programmers do understand the data, then you still have the issue of having business logic in more than one place, which is always a bad idea. There are people who insist that it's acceptable to have business logic on the client, but those people can rarely point to a successful large-scale thick-client application. | | Of course, opinions vary on this subject. My opinions reflect my experiences over the years, and your mileage may vary. | | Joe

[Guest.Visitor]

Of course, I've got to say a word or two here.

Robert, Assuming you have referential integrity, I think that being able to change a key would be absolutely acceptable. But, I think that the point Joe was making is that the key should be chosen carefully. If, for example you use the customer name as the key and then the customer name changes then it can wreak havoc. chuck Opinions expressed are not necessarily those of my employer. "Robert Dean" wrote in message news:4cf10312.2@WebX.WawyahGHajS... | You said: Many people who haven't come up through the midrange ranks will design databases where the key values can't be changed (for example, they'll use a customer name as the key for attached data). | | Is that to say that primary key values should be allowed to change, or that they make the (poor) choice of turning fields that should be allowed to change into primary keys?

[J.Pluta]

Of course, I've got to say a word or two here.

Chuck's reply was on the mark - you should be able to change a primary key, and you should choose your keys wisely so that you don't have to do it often. A typical example of when primary keys have to change is a merger. Hopefully you don't have to go through that too often. At SSA I also saw many cases where things like item numbers or lot numbering algorithms changed. In both of these cases, a lot of subsidiary records had to change. On the other hand, you definitely don't want to key things to something like document name or customer name, as Chuck pointed out. Unfortunately, if you come from a document processing environment, you probably don't think about those things. A newer example is URLs web sites. Some web administrators seem to think nothing of changing their web site layout every other week. This can play havoc with anybody who depends on the web site. Public web sites in particular should have a "URL administrator" whose job is to make sure that web links migrate properly if a change is necessary. That's something I'm working on right now, because my web site has to undergo a complete revamping. All the links are going to break, but if I do it correctly this time, this will be the last time that sort of thing happens. It's not easy, but with some foresight you can do it. (It involves breaking your website into "web entities", if you will, that are roughly akin to business objects, such as warehouses and locations, and then assigning keys to those entities. You then use your HTTP server to map those keys to actual internal URLs. By doing this, you insulate your external web structure from your physical directory layout. This technique insulates your users from changes, while at the same time offering a little better security.) Joe

[Guest.Visitor]

Of course, I've got to say a word or two here.

Chuck, You're example sound exactly like what's going on at my company. It's not neccessarily the fault of the platform, the development environment, the languages, or the developers rather the reality that you cannot re-invent a mature business application system. If the system was originally hosted on an Oracle box and they wanted to port it to an AS/400 with RPG you would have the same outcome. It's different to say that the Java developers failed at re-creating a mature application than it is to say that the Java developers couldn't have easily built an interface to the existing system if given the opportunity. It all boils down to time, effort and good direction. If the company wasn't ready to invest the right amount of time and effort to re-build the application then their direction should have been changed to building a front-end or shelled interface around the existing system. Cliff The opinions expressed are those of my own and not neccessarily understood by my employer.

[David Abramowitz]

Of course, I've got to say a word or two here.

Clifton Craig wrote: If the system was originally hosted on an Oracle box and they wanted to port it to an AS/400 with RPG you would have the same outcome I strongly disagree. Once the goals and objectives of the application are defined, it should be apparant what needs to be done on the 400 side. As it happens, in the case you have mentioned, there will be a lot less to do. There is a good deal of programming, and tweaking in Oracle, that is not necessary on the 400. What is necessary, are good people who are familiar with both systems, and know what, and what not to do. Dave

[Guest.Visitor]

Of course, I've got to say a word or two here.

Dave, You must have misunderstood my point. The point is that good systems develop over time and to have a bunch of devlopers come in and re-create from scratch what took time to implement in the first place in un-feasible in most situations. I'm not debating which technology is better or whether or not it is easier to re-code from one language to antoher. I'm only saying that most systems start very basic and develop rich functionality over time. The key factor here is time and not the programming language or platform. If a system has been enhanced for over 10 years then it will take alot more than ten months to re-write it regardless of what languages or technologies are used. That's just a point of fact.

[David Abramowitz]

Of course, I've got to say a word or two here.

That is not necessarily a fact. It isn't even a theory, it is a hypothesis which may be borne out by your own empiricism. I can respect that. Here are my personal experiences: I have taken systems from a variety of platforms to the AS/400. This includes mainframes, Unix, and PC based systems. In each case, I was able to complete the metamorphoses ahead of schedule, and in most cases with enhanced functionality. This was spec work, and in each case existing functionality had to be retained in full. The method of retaining the capabilities was up to me. My choice was not to try to copy the existing environment, but rather to play to the strengths of the new platform. OTOH, I have also been on projects where systems were taken off the 400, and on to CS based systems. To make a long story short, it was a nightmare. When the project was completed at all, it always took at least three times as long as originally allotted (I was not the manager here). In one case completion was five years overdue and $17,000,000 over budget. AND STILL SOME PORTIONS REMAIN ON THE 400!! My personal experience in general terms, is that it is far easier to move a system from Oracle to the 400, than the other way around. I do not represent that as a fact, but it is consistent in my experience over a variety of differring situations. I understand that long standing customized systems have a great deal more complexity as time progresses. I also understand that if you can document each function and process of a system, you have the battle half won. Dave

[Guest.Visitor]

Of course, I've got to say a word or two here.

Joe, You're right. I didn't explain it in enough detail. I my experience, the 40 Java developers were developing an application on a Sun/Oracale combination using Linux web servers to REPLACE the programs that were running on the AS/400. The CIO was a huge anti-AS/400 bigot that simply feared the AS/400. One by one they took customers to the new Java based platform. After about 5 customers were running they stopped the migration. Access times for information went from sub-second to over a minute. Also, at least twice a day, the database (Oracle) needed to be bounced. (That's "reboot" to you and me.) After about a year of fiddling with optimizing and enhancing performance they slowly migrated the customers back to the AS/400. This company was burning about $1.5 million per month in venture capital money they ran out and the VCs took over. Now, all of the RPG staff is gone and a couple of developers are left. Yes, it was a mismanaged and bungled software implementation. However, it was (previously) a very successful software company that tried to do this. They just couldn't do it in Java very well. I wasn't a part of the Java team so I don't know all of the details. I'm just glad I'm away from there. chuck Opinions expressed are not necessarily those of my employer or previous employers. "Joe Pluta" wrote in message news:3dd57557.7@WebX.WawyahGHajS... | Chuck wrote: | | "First of all, let me say that I don't think Java is the answer. I saw Java drag my former employer into almost non-existence. They had 40 Java developers that could barely keep up with my 5 RPG programmers. In fact the Java programmers failed miserably. So, I would dismiss Java based upon my experience." | | Unfortunately, your experience was a bad one and the project was probably not managed correctly. A joint Java/RPG development project takes a slightly different mindset, because the two languages should be used for entirely different things. Java should be used solely for middleware - preparing data for the user, and retrieving user data and sending it to a the business application. The business logic should be written in RPG. In that environment, it doesn't take 40 Java developers to support 5 RPG programmers. In my experience, which differs from yours, one good JSP/servlet programmer should be able to support several RPG programmers - but this is because the Java programmer is not programming any business logic! | | "ASNA has tools that let the VBscript programmer that knows nothing about the AS/400 to access the AS/400 database. That's a good thing because I have 5 HTML/VBscript programmers that know nothing about the AS/400. They get the benefits of blinding speed also." | | I guess my host-centric nature shows here, but this doesn't seem like an advantage to me. To have non-AS/400 programmers directly accessing the database, even in read-only mode, is a recipe for disaster. If they don't fully understand the relationships between the files, then they have potential for doing some really bad things. But that's my old saw - at all costs, avoid putting business logic on the client. By far the majority of catastrophic system failures I've seen in distributed development environments spring from one common problem: two clients with different business logic. | | And finally: | | "1) The AS/400 is totally isolated form the Internet. The VBscript programs run on a Windows server under IIS." | | For those who wish to run in an IIS environment, that's definitely a plus. For people who have some concerns about the security and stability of IIS, I think this is a pretty strong minus. Since the Gartner Group report, I believe that IIS has lost much of its luster for mission critical systems. So, it's pretty much a matter of what you're comfortable with. | | Joe Pluta | www.plutabrothers.com

[Guest.Visitor]

Of course, I've got to say a word or two here.

Dave, You have an interesting past experience. I can believe that it is easier to implement certain business applications and/or functionality on the AS/400. This may indeed be consistent with your prior experiences and I respect that. My experience has taught me that trying to re-write legacy AS/400 applications that have been maintained for several years takes time. This is because these types of applications are more than likely dependant on legacy techniques that are not easily translated into modern programming practices. Also systems of this nature (from my experiance) are poorly documented. I can imagine this being the case in many businesses. While I've never touched Oracle before I can also imagine this being the case for other platforms as well. What I'm saying is that I don't truely believe the programming language to be the ultimate factor that leads to these scenarios. Rather I believe a system that has been poorly maintained over several years (without regard for source control and maintainability) can and will be difficult to rewrite.