From: Paul Webb To: All

We are in the process of converting from our S/36 to an AS/400 and it is taking me longer than I expected (and told my boss). The situation is that we having been using ASNA's 400/RPG for several years. Most of our files are externally described, our key applications make extensive use of CALLs and we are well on our way to the Third Normal Form. The problem is that all of this was implemented on the S/36, which isn't as pure as the AS/400.

Our batch processes use an eclectic mix of externally and internally described files, lots of #GSORT, BLDINDEX, and System/3 conventions (96-byte records with only 15 bytes of data), etc. We (two programmers and I) spent about two weeks cleaning up all of our AS/400 programs (about 60 percent or 300 programs) and learning the basics about the AS/400 (re-reading many articles).

I had then planned on a week for OCL and menu work and a week of intensive testing before cutover (Feb. 1). The learning curve hit us, so I postponed the switch to the President's Day weekend. This past week, however, we have gotten seriously involved in the OCL work and have found that major changes are needed; next week seems unrealistic at this point. The last thing I want is for the Tuesday morning to be inundated with calls about DDEs, lost printouts, etc.

My question is, after a long-winded explanation, how long has it taken other companies to do a conversion from a S/36 to native AS/400? My feelings are that what we are doing (and have been doing for the last two years) will position us for the future and have long-term payoffs, but that is difficult to explain to a nontechnical person. When we are finished, we will be operating mostly in the native mode, freeing our time for new development work. Any suggestions for justification of deferring the cutover to make sure that we do it right would be greatly appreciated. The only real financial cost of waiting is the falling resale value of the S/36, as well as deferred new development work.

From: Pete Hall To: Paul Webb

I can tell you for sure that, unless your applications approach the trivial, it is unreasonable to expect to completely convert and test a S/36 to AS/400 conversion in a month, particularly when you have limited (none?) hands-on experience with the target platform. I have been in the business of doing this type of conversion for the past three years. My company has spent at least five programmer years in developing code to make the conversion process more efficient, and for the most part, we are well past the learning curve. We would be unable to do your job in a month.

You are in a much better position to exploit the advantages of externally described files than a lot of other companies. Once you have completed the conversion process, your application will probably be a lot closer to one that was written on and for the AS/400 than it would be if you had not been using ASNA in conjunction with rigid standards over the past several years. This does not, however, mean that the task of actually converting your code is going to be significantly easier. OCL to CL conversion is (if done manually) a complete rewrite. It requires programmers who are intimately familiar with the software, OCL and CL. From your message, I get the impression that you probably qualify in two out of the three. By the time you get done, it will be three for three, but it's a significant distance from here to there.

A job, particularly if you have not done one like it before, always seems radically simpler than it really is. This is because without having done it, you have no way of knowing what is involved at the detail level. Having re- invented the wheel several times myself, I can appreciate what you are going through.

From: Bret Myrick, Sr. To: Paul Webb

Without knowing how proficient you are as a coder or the type of system that has been developed, it is difficult to state how long it may take to convert. The upside is that once you have converted (assuming that you clean code up as necessary), you will be on your way to more productivity than thought of before.

As for the 400/RPG, I have always been impressed with ASNA's packages over the years (seven, to be exact) and can guarantee you that if you are using their precompiler, you have knocked out about 35-55 percent of the hard work.

Bravo for normalizing. I have been preaching this for 10 years now since college and even in high school. This is one of the most fundamental projects to save time and disk.

Try not to take things too fast. As far as the resale value of the S/36, don't worry. This is the most popular minicomputer ever and will retain the resale value much longer than any other machine. If you can get some out of it now, then you will get some later; if it is too much loss, then donate the thing and write it all off for face value.