Tweet
1 - I must somehow convert my screen files produced using SDA to a native 400 format. Will I have to recreate these screens manually? When you compile S/36 screen formats under OS/400, you can have the compiler save the screen formats it generates. 2 - I must convert RPG II to RPG III before I can use the IBM utility CVTRPGSRC. What differences must I be aware of in order to do this? Column layouts? New types? You can probably count on making the most changes to the F specs. Instead of C (chained), use F (full-procedural). Also, you don't need "L" for a limits file, just leave that column blank. Blank out block lengths. If you use EXTK as the beginning position of a key, replace it with the position of the first key field. Most everything else works fine. You'll find a few opcodes in calculation specs that won't work. MOVEA can't be used with a numeric field in RPG III. If I remember correctly, there's no KEY opcode. I and O specs for display files will probably still be OK, but don't take that for granted. The safest thing is to convert display files to externally defined files. 3 - OCL code must be converted to CL. Is there a utility to do this or is it a manual operation? There are several packages on the market that convert everything--RPG, OCL, & build external definitions for your files. What other things should I be aware of? It may be better to rewrite the interactive aps. Batch stuff & reports will be easy to convert manually, as long as you don't change any of the database file layouts. You can leave I & O specs for database files in the programs until you get around to changing them. All of this is based on my experience with RPG II to RPG III. I've never tried going from RPG II to RPG IV. Are there any good books, IBM manuals, or other reference materials I could acquire to educate me in this process? Not that I know of, but you shouldn't need them. After you've done a few programs, you'll get the hang of it. I would consider licensing a package to do the conversion to RPG III.
-
-
S/36 RPG to Native AS/400 RPG IV ILE
On Tuesday, December 09, 1997, 07:42 AM, scott andersen wrote: When you compile S/36 screen formats under OS/400, you can have the compiler save the screen formats it generates. Does this mean that I should be able to reuse the source from my screen formats and recompile under native 400 without manually recreating? color="purple"> If you have the compiler save the generated DDS, you have something to start from. You'll probably want to go in & clean it up manually, but at least you don't have to start from scratch. Can you tell me the names of some of these conversion packages? I could look them up on the internet if I had some kind of lead. I tried a web search on RPG II conversion and found serval sites but nothing that matched what I was really looking for, a package to do the conversion for me. Especially one that isn't real expensive. Something that would work for a one man shop that might even be contented converting one program at a time. color="purple">Look in the ads in MC & News. You may find more ads if you look in back issues a few years old. I didn't see anything in the December 97 MC, but here are a couple from old issues: Applied Logic Corp, 503-362-9131, fax 503-585-5581 K.S.P.S., 604-276-8201, fax 604-276-8259 I don't know if these packages are still marketed or not, but with the year 2000 coming, I'd be surprised if they're not. Good luck! -
S/36 RPG to Native AS/400 RPG IV ILE
On Monday, December 08, 1997, 02:44 PM, scott andersen wrote: What other things should I be aware of? Are there any good books, IBM manuals, or other reference materials I could acquire to educate me in this process? ************************************************** ******************* I recommend the following two books - "A Complete Guide to Creating and Maintaining Physical and Logical File DDS" by Charlie Massoglia and "Programming in RPG IV", revised edition by Judy Yaeger. I suggest creating external file definitions for your most heavily used files sooner rather than later. You can then use these external file definitions in new RPG programs, query and DFU. As long as you make them describe your existing files without changing the formats, your new programs can use externally described files and your old programs can continue to use the same file as "program described". This means that you can convert slowly to the new, improved ways without being forced to convert too much at one time. If you have files in need of a Year 2000 fix, then you must look at things differently. You may need to switch to date type field definitions. In this case your old and new file formats would be different. Just an old mainframer caught in the Web!Comment
-
S/36 RPG to Native AS/400 RPG IV ILE
You're welcome, Scott. There are other packages out there, so keep looking in the back issues. I saw your comment about decimal data errors. It is quite likely you'll have them. If an RPG program adds a record to the file & doesn't put packed or zoned decimal zeros into a numeric field, you'll have decimal data errors. You may have to change some RPG II programs to write zeros into the numeric fields when they add records to a file. I've had to do some of that. For example, let's say you have a file maintenance program with output specs like this (not to scale):OMASTER E ADDREC O FIELD1 4 O FIELD2 28 O FIELD3 78
The safe way to fix this is to insert zeros for all numeric fields before the first right-handed O spec. If a field is zoned, you can use literal zeros. If it is packed, use a packed field with zeros in it.CLR MOVE *ZERO ZERO7 70 OMASTER E ADDREC O 45 '000000' O ZERO7 68P O 78 '00000' O FIELD1 4 O FIELD2 28 O FIELD3 78
Most files only have a few programs, or even just one, that write new records to them, so this is not a hard thing to do. It just takes a little time. But you need to do this to your RPG II programs that write to a file before you convert that file to native with DDS. HTH. On Tuesday, December 09, 1997, 02:51 PM, scott andersen wrote: Thanks, Ted Holt, that looks like good information and I will contact those vendors. ScottComment
-
S/36 RPG to Native AS/400 RPG IV ILE
On Tuesday, December 09, 1997, 02:51 PM, scott andersen wrote: Thanks, Ted Holt, that looks like good information and I will contact those vendors. Scott
before you copy to DB/2 look back in one fo these fora and get a copy of fix_data;; It's a two liner and I have used it dozens of times.... I'll try to reproduce it here; my HTML is not the greatest... Ffile-nm IP C EXFMTfile-format change file-nm to your file name and file-format to the format and recompile ......
Bob Hamilton TEXAS BUSINESS SYSTEMS 736 Pinehurst Richardson, Texas 75080Comment
-
S/36 RPG to Native AS/400 RPG IV ILE
One point not mentioned in this thread: The source for S/36 screen files is in the source file QS36SRC. These are the $SFGR specifications. During the compile process, the AS/400 will automagically generate DDS specifications. These can be found in the source file: QS36DDSSRC. You may work with the DDS specs, completely abandoning $SFGR. David AbramowitzComment
-
S/36 RPG to Native AS/400 RPG IV ILE
Scott: I came across 3 more S/36 to native packages. I had these in my Day-timer for September 8, 1994, so they may not be good any more. Integrated Software Specialists 708-240-5070, fax: -5073 Advanced Network Solutions 800-451-2260 or 414-544-5504 fax: 414-544-5933 Excel Programming Innovations 800-EPI-0400 or 310-432-6239 fax: 310-434-8251Comment
-
S/36 RPG to Native AS/400 RPG IV ILE
Excel Programming Innovations Target/400 was reviewed in the MC November 1996 issue and is still obtainable (I just bought the product as a result of my own on-site review - including two other products). Best regards, CarstenComment
-
S/36 RPG to Native AS/400 RPG IV ILE
On Thursday, December 11, 1997, 12:43 PM, scott andersen wrote: Hey Thanks everybody for all the help in finding potential conversion programs. Carsten wrote: ---- Excel Programming Innovations Target/400 was reviewed in the MC November 1996 issue and is still obtainable (I just bought the product as a result of my own on-site review - including two other products). ---- I was wondering would you mind sharing the names of the two you of which you picked Excel over? I haven't determined which ones I'm going to try yet except for one offered by ASNA who gives a free three day trial. I've obtained some literatature on both the one from Excel and Applied. Scott Andersen S/36 dinosaur coming into the 90's I've got an ILE Converter shareware program available. Pretty simmilar to Connection 2000s. Mines free though (with a suggested registration fee). You run the CVTRPGSRC and then use my CVTILEFMT and it does all types of formatting for ya. Makes free format ifs, dos, whens... makes D spec variables from C-spec defined variables. Try it out.. it called CVTILEFMT and is at: href="http://prairie.lakes.com/~bvstone/as400sw.html"> href="http://prairie.lakes.com/~bvstone/as400sw.html">http://prairie.lakes.com/ ~bvstone/as400sw.html HREF="http://prairie.lakes.com/~bvstone/">src="http://prairie.lakes.com/~bvstone/gifs/as400sig.gif" BORDER=0 HEIGHT=131 WIDTH=85>
Comment
-
S/36 RPG to Native AS/400 RPG IV ILE
Hi Scott, ASNA's ProStart and Go Native were the other two candidates: I got an excellent service and follow-up on my requests and questions, and found both products to be of good quality. I chose Target/400 because of it's ability to deal with a mixed environment (S/36E- and native objects), doing mass-conversions as well as single applications and taking CL-overrides into account. It also has some post-conversion utilities allowing you to externalize data-files and print-files (I- & O-specs) which I find very valuable; running in the native environment is only part of the potential benefits; referencing externally described files is what you actually need to enable a smooth Y2K-conversion. I'd like to emphasize that under other circumstances (f.x. size of application and budget) one of the two other candidates might have been a relevant choice. Feel free to contact me if you need more information. Best regards, CarstenComment
Comment