Basic+ Locate Statement (AREV64)
At 05 DEC 2020 03:08:51PM rdhull50 wrote:
Hello,
I'm having a problem with a Basic+ statement in a Stored Procedure used in AREV64
Note that for AREV64 compatibility, I have these two statements at the top of the Stored Proc:
*#PRECOMPILE
*#FLAVOR AREV
So far, my AREV3.12 R/Basic programs have recompile successfully in OI10/AREV64, it's just this one for some reason.
GL.TRANS.LIST is a list of keys e.g.
<1> 3921*1*2019
<2> 3922*1*2019
The statements are:
READ GL.TRANS.LIST FROM LISTS,"GL.TRANS.LIST" ELSE GL.TRANS.LIST = ''
Locate ID IN GL.TRANS.LIST USING @FM SETTING FMC THEN
GL.TRANS.LIST = DELETE(GL.TRANS.LIST,FMC,0,0)WRITE GL.TRANS.LIST ON LISTS,"GL.TRANS.LIST"END
It does not compile, with the following error:
B102 - Line 135. Illegal Statement: LOCATE ID IN GL.TRANS.LIST USING @FM USING @FM SETTING FMC THEN.
Notice in the error message that "USING @FM" is repeated.
If I remove "USING @FM", then it will compile, but I understand that if the "Using" clause is omitted then Using @VM is assumed.
e.g. Locate ID IN GL.TRANS.LIST SETTING FMC THEN
The syntax of R/Basic and Basic+ appear to be the same.
The program DOES compile and run successfully in AREV 3.12
Any ideas?
Robert Hull
At 05 DEC 2020 03:37PM rdhull50 wrote:
Incidentally, if I change the statement to:
Locate ID IN GL.TRANS.LIST USING @VM SETTING FMC THEN
- OR -
Locate ID IN GL.TRANS.LIST USING @SVM SETTING FMC THEN
Then I get the following errors:
B102 - Line 135. Illegal Statement: LOCATE ID IN GL.TRANS.LIST USING @VM USING @FM SETTING FMC THEN.
- OR -
B102 - Line 135. Illegal Statement: LOCATE ID IN GL.TRANS.LIST USING @SVM USING @FM SETTING FMC THEN.
It would seem to me that the locate statement broken and is not working properly.
Robert Hull
At 07 DEC 2020 10:18AM bob carten wrote:
The syntax of LOCATE is unchanged. Your statement looks like it should work.
The error suggest that the error is in the precompiler. It is corrupting the LOCATE statement before it passing the precompiled code to the compiler. If you use a variable name without dots, e.g. GL_TRANS_LIST, does it compile correctly?
At 07 DEC 2020 11:39AM bshumsky wrote:
Yes, as Bob has implied, the precompiler isn't quite as smart as the regular compiler, and can sometimes be fooled/confused. It's normally down to things like using a keyword as a variable name, or it incorrectly finding some other statement or function name where it doesn't belong.
Was there ever an earlier, different version of LOCATE in AREV? Maybe that's what the precompiler is expecting to find, and seeing the LOCATE in "OI syntax" is throwing it off?
Thanks,
- Bryan Shumsky
At 07 DEC 2020 11:53AM Andrew McAuley wrote:
No, the syntax has been the same since the year dot. This seems to be the precompiler, as removing the directive compiles normally. Interestingly the Write is converted to a WRITE_LOCK when using the precompiler which seems a bit presumptuous.
World leaders in all things RevSoft
At 07 DEC 2020 09:36PM bshumsky wrote:
No, the syntax has been the same since the year dot. This seems to be the precompiler, as removing the directive compiles normally. Interestingly the Write is converted to a WRITE_LOCK when using the precompiler which seems a bit presumptuous.
World leaders in all things RevSoft
WRITE_LOCK is designed to be called regardless of whether or not there is a lock on the record; if the KEEP_LOCK flag isn't set, it will do a write and unlock the record IF there is a lock placed on it via READ_LOCK. It's a generic routine called in a variety of circumstances; "multi purpose" rather than "presumptuous", if you will…
- Bryan Shumsky
At 08 DEC 2020 01:01AM rdhull50 wrote:
It seems to be the "using" clause that causes the issue with the precompiler in that I have another Locate statement that compiles correctly:
LOCATE ID IN ACCT<20+TPER> SETTING VMC THEN …….. works
LOCATE ID IN GL_TRANS_LIST USING @FM SETTING FMC THEN ….. doesn't work
Also, I did change the "GL.TRANS.LIST" TO "GL_TRANS_LIST", and it didn't change anything.
I got around it by doing the following, since @vm is assumed if no "using" clause is specified.
Convert @FM To @VM In GL_TRANS_LIST
Locate ID IN GL_TRANS_LIST SETTING VMC Then
Convert @VM To @FM In GL_TRANS_LISTFMC = VMCGL_TRANS_LIST = DELETE(GL_TRANS_LIST,FMC,0,0)WRITE GL_TRANS_LIST ON LISTS,"GL_TRANS_LIST"End
I could have used a difference set of statements to extract the ID from the list, but this seemed like the simplest.
Robert Hull
At 08 DEC 2020 05:08AM Andrew McAuley wrote:
TBH I'm a bit confused. If I'm writing AREV32 code I do it in AREV32 so I don't need to add precompiler directives. That way all works as expected. You don't actually need the precompiler most of the time - it's there to deal with things like INPUT and PRINT. If you're just writing non-UI code it isn't really needed.
World leaders in all things RevSoft
At 08 DEC 2020 06:47AM Andrew McAuley wrote:
I can see that you might think that, but write_lock is undocumented and unknown to our user base. Also it's 30% slower than a native write.
World leaders in all things RevSoft
At 08 DEC 2020 07:46AM bshumsky wrote:
I can see that you might think that, but write_lock is undocumented and unknown to our user base. Also it's 30% slower than a native write.
World leaders in all things RevSoft
The user base shouldn't normally be looking at the "precompiled" code - if they're working in AREV32/AREV64, these kinds of translations should be invisible to them. Yes, there is indeed a performance hit with any kind of emulation code, but that is a price that's paid for (nearly) transparent emulation of AREV inside OI.
Of course, running AREV in OI is supposed to be a "stepping stone" towards converting into OI, so that developers should eventually take their code (or the precompiled code that we generate for them) as starting points for more efficient, "direct" code.
- Bryan Shumsky
At 08 DEC 2020 11:04AM Andrew McAuley wrote:
Thanks for taking the time to explain how this all fits together off line Bryan. I think we're in agreement that all works as intended when correctly used :).
World leaders in all things RevSoft
At 08 DEC 2020 07:36PM rdhull50 wrote:
Andrew,
In your response above where you said:
TBH I'm a bit confused. If I'm writing AREV32 code I do it in AREV32 so I don't need to add precompiler directives. That way all works as expected. You don't actually need the precompiler most of the time - it's there to deal with things like INPUT and PRINT. If you're just writing non-UI code it isn't really needed.
Since I'm leaving this app to run in AREV64 and NOT intending to convert it to OI, what would I do to leave it in AREV64? Compile it in the AREV64 window and catalog it in VOC as it was? Will that work?
Or is writing code in "AREV32" different than what came over from AREV3.12? In other words, will I have to modify my Arev 3.12 code for it to run in AREV64?
Robert Hull
At 09 DEC 2020 02:50AM Andrew McAuley wrote:
Just log into AREV 64 go to TCL and treat it like AREV 312. There is no intentional functional difference between the two other than the fact that you can make calls to open insight routines from within AREV.
World leaders in all things RevSoft