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.
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online