I believe that this functionality could be added to RPG.  I believe that I 
would use it.

T: Your particular usage of such proposed features might not have security
implications. But others might.

And as others have also noted, if you have a pointer, there's really no way of
telling what you're pointing at. It could be some static variable. It could be a
local variable in a procedure. It could be storage dynamically allocated. IF you
could retrieve the name and attributes of some variable pointed to by some
pointer, it might not be unique. There could be other variables overlaying it.

My point is that if you want to implement some functionality dealing with
display files, perhaps you should try thinking of a solution that could be more
effectively provided by the display file support, rather than by RPG. Or
alternatively, write your own code in RPG.

Here's another consideration I'm not sure many are aware of. Because of RPG's
typing rules, any time you introduce a pointer into a program, you reduce the
effectiveness of the back-end optimizations. (Actually, to be fair, RPG does not
take advantage of the really good back-end optimizations anyways.)

"When a program starts and the system allocates memory for a variable it knows 
where in memory it put that variable.  I am thinking that the system know the 
name of that variable, the length of that variable, and the type of data.  If 
this is true then it should be VERY EASY for IBM to do this."

Not necessarily - at the machine level it's a set of pointers and memory 
blocks - IBM may or may not be keeping track of the name associated with the 
memory at that level.

I don't understand how RTNCSRLOC could be throught of as untrustworthy.  I also 
do not understand how there could be ANY security concerns here.  No users can 
update any data if they do not have authority, and having this functionality 
would not change that.

Today we have pointers and these pointers are sometimes passed into procedures 
for processing.  Seems like a perfect solution to me to have the ability to 
retrieve the attributes for the variable defined at a specific memoray location.

I now it's possible to implement the application functionality that I have 
described, but it requires a lot of extra code (mostly D-specs) to be added in 
order to use the procedures that I would want to create.  Creating D-specs like 
I posted in my previous post is what I DO NOT want to have to do as many of our 
display files have MANY fields and several record formats.

Again, I think IBM could give us this with very little effort and we are of the 
opinion that these BIFs would be a more welcomed enhancement than something 
along the lines of case conversion.

T: As I mentioned before, in some interpreted programming languages, such as
Perl specifically, the practice of getting a reference to a variable by the name
in another variable is discouraged for security reasons. I'm sure you can
imagine the security problems of taking some possibly untrustworthy string and
using is as a variable name. But then again, I'm sure you've covered the
security angles for your application.

I mentioned a possible way to implement that kind of functionality using
procedures. It requires the application programmer to do a bit of upfront work.
But ultimately, I believe, that if the application programmer implements it, it
would result in a more efficient implementation since the programmer would know
exactly which fields would be involved in such a scheme.

Sure, RPG knows the attributes of all the variables declared in a program. But
unless you intend to debug your program, that information is normally not needed
at run-time.

From what you've described, it sounds to me like you're trying to get around
limitations in display file support. Perhaps you should look to Rochester for
enhancements?

I have another utility that I use in interactive applications that relies on 
data structures to do the work. One of the two data structures contain a list 
of search values (entered on the screen) and the length of the search string:

D SearchValues    DS                                       
d                               10u 0 Inz(%Size(srchCust)) 
d  srchCust                                                
d                               10u 0 Inz(%Size(srchName)) 
d  srchName

...where 'srchCust' and 'srchName' are the actual names of the fields on the 
screen.

I could add an additional subfield for the name and use this data structure for 
all fields in all record formats:

D SearchValues    DS                                       
d                               10u 0 Inz(%Size(srchCust)) 
d                               10a   Inz('SRCHCUST')
d  srchCust                                                
d                               10u 0 Inz(%Size(srchName)) 
d                               10a   Inz('SRCHNAME')
d  srchName

But I don't like the fact that we have to maintain both DDS code and a data 
structure in RPG to add functionality that IBM could easily do for us.

It's funny you mention debug...I did something like that a few years back 
(1996) where a program started debug in order to be able to use CHGPGMVAR to 
set values.  This program used data from a file to construct a message and send 
that message to a truck driver using Qualcomm's satellite communications. The 
main problem we had is that users didn't have the authority to start debug.  I 
guess I could create a service program that adopts authority.

When a program starts and the system allocates memory for a variable it knows 
where in memory it put that variable.  I am thinking that the system know the 
name of that variable, the length of that variable, and the type of data.  If 
this is true then it should be VERY EASY for IBM to do this.

Fish, that capability can be frustrating. The RTNCSRLOC return field name was
intended to provide helptext with a key value. Certainly they never expected that
field name to then be used to retrieve or modify its data. For example, an Fn
key to prompt for a date and then put that date into the field where the cursor
was located. 

I think you'd be more likely to get a result if you asked for a specific
feature/capability than to ask for something that they clearly have no interest
in providing. 

And I have looked at trying to provide something in xTools to do this. Short of
calling the QUSLFLD API and hunting through it, there is no conventional solution.

You'd need the language to support something like:

  myVar = 'CUSNO';

  %dataVar(myVar) = 12;

At this point CUSTNO=12.

The issue with an xTools thing, is that we do not have inlining support or macro
support in RPG. To even begin to make this work, we'd probably need macro
support but even then, if the field name isn't known at compile-time you are SOL
anyway.

Really the only way to do this today is to run the programs in debug mode and
use the Debug QTExxxx APIs to modify a program variable and retrieve its
attributes. The capability is in there. After all, you can issue an EVAL
statement in Debug, right?

Like I said, I am an RPG programmer...so obviously I can't name another 
language that does that.  I would think that any language should know the 
length and type of any variable that is defined within a program, just as it 
knows the location of each variable in memory.  It would be stupid to "actively 
discourage" the use of such a feature in light of the fact that already have 
pointers in RPG.  All I am looking for is a way to make accessing data through 
their memory address safer, and a new way to resolve a pointer based on the 
name of a field from either a database file or the name of a field returned 
from RTNCSRLOC in a display file.

I had two uses for this functionality.  The main one is to replace tons of 
embedded code for field prompting with an external utility that would make it 
very easy to enable field prompting in interactive programs and even choice 
text in command prompting.

I have designed a procedure that I think will work fairly good with display 
files.  It uses APIs to retrieve the location of a field and the length of the 
field from the display file definition.  Using this information it would read 
the value from the display to know what the current value of the field is.  
However, I have not been able to come up with a way to generically replace a 
value with a new value.  There may be a way to write the value to the 5250 
screen and trick the application, but I don't know at this point.

T: Can you name ANY other compiled programming language that offers the kind of
capability you're asking for? Heck, even in the interpreted languages that offer
that capability, use of that feature is often actively discouraged.

If you think you really need that kind of capability, it shouldn't be difficult
to write some code to set things up. First, load up a couple of arrays with the
names of the variables you're interested in and their addresses. When you need
the address of a variable, just search on the name. Maybe Bob can add a couple
of procedures to xTools to implement that functionality?

Bob,

"Do the 200,000 RPG programmers (guessing at that figure) need to figure out 
how to do case-insensitive searchers or should IBM provide it? Or should they 
learn to do it incorrectly using %XLATE--after all, all code only runs in 
North America CCSUD(37), right?"

Well - some quick and dirty code that I believe accomplishes what you want - 
add a tad bit of error checking and commenting ...

H Option(*NoDeBugIO) NOMAIN                             
                                                        
D StrCompI        PR              N                     
D  Comp_Str1_                65535    CONST VARYING     
D  Comp_Str2_                65535    CONST VARYING     
                                                        
P StrCompI        B                    EXPORT           
D StrCompI        PI              N                     
D  Comp_Str1                 65535    CONST VARYING     
D  Comp_Str2                 65535    CONST VARYING     
                                                        
D Sel_Str         S           4096    VARYING           
D RetVal          S               N                     
                                                        
 /FREE                                                  
  EXEC SQL                                              
     SET OPTION NAMING = *SYS,                          
                CLOSQLCSR = *ENDMOD,                    
                COMMIT = *NONE,                         
                SRTSEQ = *lANGIDSHR,                                        
               COMPILEOPT = 'DBGVIEW(*LIST)';                              
   Sel_Str =                                                                
   'SELECT +                                                                
    CASE WHEN ''' + Comp_Str1 + ''' = ''' + Comp_Str2 + ''' then ''1'' +   
    ELSE ''0'' +                                                           
    END AS ESTFLD FROM SYSIBM/SYSDUMMY1';                                  
                                                                           
   EXEC SQL                                                                 
    DECLARE csr CURSOR for STR_TEST;                                       
                                                                           
   EXEC SQL                                                                  
    PREPARE STR_TEST FROM :SEL_STR;                                         
                                                                           
   EXEC SQL OPEN CSR;                                                        
                                                                           
   EXEC SQL FETCH NEXT                                                       
    FROM CSR into :Retval;                                                  
                                                                           
   EXEC SQL CLOSE CSR; 
                             
   RETURN RetVal;            
                             
  /END-FREE                  
 P StrCompI       E

I put this together quickly - so didn't add appropriate comments or error 
checking/sanity checking... but as I understand it it should be language 
independant... - not bad for a needed function that made 6.1 "Fail".

Hans,
We don't use OO, nor do I think I have such a desire to learn an OO language.  
Our shop is RPG, with a couple of old Cobol programs and a couple of C 
programs.  My point here is that they gave us pointers and I feel that there is 
even more that they could give us to make the language more powerful (without 
having to go to some OO language).   

How to handle handle overlapping subfields?  From my point of view I don't 
think you worry about it.  If I have a variable name FLDNAME that contains a 
value of 'CUSTNUMB' then I simply want to be able to access CUSTNUMB like this:

  Pointer = %addr(FLDNAME:*VALUE);  // where *VALUE tells %ADDR to return 
                                    // the pointer of the field named in 
                                    // FLDNAME and not the address of FLDNAME
  
  // I need to extract the value of that field, but I don't know ahead of time
  // what the field will be.  So I want to be able to access the definition of
  // that memory location.  
  Length = %AddrSize(Pointer);

If we had this ability it would even be great if they worked outside of the 
application that declared the variable.  That is, the application that declares 
the variable could pass a pointer (memory address) into another 
program/subprocedure and the called program/subprocedure could access 
additional details about the variable if it needed to.

Now, it's true that CUSTNUMB could be defined in a DS with another field 
overlapping it.  But I don't see that it really matters.

I also figure that "if" IBM really wanted to do some meaningful enhancements to 
RPG that these would be MUCH MORE usful than all that uppercase/lowercase crap 
that is already easily accomplished.  I understand that there may be other 
languages that might do this, but I am an RPG programmer and from my 
perspective I don't think this would be very difficult for IBM to deliver.

T: I've made this point before: If you think those things are important, then
you probably should be programming in an interpreted OO language.

But specifically regarding getting variable attributes based on address, how do
you propose to handle overlapping subfields?

<But name one needed feature in RPG that can't be done in code by the 
programmer?>  Resolving a pointer to a variable whose name is stored in a 
field.  The ability to determine the length of a variable based on it's memory 
address.  The ability to determine the type of data stored in a memory address.

I really cannot think of ANYTHING else I have needed and not been able to code 
for myself inside of RPG.  

"Or should they learn to do it incorrectly using %XLATE--after all, all code 
only runs in North America CCSUD(37), right?"

In my case? Absolutely - this county will never ever be anywhere but in 
Northeast WY... :-)

However, people like yourself can create service programs that meet a 
particular need and sell it. Why take away income from Bob Cozzi? :-)

I'd like IBM deal with idiotic things myself. I have a few fill-in projects 
that if I had my way IBM would change - like eliminate the need for those 
stupid /end-free /free statements and eliminate the preprocessor of embedded 
SQL and make it part of the compiler - just to name a couple.

Rocky, I appreciate where you're coming from. But name one needed feature in RPG
that can't be done in code by the programmer? 

Heck, between RPG Open.com and RPGLIB (RPG xTools) just about anything a
programmer may want in RPG is already there. 

Back when microsoft did Visual C++ and its MFC library, the user interface they
provided in Visual Studio included "tabbed dialog boxes". I thought this feature
was cool, but there was no Tabbed Dialog class in their MFC library. So I wrote
one, from scratch and gave the code away.

Then when I saw Microsoft at a Developers Conferece around 1994/95 I pushed them
to implement a tabbed dialog class. 

The response I got back from them was "you can write that code yourself, today,
by doing these 27,000 steps". 

I kept it up, and they eventually added tabbed windows/dialogs to MFC just two
releases later. Now its everywhere, pervasive throughout Windows code.

The feature I'm referring to in my comment is a consolidation of two existing
features into one. Of course this could have been done in a Subprocedure. One
example might be the FindReplace subprocedure in RPG xTools/RPGLIB. Its already
in a subprocedure and works great. 

Should the Find portion be case-sensitive or should it have an option to ignore
upper/lower case? Doesn't RegEx include a feature for upper/lower case? Aren't
there regex APIs available on System i? Do the 200,000 RPG programmers (guessing
at that figure) need to figure out how to do case-insensitive searchers or
should IBM provide it? Or should they learn to do it incorrectly using
%XLATE--after all, all code only runs in North America CCSUD(37), right?

I also somehow missed the connection between IBM not providing "ignore 
upper/lower case" option and "RPG v6.1 + 1 = #FAIL"

That hardly makes it "fail".

Bob,

Why - when it can be so easily handled via a subprocedure? Why is there this 
inane desire to harp on IBM on providing features that are easily handled 
ourselves? Create a subprocedure UPPER that converts everything to uppercase - 
pretty easy to do using %XLATE...

I'd rather IBM work on providing functionality that is a pain in the butt to 
implement otherwise...

Right. I've had zero influence since 2003. Heck, even on that last release I
worked on, I didn't really have much influence on the content. 

But regarding an "ignore upper/lower case" option, would that have code page
implications? If so, I can understand why the option wasn't provided.

Not true! They listen to a few former Toronto employees and a few business
partners and even fewer customers. I've been out of the loop for at least as
long as Hans has been.

LOL!!! Ask the big guys, Bob. You're probably a lot closer to them than I am!! 
lol

I can't believe that IBM is adding a new feature to RPG IV and it does not
support an "ignore upper/lower case" option.  What is so difficult about
including this kind feature?

Sigh!