|
Richard, It does make this a whole lot clearer. I can say it addressed more or less all my doubts. Thank you very much. Sunil ----- Original Message ----- From: "Richard B Baird" <rbaird@esourceconsulting.com> To: <rpg400-l@midrange.com> Sent: Thursday, June 27, 2002 6:32 PM Subject: Re: Doubt on prerun time array And a doubt about batch job > > Sunil, > > I'll try to answer some of your questions: > > there are very few 'restrictions' for packed fields. If you can tell the > program that a field is packed, either by definition in the program, or > from the external description of a file, you can use it as packed. The > only gotcha I can think about off hand is using packed fields as > parameters, when character or zoned is expected (and visa versa). The > reason why your first example didn't work is that you never told the > program it was packed (extfmt(p) , so it assumed it was char. > > Yes, the perrcd keyword would come into play when using compile time > arrays, but could also come into play using pre-run arrays. The only > differences between the two types of arrays is when the data is loaded and > where it gets the data. > > consider the following examples: > > example 1 - pre-run time array. > > physical file TBLDATA has three records, 15 bytes long, 3 fields, 5 bytes > each. > > Data looks as follows: - note, there are 3 array elements per record > (PERRCD) > > 000010000200003 > 000040000500006 > 000070000800009 > > defined this way in RPGLE... > > FTBLDATA IT F 10 DISK > DARY S 5A DIM(12) PERRCD(3) > D FROMFILE(TBLDATA) > > example 2. compile time array > > DARY S 5A DIM(12) PERRCD(2) > D CTDATA > > <snip> > > **CTDATA(ARY) > 0000100002 > 0000300004 > 0000500006 > 0000700008 > 00009 > > > note, there are 2 array elements per record (PERRCD). > > both of these examples will produce an array in your pgm, twelve elements > long, that looks like this. > > 00001 > 00002 > 00003 > 00004 > 00005 > 00006 > 00007 > 00008 > 00009 > > > > > (with the last three elements blank) > > does this clear things up for you? > > As far I know, these types of tables are not used extensively anymore for > new programming, unless you have a huge batch job, where you need to > retrieve data from a reletively small file (1000 records or less?) many > many times in one job. > > as far as the term 'table' is concerned, when discussing arrays and tables, > don't get them confused with the SQL table term. While in both cases the > terms vaguely refer to 'a set of rows/columns where data is stored and > accessed' they are not really the same physical objects on an as/400. > > When speaking of 'arrays' in RPG - they are typically many 'rows' with one > 'column' of data to be used for lookup or iteration purposes, to retrieve > the data based on a row index number, or to retrieve the row or index > number, based on the data in a lookup. > > when speaking of 'tables' in RPG (any array who's name starts with TAB...) > - typically they are many rows with 2 (or more) columns of data. the first > column is used for lookup purposes, the second is the data to be retrieved > via the lookup, as in this example: > > D TAB1 S 2 DIM(4) CTDATA PERRCD(1) > D TAB2 S 25 DIM(4) ALT(TAB1) > > * CODE = 'CC' > C CODE LOOKUP TAB1 TAB2 > 26 > C EVAL DESC = TAB2 > * DESC = 'Description for Code CC' > > **CTDATA > AADescription for Code AA > BBDescription for Code BB > CCDescription for Code CC > DDDescription for Code DD > > The above would equate directly to having the 'table' data in a file, and > chaining to it. If you had the above scenario, and the data was in a > file, instead of **CTDATA at the end of your program, you could chain > instead. > > But, if your program was reading another file with millions of records, and > chaining to this file each time, it would be much quicker to load the table > pre-run time and doing a lookup on it. > > does this make it any clearer to you? > > hope this helps. > > Rick > > _______________________________________________ > This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list > To post a message email: RPG400-L@midrange.com > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l > or email: RPG400-L-request@midrange.com > Before posting, please take a moment to review the archives > at http://archive.midrange.com/rpg400-l. >
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.