|
Aaron, Its been 20 years since I first played with these things and then it was MI, later I used System C, and then ILE C. Recently I used RPG and the APIs but I moved to using the MI instructions in RPG to access index entries. The best place to read about these things is in the MI instructions for Independent Indexes. Some MI instructions are: CRTINX INSINXEN FNDINXEN And then there's this: The maximum entry length field is ignored. All indexes are created with a maximum entry length of 2,000 bytes. Note that indexes created before Version 3 Release 6 could have been created with a maximum entry length of 120 bytes or 2,000 bytes. The MATINXAT instruction can be used to materialize this attribute. The key length field specifies the length of the key for the entries that are inserted into the index. The argument length specifies the length of the entries when fixed length entries are used. The key length must have a value less than or equal to the argument length whether specified during creation (for fixed-length entries) or during insertion (for variable length). The key length is not used if the key insertion field specifies no insertion by key. -Bob Cozzi www.i5PodCast.com Ask your manager to watch i5 TV -----Original Message----- From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of albartell Sent: Thursday, March 15, 2007 8:06 AM To: 'RPG programming on the AS400 / iSeries' Subject: Understanding User Indexes from RPG So I have incorporated User Indexes (i.e. *USRIDX - <http://tinyurl.com/yw8r4g> http://tinyurl.com/yw8r4g) into a handful of applications in the past, but my most recent venture has caused me to look into them more deeply. After playing with them for the better part of an afternoon I would describe RPG's accessing User Indexes as "Loosely coupled 'CHAINing' to a loosely typed 'table'.". Maybe I could best describe what I believe to be happening with some data. When I create the User Index I specify a key length of six which is the length of the CstNbr "column". Let's say I load the following as individual entries within a User Index. As each entry is added I believe the User Index simply looks at the first six bytes of whatever I sent in (whether it be character or numeric) and indexes that entry accordingly, correct? Is the whole record considered a part of the key and thus indexed? The documentation to me didn't do a good job of describing how User Indexes work but instead just described how the API's work. CstNbr Name MI City .........1....+....2....+....3 192837Lee F L Hector 389572Stevens K L Denver 392859Vine S S Broton 397267Tyron W E Hector 475938Doe J W Sutter 583990Abraham M T Isle 593029Williams E D Dallas 693829Thomas A N Casper 839283Jones B D Clay 846283Alison J S Isle 938472Henning G K Dallas 938485Johnson J A Helen When I use the QUSRTVUI (Retrieve User Index Entry) API I simply specify the search criteria (i.e. 192837) that I am looking for, and also specify the length of that search criteria (six in this case). This works as expected. If I change my search criteria to be 192837L (Note the 'L' at the end) but DO NOT change the declared search criteria length (i.e. search criteria length is still six) when making my call to QUSRTVUI it still finds the entry even though I created the User Index with a key length of six and attempted to retrieve an entry with a seven long search criteria even though I specified the search criteria length to be six. Any insight as to how User Indexes work under the covers would be much appreciated. p.s. I have included a working example at the bottom of this post that others can play with. File QCUSTCDT is located in library QIWS on most every iSeries system (great for test data). Thanks, Aaron Bartell http://mowyourlawn.com Fqcustcdt if e disk d QUSCRTUI pr extpgm('QUSCRTUI') d usridxnamlib 20a const d extattrib 10a const d entattrib 1a const d entlgth 10i 0 const d keyinsert 1a const d keylgth 10i 0 const d immupdate 1a const d optimization 1a const d pubauth 10a const d description 50a const d replace 10a const d APIError likeds(APIError) d QUSADDUI pr extpgm('QUSADDUI') d rtnlibname 10a d nbrentadd 10i 0 d usridxnamlib 20a const d instype 10i 0 const d entry 2000a const d entlgth 10i 0 const d entlgthoff 8a const d nbrentinp 10i 0 const d APIError likeds(APIError) d QUSRTVUI pr extpgm('QUSRTVUI') d rcvvar 2000a d length 10i 0 const d rcvLenOfs like(rcvLenOfs) d lenEntLenOfs 10i 0 const d nbrEntRtn 10i 0 d rtnLibNam 10a d usrIdxNamLib 20a const d fmt 8a const d maxNbrEnt 10i 0 const d srchType 10i 0 const d srchCrit 200a const d srchCritLen 10i 0 const d srchCritOfs 10i 0 const d APIError likeds(APIError) // User Index definitions D uiNam c const('DOGBREATH QTEMP ') D rtnLib S 10a Inz D numAdded S 10i 0 Inz D rcvVar S 2000a Inz D rcvVarLen S 10i 0 Inz(%size(RcvVar)) D rcvLenOfs S 128a Inz D rcvVarOffL S 10i 0 Inz(%size(rcvLenOfs)) D nbrRtn S 10i 0 Inz D SearchKey S 7a // API Error Data Structure D APIError DS Inz D BytesProv 10i 0 Inz(%Size(APIError)) D BytesAvail 10i 0 D MsgID 7a D Reserved 1a D MsgData 100a D entry ds qualified inz D cstNum 6a D cstNam 9a D cstIntl 3a D cstCity 6a /free // Create User Index QUSCRTUI( uiNam: *blanks: 'F': %size(entry): '1': %len(entry.cstNum): '1': '1': '*ALL': '': '*YES': APIError); // Read data & add to the index dow '1'; read QCUSTCDT; if %eof(); leave; endif; entry.cstNum = %char(cusnum); entry.cstNam = LSTNAM; entry.cstIntl = INIT; entry.cstCity = CITY; QUSADDUI( rtnLib: numAdded: uiNam: 2: entry: %size(entry): ' ': 1: APIError); enddo; // Randomly access the data via a key. Note the first search key has // a 'T' at the end. SearchKey = '693829T'; //Thomas A N Casper exsr process; SearchKey = '938485'; //Johnson J A Helen exsr process; SearchKey = '389572'; //Stevens K L Denver exsr process; *inlr = *on; return; begsr process; QUSRTVUI( rcvVar: rcvVarLen: rcvLenOfs: rcvVarOffL: nbrRtn: rtnLib: uiNam: 'IDXE0100': 1: 1: searchKey: %len(entry.cstNum): *zeros: APIError); if nbrRtn > 0; // Run in debug to see what is in variable 'entry' entry = %SubSt(rcvVar: 9: %len(entry)); endif; endsr; /END-FREE
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.
midrange.com
