Re: Pointer question

[Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>]

You have to remember, and keep firmly in mind, that variable names are 
not used by the computer.  The CPU doesn't want/need your variable 
names.  Variable names don't exist at run time.  Variables onyl exist to 
make things easier for us human beings.

So passing a parameter that contains the word 'DATE1' or 'DATE2' 
accomplishes nothing.  You have a parameter that contains the name of a 
variable -- and it does you no good, because your program has no notion 
of what 'DATE1' and 'DATE2' are at runtime.

Is it possible to do what you require?   Sure.... assuming these are 
externally defined fields in a record buffer.  You could use an API to 
list the fields in the buffer, and get an offset of where those fields 
are relative to the start of the buffer.   As long as the RPG variables 
are also at the same offset from the start of the buffer (i.e. you're 
using a LIKEREC data structure, or similar, when reading the file) you 
could calculate the position of DATE3 (for example) by getting it's 
offset within the record, and adding that offset to the start of the 
data structure.

For example, the QUSLFLD API could be used to dump the external 
definition.  By reading the user space that's the output of that API, 
you could determine that DATE3 happens to start in position 45 of the 
record...  You could then take a basing pointer, and point it to 44 
bytes after the start of your LIKEREC data structure, and it would point 
to the start of the DATE3 field.  Assuming your based variable is the 
same data type and length as the DATE3 field, the based variable would 
contain the appropriate value.

So, basically what I'm saying is that if you truly want to eliminate 
your SELECT group, which would require about 14 lines of code, you could 
do so in about 150-200 lines of significantly more complex code.

But keep in mind that this'll only work if you force the RPG variables 
to match the file buffer (i.e. use LIKEREC or EXTNAME with 
*INPUT/*OUTPUT specified), and only will work with fields in a file. 
What you're really doing is looking up how stuff is organized in the 
file, and then making the assumption that your RPG variables are laid 
out the same way.  And that's not always true, unless you force it to be 
true.  But, this workaround is necessasry because the RPG variables 
themselves do not exist at run-time, so having the name of those 
variables doesn't really do you any good.


sjl wrote:
> I'll preface this by saying I'm not a pointer expert...
>
> One of my co-workers is writing a program in which he needs to access 
> several different fields within a record in a file depending on a soft-coded 
> criteria that is fed into the program, and he was hoping that he could 
> somehow use a pointer to accomplish this and thus have a more elegant 
> solution.
>
> The file has six different date fields:
>
> DATE1
> DATE2
> DATE3
> DATE4
> DATE5
> DATE6
>
> and depending of the value of the input field (I'll call it WHICHDATE), he 
> wants to be able to set a pointer to one of these six different date fields 
> in order to reference the value of the field, instead of using a SELECT 
> group with six different branches...
>
> So, if WHICHDATE = 'DATE1', he wants the pointer to reference the address of 
> field DATE1, if WHICHDATE = 'DATE2', he wants the pointer to reference the 
> address of field DATE2, etc.
>
> Does this even make sense?  Is this possible?
> As for me, I'd just use SELECT...
>
> Regards,
> sjl
>