RPG Field names as variables

[Simon Thompson]

Regards to all,

I would like to be able to reference a field as a variable. Is there any
flavour of RPG that will cope ?

All appropriate manuals have been read and 'RPGIV Jump Start'.

Thanks

[Bradley V. Stone]

Short answer is no.

Long answer is it is possible to emulate this using SQL. But, it's
almost not worth the time.

What I ended up doing was creating subprocedure wrappers for this. So
I'd say #GetCSTMST(key1:key2:..keyn:'fieldname')

Then this would return the field name specified in the parameter from
the CSTMST file. In the subprocedure it was simply a big select
statement.

I needed this for web applications. And it worked very well and was
very fast. I would check to see if the the last record retrieved
equaled the one I was getting and if so didn't chain again unless I
had another variable set to "force" another chain.

There are drawbacks to this as well. Reading through "detail" type
files wasn't always the best. But, it's still working flawlessly
today. :) And the good thing was I could make up field names for
data that wasnt there and format the data how I wanted it (like dates
for example). So, if I wanted total tax, I would retrieve a variable
named $TOTTAX that would att all the tax fields together and return
the single value. Made things a little faster as well.

Brad

[Simon Thompson]

Thanks for the reply - I shall have to get the books out again !

It is a real pity, the end result is going to be some reports in Business
Objects.
The payroll department is sending a file with a code(s) e.g. CODEX =
ValueOfTax.
The DB2 file field could have been called CODEX and with the QUSLFLD api I
could have listed the fields and where the field name was equal to the code
blah blah added data to the field (with the name as a variable).

As there are 100 + codes I feel a lot of repetitive coding being done.

Thanks again.

"Bradley V. Stone" <bvs...@onebox.com> wrote in message
news:3d652f5e....@news.gotocrystal.net...

[Jim Barnes]

If I understand the problem:

If you can calculate the offset to the CODEX field in the DB2 and the fields
(like ValueOfTx) always have the same attributes; you should be able to
establish a standalone variable (with based keyword) and set the pointer to
the field =(equal to) first position in the record format + the offset to
the first byte in that field, then use the based variable name consistently
throughout the calculation. For example,

d tax_fld s 5p 3 based(ptr_to_ValueOfTax)

Do your call to QUSFLDL API to get the offset of the field in the record.
Calculate the pointer value:

c { do lookup in list_api results & get offset in bytes}
c eval ptr_to_ValueOfTax = %addr(data_buffer(1)) +
integer_offset_to_field

Now you can use tax_fld consistently in your subsequent calculations to
represent any tax field in the file. Note: The integer_offset_to_field must
be the offset in bytes.

That is, if I understood the problem. If not, ignore this.
"Simon Thompson" <rat...@enterprise.net> wrote in message
news:1ya99.4898$z16....@news.webusenet.com...

[Simon Thompson]

That sounds just the ticket - but guess who works for an IT deparment where
the programmers have os/400 v3r2 and the users v4r2 ?

I shall give it a go on a production box and see if I can get it to work and
then beg for more money for an upgrade !

Thanks for you help.

"Jim Barnes" <barn...@swbell.net> wrote in message
news:Q%a99.1017$Q_5.20...@newssvr12.news.prodigy.com...

[Barbara Morris]

Simon Thompson wrote:
>
> That sounds just the ticket - but guess who works for an IT deparment where
> the programmers have os/400 v3r2 and the users v4r2 ?
>
> I shall give it a go on a production box and see if I can get it to work and
> then beg for more money for an upgrade !
>

Simon, if it's the pointer arithmetic that's bothering you, there's a
kludge you can use in V3R2 to get around it. (But keep it a secret if
you think this might be the tipping point for getting your new hardware.
:)

You can write an addPtr procedure for your general-use service-program.
Call it like this:
eval p = addPtr (p : offset)

c eval ptr_to_ValueOfTax = addPtr(%addr(data_buffer(1)) :
integer_offset_to_field)

The code is something like this. (From the way it's not in the right
columns, you can tell it's not tested, but this should give you the
general principle)

P addPtr b
D addPtr pi *
D ptr * value
D increment 10i 0 value

D array s 1a based(p) dim(32767)
D inc s 10i 0

c eval p = ptr
c dow increment > 0
c | eval inc = increment
c | if inc > %elem(array)
c | | eval inc = %elem(array)
c | endif
c | eval increment = increment - inc
c | eval p = %addr(array(inc + 1))
c enddo

c return p
P e

When you get to a release that supports pointer arithmetic, change the
procedure to
just return ptr + increment, and stop calling the procedure in any new
code.

[Simon Thompson]

Most (if not all) that went over my head - never having used pointers
before. I shall certainly try it out - this problem/puzzle has occured
before (funnily enough again on a payroll system) - Next time I shall be
ready !

Thanks a lot !

"Barbara Morris" <bmo...@ca.ibm.com> wrote in message
news:3D66989D...@ca.ibm.com...

[Jim Barnes]

Simon,

Barbara's is simply stating that since you are restricted to V3R2 solutions
and pointer arithmetic (if I am not mistaking) was not available to RPGIV
until V4R2. So, by advancing the array index to the proper location [in the
data_buffer] of the first byte of the CODEX field you have selected from
your QUSFLDL inquiry; then taking the %addr(address of) that element
location and returning it as the basing pointer for the rate field - you
can accomplish the same objective as taking the pointer to the beginning of
the record and adding the offset to the CODEX field. It effectively
accomplishes the same objective and is a technique available at V3R2.

Good luck!

"Simon Thompson" <rat...@enterprise.net> wrote in message

news:BnQ99.6743$z16...@news.webusenet.com...