RE: [U2] curious EQUATE issue - SOLVED Just want to know if anyone understands WHY?
Bill, So what you are saying is that it is bad usage of the equate statement even though it can be done. I agree and the '=' is used more often for this type of equation. However, this program was created 15 years ago (long before I started here) and had been working fine until the code was changed with the variable being inserted instead of the raw character causing us to wonder about why. The program is back to the way it was and is working fine. We just thought we could get an explanation from someone on the list as to why it made a difference and maybe let some of you all out there know to watch out for these little quirks of the language. Jerry -Original Message- From: Bill Haskett [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 23, 2007 9:11 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] curious EQUATE issue - SOLVED Just want to know if anyone understands WHY? Jerry: I hate to mention the obvious, but one should not equate anything unless they intend both sides of the equate to change when either variable changes. For instance, DIM MYREC(30) EQUATE MYREC.DATE TO MYREC(1) EQUATE MYREC.NAME TO MYREC(2) --etc-- Thus, whenever MYREC changes, due to a new record read, so does MYREC.DATE, etc. Alternatively, you simply have to alter MYREC.DATE to make sure the MYREC record has been changed too. To fix the problems you've encountered try: VALID.CC.TYPES = 'A':@VM:'B':@VM:'D':@VM:'M':@VM:'S':@VM:'V' VALID.CC.NAMES = 'American Express':@VM:'Carte Blanche':@VM:'Diners Club':@VM:'Mastercard':@VM:'Discover':@VM:'Visa' --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] curious EQUATE issue - SOLVED Just want to know if anyone understands WHY?
Jerry: I hate to mention the obvious, but one should not equate anything unless they intend both sides of the equate to change when either variable changes. For instance, DIM MYREC(30) EQUATE MYREC.DATE TO MYREC(1) EQUATE MYREC.NAME TO MYREC(2) --etc-- Thus, whenever MYREC changes, due to a new record read, so does MYREC.DATE, etc. Alternatively, you simply have to alter MYREC.DATE to make sure the MYREC record has been changed too. To fix the problems you've encountered try: VALID.CC.TYPES = 'A':@VM:'B':@VM:'D':@VM:'M':@VM:'S':@VM:'V' VALID.CC.NAMES = 'American Express':@VM:'Carte Blanche':@VM:'Diners Club':@VM:'Mastercard':@VM:'Discover':@VM:'Visa' VALID.CC.TYPES2 = 'A]B]D]M]S]V' VALID.CC.NAMES2 = 'American Express]Carte Blanche]Diners Club]Mastercard]Discover]Visa' ...the output looks like: 3 Dev (0)-> RUN DTABP TEST Equate with @VM: A2B2D2M2S2V Equate with @VM: American Express2Carte Blanche2Diners Club2Mastercard2Discover2V isa Equate with `253: A2B2D2M2S2V Equate with `253: American Express2Carte Blanche2Diners Club2Mastercard2Discover2 Visa Account type: A FIRST WAY Account name: American Express Position: 1 SECOND WAY Account name: American Express Position: 1 THIRD WAY Account name: American Express Position: 1 FOURTH WAY Account name: American Express Position: 1 In all the years I've been doing this I've never run into these kinds of problems because I follow the basic guideline noted. So, use an equate if both sides can change. If that's not what you want make a simple assignment. There is no reason, with today's machines, to create more complexity of syntax in order to accomplish this simple task. Just my $.02 :-) Bill >-Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of Jerry Banker >Sent: Tuesday, October 23, 2007 7:06 AM >To: u2-users@listserver.u2ug.org >Subject: RE: [U2] curious EQUATE issue - SOLVED Just want to >know if anyone understands WHY? > >We are running in Reality flavor on UniVerse 10.2.4 and Red >Hat Linux AS3. Here is a test of the code using the two forms >of LOCATE: > > EQU VALID.CC.TYPES TO 'A':@VM:'B':@VM:'D':@VM:'M':@VM:'S':@VM:'V' > EQU VALID.CC.NAMES TO 'American Express':@VM:'Carte >Blanche':@VM:'Diners Club':@VM:'Mastercard':@VM:'Discover':@VM:'Visa' > > EQU VALID.CC.TYPES2 TO 'A]B]D]M]S]V' > EQU VALID.CC.NAMES2 TO 'American Express]Carte >Blanche]Diners Club]Mastercard]Discover]Visa' > > CC.ACCT.TYPE = 'A' > > CRT 'Equate with @VM: ':VALID.CC.TYPES > CRT 'Equate with @VM: ':VALID.CC.NAMES > CRT > CRT 'Equate with `253: ':VALID.CC.TYPES2 > CRT 'Equate with `253: ':VALID.CC.NAMES2 > CRT > CRT 'Account type: ':CC.ACCT.TYPE > CRT > CRT 'FIRST WAY' > LOCATE(CC.ACCT.TYPE, VALID.CC.TYPES, 1 ; CC.PTR) THEN > CRT 'Account name: ':VALID.CC.NAMES<1,CC.PTR> > END ELSE > CRT 'Account name: NOT FOUND' > END > CRT 'Position: ':CC.PTR > CRT > CRT 'SECOND WAY' > LOCATE CC.ACCT.TYPE IN VALID.CC.TYPES<1> SETTING CC.PTR THEN > CRT 'Account name: ':VALID.CC.NAMES<1,CC.PTR> > END ELSE > CRT 'Account name: NOT FOUND' > END > CRT 'Position: ':CC.PTR > CRT > CRT 'THIRD WAY' > LOCATE(CC.ACCT.TYPE, VALID.CC.TYPES2, 1 ; CC.PTR) THEN > CRT 'Account name: ':VALID.CC.NAMES2<1,CC.PTR> > END ELSE > CRT 'Account name: NOT FOUND' > END > CRT 'Position: ':CC.PTR > CRT > CRT 'FOURTH WAY' > LOCATE CC.ACCT.TYPE IN VALID.CC.TYPES2<1> SETTING CC.PTR THEN > CRT 'Account name: ':VALID.CC.NAMES2<1,CC.PTR> > END ELSE > CRT 'Account name: NOT FOUND' > END > CRT 'Position: ':CC.PTR > > END > >And here are the results when you run the test program. > >Equate with @VM: A}B}D}M}S}V >Equate with @VM: American Express}Carte Blanche}Diners >Club}Mastercard}Discover}Visa > >Equate with `253: A}B}D}M}S}V >Equate with `253: American Express}Carte Blanche}Diners >Club}Mastercard}Discover}Visa > >Account type: A > >FIRST WAY >Account name: American Express}Carte Blanche}Diners >Club}Mastercard}Discover}Visa >Position: 1 > >SECOND WAY >Account name: NOT FOUND >Position: 2 > >THIRD WAY >Account name: American Express >Position: 1 > >FOURTH WAY >Account name: American Express >Position: 1 >--- >u2-users mailing list >u2-users@listserver.u2ug.org >To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] curious EQUATE issue - SOLVED Just want to know if anyone understands WHY?
regarding the example below: EQU VALID.CC.TYPES TO CHANGE('A.B.D.M.S.V','.',@VM) The problem with this is that the "CHANGE" within the EQU will get evaluated at run time, so it will be done repeatedly if placed within a LOOP or FOR structure. You would be better off with the earlier suggestion of EQU VALID.CC.TYPES TO ('A':@VM:'B':@VM:'D':@VM:'M':@VM:'S':@VM:'V') The concatenation will be done by the compiler, and the parenthesis will protect the LOCATE field designator, "<1,1>" from being interpreted as an extraction. This does compile, by the way. -Rick On Oct 23, 2007, at 2:04 PM, Rex Gozar wrote: Allen, EQU VALID.CC.TYPES TO CHANGE('A.B.D.M.S.V','.',@VM) does compile and it will protect the value of VALID.CC.TYPES from being unintentionally changed -- which is the reason for using EQU to declare constants in the code. I just wanted to remind people that equating to a variable does not set an unchanging, constant value; this can be a source of hard-to- find bugs. rex --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] curious EQUATE issue - SOLVED Just want to know if anyone understands WHY?
Allen, EQU VALID.CC.TYPES TO CHANGE('A.B.D.M.S.V','.',@VM) does compile and it will protect the value of VALID.CC.TYPES from being unintentionally changed -- which is the reason for using EQU to declare constants in the code. I just wanted to remind people that equating to a variable does not set an unchanging, constant value; this can be a source of hard-to-find bugs. rex --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] curious EQUATE issue - SOLVED Just want to know if anyone understands WHY?
Hi Rex, Interesting, never tried it before. I've only used it when I've had stuff that wouldn't go directly into EQU such as @(-1) in MvBASE. In that case I did: CCLR = @(-1) EQU CLR TO CCLR Wonder if EQU VALID.CC.TYPES TO CHANGE('A.B.D.M.S.V','.',@VM) Would work or error out.? *=aee=* -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Rex Gozar Allen, In your example, you use a variable in an EQUATE statement. This references the variable's pointer, not its value. So the code: TEMP = CHANGE('A.B.D.M.S.V','.',@VM) EQU VALID.CC.TYPES TO TEMP TEMP = "SOMETHINGELSE" ;* change TEMP's value DISPLAY VALID.CC.TYPES will display "SOMETHINGELSE", not the valid cc types as intended. rex --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] curious EQUATE issue - SOLVED Just want to know if anyone understands WHY?
Allen, In your example, you use a variable in an EQUATE statement. This references the variable's pointer, not its value. So the code: TEMP = CHANGE('A.B.D.M.S.V','.',@VM) EQU VALID.CC.TYPES TO TEMP TEMP = "SOMETHINGELSE" ;* change TEMP's value DISPLAY VALID.CC.TYPES will display "SOMETHINGELSE", not the valid cc types as intended. rex --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] curious EQUATE issue - SOLVED Just want to know if anyone understands WHY?
We are running in Reality flavor on UniVerse 10.2.4 and Red Hat Linux AS3. Here is a test of the code using the two forms of LOCATE: EQU VALID.CC.TYPES TO 'A':@VM:'B':@VM:'D':@VM:'M':@VM:'S':@VM:'V' EQU VALID.CC.NAMES TO 'American Express':@VM:'Carte Blanche':@VM:'Diners Club':@VM:'Mastercard':@VM:'Discover':@VM:'Visa' EQU VALID.CC.TYPES2 TO 'A]B]D]M]S]V' EQU VALID.CC.NAMES2 TO 'American Express]Carte Blanche]Diners Club]Mastercard]Discover]Visa' CC.ACCT.TYPE = 'A' CRT 'Equate with @VM: ':VALID.CC.TYPES CRT 'Equate with @VM: ':VALID.CC.NAMES CRT CRT 'Equate with `253: ':VALID.CC.TYPES2 CRT 'Equate with `253: ':VALID.CC.NAMES2 CRT CRT 'Account type: ':CC.ACCT.TYPE CRT CRT 'FIRST WAY' LOCATE(CC.ACCT.TYPE, VALID.CC.TYPES, 1 ; CC.PTR) THEN CRT 'Account name: ':VALID.CC.NAMES<1,CC.PTR> END ELSE CRT 'Account name: NOT FOUND' END CRT 'Position: ':CC.PTR CRT CRT 'SECOND WAY' LOCATE CC.ACCT.TYPE IN VALID.CC.TYPES<1> SETTING CC.PTR THEN CRT 'Account name: ':VALID.CC.NAMES<1,CC.PTR> END ELSE CRT 'Account name: NOT FOUND' END CRT 'Position: ':CC.PTR CRT CRT 'THIRD WAY' LOCATE(CC.ACCT.TYPE, VALID.CC.TYPES2, 1 ; CC.PTR) THEN CRT 'Account name: ':VALID.CC.NAMES2<1,CC.PTR> END ELSE CRT 'Account name: NOT FOUND' END CRT 'Position: ':CC.PTR CRT CRT 'FOURTH WAY' LOCATE CC.ACCT.TYPE IN VALID.CC.TYPES2<1> SETTING CC.PTR THEN CRT 'Account name: ':VALID.CC.NAMES2<1,CC.PTR> END ELSE CRT 'Account name: NOT FOUND' END CRT 'Position: ':CC.PTR END And here are the results when you run the test program. Equate with @VM: A}B}D}M}S}V Equate with @VM: American Express}Carte Blanche}Diners Club}Mastercard}Discover}Visa Equate with `253: A}B}D}M}S}V Equate with `253: American Express}Carte Blanche}Diners Club}Mastercard}Discover}Visa Account type: A FIRST WAY Account name: American Express}Carte Blanche}Diners Club}Mastercard}Discover}Visa Position: 1 SECOND WAY Account name: NOT FOUND Position: 2 THIRD WAY Account name: American Express Position: 1 FOURTH WAY Account name: American Express Position: 1 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] curious EQUATE issue - SOLVED Just want to know if anyone understands WHY?
Richard Nuckolls wrote: > the compiler is evaluating "VALID.CC.TYPES<1,1>" as > "A':@VM:'B':@VM:'D':@VM:'M':@VM:'S':@VM:'V'<1,1>" The precedence of concatenation is lower than dynamic array extraction. Try placing parenthesis characters around the equate definition. E.g. EQU VALID.CC.TYPES TO ('A':@VM:'B':@VM:'D':@VM:'M':@VM:'S':@VM:'V'). It might be necessary to use the EQUATE LITERALLY form to maintain the parenthesis characters. Best regards, Gyle --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] curious EQUATE issue - SOLVED Just want to know if anyone understands WHY?
Very oddnot sure why, mass hysteria? ;-) I'll tell you what, this is an easier construct, especially if you have two dozen or so values to stick into an array. TEMP = CHANGE('A.B.D.M.S.V','.',@VM) EQU VALID.CC.TYPES TO TEMP -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Brenda Price Sent: Monday, October 22, 2007 14:55 To: u2-users@listserver.u2ug.org Subject: [U2] curious EQUATE issue - SOLVED Just want to know if anyone understands WHY? One of our end users started getting the printer on (AccuTerm - this prints everything you do to the printer and keeps it attached to your session so no one else can print) last week. One of our other programs, found the reason was he'd changed some equated statements from having the actual value of the value mark and subvalue mark to @VM and @SVM. Example: EQU VALID.CC.TYPES TO 'A}B}D}M}S}V' was changed to EQU VALID.CC.TYPES TO 'A':@VM:'B':@VM:'D':@VM:'M':@VM:'S':@VM:'V' The locates that previously worked on stopped working on the new equ values causing the whole string that related to that value to be sent back to the user. Somehow this whole string when it was displayed to the screen turned on the printer on function. The other programmer did several example different locate types in a test program and all but one failed on the new value that used the @VM and all worked with the old equate. So, we all said "HUH???", he changed it back and the program is now working properly again. Just wanting to know, does anyone have an explanation for this? Brenda Price Affiliated Acceptance Corp Sunrise Beach, MO --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] curious EQUATE issue - SOLVED Just want to know if anyone understands WHY?
When the "new" version of the equate was compiled under Information flavor, the compiler warned that it was a Reality style LOCATE. To its credit, the compiler defers the evaluation of the EQU until it is used, at which point, it evaluates it in context, so the compiler is evaluating "VALID.CC.TYPES<1,1>" as "A':@VM:'B':@VM:'D':@VM:'M':@VM:'S':@VM:'V'<1,1>" The vlist output below gives a good hint as to what is going on. Notice that the is being applied to the last value of the EQU string prior to doing the build with the rest of the codes. In the Reality format, it is legitimate to omit the specifier, in which case the program will do a field level search rather than a value level search. This quirk would only show up with the use of an EQUATE rather than a variable assignment. If you feel compelled to use an EQUATE for the codes, you could overcome the issue with a temporary assignment such as EQU VALID.CC.TYPES TO 'A':@VM:'B':@VM:'D':@VM:'M':@VM:'S':@VM:'V' ... CC.TYPES = VALID.CC.TYPES LOCATE X IN CC.TYPES<1,1> ... - VLIST of LOCATE on original equate -- 5: LOCATE X IN VALID.CC.TYPES<1,1> BY 'AL' SETTING LP THEN Press any key to continue... 5 E : 060 dyn_extract"V" 1 1 0 => $R0 5 0001A : 03A concat "A}B}D}M}S}" $R0 => $R1 5 00022 : 0D4 locate X $R1 1 0 0 "AL" => LP 5 00032 : 0C4 jumpf --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/