|
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
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.