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?
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.NAMES1,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.TYPES1 SETTING CC.PTR THEN CRT 'Account name: ':VALID.CC.NAMES1,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.NAMES21,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.TYPES21 SETTING CC.PTR THEN CRT 'Account name: ':VALID.CC.NAMES21,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?
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?
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,
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?
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?
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.NAMES1,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.TYPES1 SETTING CC.PTR THEN CRT 'Account name: ':VALID.CC.NAMES1,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.NAMES21,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.TYPES21 SETTING CC.PTR THEN CRT 'Account name: ':VALID.CC.NAMES21,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?
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.TYPES1,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 field,value 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 field,value 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.TYPES1,1 ... - VLIST of LOCATE on original equate -- 5: LOCATE X IN VALID.CC.TYPES1,1 BY 'AL' SETTING LP THEN Press any key to continue... 5 E : 060 dyn_extractV 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/
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?
Richard Nuckolls wrote:
the compiler is evaluating VALID.CC.TYPES1,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/
