AS400 DDS Specifications and Arrays

35 pts.
Tags:
AS/400 upgrades
DDS
DDS RPG ARRAY
S/36
S36E
We are working toward converting our system from a S/36 to an AS400 S36/E. On the way we are attempting to create DDS specifications for our files and externally define the files to the RPG code. We are prototyping a program to read the RPG II programs and build the DDS specifications from the source specifications contained in the RPG programs. Since we are basically new to the AS400 (we know a ton about the S/36, not very useful in the new world) we cannot find anything about how to define or use an array in DDS. Oh and we are moving to an old V4M4 machine because we need the M36 world as a working step to a more current AS400. How are arrays processed in DDS and then made useful in a RPG program? The only thing we can figure is a field that is MOVE'd into the array each time the record is processed. Seems stuipd.

Answer Wiki

Thanks. We'll let you know when a new response is added.

You are basically correct. The DDS doesn’t have arrays so you might format sales as
A Sales01 9S 2
A Sales02 9S 2

A Sales12 9S 2

In RPG IV you can overlay the data with an array for the program
These you can put into a copy book and copy into every program

D MySalesds E DS EXTNAME(mySales)
D SalesAR like(Sales01) Dim(12)
D overlay(MySalesds : 54)
D inz(*zero)
where 54 is the first byte the data in the physical

Since SalesAR overlays the 12 sales fields in the file
The field values always equals the array values ..
Sales01 will always be equal to SalesAR(1) etc.

I’m not sure if all of this will work in V4R4.

Phil

Discuss This Question: 10  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • Kirk48906
    We use a pre compiler here that we wrote to insert I & O specifications as the program needs (very simular to DDS), it also inserts the E spec as required for an array. Which got me thinking about doing things the manual way. If we use DDS with externally defined field and define the field in DDS as a single long alpha field with a name, can we also code an E spec with the same field name and have it work correctly? This is the way you define an array inside of the program anyway. Would it also work when the field is described externally? We would have to manuualy enter a E spec everytime, but at least we would have the array. I cannot believe that IBM would not include arrays as a part of DDS. I thought I was totally missing an entire chapter of the DDS manual or something. That's got to be the most bone headed mistake since Ford forgot to put reverse in his first automobile.
    35 pointsBadges:
    report
  • philpl1jb
    No absolutely not, don't do that. You are a great S/36 programmer but now you must feel the force ... On the i-thingy it's not the programs that are on center stage, it's the data. On the S/36 the data is a bunch of punch card type things that are only good for programs. On the i-thingy the programs are only a tool for manupulating the data. And worse yet the programs are only one of many tools you'll have for working with the data. So the most important job you have is to get the data right. Those should be fields with names like Sales01, Sales02 etc or field01 .. field12. Structure them properly and release the force of the i-thingy. Arrays -- those are procedural programmers terms -- and that's where it gets applied. If you are using RPGLE then you want D specs not E and I specs and You can use the overlay to relate the array to the data. The D specs could be in copy books. If you're making the move to RPGIII then you can do the same thing with E and I specs. No moves are necessary. Sorry if I was a bit blunt but it's critical to change your hat and become a database administrator first and a programmer second. Finally, thanks, I now know why my father always parked his Ford facing up a hill. Phil
    49,850 pointsBadges:
    report
  • Gilly400
    Hi, Back in the days of S/36 arrays were often used to handle scrolling screens - these have now been replaced by subfiles which (reasonably effectively) eliminate the need for arrays on screens. What I would suggest, is to leave your screens internally defined for the time being and concentrate on your data files. You can compile your SFGR screen sources directly to *DSPF's (you can also create DDS source from the SFGR compiles). Once you have your data files (physical and logical) externally described, then you can start gradually converting your display files and the programs that use them to "real" native objects. You can, of course, try converting everything at one time, but in my experience it takes a very long time before you start seeing the first results and the management guys tend to get impatient. The last site I worked at with the S/36 environment is still running certain apps non-native - purely because of the amount of work involved in trying to get them native. This will also depend on how your S/36 programs have been developed and how much S/36-only code is used in them. If you only want to get your software running in the S/36 environment you won't need to change much at all (if you have all the sources). If you don't have the sources then you will need to use the M36 environment as this allows S/36 object execution. I've been in a situation where we didn't have source for the accounting package (and the company no longer existed), so we ran the accounting package in the M36 environment and the rest of the applications in the S/36 environment and used virtual communications between the 2 environments (a sort of DDM link). So there are plenty of options open to you, depending on what you want to achieve. Regards, Martin Gilbert.
    23,730 pointsBadges:
    report
  • Gilly400
    Hi, By the way, I agree with Phil about eventually using all the potential of your system, I just know from experience that it can take a long time to get there. Regards, Martin Gilbert.
    23,730 pointsBadges:
    report
  • Krttrs
    I agree with the other posts. But I would like to say "get away from the M36 environment" if you can. My experience is that you will eventually convert to an iSeries S/36 emulation environment from the S/36 "Machine" running under OS400 ( I5/OS ). S36 emulation on the iSeries is much better than running a S/36 SSP on a virtual M36. ( you are talking about that old 9402-236 with virtual S/36 machine, aren't you? ). Skip RPG-III and go to RPG-ILE Convert program described files to external. In the shops I worked at, I had created Input/Output specifications always using the /COPY method. So, we did the same as you propose to convert to I/O copy book specs, convert code and run programs. We eventually converted I/O specs to DDS. Now, we are converting DDS to SQL tables and for anything "NEW". The really NASTY thing about S/36 RPGII is that the program defined files were never consistently assigned the same way in all programs. Also, you might want to consider defining your database in SQL instead of DDS as that is the way IBM is headed.
    65 pointsBadges:
    report
  • Kirk48906
    Our goal is to go native, but move off in steps. The first logical step we thought was to move from the M36 to 36E on the 400. The old system is a 9404-436, great box for it's time, but its time has passed. We have all the source code for all the screens and programs since everything was developed in house over the last 25 years. By using the pre-compiler we standardized all of the field names and record format names accross the entire package. What we were hoping to accomplish is migrating the data to DDS and maintaining the externally described files we already have this way. Currently only a few programs have internally described files. There seems to be a few kickers in our testing of this. First we've used some addtional S/36 assmbelers mods that insert special op codes (IE CLOSE and OPEN for printer files is a often used one) that are not part of the standard RPG II S36E compiler. These op codes are legal in RPG III, or IV, but not in II. We've found that changing the compiler to compile in say III makes other sloppy coding we've done (apparently defining a variable to the same specifications more than 1 time is a no-no) bauk in the newer RPG standards. So we've got clean up issues there in programs. We were hoping that we'd be able to take our existing externally described files, and convert them to DDS and make some very minor modifications to the existing RPG II code, compile them at say RPG III or IV to get the new op codes and be running very quickly. But the array thing slapped us back really fast. We've also had discussions about multiple record formats in that we'll have to create solutions to remove all of multiple record formats from a file and push the records into several files at this time too. I'll have to lookup the references to your suggestions. As we've learned these issues, we've altered all new coding being done to reflect the movement standards, no multiple record formats if possible, etc. We picked up a 720 loaded up really well to operate the M36 and move away from the 436 for $300, so we've got the speed issue resolved for now. We've operated in the M36 environment for 15 years want to get serious about moving away from the M36 entirely. We realize this will be a huge undertaking, but are probing solutions to minimize the time impact for the conversion because of the pre-compiler.
    35 pointsBadges:
    report
  • Krttrs
    Sounds like you are on the right path. Simple solution to multi-format files is to create individual file DDS or SQL table for each record type, then create a Logical file ( or SQL view ) to use in the S/36 programs. Only gotcha is you have to create a "RECORD FORMAT SELECTOR PROGRAM" for updating the LF file ( if you update the files ). When CRTLF you must use the FMTSLR keyword. Here's a sample CL select program we use for the FMTSLR: SELCL: PGM parm(&DATA &FORMAT) DCL VAR(&DATA) TYPE(*CHAR) LEN(12) DCL VAR(&FORMAT) TYPE(*CHAR) LEN(10) DCL VAR(&RECID) TYPE(*CHAR) LEN(1) CHGVAR VAR(&RecId) VALUE(%SST(&DATA 11 1)) /* This is location of record code in file */ if cond(&RecId *eq 'D') then(DO) ChgVar var(&Format) value('AUXAF01') /* Tells which record format to update */ /* Aditional Accounts Record */ EndDo else if cond(&recId *eq 'C') then(DO) ChgVar var(&Format) value('AUXCI01') /* Compliant Inserts Record */ EndDo else if cond(&recId *eq 'E') then(DO) ChgVar var(&Format) value('AUXEI01') /* Employment Record */ EndDo ....... ....... EndPGM Read up on RPG-ILE and figure out how to redefine ARRAYS in the D-specs and you're ready to go Check out this doc: http://www.redbooks.ibm.com/redbooks/SG245402.html It has some useful coding examples for redefining arrays in the d-specs. Plus other neat stuff Also, check out Bob Cozzi's Tuesday's Tips http://systeminetwork.com/tuesdaytips/ He's has good information for all RPG-ILE programmers
    65 pointsBadges:
    report
  • graybeard52
    A couple of gotchas to watch out for : File names cannot be the same as any field names or any record format names. There are rename options to workaround, but these can get you if you are not ready. Having worked many years in S36, I will suggest going to RPG-IV as soon as possible. If you run in the default activation group, you can mix the RPG-IV programs right into the flow. Its not a long term goal, but it beats moving to RPG-III first. Even without the ILE features, you get a LOT of benefit - long field names, format prefix options, date handling, etc. FWIW - I agree with you on the array in DDS. Should have been in there. But I got used to the workaround. over the last decade and a half.
    3,115 pointsBadges:
    report
  • Kirk48906
    Everyone's been great, thanks for your continued help. So much to learn, so little time. I have a question about DDS and long field names. When we wrote the pre-compiler and our version of externally described records and field names we didn't like 6 character field names so we made them 10 characters (10 happens to be the Field 1 and 2 lengths right? So we went with it). When the pre-compiler does its stuff it converts the 10 character name into a random 6 character name for the compile. Everything I've read says that we need to have them back to 6 for the RPG compiler, but that DDS can accept longer field names. One of our goals is to leave the pre-compiler out of the loop. Are you suggesting that we could continue to use our 10 character names in RPG IV? That would save us hours of work. But how easy is it to take a II program and compile it as a IV? Since I've only heard of IV and not read anything on it yet I have no idea what it is like. I did crack open a book we have on ILE and at first glance it doesn't look at all like II or III. Are there options on the AS400 comiler to tell it what standard/version of RPG to compile too? I know there is S/36 RPG II and whatever AS400 version option is, but other than that I'm uninformed.
    35 pointsBadges:
    report
  • Cwc
    The system uses different compile commands for the specific version of the RPG source: CRTS36RPG, which is the RPG II compiler CRTRPGPGM, which is the RPG III / RPG/400 compiler CRTBNDRPG, which is the RPG IV compiler (there are other specific ones for use with true ILE, but this is the main one). I'm not aware of an RPG II to III conversion utility, but if you could get your programs to RPG III as just an intermediate step, then you could use the CVTRPGSRC command to get them to IV. But just to see what would happen, I have the source for an ancient System 36 RPG II interactive program lying around (with COMPARES, resulting indicators and GOTOs) and used the CVTRPGSRC command against it. I had to change its subtype to RPG instead of RPG36, but it actually converted the source! It's a fairly simple program though, without much S/36 specific methods, so more complex programs would take more work. Still, perhaps you could experiment with it to see if it helps for some of the simpler ones.
    4,290 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following