RPGILE comparing values

30 pts.
Tags:
RPG
RPG ILE
i have a value say for example ASD12246. i need to check this value against afile which contains similar values lik this. i need to pick the value that has maximum matches with this number. Sa y for example if the File has ASD122 and ASD1224 i have to selct the code corresponding to ASD1224 as it has the max matches. can any one tell me how this can be done with min noof counts

Answer Wiki

Thanks. We'll let you know when a new response is added.

Hi,

My solution would be to chain with the full length of the string, then reduce the length by one, chain again, etc until you have a match – or you run out of string.

Regards,

Martin Gilbert.

///////////////////////
that might look something like this

L = %Length(%trim(InString))
Chain (%subst(InString:1:L)) myFile
dow L > 1 and not %found( myFile)
L -= 1
Chain (%subst(InString:1:L)) myFile
enddo
if %found( myFile )
wrkCde = Code
endif

Phil

//////////////////////////////////
Gilly

A chain goes to the index — like a SETLL
the SETLL almost always sets the pointer
The chain stops at the index step if match not found
it doesn’t have an address to read from.
So I doubt that a failed chain takes more resources than a SETLL
A susccessful chain, on the other hand, does.
So as you said if the user needs some data from the file a chain is required
otherwise a setll is better.

But this option beets the looping?
SETGT complete string
READP
if %subst(Complete string : 1 : %length(%trim(InField)) = Infield
got it
else
doesn’t exist
endif
Phil

Hi Phil,

That looks pretty effective to me. Certainly beats lots of chains or setlls per checked item.

Regards,

Martin Gilbert.
Tks Gilly
Great and I’ll push SETLL over CHAIN, thanks for all your great input.
Wonder if the person with the question is listening?
Isn’t it pretty late where you are?

Hi Yorkshireman

Binary search — just know you’re dying to code that one again.
But correct me if I’m wrong, isn’t that just about what setll does, maybe with alot smarter algorithm?

Phil

Discuss This Question: 5  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • Yorkshireman
    Create an access path over the file keyed by the value field. use binary search technique to arrive at correct record. - do NOT chain to the file repeatedly, create an access path and use SETLL to see if a record exists with the value you have. the once only access path creation will be cheaper on resource than millions of CHAIN s alternatively, if the number of records is small, make one pass over the file and load an array - use some array extendible routines, and ensure you prevent runaways by providing a max number of entries. Then search over the array entries. - even quicker
    5,580 pointsBadges:
    report
  • Gilly400
    Hi, Yorkshireman is right - SETLL is much more efficient - as long as you don't need any data from the record. If you need data then you'll still need to do a chain or read somewhere. @yorkshireman - can you explain what you mean by "use binary search technique to arrive at correct record."? Regards, Martin Gilbert.
    23,730 pointsBadges:
    report
  • philpl1jb
    The SETLL and chain should take the same resources when the record is not found and when/if it is found he needs a code from the record found and the process stops. But an even easier find would be SETGT complete string READP if %subst(Complete string : 1 : %length(%trim(InField)) = Infield got it else doesn't exist endif Phiil
    51,235 pointsBadges:
    report
  • Gilly400
    Hi Phil, I believe that a SETLL uses less resource than a CHAIN - SETLL only attempts to position the pointer for the file and check whether there's a match with the key, whereas CHAIN also attempts to retrieve data for the record. Regards, Martin Gilbert.
    23,730 pointsBadges:
    report
  • Yorkshireman
    folks, the key part of my solution was that we create an access path over the code value. the original question says ' the file contains values' - which implies they are not a key. As soon as we have the values keyed then the solution is simple. a couple of DB i/o's and some string compares should get it. the 'binary search' technique wouldn't necassarily apply, but if we have a value of 12245 in the file, then in the example given, a READP on 12246 would return the wrong result. Generalising that case ( and we don't have a full story here) then we could use RRN retrieval as the basis, and access the file at, say, the half way point, see what value is there, and then access at the half way point of whichever half will have the value we seek, and so on. eventually a couple of READ and the string comparison would let us creep up on the record we need. - quicker than reading a lump of the entire file - but it all depends on scale. solutions for 50 million records differ to solutions for 5000 records, as we all know. same with the array solution / single file pass - placing the values and the (real, current) key values in memory is OK for 5000, but stupid for 50 million. Its my understanding that CHAIN will always use more overhead, as it starts life assuming it will get data, therefore has a little check around buffer areas, sucks on a straw and thinks a bit before getting to the index. SETLL only has to go to the index - no thinking involved, and flip a bit if it gets a record match (logical add on the keys = 0 ) - something like that, anyway..
    5,580 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following