IBM Power Ideas Portal
This portal is to open public enhancement requests against IBM Power Systems products, including IBM i. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).
Shape the future of IBM!
We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Search existing ideas
Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,
Post your ideas
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
Specific links you will want to bookmark for future use
Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.
IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.
ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.
Based on the comments from the community (thank you all BTW!!) Looks like this RFE can be closed as the support is already available. Please chime in if you disagree.
Previous comment should read _Rreadk() not _Rread.
Previous comment should read _Rreadk() not _Rread.
Based on my findings I am not sure if this an RFE or a PMR? _Rlocate should be capable of using a partial key (is a long int stored in a long long int field a partial?), I know it works on partial keys within character based fields. I tested the retrieval of the same keyed record in SQL by doing a "select from file where key = 1234..." and the record was correctly located. so why would SQL return the record and a _Rlocate not? Also tried with _Rread with the same results.
Sorry, I was testing a program and the results would not find the correct key value because the record field was capable of holding a larger value than I was writing to it, subsequent requests for the record using the key written failed. I created the file with a key field of 16B and wrote a long int to the key field, the subsequent rlocate using a long int value failed to locate the record! I reduced the field to a 8B storage location and the write/rlocate of the key works. However if I was using a string and wrote 10 characters to a 20 character field with a subsequent rlocate with a key length of 10 it would find it. Also the manual states the the parameter passed to the _Rlocate function should be a string. " key
Points to a string containing the key fields to be used for positioning." The header does state a void * which is why I thought an address of a long int should work, but testing as above failed.
This is already available. Keys are a "data structure" if you will, but regardless, you can pass the address of an int variable and simply cast it to whatever. The prototype is "void *" (void pointer) so any address is permitted.
int custno = 3741;
_Rlocate(hFile, &custno, sizeof(custno) );
The C prototype as supplied in QSYSINC/H.RECIO has type void * for the key, so is not restricted to being passed as a string.
Use either a pointer to int or the address of the int or a pointer to a struct that contains an int or the address of the structure that contains an int..
More generically we use either of the latter and the struct contains all key fields for the file and use the length of key argument to control whether doing full or partial (and how partial) key operation. This RFE is not needed IMHO.