× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.