Just to address a couple of your comments... The reason I use SPECIAL so much is the file I'm reading this information from is SPECIAL.PRICE. The fields I'm referencing are from something similar to a sales quote. I'd expect the quantity numbers to rarely match. The fields I'm referencing are Part Number, From Qty and Sales Price. So there could be 5 iterations of part number "12345" with >From Qtys of 0, 1000, 2000, 4000 and 10000 and Prices of 0.35200, 0.34200, 0.33200, 0.31200 and 0.29200. From experience, I know that I can't count on each of these triads being in any particular order, except for the fact that each mv will be in the same order as the other 2 for any given record. This is information living in my ERP system.
-----Original Message----- From: Mark Johnson [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 16, 2004 5:46 PM To: U2 Users Discussion List Subject: Re: Looking for associated multi-value algorithm... Perhaps the most glaring problem here is the level of the LOCATE. Since SPECIAL.PARTS is a value and thus possibly multi-valued, the ,STARTPOS indicator suggests to the LOCATE to look at the first subvalue of the value'd. Somehow, especially since STARTPOS isn't previously defined, it become zero and <1,0> is the same as <1> which may accidentally satisfiy the LOCATE. Remove the <comma>STARTPOS from the <> in the LOCATE and the STARTPOS=SPECIAL+1 as they don't contribute anything. Also, this looks like a FIFO/LIFO algorithm. What are the failures if the qtys don't match. The LOCATE should eliminate the FOR...NEXT loop unless you have the PART.NBR in the <12> more than once. In any case, the FOR...NEXT is is useless. If the PART.NBR is in <12> more than once, use FOR...NEXT and do a simple equals test on <12>. I don't believe that LOCATE can find occurrences of PART.NBR after the first one it finds. At least using numbers inside the <>. Perhaps LOCATE X in Y<1>,STARTPOS on the outside. I don't use it. FInally, if it's any contribution (and it's my purely non-technical opinion). Remove all the extraneous uses of the prefix SPECIAL. That makes it hard to read as all the variables start with SPECIAL and it's hard to identify their purpose quickly. I'm sure I'll get flamed for this, but it does make it more readable. PARTS=SPECIAL.REC<12> C.PARTS=DCOUNT(PARTS,VM) QTYS=SPECIAL.REC<14> ; PRICES=SPECIAL.REC<16> QTEMP=0 FOR I=1 TO C.PARTS IF PARTS<1,I>=PART.NBR THEN QTY=QTYS<1,I> IF QTY < QTY.REQUESTED AND QTY > QTEMP THEN DATA.OUT=OCONV(PRICES<1,I>,MDP)"R#12" QTEMP=QTY END END NEXT I my 2 cents. I'm looking for an algorithm for searching through a group of associated multi-value fields. The fields are F12 (PartsList), F14 (From Qty) and F16 (Unit Price). I can't depend on these being in any certain order, just that the associated fields will be in identical order. What I want to return is the Unit Price (F16) given PART.NBR and QTY.REQUESTED. I've got a code snippet of what I think will work, but I'd like to get some feedback on it...it won't work because, there's a better way of doing this, etc. Thanks. SPECIAL.PARTS = SPECIAL.REC<12> SPECIALCOUNT = DCOUNT(SPECIAL.PARTS,VM) SPECIAL.FROM.QTY.TEMP = 0 FOR SPECIALPART = 1 TO SPECIALCOUNT LOCATE PART.NBR IN SPECIAL.PARTS<1,STARTPOS> SETTING SPECIAL ELSE EXIT SPECIAL.FROM.QTY=SPECIAL.REC<14,SPECIAL> IF SPECIAL.FROM.QTY<QTY.REQUESTED AND SPECIAL.FROM.QTY>=SPECIAL.FROM.QTY.TEMP THEN SPECIAL.FROM.QTY = SPECIAL.REC<14,SPECIAL> SPECIAL.PART.PRICE = SPECIAL.REC<16,SPECIAL> TEMP.OUT = OCONV(SPECIAL.PART.PRICE,MDP) "R#12" SPECIAL.FROM.QTY.TEMP = SPECIAL.FROM.QTY END STARTPOS = SPECIAL + 1 FIRST = 0 NEXT SPECIALPART DATA.OUT=TEMP.OUT RETURN -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
