Re: [U2] List Changes?
Larry: 1. Thanks for writing. 2. We started to use Goole Mail a few months ago. 3. I only see inbound filtration settings. 4. While I also use Outlook 2013... a lot of times when I am sending... including this time... I have been using the gMail web client. 5. I hope that this message arrives there. 6. Perhaps I am being blocked for my prior transgressions. Regards, --Bill -- William J. Brutzman Manager, IT HK MetalCraft Mfg Corp 35 Industrial Road Lodi NJ 07644-2607 973.471.7770 x145 bi...@hkmetalcraft.com ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] List Changes?
Hi Bill, This made it to the list, and was delivered. Did you get a copy of it? --Larry Larry Hiscock Moderator Larry: 1. Thanks for writing. 2. We started to use Goole Mail a few months ago. 3. I only see inbound filtration settings. 4. While I also use Outlook 2013... a lot of times when I am sending... including this time... I have been using the gMail web client. 5. I hope that this message arrives there. 6. Perhaps I am being blocked for my prior transgressions. Regards, --Bill -- William J. Brutzman Manager, IT HK MetalCraft Mfg Corp 35 Industrial Road Lodi NJ 07644-2607 973.471.7770 x145 bi...@hkmetalcraft.com ___ 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] List Changes?
LH: Thanks for writing. No... I did not see my original post appear... both in Outlook 2013 and the gMail web client. I presume that this is a Google Mail thing. I expect to contact Google tech support on it. --Bill On Thu, Jul 25, 2013 at 11:43 AM, lar...@wcs-corp.com wrote: Hi Bill, This made it to the list, and was delivered. Did you get a copy of it? --Larry Larry Hiscock Moderator Larry: 1. Thanks for writing. 2. We started to use Goole Mail a few months ago. 3. I only see inbound filtration settings. 4. While I also use Outlook 2013... a lot of times when I am sending... including this time... I have been using the gMail web client. 5. I hope that this message arrives there. 6. Perhaps I am being blocked for my prior transgressions. Regards, --Bill -- William J. Brutzman Manager, IT HK MetalCraft Mfg Corp 35 Industrial Road Lodi NJ 07644-2607 973.471.7770 x145 bi...@hkmetalcraft.com ___ 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 -- William J. Brutzman Manager, IT HK MetalCraft Mfg Corp 35 Industrial Road Lodi NJ 07644-2607 973.471.7770 x145 bi...@hkmetalcraft.com ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
[U2] [UD] BASIC Code Failing
We've been having an anomaly that has occurred over the past 7 years we've been using UniData on Windows. Yesterday one of the accounts on our ASP server, that contains about 30 accounts, had a billing issue. This issue was created because a single BASIC program didn't run a couple of lines of code, thus a particular type of charge wasn't created for anyone on this account. The BASIC code is compiled in an application account then cataloged locally in each account (a pointer to the program file exists on every account). When I make a copy of this particular account, then run the offending program in it, I see the same problem. When I put a DEBUG statement (in the offending program) just above where I suspect the problem occurs, recompile then rerun it, there is no problem. After futzing around with placing the DEBUG statement in several different locations, with no further issue, I remove the DEBUG statement and finally re-compile the offending program. I've changed nothing in the program, but it now works. This particular program runs maybe 250,000 billings every month with nothing wrong happening. In fact, I haven't seen this problem in this billing program for the past seven years, which means that maybe over 20 million transactions have been created with no issues. This happens about once every six months or so on one BASIC program or another, where I look at an offending program, see something like five lines of code writing to five different files, and the issue is the last two lines didn't execute. When I put a DEBUG into the program everything works fine. When I remove the DEBUG statement and recompile everything works fine from then on. Has anyone else seen this? Maybe there's something I should do to prevent this. Bill ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UD] BASIC Code Failing
Put the five into a single transaction. You will never see the issue again -Original Message- From: Bill Haskett wphask...@advantos.net To: U2 Mail List U2-users@listserver.u2ug.org Sent: Thu, Jul 25, 2013 12:25 pm Subject: [U2] [UD] BASIC Code Failing We've been having an anomaly that has occurred over the past 7 years we've been using UniData on Windows. Yesterday one of the accounts on our ASP server, that contains about 30 accounts, had a billing issue. This issue was created because a single BASIC program didn't run a couple of lines of code, thus a particular type of charge wasn't created for anyone on this account. The BASIC code is compiled in an application account then cataloged locally in each account (a pointer to the program file exists on every account). When I make a copy of this particular account, then run the offending program in it, I see the same problem. When I put a DEBUG statement (in the offending program) just above where I suspect the problem occurs, recompile then rerun it, there is no problem. After futzing around with placing the DEBUG statement in several different locations, with no further issue, I remove the DEBUG statement and finally re-compile the offending program. I've changed nothing in the program, but it now works. This particular program runs maybe 250,000 billings every month with nothing wrong happening. In fact, I haven't seen this problem in this billing program for the past seven years, which means that maybe over 20 million transactions have been created with no issues. This happens about once every six months or so on one BASIC program or another, where I look at an offending program, see something like five lines of code writing to five different files, and the issue is the last two lines didn't execute. When I put a DEBUG into the program everything works fine. When I remove the DEBUG statement and recompile everything works fine from then on. Has anyone else seen this? Maybe there's something I should do to prevent this. Bill ___ 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] [UD] BASIC Code Failing
Bill, at Pick Systems we occasionally saw issues like this, where the object code would behave differently if specific statements (their opcodes/tokens) were broken across frame boundaries. Until DBMS patches become available, the problem could be avoided with some carefully-placed NULL statements. I've seen this with RPL too, for exactly the same reasons. I know nothing of U2 internals but the internals are of course similar. Unfortunately without a confirmed cause/effect scenario defined by engineers, it's a crap shoot as to whether inserting NULLs will help, or where they can be inserted to ensure they work. I suggest you contact Rocket and ask them to pursue this as a byte-level issue in your object code. Sending them the code might not help if they test in an environment that's different from your own. They need to see it on your system. I'm just trying to save you some wasted diagnostic time... Best, T From: Bill Haskett ... a single BASIC program didn't run a couple of lines of code... ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] List Changes?
my google mail on both my galaxy s2 as well as desktop and laptop are iffy loads of sending and receiving errors with delays as much as days i have a friend with stuff in her outbox from a month ago... otoh, it is free On 7/25/2013 11:08 AM, William Brutzman wrote: LH: Thanks for writing. No... I did not see my original post appear... both in Outlook 2013 and the gMail web client. I presume that this is a Google Mail thing. I expect to contact Google tech support on it. --Bill On Thu, Jul 25, 2013 at 11:43 AM, lar...@wcs-corp.com wrote: Hi Bill, This made it to the list, and was delivered. Did you get a copy of it? --Larry Larry Hiscock Moderator Larry: 1. Thanks for writing. 2. We started to use Goole Mail a few months ago. 3. I only see inbound filtration settings. 4. While I also use Outlook 2013... a lot of times when I am sending... including this time... I have been using the gMail web client. 5. I hope that this message arrives there. 6. Perhaps I am being blocked for my prior transgressions. Regards, --Bill -- William J. Brutzman Manager, IT HK MetalCraft Mfg Corp 35 Industrial Road Lodi NJ 07644-2607 973.471.7770 x145 bi...@hkmetalcraft.com ___ 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] [UD] BASIC Code Failing
I agree with Tony. I once had a program that my fix was just adding a JUNK = 0 line near the top of the program. With that do-nothing line the program worked. Comment the line out or remove it completely and the program seemed to skip lines of code. This was a LONG time ago, though. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno Sent: Thursday, July 25, 2013 1:05 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] [UD] BASIC Code Failing Bill, at Pick Systems we occasionally saw issues like this, where the object code would behave differently if specific statements (their opcodes/tokens) were broken across frame boundaries. Until DBMS patches become available, the problem could be avoided with some carefully-placed NULL statements. I've seen this with RPL too, for exactly the same reasons. I know nothing of U2 internals but the internals are of course similar. Unfortunately without a confirmed cause/effect scenario defined by engineers, it's a crap shoot as to whether inserting NULLs will help, or where they can be inserted to ensure they work. I suggest you contact Rocket and ask them to pursue this as a byte-level issue in your object code. Sending them the code might not help if they test in an environment that's different from your own. They need to see it on your system. I'm just trying to save you some wasted diagnostic time... Best, T From: Bill Haskett ... a single BASIC program didn't run a couple of lines of code... ___ 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] [UD] BASIC Code Failing
I have seen this recently with either UNIVERSE or UNIDATA. I don't remember which. I have very very rarely seen this happen in 26 years. I believe it is a glitch in the compiler or in the RUN command. I was able to rewrite the offending part of the program and it would work. I wish I had the example handy. The following is not an actual example, but will allow you to understand what I did to fix it: Let's say you found a section of code that behaves strange and you confirmed that there is absolutely nothing wrong with it. Here's the existing logic: 0001: I=0;VM=CHAR(253);STRING='' 0002: 10* 0003: STRING:=VM 0004: I=I+1 0005: IF I10 THEN GOTO 10 Simply rewrite and even try restructuring it slightly. For example: 0001: I=0 0002: VM=CHAR(253) 0003: STRING='' 0004: FOR I=1 TO 10 0005:STRING=STRING:VM 0006: NEXT I 0007: * I think I even had it happen once on one system that failed, I did the above and it worked. But at a later point, I put the code back and it worked fine. This might actually be a hardware problem in disguise. In the old days, there was a program that would write blocks of data to a tape. A block of 512 letter As, then a block of 512 letter Bs, etc. Then it would rewind and read it back it. If the blocks had anything different when they read it in, it would complain that there was a tape problem (bad tape, dirty tape heads, bad tape controller card, etc.). It might be wise to run an overnight memory test using a diagnostic program. I have been able to do in that in the past and detect hard to find memory problems. For example, you run the quick memory test and it checks out okay. You run it overnight over and over, and it eventually finds the intermittent memory problem.Keep in mind that with many virtual memory systems (all PICK-type systems are), you are not looking at memory chip problems, but hard drive problems. So in some cases, this means the hard drive might have a bad spot or intermittent problem. Please let us know what you find out. Or perhaps post the program for us to take a look at and sharpen our skills even more. Thanks, Robert Norman ROBERT NORMAN AND ASSOCIATES 23441 Golden Springs Dr., #289, Diamond Bar, CA 91765 (951) 541-1668 i...@keyway.net mailto:i...@keyway.net http://users.keyway.net/~ice/ http://users.keyway.net/%7Eice/ Affordable UNIVERSE programming services for PICK/BASIC, DATA/BASIC, UniVerse Basic, UniBasic, R/BASIC, jBC. On 7/25/2013 12:25 PM, Bill Haskett wrote: We've been having an anomaly that has occurred over the past 7 years we've been using UniData on Windows. Yesterday one of the accounts on our ASP server, that contains about 30 accounts, had a billing issue. This issue was created because a single BASIC program didn't run a couple of lines of code, thus a particular type of charge wasn't created for anyone on this account. The BASIC code is compiled in an application account then cataloged locally in each account (a pointer to the program file exists on every account). When I make a copy of this particular account, then run the offending program in it, I see the same problem. When I put a DEBUG statement (in the offending program) just above where I suspect the problem occurs, recompile then rerun it, there is no problem. After futzing around with placing the DEBUG statement in several different locations, with no further issue, I remove the DEBUG statement and finally re-compile the offending program. I've changed nothing in the program, but it now works. This particular program runs maybe 250,000 billings every month with nothing wrong happening. In fact, I haven't seen this problem in this billing program for the past seven years, which means that maybe over 20 million transactions have been created with no issues. This happens about once every six months or so on one BASIC program or another, where I look at an offending program, see something like five lines of code writing to five different files, and the issue is the last two lines didn't execute. When I put a DEBUG into the program everything works fine. When I remove the DEBUG statement and recompile everything works fine from then on. Has anyone else seen this? Maybe there's something I should do to prevent this. Bill ___ 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] [UD] BASIC Code Failing
I just remembered another situation I saw once where a program behaved strangely. When we used the command to verify the object code (BVERIFY?) it didn't verify. A recompile fixed it because the object code became corrupt due to a system crash. Sometimes you can have the same thing happen, but in the catalog space. Robert Norman ROBERT NORMAN AND ASSOCIATES 23441 Golden Springs Dr., #289, Diamond Bar, CA 91765 (951) 541-1668 i...@keyway.net mailto:i...@keyway.net http://users.keyway.net/~ice/ http://users.keyway.net/%7Eice/ Affordable UNIVERSE programming services for PICK/BASIC, DATA/BASIC, UniVerse Basic, UniBasic, R/BASIC, jBC. On 7/25/2013 1:36 PM, Woodward, Bob wrote: I agree with Tony. I once had a program that my fix was just adding a JUNK = 0 line near the top of the program. With that do-nothing line the program worked. Comment the line out or remove it completely and the program seemed to skip lines of code. This was a LONG time ago, though. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno Sent: Thursday, July 25, 2013 1:05 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] [UD] BASIC Code Failing Bill, at Pick Systems we occasionally saw issues like this, where the object code would behave differently if specific statements (their opcodes/tokens) were broken across frame boundaries. Until DBMS patches become available, the problem could be avoided with some carefully-placed NULL statements. I've seen this with RPL too, for exactly the same reasons. I know nothing of U2 internals but the internals are of course similar. Unfortunately without a confirmed cause/effect scenario defined by engineers, it's a crap shoot as to whether inserting NULLs will help, or where they can be inserted to ensure they work. I suggest you contact Rocket and ask them to pursue this as a byte-level issue in your object code. Sending them the code might not help if they test in an environment that's different from your own. They need to see it on your system. I'm just trying to save you some wasted diagnostic time... Best, T From: Bill Haskett ... a single BASIC program didn't run a couple of lines of code... ___ 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] [UD] BASIC Code Failing
Robert: ...the object code became corrupt due to a system crash. That sounds plausible. Our systems rarely go down, but they do get rebooted with Windows Updates. UO connections often fail, then get picked up. Telnet often freezes or aborts (mostly client issues) then they log in again. Then there's ... It's always something...and these moron kids think everything works just fine (because they haven't lived long enough to see it not work). :-) Bill Untitled Page - Original Message - *From:* i...@keyway.net *To:* U2 Users List u2-users@listserver.u2ug.org *Date:* 7/25/2013 1:57 PM *Subject:* Re: [U2] [UD] BASIC Code Failing I just remembered another situation I saw once where a program behaved strangely. When we used the command to verify the object code (BVERIFY?) it didn't verify. A recompile fixed it because the object code became corrupt due to a system crash. Sometimes you can have the same thing happen, but in the catalog space. Robert Norman ROBERT NORMAN AND ASSOCIATES 23441 Golden Springs Dr., #289, Diamond Bar, CA 91765 (951) 541-1668 i...@keyway.net mailto:i...@keyway.net http://users.keyway.net/~ice/ http://users.keyway.net/%7Eice/ Affordable UNIVERSE programming services for PICK/BASIC, DATA/BASIC, UniVerse Basic, UniBasic, R/BASIC, jBC. On 7/25/2013 1:36 PM, Woodward, Bob wrote: I agree with Tony. I once had a program that my fix was just adding a JUNK = 0 line near the top of the program. With that do-nothing line the program worked. Comment the line out or remove it completely and the program seemed to skip lines of code. This was a LONG time ago, though. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno Sent: Thursday, July 25, 2013 1:05 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] [UD] BASIC Code Failing Bill, at Pick Systems we occasionally saw issues like this, where the object code would behave differently if specific statements (their opcodes/tokens) were broken across frame boundaries. Until DBMS patches become available, the problem could be avoided with some carefully-placed NULL statements. I've seen this with RPL too, for exactly the same reasons. I know nothing of U2 internals but the internals are of course similar. Unfortunately without a confirmed cause/effect scenario defined by engineers, it's a crap shoot as to whether inserting NULLs will help, or where they can be inserted to ensure they work. I suggest you contact Rocket and ask them to pursue this as a byte-level issue in your object code. Sending them the code might not help if they test in an environment that's different from your own. They need to see it on your system. I'm just trying to save you some wasted diagnostic time... Best, T From: Bill Haskett ... a single BASIC program didn't run a couple of lines of code... ___ 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] [UD] BASIC Code Failing
As always, thanks G-Man! I can't replicate it. It just comes up every six months (or so) with something totally different happening within our application, not to everybody, but to someone. The testing is always the same; test to confirm, put in the DEBUG, recompile, test, confirm fix, take out DEBUG, recompile, test to confirm fix, then move on. In the meantime, hundreds of thousands of transactions have taken place with no problems. All I can say is; it could be worse! :-) Bill - Original Message - *From:* 3xk547...@sneakemail.com *To:* u2-users@listserver.u2ug.org *Date:* 7/25/2013 1:04 PM *Subject:* Re: [U2] [UD] BASIC Code Failing Bill, at Pick Systems we occasionally saw issues like this, where the object code would behave differently if specific statements (their opcodes/tokens) were broken across frame boundaries. Until DBMS patches become available, the problem could be avoided with some carefully-placed NULL statements. I've seen this with RPL too, for exactly the same reasons. I know nothing of U2 internals but the internals are of course similar. Unfortunately without a confirmed cause/effect scenario defined by engineers, it's a crap shoot as to whether inserting NULLs will help, or where they can be inserted to ensure they work. I suggest you contact Rocket and ask them to pursue this as a byte-level issue in your object code. Sending them the code might not help if they test in an environment that's different from your own. They need to see it on your system. I'm just trying to save you some wasted diagnostic time... Best, T From: Bill Haskett ... a single BASIC program didn't run a couple of lines of code... ___ 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] [UD] BASIC Code Failing
You can turn off automatic reboots. -Original Message- From: Bill Haskett wphask...@advantos.net To: U2 Users List u2-users@listserver.u2ug.org Sent: Thu, Jul 25, 2013 3:11 pm Subject: Re: [U2] [UD] BASIC Code Failing Robert: ...the object code became corrupt due to a system crash. That sounds plausible. Our systems rarely go down, but they do get rebooted with Windows Updates. UO connections often fail, then get picked up. Telnet often freezes or aborts (mostly client issues) then they log in again. Then there's ... It's always something...and these moron kids think everything works just fine (because they haven't lived long enough to see it not work). :-) Bill Untitled Page - Original Message - *From:* i...@keyway.net *To:* U2 Users List u2-users@listserver.u2ug.org *Date:* 7/25/2013 1:57 PM *Subject:* Re: [U2] [UD] BASIC Code Failing I just remembered another situation I saw once where a program behaved strangely. When we used the command to verify the object code (BVERIFY?) it didn't verify. A recompile fixed it because the object code became corrupt due to a system crash. Sometimes you can have the same thing happen, but in the catalog space. Robert Norman ROBERT NORMAN AND ASSOCIATES 23441 Golden Springs Dr., #289, Diamond Bar, CA 91765 (951) 541-1668 i...@keyway.net mailto:i...@keyway.net http://users.keyway.net/~ice/ http://users.keyway.net/%7Eice/ Affordable UNIVERSE programming services for PICK/BASIC, DATA/BASIC, UniVerse Basic, UniBasic, R/BASIC, jBC. On 7/25/2013 1:36 PM, Woodward, Bob wrote: I agree with Tony. I once had a program that my fix was just adding a JUNK = 0 line near the top of the program. With that do-nothing line the program worked. Comment the line out or remove it completely and the program seemed to skip lines of code. This was a LONG time ago, though. -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno Sent: Thursday, July 25, 2013 1:05 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] [UD] BASIC Code Failing Bill, at Pick Systems we occasionally saw issues like this, where the object code would behave differently if specific statements (their opcodes/tokens) were broken across frame boundaries. Until DBMS patches become available, the problem could be avoided with some carefully-placed NULL statements. I've seen this with RPL too, for exactly the same reasons. I know nothing of U2 internals but the internals are of course similar. Unfortunately without a confirmed cause/effect scenario defined by engineers, it's a crap shoot as to whether inserting NULLs will help, or where they can be inserted to ensure they work. I suggest you contact Rocket and ask them to pursue this as a byte-level issue in your object code. Sending them the code might not help if they test in an environment that's different from your own. They need to see it on your system. I'm just trying to save you some wasted diagnostic time... Best, T From: Bill Haskett ... a single BASIC program didn't run a couple of lines of code... ___ 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] [UD] BASIC Code Failing
I recall seeing and reporting this issue back in UniData 3.5.2 on Solaris. I recall seeing and reporting this issue back in UniData 5.something on AIX. Both times, support calls were opened. Both times, as we had done much of what you have already done, the call was closed as No Fault Found because we were unable to reproduce the fault. There are also prior reports of this or a similar issue in the archives here (to the best of my recollection). None of these occurred after an upgrade or update to the system or UniData; administratively, the machines had been stagnant for a while. Best of luck! Regards, Bob Wyatt -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett Sent: Thursday, July 25, 2013 6:11 PM To: U2 Users List Subject: Re: [U2] [UD] BASIC Code Failing As always, thanks G-Man! I can't replicate it. It just comes up every six months (or so) with something totally different happening within our application, not to everybody, but to someone. The testing is always the same; test to confirm, put in the DEBUG, recompile, test, confirm fix, take out DEBUG, recompile, test to confirm fix, then move on. In the meantime, hundreds of thousands of transactions have taken place with no problems. All I can say is; it could be worse! :-) Bill - Original Message - *From:* 3xk547...@sneakemail.com *To:* u2-users@listserver.u2ug.org *Date:* 7/25/2013 1:04 PM *Subject:* Re: [U2] [UD] BASIC Code Failing Bill, at Pick Systems we occasionally saw issues like this, where the object code would behave differently if specific statements (their opcodes/tokens) were broken across frame boundaries. Until DBMS patches become available, the problem could be avoided with some carefully-placed NULL statements. I've seen this with RPL too, for exactly the same reasons. I know nothing of U2 internals but the internals are of course similar. Unfortunately without a confirmed cause/effect scenario defined by engineers, it's a crap shoot as to whether inserting NULLs will help, or where they can be inserted to ensure they work. I suggest you contact Rocket and ask them to pursue this as a byte-level issue in your object code. Sending them the code might not help if they test in an environment that's different from your own. They need to see it on your system. I'm just trying to save you some wasted diagnostic time... Best, T From: Bill Haskett ... a single BASIC program didn't run a couple of lines of code... ___ 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] [UD] BASIC Code Failing
Do you have the two-inch lead shielding around your server room to block cosmic rays? -Original Message- From: Bob Wyatt bwyatt_...@comcast.net To: 'U2 Users List' u2-users@listserver.u2ug.org Sent: Thu, Jul 25, 2013 5:28 pm Subject: Re: [U2] [UD] BASIC Code Failing I recall seeing and reporting this issue back in UniData 3.5.2 on Solaris. I recall seeing and reporting this issue back in UniData 5.something on AIX. Both times, support calls were opened. Both times, as we had done much of what you have already done, the call was closed as No Fault Found because we were unable to reproduce the fault. There are also prior reports of this or a similar issue in the archives here (to the best of my recollection). None of these occurred after an upgrade or update to the system or UniData; administratively, the machines had been stagnant for a while. Best of luck! Regards, Bob Wyatt -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett Sent: Thursday, July 25, 2013 6:11 PM To: U2 Users List Subject: Re: [U2] [UD] BASIC Code Failing As always, thanks G-Man! I can't replicate it. It just comes up every six months (or so) with something totally different happening within our application, not to everybody, but to someone. The testing is always the same; test to confirm, put in the DEBUG, recompile, test, confirm fix, take out DEBUG, recompile, test to confirm fix, then move on. In the meantime, hundreds of thousands of transactions have taken place with no problems. All I can say is; it could be worse! :-) Bill - Original Message - *From:* 3xk547...@sneakemail.com *To:* u2-users@listserver.u2ug.org *Date:* 7/25/2013 1:04 PM *Subject:* Re: [U2] [UD] BASIC Code Failing Bill, at Pick Systems we occasionally saw issues like this, where the object code would behave differently if specific statements (their opcodes/tokens) were broken across frame boundaries. Until DBMS patches become available, the problem could be avoided with some carefully-placed NULL statements. I've seen this with RPL too, for exactly the same reasons. I know nothing of U2 internals but the internals are of course similar. Unfortunately without a confirmed cause/effect scenario defined by engineers, it's a crap shoot as to whether inserting NULLs will help, or where they can be inserted to ensure they work. I suggest you contact Rocket and ask them to pursue this as a byte-level issue in your object code. Sending them the code might not help if they test in an environment that's different from your own. They need to see it on your system. I'm just trying to save you some wasted diagnostic time... Best, T From: Bill Haskett ... a single BASIC program didn't run a couple of lines of code... ___ 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] [UD] BASIC Code Failing
We never knew which guys to ask for - the guys in the black suits or the white suits? -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson Sent: Thursday, July 25, 2013 8:36 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] [UD] BASIC Code Failing Do you have the two-inch lead shielding around your server room to block cosmic rays? -Original Message- From: Bob Wyatt bwyatt_...@comcast.net To: 'U2 Users List' u2-users@listserver.u2ug.org Sent: Thu, Jul 25, 2013 5:28 pm Subject: Re: [U2] [UD] BASIC Code Failing I recall seeing and reporting this issue back in UniData 3.5.2 on Solaris. I recall seeing and reporting this issue back in UniData 5.something on AIX. Both times, support calls were opened. Both times, as we had done much of what you have already done, the call was closed as No Fault Found because we were unable to reproduce the fault. There are also prior reports of this or a similar issue in the archives here (to the best of my recollection). None of these occurred after an upgrade or update to the system or UniData; administratively, the machines had been stagnant for a while. Best of luck! Regards, Bob Wyatt -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett Sent: Thursday, July 25, 2013 6:11 PM To: U2 Users List Subject: Re: [U2] [UD] BASIC Code Failing As always, thanks G-Man! I can't replicate it. It just comes up every six months (or so) with something totally different happening within our application, not to everybody, but to someone. The testing is always the same; test to confirm, put in the DEBUG, recompile, test, confirm fix, take out DEBUG, recompile, test to confirm fix, then move on. In the meantime, hundreds of thousands of transactions have taken place with no problems. All I can say is; it could be worse! :-) Bill - Original Message - *From:* 3xk547...@sneakemail.com *To:* u2-users@listserver.u2ug.org *Date:* 7/25/2013 1:04 PM *Subject:* Re: [U2] [UD] BASIC Code Failing Bill, at Pick Systems we occasionally saw issues like this, where the object code would behave differently if specific statements (their opcodes/tokens) were broken across frame boundaries. Until DBMS patches become available, the problem could be avoided with some carefully-placed NULL statements. I've seen this with RPL too, for exactly the same reasons. I know nothing of U2 internals but the internals are of course similar. Unfortunately without a confirmed cause/effect scenario defined by engineers, it's a crap shoot as to whether inserting NULLs will help, or where they can be inserted to ensure they work. I suggest you contact Rocket and ask them to pursue this as a byte-level issue in your object code. Sending them the code might not help if they test in an environment that's different from your own. They need to see it on your system. I'm just trying to save you some wasted diagnostic time... Best, T From: Bill Haskett ... a single BASIC program didn't run a couple of lines of code... ___ 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] [UD] BASIC Code Failing
don't worry about the color of the suit. It's the hat that matters. I think the choices are black, white, and red. On Jul 25, 2013, at 8:40 PM, Bob Wyatt bwyatt_...@comcast.net wrote: We never knew which guys to ask for - the guys in the black suits or the white suits? -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Wjhonson Sent: Thursday, July 25, 2013 8:36 PM To: u2-users@listserver.u2ug.org Subject: Re: [U2] [UD] BASIC Code Failing Do you have the two-inch lead shielding around your server room to block cosmic rays? -Original Message- From: Bob Wyatt bwyatt_...@comcast.net To: 'U2 Users List' u2-users@listserver.u2ug.org Sent: Thu, Jul 25, 2013 5:28 pm Subject: Re: [U2] [UD] BASIC Code Failing I recall seeing and reporting this issue back in UniData 3.5.2 on Solaris. I recall seeing and reporting this issue back in UniData 5.something on AIX. Both times, support calls were opened. Both times, as we had done much of what you have already done, the call was closed as No Fault Found because we were unable to reproduce the fault. There are also prior reports of this or a similar issue in the archives here (to the best of my recollection). None of these occurred after an upgrade or update to the system or UniData; administratively, the machines had been stagnant for a while. Best of luck! Regards, Bob Wyatt -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett Sent: Thursday, July 25, 2013 6:11 PM To: U2 Users List Subject: Re: [U2] [UD] BASIC Code Failing As always, thanks G-Man! I can't replicate it. It just comes up every six months (or so) with something totally different happening within our application, not to everybody, but to someone. The testing is always the same; test to confirm, put in the DEBUG, recompile, test, confirm fix, take out DEBUG, recompile, test to confirm fix, then move on. In the meantime, hundreds of thousands of transactions have taken place with no problems. All I can say is; it could be worse! :-) Bill - Original Message - *From:* 3xk547...@sneakemail.com *To:* u2-users@listserver.u2ug.org *Date:* 7/25/2013 1:04 PM *Subject:* Re: [U2] [UD] BASIC Code Failing Bill, at Pick Systems we occasionally saw issues like this, where the object code would behave differently if specific statements (their opcodes/tokens) were broken across frame boundaries. Until DBMS patches become available, the problem could be avoided with some carefully-placed NULL statements. I've seen this with RPL too, for exactly the same reasons. I know nothing of U2 internals but the internals are of course similar. Unfortunately without a confirmed cause/effect scenario defined by engineers, it's a crap shoot as to whether inserting NULLs will help, or where they can be inserted to ensure they work. I suggest you contact Rocket and ask them to pursue this as a byte-level issue in your object code. Sending them the code might not help if they test in an environment that's different from your own. They need to see it on your system. I'm just trying to save you some wasted diagnostic time... Best, T From: Bill Haskett ... a single BASIC program didn't run a couple of lines of code... ___ 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 ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
