Re: [U2] [UV] odd problem with read statement assigning variable with random data with else clause in pick flavor
Thanks Stuart. Yep, it is part of a terminal escape sequence and I actually wrote a subroutine that I called when this occurred that scanned all of common for the escape sequence. I only found subsets of the string, and not the full string that was being inserted into CITEM when the read failed. So it is not coming from another common variable. -Troy -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Boydell, Stuart Sent: Wednesday, December 23, 2009 1:08 PM To: U2 Users List Subject: Re: [U2] [UV] odd problem with read statement assigningvariable with random data with else clause in pick flavor Another interesting behaviour is if you have 2 programs, one with COMMON A,B,C,D,CITEM and the other with COMMON REC(99) the ordinal positions of the commons equate to the same thing. ie REC(5) = CITEM. Also, what's the nature of the escape sequence you get - can you ascertain if it's an edit key sequence or a terminal display sequence.. you might get another clue where the value is coming from. Stuart Boydell ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UV] odd problem with read statement assigning variable with random data with else clause in pick flavor
Need to use the LOCK conditional on the READU. ELSE is if the record does not exist. Do a help on READU to get more details. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Mecki Foerthmann Sent: Wednesday, December 23, 2009 12:34 AM To: U2 Users List Subject: Re: [U2] [UV] odd problem with read statement assigning variable with random data with else clause in pick flavor Hi Firstly READU will not execute the ELSE clause when the item is locked. It will just sit there and wait for the lock to be released. Regardless if it is a bug or not, your piece of code just doesn't make sense. What do you actually try to achieve? You try to read a record and when it doesn't exist you want to set the variable to null, right? So you use READU CITEM FROM FILE THEN ... END ELSE CITEM = '' instead of CITEM = '' READU CITEM FROM FILE THEN ... END and your problem is solved. I always use the ELSE clause with any READ BTW Regards Mecki Buss, Troy (Logitek Systems) wrote: Thanks for the replies... In this example I was using, the ID was not on file, so it would not have taken the LOCKED clause. I just added the locked clause to my actual failing code to test the theory and it still takes the ELSE clause because the record is truly not on file. I tried George's idea of using named common and the problem still happens. One last clarification, the problem seems to occur if the READ statement is a READU. If the statement is a regular READ, it does not happen. -Troy -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of David Jordan Sent: Tuesday, December 22, 2009 1:23 PM To: U2 Users List Subject: Re: [U2] [UV] odd problem with read statement assigning variablewith random data with else clause in pick flavor Hi Troy The problem with that code is that the else clause is taken when the record is locked. You are assuming if the else clause is taken that the record does not exist, which is not a safe assumption. I would suggest Readu citem from fv, key locked * locked options End then * then options End else Citem = end -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Buss, Troy (Logitek Systems) Sent: Wednesday, 23 December 2009 7:59 AM To: u2-users@listserver.u2ug.org Subject: [U2] [UV] odd problem with read statement assigning variable with random data with else clause in pick flavor We are running universe 10.2.10 in pick flavor. I have a program (part of a 4gl subroutine) that simplified does the following: CITEM = READU CITEM FROM F.FILE, CID THEN END ELSE IF CITEM # THEN PRINT CITEM IS NOT NULL! END According to the documentation, when running in pick flavor, the value of CITEM is unchanged if the read fails. What happens is that CITEM is sometimes assigned to a random value and not NULL. Right now it is being assigned to zero. Last week, this same CITEM was being assigned to an escape sequence (about 8 characters long) when the read failed. CITEM is a non-named common variable. This issues does NOT happen if CITEM is not a common variable. The result also has varied if I use READU vs READ. Clearly there is a bug here in retaining the value of CITEM with a READ statement in pick flavor. Unfortunately, I have not been able to create a simple example to reproduce this problem outside of the 4gl. And this does not happen in all the code, only in one section so far and IS reproducible in this one case from logon session to logon session. Any ideas? -Troy ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UV] odd problem with read statement assigning variable with random data with else clause in pick flavor
Hi Firstly READU will not execute the ELSE clause when the item is locked. It will just sit there and wait for the lock to be released. Regardless if it is a bug or not, your piece of code just doesn't make sense. What do you actually try to achieve? You try to read a record and when it doesn't exist you want to set the variable to null, right? So you use READU CITEM FROM FILE THEN ... END ELSE CITEM = '' instead of CITEM = '' READU CITEM FROM FILE THEN ... END and your problem is solved. I always use the ELSE clause with any READ BTW Regards Mecki Buss, Troy (Logitek Systems) wrote: Thanks for the replies... In this example I was using, the ID was not on file, so it would not have taken the LOCKED clause. I just added the locked clause to my actual failing code to test the theory and it still takes the ELSE clause because the record is truly not on file. I tried George's idea of using named common and the problem still happens. One last clarification, the problem seems to occur if the READ statement is a READU. If the statement is a regular READ, it does not happen. -Troy -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of David Jordan Sent: Tuesday, December 22, 2009 1:23 PM To: U2 Users List Subject: Re: [U2] [UV] odd problem with read statement assigning variablewith random data with else clause in pick flavor Hi Troy The problem with that code is that the else clause is taken when the record is locked. You are assuming if the else clause is taken that the record does not exist, which is not a safe assumption. I would suggest Readu citem from fv, key locked * locked options End then * then options End else Citem = end -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Buss, Troy (Logitek Systems) Sent: Wednesday, 23 December 2009 7:59 AM To: u2-users@listserver.u2ug.org Subject: [U2] [UV] odd problem with read statement assigning variable with random data with else clause in pick flavor We are running universe 10.2.10 in pick flavor. I have a program (part of a 4gl subroutine) that simplified does the following: CITEM = READU CITEM FROM F.FILE, CID THEN END ELSE IF CITEM # THEN PRINT CITEM IS NOT NULL! END According to the documentation, when running in pick flavor, the value of CITEM is unchanged if the read fails. What happens is that CITEM is sometimes assigned to a random value and not NULL. Right now it is being assigned to zero. Last week, this same CITEM was being assigned to an escape sequence (about 8 characters long) when the read failed. CITEM is a non-named common variable. This issues does NOT happen if CITEM is not a common variable. The result also has varied if I use READU vs READ. Clearly there is a bug here in retaining the value of CITEM with a READ statement in pick flavor. Unfortunately, I have not been able to create a simple example to reproduce this problem outside of the 4gl. And this does not happen in all the code, only in one section so far and IS reproducible in this one case from logon session to logon session. Any ideas? -Troy ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UV] odd problem with read statement assigning variable with random data with else clause in pick flavor
Mecki, Thanks for your ideas and help. Correct, the READU will stop on a record locked condition which is not the problem. Also this is not my code, but represents maybe 2000 read statements that might be in the entire application that assumes that the CITEM will not be changed if the ELSE clause is taken (per the pick flavor behavior of $options read.retain). And yes, with all of my own original code, I always assume that the ITEM is undefined if the read fails and I always set the ITEM to null. But again, this is code I inherited and have to deal with the runtime aspect of something not working correctly under some unknown circumstance. I'm not sure how long this issue has been present since I just happen to go into this one screen and notice that a field that should be empty suddenly had a zero in it. Upon further investigation, I'm able to see that the ITEM record was not being left NULL by the READ statement in this particular case. Over the holiday break I'm hoping I can come up with some sort of concise reproducible case that anyone can execute to see the issue. If it was happening everywhere, it would be pretty easy, but so far I can only see this scenario in one screen and with the combination of a COMMON variable and a READU statement. If I replace the variable being used with a local variable, the logic works as expected; leaving the ITEM null as it should. If I change the READU to a READ it works. Sounds like a runtime bug to me. -Troy -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Mecki Foerthmann Sent: Wednesday, December 23, 2009 12:34 AM To: U2 Users List Subject: Re: [U2] [UV] odd problem with read statement assigning variable with random data with else clause in pick flavor Hi Firstly READU will not execute the ELSE clause when the item is locked. It will just sit there and wait for the lock to be released. Regardless if it is a bug or not, your piece of code just doesn't make sense. What do you actually try to achieve? You try to read a record and when it doesn't exist you want to set the variable to null, right? So you use READU CITEM FROM FILE THEN ... END ELSE CITEM = '' instead of CITEM = '' READU CITEM FROM FILE THEN ... END and your problem is solved. I always use the ELSE clause with any READ BTW Regards Mecki ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UV] odd problem with read statement assigning variable with random data with else clause in pick flavor
Troy, The things that stick out to me about this, is that CITEM is a common, it has changed values and it hasn't been reproduced outside of the 4gl code. I would look into the common statements of the code surrounding and including the code that you have isolated this problem to and verify that they all contain the same variables and in the same order. If the common variables order has been mixed up than CITEM is being assigned some other variables value, perhaps a screen control value, since its and escape sequence. Normally common's are defined in an INCLUDE file, so if most programs have the include file, check those that don't, if any. Also, is it possible that F.FILE has a trigger associated with it that might be manipulating the result of CITEM? The other thing that I would check out would be the integrity of F.FILE, has the file been corrupted? I'm guessing not, but one more thing to eliminate. I know that these don't explain why it would happen on Readu and not Read, but they are worth checking out. Good Luck and Happy Holidays. Curt Stewart TRI-SYS Consulting -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Buss, Troy (Logitek Systems) Sent: Tuesday, December 22, 2009 3:32 PM To: U2 Users List Subject: Re: [U2] [UV] odd problem with read statement assigning variable with random data with else clause in pick flavor Thanks for the replies... In this example I was using, the ID was not on file, so it would not have taken the LOCKED clause. I just added the locked clause to my actual failing code to test the theory and it still takes the ELSE clause because the record is truly not on file. I tried George's idea of using named common and the problem still happens. One last clarification, the problem seems to occur if the READ statement is a READU. If the statement is a regular READ, it does not happen. -Troy -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of David Jordan Sent: Tuesday, December 22, 2009 1:23 PM To: U2 Users List Subject: Re: [U2] [UV] odd problem with read statement assigning variablewith random data with else clause in pick flavor Hi Troy The problem with that code is that the else clause is taken when the record is locked. You are assuming if the else clause is taken that the record does not exist, which is not a safe assumption. I would suggest Readu citem from fv, key locked * locked options End then * then options End else Citem = end -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Buss, Troy (Logitek Systems) Sent: Wednesday, 23 December 2009 7:59 AM To: u2-users@listserver.u2ug.org Subject: [U2] [UV] odd problem with read statement assigning variable with random data with else clause in pick flavor We are running universe 10.2.10 in pick flavor. I have a program (part of a 4gl subroutine) that simplified does the following: CITEM = READU CITEM FROM F.FILE, CID THEN END ELSE IF CITEM # THEN PRINT CITEM IS NOT NULL! END According to the documentation, when running in pick flavor, the value of CITEM is unchanged if the read fails. What happens is that CITEM is sometimes assigned to a random value and not NULL. Right now it is being assigned to zero. Last week, this same CITEM was being assigned to an escape sequence (about 8 characters long) when the read failed. CITEM is a non-named common variable. This issues does NOT happen if CITEM is not a common variable. The result also has varied if I use READU vs READ. Clearly there is a bug here in retaining the value of CITEM with a READ statement in pick flavor. Unfortunately, I have not been able to create a simple example to reproduce this problem outside of the 4gl. And this does not happen in all the code, only in one section so far and IS reproducible in this one case from logon session to logon session. Any ideas? -Troy ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.722 / Virus Database: 270.14.117/2581 - Release Date: 12/22/09 02:09:00 ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
[U2] [UV] odd problem with read statement assigning variable with random data with else clause in pick flavor
We are running universe 10.2.10 in pick flavor. I have a program (part of a 4gl subroutine) that simplified does the following: CITEM = READU CITEM FROM F.FILE, CID THEN END ELSE IF CITEM # THEN PRINT CITEM IS NOT NULL! END According to the documentation, when running in pick flavor, the value of CITEM is unchanged if the read fails. What happens is that CITEM is sometimes assigned to a random value and not NULL. Right now it is being assigned to zero. Last week, this same CITEM was being assigned to an escape sequence (about 8 characters long) when the read failed. CITEM is a non-named common variable. This issues does NOT happen if CITEM is not a common variable. The result also has varied if I use READU vs READ. Clearly there is a bug here in retaining the value of CITEM with a READ statement in pick flavor. Unfortunately, I have not been able to create a simple example to reproduce this problem outside of the 4gl. And this does not happen in all the code, only in one section so far and IS reproducible in this one case from logon session to logon session. Any ideas? -Troy ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UV] odd problem with read statement assigning variable with random data with else clause in pick flavor
Does it happen if it's a named common? If it doesn't, then can you make all your unnamed commons - /noname/ ? -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users- boun...@listserver.u2ug.org] On Behalf Of Buss, Troy (Logitek Systems) Sent: Tuesday, December 22, 2009 3:59 PM To: u2-users@listserver.u2ug.org Subject: [U2] [UV] odd problem with read statement assigning variable with random data with else clause in pick flavor We are running universe 10.2.10 in pick flavor. CITEM is a non-named common variable. This issues does NOT happen if CITEM is not a common variable. Any ideas? -Troy ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UV] odd problem with read statement assigning variable with random data with else clause in pick flavor
Hi Troy The problem with that code is that the else clause is taken when the record is locked. You are assuming if the else clause is taken that the record does not exist, which is not a safe assumption. I would suggest Readu citem from fv, key locked * locked options End then * then options End else Citem = end -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Buss, Troy (Logitek Systems) Sent: Wednesday, 23 December 2009 7:59 AM To: u2-users@listserver.u2ug.org Subject: [U2] [UV] odd problem with read statement assigning variable with random data with else clause in pick flavor We are running universe 10.2.10 in pick flavor. I have a program (part of a 4gl subroutine) that simplified does the following: CITEM = READU CITEM FROM F.FILE, CID THEN END ELSE IF CITEM # THEN PRINT CITEM IS NOT NULL! END According to the documentation, when running in pick flavor, the value of CITEM is unchanged if the read fails. What happens is that CITEM is sometimes assigned to a random value and not NULL. Right now it is being assigned to zero. Last week, this same CITEM was being assigned to an escape sequence (about 8 characters long) when the read failed. CITEM is a non-named common variable. This issues does NOT happen if CITEM is not a common variable. The result also has varied if I use READU vs READ. Clearly there is a bug here in retaining the value of CITEM with a READ statement in pick flavor. Unfortunately, I have not been able to create a simple example to reproduce this problem outside of the 4gl. And this does not happen in all the code, only in one section so far and IS reproducible in this one case from logon session to logon session. Any ideas? -Troy ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UV] odd problem with read statement assigning variable with random data with else clause in pick flavor
Thanks for the replies... In this example I was using, the ID was not on file, so it would not have taken the LOCKED clause. I just added the locked clause to my actual failing code to test the theory and it still takes the ELSE clause because the record is truly not on file. I tried George's idea of using named common and the problem still happens. One last clarification, the problem seems to occur if the READ statement is a READU. If the statement is a regular READ, it does not happen. -Troy -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of David Jordan Sent: Tuesday, December 22, 2009 1:23 PM To: U2 Users List Subject: Re: [U2] [UV] odd problem with read statement assigning variablewith random data with else clause in pick flavor Hi Troy The problem with that code is that the else clause is taken when the record is locked. You are assuming if the else clause is taken that the record does not exist, which is not a safe assumption. I would suggest Readu citem from fv, key locked * locked options End then * then options End else Citem = end -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Buss, Troy (Logitek Systems) Sent: Wednesday, 23 December 2009 7:59 AM To: u2-users@listserver.u2ug.org Subject: [U2] [UV] odd problem with read statement assigning variable with random data with else clause in pick flavor We are running universe 10.2.10 in pick flavor. I have a program (part of a 4gl subroutine) that simplified does the following: CITEM = READU CITEM FROM F.FILE, CID THEN END ELSE IF CITEM # THEN PRINT CITEM IS NOT NULL! END According to the documentation, when running in pick flavor, the value of CITEM is unchanged if the read fails. What happens is that CITEM is sometimes assigned to a random value and not NULL. Right now it is being assigned to zero. Last week, this same CITEM was being assigned to an escape sequence (about 8 characters long) when the read failed. CITEM is a non-named common variable. This issues does NOT happen if CITEM is not a common variable. The result also has varied if I use READU vs READ. Clearly there is a bug here in retaining the value of CITEM with a READ statement in pick flavor. Unfortunately, I have not been able to create a simple example to reproduce this problem outside of the 4gl. And this does not happen in all the code, only in one section so far and IS reproducible in this one case from logon session to logon session. Any ideas? -Troy ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
