Re: Doubt on prerun time array And a doubt about batch job

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