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