Re: [U2] [UD] BASIC Code Failing

[Wjhonson]

If you were to copy your source code to another location and then compile and 
compare the object, would the two objects be the same?


 

 

 

-Original Message-
From: Brian Leach 
To: 'U2 Users List' 
Sent: Thu, Aug 1, 2013 4:10 am
Subject: Re: [U2] [UD] BASIC Code Failing


David

I add version stamps to my code that compile into the object code, so at
least I can easily check that the source and object (including that in
catdir) matches what I expect. That's at least a small and easy step in the
right direction, though that doesn't rule out changes that don't update the
stamp of course. 

The stamps are always updated by my cutting routines and then the items are
then added to source control as part of the cut... If you did something
similar you can always diff what you've got against your source code control
system rather than reinventing the wheel.

Brian



-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Hona, David
Sent: 01 August 2013 10:49
To: U2 Users List
Subject: Re: [U2] [UD] BASIC Code Failing

In UV we're had similar strange problems with seemingly unchanged
source/object code - not work as per normal and things going amiss for no
good reason...once we found the object code in BP and the catalog space were
mismatched and simply re-catalog'd it. Another time we re-compiled a program
- as it was always invoked via RUN BP PROGNAME... in both instances the
problem seem to go away.  This was in a controlled product environment so
it's in highly unlikely someone could of or would've changed the code...

In UV you can do a VCATALOG to verify the BASIC object to what is actually
catalogued...

All of these issues made me wonder if our implementation routines need to
have a more robust. More robust in terms of storing some control information
for both pre/post verification - hence being able to detect 'unauthorised
changes' through the various stages. This could include calculating and
storing (say) MD5 (etc) hashes on the source and object to cross verify
changes. Hence, make it more easy to detect object or source changes outside
the authorised/control deployment process... without having to go through
every single file and comparing to tape or disk backups, etc., etc.


-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Wednesday, 31 July 2013 6:06 AM
To: U2 Users List
Subject: Re: [U2] [UD] BASIC Code Failing

John:

That's an interesting thought.  We do backups of the application account
every night, so I do have the last 10 days object code in a backup (plus the
last four months weekly backups).  I'll look at this the next time it
happens.  Thanks,

Bill
Untitled Page



- Original Message -
*From:* jhes...@momtex.com
*To:* U2 Users List 
*Date:* 7/30/2013 11:01 AM
*Subject:* Re: [U2] [UD] BASIC Code Failing
> I would also consider the possibility of data corruption at the 
> hardware level.  Granted, I would expect that you'd also occasionally 
> find anomalies within your source code and data files if this were the 
> case, but I don't know how your filesystems are set up.  If the object 
> code has become corrupt, that would explain why recompiling fixes the 
> problem.  The newly created object code will be stored on a new 
> location in the filesystem.  Fortunately this possibility is very easy 
> to test for.  Just make a copy of your application account on 
> alternate storage and wait for the problem to recur.  When it does, 
> open the live object file and your backup copy in an editor with diff 
> capability (Notepad++ is a good one) and see if they still match.
>
> -John


** IMPORTANT MESSAGE *   
This e-mail message is intended only for the addressee(s) and contains
information which may be confidential. 
If you are not the intended recipient please advise the sender by return
email, do not use or disclose the contents, and delete the message and any
attachments from your system. Unless specifically indicated, this email does
not constitute formal advice or commitment by the sender or the Commonwealth
Bank of Australia (ABN 48 123 123 124) or its subsidiaries. 
We can be contacted through our web site: commbank.com.au. 
If you no longer wish to receive commercial electronic messages from us,
please reply to this e-mail by typing Unsubscribe in the subject line. 
**



___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] [UD] BASIC Code Failing

[Hona, David]

Hi Brian

That's a good idea to do what you have done and do in mvStamp...

I guess what I'm also look at is that the use of MD5 checksums (for example) is 
a 'well known/accepted and platform independent' mechanism to verify files are 
'as they should be'.

Hence, in theory you quickly detect changes that have occurred to the object, 
source and catalog version in simple independent way without even referencing 
back a source control system. Plus in UV BASIC you now have the ENCODE and 
ENCRYPT functions to help you check/secure your code - if you so desire - 
post-implementation.

Here's simple compilation comparison before and after...obviously you can 
extend it to the source changes in catdir, etc.


$ openssl md5 /my/PROGRAMS/BP.O/test123
MD5(/my/PROGRAMS/BP.O/test123)= 7e3743a1ac709cca2f9e1dd034e19048
$ nbasic BP test123
Compiling: Source = '/my/PROGRAMS/BP/test123, Object = 
'/my/PROGRAMS/BP.O/test123
***

Compilation Complete.
$ openssl md5 /my/PROGRAMS/BP.O/test123
MD5(/my/PROGRAMS/BP.O/test123)= 080524f5d4da1c363298e2e538d3cf49

$ openssl md5 `cat /.uvhome`/catdir/'*test123
MD5(/usr/ibm/uv/catdir/*test123)= 05b3b02a4369915e448af6837160ac8f
$


Regards,
David


-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Brian Leach
Sent: Thursday, 1 August 2013 11:13 PM
To: 'U2 Users List'
Subject: Re: [U2] [UD] BASIC Code Failing

Dale

The stamp I use assigns a dummy variable using strings that contain searchable 
keys. That means when the code is compiled these strings end up unaltered in 
the object code string table, so that they can be easily found and extracted.

For example:

VERDATA=''
   VERDATA := 'Version=001000136;'
   VERDATA := 'VerBeta=;'
   VERDATA := 'VerDate=16637;'
   VERDATA := 'VerProd=mvPDF;'
   VERDATA := 'VerTM=mvPDF;'
   VERDATA := 'VerCopy=2013 Brian Leach Consulting Limited;'
   VERDATA := 'VerCo=Brian Leach Consulting Limited;'
   VERDATA := 'VerDesc=Produce a PDF Document by merging data;'
   VERDATA := 'CatName=PDF.MERGE;'
   VERDATA := 'VerModule=GENERAL;'
   VERDATA := 'VerModVer=002003022;'
   VERDATA := 'VerHist=19 JUL 13 1.0.136 Release 2.3.22;'


A useful addition is that I have a I Descriptor that returns this, so I can 
list the source or object file and rip out these details:


LIST pdf.bp.O "PDF.MERGE" 01:02:24pm  01 Aug 2013  PAGE1
pdf.bp.O.. Version.. Version 
Description... Module Version

PDF.MERGE  1.0.136   Produce a PDF Document by merging
data 2.3.22

I did put some free code on my website to do this - look for mvStamp.

As for cutting or build scripts, these refer to anything that builds your 
software.. every site should have something to do this, to ensure a smooth and 
automated transition from test to live or for deployment.

In my case, the build process usually consists of a script written in vbscript 
(WSH) that runs the various client side builds (for Delphi, C#
etc.) then uses UniObjects to execute a server side cutting paragraph passing 
the new version number. This typically updates the version stamps, recompiles 
everything, handles any platform builds (most of my stuff runs on UniVerse, 
UniData, QM and D3), updates a README document from my task system, adds them 
all into revision control, then calls mvInstaller to build the release package. 
Then control passes back to the vbscript to assemble the setup (InstallShield 
or visual studio) and zip  the resulting setup ready for upload.

I did think about kicking off all the unit tests as well but I prefer to do 
that after a test installation.

All of which took some setting up to begin with but has saved enormous amounts 
of time and agony since.

Brian

-----Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of dale kelley
Sent: 01 August 2013 12:27
To: U2 Users List
Subject: Re: [U2] [UD] BASIC Code Failing

Brian,

Is the stamp just

VERSION = "123"  ,?

Could you explain what you mean by "cutting routines",  I've either never heard 
that term or my "old timers" is kicking in.

dale

On 08/01/2013 06:09 AM, Brian Leach wrote:
> David
>
> I add version stamps to my code that compile into the object code, so 
> at least I can easily check that the source and object (including that 
> in
> catdir) matches what I expect. That's at least a small and easy step 
> in the right direction, though that doesn't rule out changes that 
> don't updat

Re: [U2] [UD] BASIC Code Failing

[Brian Leach]

Dale

The stamp I use assigns a dummy variable using strings that contain
searchable keys. That means when the code is compiled these strings end up
unaltered in the object code string table, so that they can be easily found
and extracted.

For example:

VERDATA=''
   VERDATA := 'Version=001000136;'
   VERDATA := 'VerBeta=;'
   VERDATA := 'VerDate=16637;'
   VERDATA := 'VerProd=mvPDF;'
   VERDATA := 'VerTM=mvPDF;'
   VERDATA := 'VerCopy=2013 Brian Leach Consulting Limited;'
   VERDATA := 'VerCo=Brian Leach Consulting Limited;'
   VERDATA := 'VerDesc=Produce a PDF Document by merging data;'
   VERDATA := 'CatName=PDF.MERGE;'
   VERDATA := 'VerModule=GENERAL;'
   VERDATA := 'VerModVer=002003022;'
   VERDATA := 'VerHist=19 JUL 13 1.0.136 Release 2.3.22;'


A useful addition is that I have a I Descriptor that returns this, so I can
list the source or object file and rip out these details:


LIST pdf.bp.O "PDF.MERGE" 01:02:24pm  01 Aug 2013  PAGE1
pdf.bp.O.. Version.. Version
Description... Module Version

PDF.MERGE  1.0.136   Produce a PDF Document by merging
data 2.3.22

I did put some free code on my website to do this - look for mvStamp.

As for cutting or build scripts, these refer to anything that builds your
software.. every site should have something to do this, to ensure a smooth
and automated transition from test to live or for deployment.

In my case, the build process usually consists of a script written in
vbscript (WSH) that runs the various client side builds (for Delphi, C#
etc.) then uses UniObjects to execute a server side cutting paragraph
passing the new version number. This typically updates the version stamps,
recompiles everything, handles any platform builds (most of my stuff runs on
UniVerse, UniData, QM and D3), updates a README document from my task
system, adds them all into revision control, then calls mvInstaller to build
the release package. Then control passes back to the vbscript to assemble
the setup (InstallShield or visual studio) and zip  the resulting setup
ready for upload.

I did think about kicking off all the unit tests as well but I prefer to do
that after a test installation.

All of which took some setting up to begin with but has saved enormous
amounts of time and agony since.

Brian

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of dale kelley
Sent: 01 August 2013 12:27
To: U2 Users List
Subject: Re: [U2] [UD] BASIC Code Failing

Brian,

Is the stamp just

VERSION = "123"  ,?

Could you explain what you mean by "cutting routines",  I've either never
heard that term or my "old timers" is kicking in.

dale

On 08/01/2013 06:09 AM, Brian Leach wrote:
> David
>
> I add version stamps to my code that compile into the object code, so 
> at least I can easily check that the source and object (including that 
> in
> catdir) matches what I expect. That's at least a small and easy step 
> in the right direction, though that doesn't rule out changes that 
> don't update the stamp of course.
>
> The stamps are always updated by my cutting routines and then the 
> items are then added to source control as part of the cut... If you 
> did something similar you can always diff what you've got against your 
> source code control system rather than reinventing the wheel.
>
> Brian
>
>
>
> -Original Message-
> From: u2-users-boun...@listserver.u2ug.org
> [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Hona, David
> Sent: 01 August 2013 10:49
> To: U2 Users List
> Subject: Re: [U2] [UD] BASIC Code Failing
>
> In UV we're had similar strange problems with seemingly unchanged 
> source/object code - not work as per normal and things going amiss for 
> no good reason...once we found the object code in BP and the catalog 
> space were mismatched and simply re-catalog'd it. Another time we 
> re-compiled a program
> - as it was always invoked via RUN BP PROGNAME... in both instances 
> the problem seem to go away.  This was in a controlled product 
> environment so it's in highly unlikely someone could of or would've
changed the code...
>
> In UV you can do a VCATALOG to verify the BASIC object to what is 
> actually catalogued...
>
> All of these issues made me wonder if our implementation routines need 
> to have a more robust. More robust in terms of storing some control 
> information for both pre/post verification - hence being able to 
> detect 'unauthorised changes' through the various stages. This could 
> 

Re: [U2] [UD] BASIC Code Failing

[dale kelley]

Brian,

Is the stamp just

VERSION = "123"  ,?

Could you explain what you mean by "cutting routines",  I've either 
never heard that term or my "old timers" is kicking in.


dale

On 08/01/2013 06:09 AM, Brian Leach wrote:

David

I add version stamps to my code that compile into the object code, so at
least I can easily check that the source and object (including that in
catdir) matches what I expect. That's at least a small and easy step in the
right direction, though that doesn't rule out changes that don't update the
stamp of course.

The stamps are always updated by my cutting routines and then the items are
then added to source control as part of the cut... If you did something
similar you can always diff what you've got against your source code control
system rather than reinventing the wheel.

Brian



-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Hona, David
Sent: 01 August 2013 10:49
To: U2 Users List
Subject: Re: [U2] [UD] BASIC Code Failing

In UV we're had similar strange problems with seemingly unchanged
source/object code - not work as per normal and things going amiss for no
good reason...once we found the object code in BP and the catalog space were
mismatched and simply re-catalog'd it. Another time we re-compiled a program
- as it was always invoked via RUN BP PROGNAME... in both instances the
problem seem to go away.  This was in a controlled product environment so
it's in highly unlikely someone could of or would've changed the code...

In UV you can do a VCATALOG to verify the BASIC object to what is actually
catalogued...

All of these issues made me wonder if our implementation routines need to
have a more robust. More robust in terms of storing some control information
for both pre/post verification - hence being able to detect 'unauthorised
changes' through the various stages. This could include calculating and
storing (say) MD5 (etc) hashes on the source and object to cross verify
changes. Hence, make it more easy to detect object or source changes outside
the authorised/control deployment process... without having to go through
every single file and comparing to tape or disk backups, etc., etc.


-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Wednesday, 31 July 2013 6:06 AM
To: U2 Users List
Subject: Re: [U2] [UD] BASIC Code Failing

John:

That's an interesting thought.  We do backups of the application account
every night, so I do have the last 10 days object code in a backup (plus the
last four months weekly backups).  I'll look at this the next time it
happens.  Thanks,

Bill
Untitled Page



- Original Message -----
*From:* jhes...@momtex.com
*To:* U2 Users List
*Date:* 7/30/2013 11:01 AM
*Subject:* Re: [U2] [UD] BASIC Code Failing

I would also consider the possibility of data corruption at the
hardware level.  Granted, I would expect that you'd also occasionally
find anomalies within your source code and data files if this were the
case, but I don't know how your filesystems are set up.  If the object
code has become corrupt, that would explain why recompiling fixes the
problem.  The newly created object code will be stored on a new
location in the filesystem.  Fortunately this possibility is very easy
to test for.  Just make a copy of your application account on
alternate storage and wait for the problem to recur.  When it does,
open the live object file and your backup copy in an editor with diff
capability (Notepad++ is a good one) and see if they still match.

-John


** IMPORTANT MESSAGE *
This e-mail message is intended only for the addressee(s) and contains
information which may be confidential.
If you are not the intended recipient please advise the sender by return
email, do not use or disclose the contents, and delete the message and any
attachments from your system. Unless specifically indicated, this email does
not constitute formal advice or commitment by the sender or the Commonwealth
Bank of Australia (ABN 48 123 123 124) or its subsidiaries.
We can be contacted through our web site: commbank.com.au.
If you no longer wish to receive commercial electronic messages from us,
please reply to this e-mail by typing Unsubscribe in the subject line.
**



___
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

[Brian Leach]

David

I add version stamps to my code that compile into the object code, so at
least I can easily check that the source and object (including that in
catdir) matches what I expect. That's at least a small and easy step in the
right direction, though that doesn't rule out changes that don't update the
stamp of course. 

The stamps are always updated by my cutting routines and then the items are
then added to source control as part of the cut... If you did something
similar you can always diff what you've got against your source code control
system rather than reinventing the wheel.

Brian



-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Hona, David
Sent: 01 August 2013 10:49
To: U2 Users List
Subject: Re: [U2] [UD] BASIC Code Failing

In UV we're had similar strange problems with seemingly unchanged
source/object code - not work as per normal and things going amiss for no
good reason...once we found the object code in BP and the catalog space were
mismatched and simply re-catalog'd it. Another time we re-compiled a program
- as it was always invoked via RUN BP PROGNAME... in both instances the
problem seem to go away.  This was in a controlled product environment so
it's in highly unlikely someone could of or would've changed the code...

In UV you can do a VCATALOG to verify the BASIC object to what is actually
catalogued...

All of these issues made me wonder if our implementation routines need to
have a more robust. More robust in terms of storing some control information
for both pre/post verification - hence being able to detect 'unauthorised
changes' through the various stages. This could include calculating and
storing (say) MD5 (etc) hashes on the source and object to cross verify
changes. Hence, make it more easy to detect object or source changes outside
the authorised/control deployment process... without having to go through
every single file and comparing to tape or disk backups, etc., etc.


-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Wednesday, 31 July 2013 6:06 AM
To: U2 Users List
Subject: Re: [U2] [UD] BASIC Code Failing

John:

That's an interesting thought.  We do backups of the application account
every night, so I do have the last 10 days object code in a backup (plus the
last four months weekly backups).  I'll look at this the next time it
happens.  Thanks,

Bill
Untitled Page



- Original Message -
*From:* jhes...@momtex.com
*To:* U2 Users List 
*Date:* 7/30/2013 11:01 AM
*Subject:* Re: [U2] [UD] BASIC Code Failing
> I would also consider the possibility of data corruption at the 
> hardware level.  Granted, I would expect that you'd also occasionally 
> find anomalies within your source code and data files if this were the 
> case, but I don't know how your filesystems are set up.  If the object 
> code has become corrupt, that would explain why recompiling fixes the 
> problem.  The newly created object code will be stored on a new 
> location in the filesystem.  Fortunately this possibility is very easy 
> to test for.  Just make a copy of your application account on 
> alternate storage and wait for the problem to recur.  When it does, 
> open the live object file and your backup copy in an editor with diff 
> capability (Notepad++ is a good one) and see if they still match.
>
> -John


** IMPORTANT MESSAGE *   
This e-mail message is intended only for the addressee(s) and contains
information which may be confidential. 
If you are not the intended recipient please advise the sender by return
email, do not use or disclose the contents, and delete the message and any
attachments from your system. Unless specifically indicated, this email does
not constitute formal advice or commitment by the sender or the Commonwealth
Bank of Australia (ABN 48 123 123 124) or its subsidiaries. 
We can be contacted through our web site: commbank.com.au. 
If you no longer wish to receive commercial electronic messages from us,
please reply to this e-mail by typing Unsubscribe in the subject line. 
**



___
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

[Hona, David]

In UV we're had similar strange problems with seemingly unchanged source/object 
code - not work as per normal and things going amiss for no good reason...once 
we found the object code in BP and the catalog space were mismatched and simply 
re-catalog'd it. Another time we re-compiled a program - as it was always 
invoked via RUN BP PROGNAME... in both instances the problem seem to go away.  
This was in a controlled product environment so it's in highly unlikely someone 
could of or would've changed the code...

In UV you can do a VCATALOG to verify the BASIC object to what is actually 
catalogued...

All of these issues made me wonder if our implementation routines need to have 
a more robust. More robust in terms of storing some control information for 
both pre/post verification - hence being able to detect 'unauthorised changes' 
through the various stages. This could include calculating and storing (say) 
MD5 (etc) hashes on the source and object to cross verify changes. Hence, make 
it more easy to detect object or source changes outside the authorised/control 
deployment process... without having to go through every single file and 
comparing to tape or disk backups, etc., etc.


-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett
Sent: Wednesday, 31 July 2013 6:06 AM
To: U2 Users List
Subject: Re: [U2] [UD] BASIC Code Failing

John:

That's an interesting thought.  We do backups of the application account every 
night, so I do have the last 10 days object code in a backup (plus the last 
four months weekly backups).  I'll look at this the next time it happens.  
Thanks,

Bill
Untitled Page



- Original Message -
*From:* jhes...@momtex.com
*To:* U2 Users List 
*Date:* 7/30/2013 11:01 AM
*Subject:* Re: [U2] [UD] BASIC Code Failing
> I would also consider the possibility of data corruption at the 
> hardware level.  Granted, I would expect that you'd also occasionally 
> find anomalies within your source code and data files if this were the 
> case, but I don't know how your filesystems are set up.  If the object 
> code has become corrupt, that would explain why recompiling fixes the 
> problem.  The newly created object code will be stored on a new 
> location in the filesystem.  Fortunately this possibility is very easy 
> to test for.  Just make a copy of your application account on 
> alternate storage and wait for the problem to recur.  When it does, 
> open the live object file and your backup copy in an editor with diff 
> capability (Notepad++ is a good one) and see if they still match.
>
> -John


** IMPORTANT MESSAGE *   
This e-mail message is intended only for the addressee(s) and contains 
information which may be
confidential. 
If you are not the intended recipient please advise the sender by return email, 
do not use or
disclose the contents, and delete the message and any attachments from your 
system. Unless
specifically indicated, this email does not constitute formal advice or 
commitment by the sender
or the Commonwealth Bank of Australia (ABN 48 123 123 124) or its subsidiaries. 
We can be contacted through our web site: commbank.com.au. 
If you no longer wish to receive commercial electronic messages from us, please 
reply to this
e-mail by typing Unsubscribe in the subject line. 
**



___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] [UD] BASIC Code Failing

[Bill Haskett]

John:

That's an interesting thought.  We do backups of the application account 
every night, so I do have the last 10 days object code in a backup (plus 
the last four months weekly backups).  I'll look at this the next time 
it happens.  Thanks,


Bill
Untitled Page



- Original Message -
*From:* jhes...@momtex.com
*To:* U2 Users List 
*Date:* 7/30/2013 11:01 AM
*Subject:* Re: [U2] [UD] BASIC Code Failing

I would also consider the possibility of data corruption at the hardware
level.  Granted, I would expect that you'd also occasionally find
anomalies within your source code and data files if this were the case,
but I don't know how your filesystems are set up.  If the object code
has become corrupt, that would explain why recompiling fixes the
problem.  The newly created object code will be stored on a new location
in the filesystem.  Fortunately this possibility is very easy to test
for.  Just make a copy of your application account on alternate storage
and wait for the problem to recur.  When it does, open the live object
file and your backup copy in an editor with diff capability (Notepad++
is a good one) and see if they still match.

-John

-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 12:25 PM
To: U2 Mail List
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


___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] [UD] BASIC Code Failing

[John Hester]

I would also consider the possibility of data corruption at the hardware
level.  Granted, I would expect that you'd also occasionally find
anomalies within your source code and data files if this were the case,
but I don't know how your filesystems are set up.  If the object code
has become corrupt, that would explain why recompiling fixes the
problem.  The newly created object code will be stored on a new location
in the filesystem.  Fortunately this possibility is very easy to test
for.  Just make a copy of your application account on alternate storage
and wait for the problem to recur.  When it does, open the live object
file and your backup copy in an editor with diff capability (Notepad++
is a good one) and see if they still match.

-John

-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 12:25 PM
To: U2 Mail List
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

[Tony Gravagno]

> From: Charlie Noah 
> 1. If POLREC<6> is null, an empty value won't be inserted...
> 2. INSERT sometimes doesn't like delimited source
> 3. If POLREC<6> has multivalues itself...

Charlie, you present a valid discussion of a failure with the Insert
statement, but that might not be the problem at all. Bill Haskett's
original statement says he just inserted a DEBUG statement before the
problem line and the problem went away. We're not talking about syntax
or any one statement. We're talking about a run-time failure to
execute any random statement in your code base. The ramifications for
that are huge.

The best thing that can happen to anyone here is to find one of these
buggers in some non-critical location. The worst thing anyone can do
is to hide the condition so that the problem doesn't occur in a benign
area - that just leaves the problem undiagnosed and unresolved for
potentially critical areas in the current application or others. I
can't emphasize strongly enough how devastating a problem like this
could be ... if indeed this is the problem.

I strongly encourage any sites still covered by support to report this
issue to RS if they have a repeatable case. Diagnosing these issues in
the wild can be extremely difficult, making it easy for too many
people to get lazy, delay, defer, work-around, and not get aggressive
about the problem. But any manager of any large site here should be
thinking about how much damage an issue like this can do to their
business if it's not resolved. People who do Not see this problem in
their systems should be as assertive about seeing it resolved as those
who Do see it.

And Rocket stands to reap huge rewards in terms of customer
satisfaction if they pro-actively take steps to resolve this issue
with anyone who reports it. It doesn't make sense to avoid an
opportunity to resolve an issue for paying clients just because a
system where it's repeatable isn't currently covered.

T

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] [UD] BASIC Code Failing

[dale kelley]

On 07/26/2013 04:37 PM, Charlie Noah wrote:

Tony,

I think Bob may have a good troubleshooting technique here. It would 
be simple to eliminate causes. Line 107 has a couple of potential 
problems:


0107: SUPREC = INSERT(SUPREC,2,1,0,POLREC<6>)

I have seen these 3 situations in more than 1 MV implementation/flavor -

1. If POLREC<6> is null, an empty value won't be inserted, throwing 
associated values out of sync. Fix by prefixing or suffixing POLREC<6> 
with a character that won't be in the data, then converting it out later.
POLREC<6> is the unit price of the line item.  When it was entered 
earlier or just now on the fly, my input routine required numeric and I 
filter for unprintables.  So they can't get to receiving without a 
numeric price, though it could be zero.


2. INSERT sometimes doesn't like delimited source. Fix by moving 
POLREC<6> to a variable and inserting that.

I can try this.  The intermittence is still troubling.


3. If POLREC<6> has multivalues itself, that presents a whole 
different problem. Check it first.


Should not be possible unless I've stepped on it through miscoding in 
some other programs.


All these things can be checked in a little test program in just a few 
minutes, and a safer coding technique used.


Charlie


Thanks

dale
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] [UD] BASIC Code Failing

[Robert]

Could you post the entire program in case there are the frame boundary 
issues that Tony talked about?


Thanks,

Robert Norman
ROBERT NORMAN AND ASSOCIATES
23441 Golden Springs Dr., #289, Diamond Bar, CA 91765
(951) 541-1668
i...@keyway.net 
http://users.keyway.net/~ice/ 
Affordable UNIVERSE programming services for PICK/BASIC, DATA/BASIC, 
UniVerse

Basic, UniBasic, R/BASIC, jBC.

On 7/26/2013 6:41 AM, dale kelley wrote:
This is all very interesting to hear.  I have a customer who has 
occasional instances when they complain that a supply receipt has 
failed to update the "last receipt" fields. This is the code:


0092: 
***

0093: 7000:* UPDATE SUPPLIES
0094: 
***

0095: SUPKEY = POLREC<2>
0096: GOSUB 7300   * reads suprec
0097: IF SUPREC EQ "" THEN
0098:RETURN
0099: END
0100: SUPREC<16,1> = SUPREC<16,1> + OCONV(POLREC<13,RCPSUB>,"MD4")
0101: NEWQTY = 0
0102: LOCCNT = DCOUNT(SUPREC<15>,@VM)
0103: FOR LOCSUB = 1 TO LOCCNT
0104:NEWQTY = NEWQTY + SUPREC<16,LOCSUB>
0105: NEXT LOCSUB
0106: SUPREC<3> = NEWQTY
0107: SUPREC = INSERT(SUPREC,2,1,0,POLREC<6>)
0108: SUPREC = INSERT(SUPREC,11,1,0,POLREC<11,RCPSUB>)
0109: SUPREC = INSERT(SUPREC,12,1,0,FIELD(POLKEY,".",1))
0110: SUPREC = INSERT(SUPREC,13,1,0,VNDKEY)
0111: GOSUB 7400* writes suprec
0112: RETURN
:

I have never been able to figure out why line 106 gets executed but 
107 - 110 do not.


My customer refers to it as "the lawnmower man".

dale

___
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

[Charlie Noah]

Tony,

I think Bob may have a good troubleshooting technique here. It would be 
simple to eliminate causes. Line 107 has a couple of potential problems:


0107: SUPREC = INSERT(SUPREC,2,1,0,POLREC<6>)

I have seen these 3 situations in more than 1 MV implementation/flavor -

1. If POLREC<6> is null, an empty value won't be inserted, throwing 
associated values out of sync. Fix by prefixing or suffixing POLREC<6> 
with a character that won't be in the data, then converting it out later.


2. INSERT sometimes doesn't like delimited source. Fix by moving 
POLREC<6> to a variable and inserting that.


3. If POLREC<6> has multivalues itself, that presents a whole different 
problem. Check it first.


All these things can be checked in a little test program in just a few 
minutes, and a safer coding technique used.


Charlie

If this occasional problem is consistently the same lines then just
validate the insert afterwards:

0106.1 MV.CNT = DCOUNT(SUPREC<2>,@VM)
0107: SUPREC = INSERT(SUPREC,2,1,0,POLREC<6>)
0107.1 IF SUPREC<2,1> NE POLREC<6> THEN
0107.2MV.CNT2 = DCOUNT(SUPREC<2>,@VM)
0107.3IF MV.CNT = MV.CNT2 THEN GOSUB REPORT.ERROR
0107.4 END

With this logic, you're verifying the value and that a new value is, in
fact, being created in the attribute.  You may want to tweak the logic a
bit to match your exact specifics, like if POLREC<6> is a non-null
value, but this should give you an idea.


Tiny Bear's Wild Bird Store
Home of "Safety Net Shipping"
http://www.TinyBearWildBirdStore.com
Toll Free: 1-855-TinyBear (855-846-9232)

On 07-26-2013 12:13 PM, Tony Gravagno wrote:

From: Woodward, Bob
If this occasional problem is consistently the same lines then just
validate the insert afterwards...

Dale, don't accept that solution. (Sorry Bob)

Note, we're still not really Sure yet that this is a good definition
of the problem, just a working theory...

Overall, the problem seems to be that some statements can't be trusted
to be executed - not specific statements or functions, but random
lines of code in different systems. The problem might not be something
wrong with the statements themselves but just where they happen to be
in the program. The issues might be fixed with some extra code, or by
putting the few lines in question into an internal subroutine just to
move the bytecode to a different location. But a "solution" like that
is random and subject to just moving the problem to an as yet unknown
and perhaps more critical location.

When you can't trust a line of code to be executed in a linear series
of statements the reliability of everything we do comes into question.
If this is indeed the problem, "fixing" it by writing work around code
isn't good for anyone here.

It's tough to call in Support when the problem is so vaguely defined
but having "sat in the chair" as a QA Manager and Product Manager for
a related product, I can tell you the resolution starts with finding
sites that seem to have this issue, assigning someone to the task of
gathering data and scheduling tests on the target systems, getting
engineers to verify the issue, and establishing a pattern from which a
problem can be diagnosed.

I don't know who has to initiate that with Rocket Software but I'd
assume it starts with paying clients filing formal requests with
Support and committing to follow-through toward a resolution. And
while re-compilation might indeed be the correct fix, don't accept a
tier-1 techie solution intended to just get you off the phone!

HTH
T

___
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

[dale kelley]

Tony made a key qualification in his suggestion, "paying customer".  In 
this case, the system has been unupgraded for 7 and unsupported for 6 
years.  (With this exception UniVerse is just so dependable!)  I've 
noticed that hard to track problems just become albatrosses around the 
customer service persons neck and smells worse and worse as the ticket 
ages on their supervisors daily report.   The customer is just a small 
county highway department.  I'm going to do 2 things; put in the 
validation(s) and build a little repair screen that lets them take their 
exception report and correct the "last" info.  This is the first time 
I've even had any plan for it except a log file which has reflected nothing.


dale
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] [UD] BASIC Code Failing

[Woodward, Bob]

Not a problem, Tony.  I never want someone to just blindly accept a
quick fix.  It would be great if manufacturer's would commit the kind of
resources you mention when I submit an intermittent/can't
replicate/seems to only be on my system type of problem, but my
experience is with this kind of one-off, small potato client's problem,
I'm lucky if I get a first-tier, new to their helpline, fresh out of
training rookie to even give me a call to verify if I knew what I was
saying.

To me, a work-around is far more desirable to try and gather more
information in the error reporting than to leave the situation as is
with nothing to give back to the system owner besides a shoulder shrug.
If the problem changes, this is as good a piece of information as any
that it's most likely not data related and that the problem really does
need the type of resources you mentioned.

As always, Tony, you have very good, valid information that you
generously share with everyone.  We all appreciate that of you.

BobW

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Tony Gravagno
Sent: Friday, July 26, 2013 10:13 AM
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] [UD] BASIC Code Failing

> From: Woodward, Bob
> If this occasional problem is consistently the same lines then just 
> validate the insert afterwards...

Dale, don't accept that solution. (Sorry Bob)

Note, we're still not really Sure yet that this is a good definition of
the problem, just a working theory...

Overall, the problem seems to be that some statements can't be trusted
to be executed - not specific statements or functions, but random lines
of code in different systems. The problem might not be something wrong
with the statements themselves but just where they happen to be in the
program. The issues might be fixed with some extra code, or by putting
the few lines in question into an internal subroutine just to move the
bytecode to a different location. But a "solution" like that is random
and subject to just moving the problem to an as yet unknown and perhaps
more critical location.

When you can't trust a line of code to be executed in a linear series of
statements the reliability of everything we do comes into question.
If this is indeed the problem, "fixing" it by writing work around code
isn't good for anyone here.

It's tough to call in Support when the problem is so vaguely defined but
having "sat in the chair" as a QA Manager and Product Manager for a
related product, I can tell you the resolution starts with finding sites
that seem to have this issue, assigning someone to the task of gathering
data and scheduling tests on the target systems, getting engineers to
verify the issue, and establishing a pattern from which a problem can be
diagnosed.

I don't know who has to initiate that with Rocket Software but I'd
assume it starts with paying clients filing formal requests with Support
and committing to follow-through toward a resolution. And while
re-compilation might indeed be the correct fix, don't accept a
tier-1 techie solution intended to just get you off the phone!

HTH
T

___
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

[Tony Gravagno]

> From: Woodward, Bob 
> If this occasional problem is consistently the same lines then just
> validate the insert afterwards...

Dale, don't accept that solution. (Sorry Bob)

Note, we're still not really Sure yet that this is a good definition
of the problem, just a working theory...

Overall, the problem seems to be that some statements can't be trusted
to be executed - not specific statements or functions, but random
lines of code in different systems. The problem might not be something
wrong with the statements themselves but just where they happen to be
in the program. The issues might be fixed with some extra code, or by
putting the few lines in question into an internal subroutine just to
move the bytecode to a different location. But a "solution" like that
is random and subject to just moving the problem to an as yet unknown
and perhaps more critical location.

When you can't trust a line of code to be executed in a linear series
of statements the reliability of everything we do comes into question.
If this is indeed the problem, "fixing" it by writing work around code
isn't good for anyone here.

It's tough to call in Support when the problem is so vaguely defined
but having "sat in the chair" as a QA Manager and Product Manager for
a related product, I can tell you the resolution starts with finding
sites that seem to have this issue, assigning someone to the task of
gathering data and scheduling tests on the target systems, getting
engineers to verify the issue, and establishing a pattern from which a
problem can be diagnosed.

I don't know who has to initiate that with Rocket Software but I'd
assume it starts with paying clients filing formal requests with
Support and committing to follow-through toward a resolution. And
while re-compilation might indeed be the correct fix, don't accept a
tier-1 techie solution intended to just get you off the phone!

HTH
T

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] [UD] BASIC Code Failing

[David A. Green]

Intermittent data issues can be one of the hardest to debug.  One way that
has helped me out is to create a log file to log the transaction
information, then verify the data and when it is incorrect, send off an
email with the log file key to investigate.

David A. Green
(480) 813-1725
DAG Consulting

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of dale kelley
Sent: Friday, July 26, 2013 9:32 AM
To: U2 Users List
Subject: Re: [U2] [UD] BASIC Code Failing

Thanks Bob,

I'll try that validation, maybe even write SUPREC and read it back for
another validation.  (It's a low intensity system.)  At least that way I
could be telling them rather than them telling me!

dale
___
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

[dale kelley]

Thanks Bob,

I'll try that validation, maybe even write SUPREC and read it back for 
another validation.  (It's a low intensity system.)  At least that way I 
could be telling them rather than them telling me!


dale
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] [UD] BASIC Code Failing

[Woodward, Bob]

If this occasional problem is consistently the same lines then just
validate the insert afterwards:

0106.1 MV.CNT = DCOUNT(SUPREC<2>,@VM)
0107: SUPREC = INSERT(SUPREC,2,1,0,POLREC<6>)
0107.1 IF SUPREC<2,1> NE POLREC<6> THEN
0107.2MV.CNT2 = DCOUNT(SUPREC<2>,@VM)
0107.3IF MV.CNT = MV.CNT2 THEN GOSUB REPORT.ERROR
0107.4 END

With this logic, you're verifying the value and that a new value is, in
fact, being created in the attribute.  You may want to tweak the logic a
bit to match your exact specifics, like if POLREC<6> is a non-null
value, but this should give you an idea.

BobW

-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of dale kelley
Sent: Friday, July 26, 2013 6:42 AM
To: U2 Users List
Subject: Re: [U2] [UD] BASIC Code Failing

This is all very interesting to hear.  I have a customer who has
occasional instances when they complain that a supply receipt has failed
to update the "last receipt" fields.  This is the code:

0092: 
***
0093: 7000:* UPDATE SUPPLIES
0094: 
***
0095: SUPKEY = POLREC<2>
0096: GOSUB 7300   * reads suprec
0097: IF SUPREC EQ "" THEN
0098:RETURN
0099: END
0100: SUPREC<16,1> = SUPREC<16,1> + OCONV(POLREC<13,RCPSUB>,"MD4")
0101: NEWQTY = 0
0102: LOCCNT = DCOUNT(SUPREC<15>,@VM)
0103: FOR LOCSUB = 1 TO LOCCNT
0104:NEWQTY = NEWQTY + SUPREC<16,LOCSUB>
0105: NEXT LOCSUB
0106: SUPREC<3> = NEWQTY
0107: SUPREC = INSERT(SUPREC,2,1,0,POLREC<6>)
0108: SUPREC = INSERT(SUPREC,11,1,0,POLREC<11,RCPSUB>)
0109: SUPREC = INSERT(SUPREC,12,1,0,FIELD(POLKEY,".",1))
0110: SUPREC = INSERT(SUPREC,13,1,0,VNDKEY)
0111: GOSUB 7400* writes suprec
0112: RETURN
:

I have never been able to figure out why line 106 gets executed but 107
- 110 do not.

My customer refers to it as "the lawnmower man".

dale

___
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

[Israel, John R.]

It is worth noting that lines 107 - 110 are all doing an INSERT.  The lines 
before and after do not.

I'm not sure what that may or may not point to, but it is worth noting.  Any 
chance that what they are inserting is the problem (i.e. POLREC and VNDKEY are 
null or something other than what you suspect)?

JRI

-Original Message-
From: u2-users-boun...@listserver.u2ug.org 
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of dale kelley
Sent: Friday, July 26, 2013 9:42 AM
To: U2 Users List
Subject: Re: [U2] [UD] BASIC Code Failing

This is all very interesting to hear.  I have a customer who has occasional 
instances when they complain that a supply receipt has failed to update the 
"last receipt" fields.  This is the code:

0092: 
***
0093: 7000:* UPDATE SUPPLIES
0094: 
***
0095: SUPKEY = POLREC<2>
0096: GOSUB 7300   * reads suprec
0097: IF SUPREC EQ "" THEN
0098:RETURN
0099: END
0100: SUPREC<16,1> = SUPREC<16,1> + OCONV(POLREC<13,RCPSUB>,"MD4")
0101: NEWQTY = 0
0102: LOCCNT = DCOUNT(SUPREC<15>,@VM)
0103: FOR LOCSUB = 1 TO LOCCNT
0104:NEWQTY = NEWQTY + SUPREC<16,LOCSUB>
0105: NEXT LOCSUB
0106: SUPREC<3> = NEWQTY
0107: SUPREC = INSERT(SUPREC,2,1,0,POLREC<6>)
0108: SUPREC = INSERT(SUPREC,11,1,0,POLREC<11,RCPSUB>)
0109: SUPREC = INSERT(SUPREC,12,1,0,FIELD(POLKEY,".",1))
0110: SUPREC = INSERT(SUPREC,13,1,0,VNDKEY)
0111: GOSUB 7400* writes suprec
0112: RETURN
:

I have never been able to figure out why line 106 gets executed but 107
- 110 do not.

My customer refers to it as "the lawnmower man".

dale

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://cp.mcafee.com/d/FZsScz8scCQmhP3P3yb3NKVJ6WarZQrFCzASzt5d-Waq9EVdEThjvKztCVJ6WapEVvpood79Kl8XUz458qmDm56RLzaIundEqmDm56RLzaIundImIejthvW_8IfecnpWZOWtTCujhKUepLORQr8EGTKVOEuvkzaT0QSyrhdTdTdw0PVkDjUCvzPqrp7w0e2qKMM-l9OwXn6QOXtfzgSSCnrFYq5O5mUm-wafBitfyp-fdFJAu00CS7TbCMnWhEwdbojjdbFEwdboj3ziWq81Ag60Qid40Bl3Ph0bX8-k29KVLbCN1DxO_sIf
___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] [UD] BASIC Code Failing

[dale kelley]

This is all very interesting to hear.  I have a customer who has 
occasional instances when they complain that a supply receipt has failed 
to update the "last receipt" fields.  This is the code:


0092: 
***

0093: 7000:* UPDATE SUPPLIES
0094: 
***

0095: SUPKEY = POLREC<2>
0096: GOSUB 7300   * reads suprec
0097: IF SUPREC EQ "" THEN
0098:RETURN
0099: END
0100: SUPREC<16,1> = SUPREC<16,1> + OCONV(POLREC<13,RCPSUB>,"MD4")
0101: NEWQTY = 0
0102: LOCCNT = DCOUNT(SUPREC<15>,@VM)
0103: FOR LOCSUB = 1 TO LOCCNT
0104:NEWQTY = NEWQTY + SUPREC<16,LOCSUB>
0105: NEXT LOCSUB
0106: SUPREC<3> = NEWQTY
0107: SUPREC = INSERT(SUPREC,2,1,0,POLREC<6>)
0108: SUPREC = INSERT(SUPREC,11,1,0,POLREC<11,RCPSUB>)
0109: SUPREC = INSERT(SUPREC,12,1,0,FIELD(POLKEY,".",1))
0110: SUPREC = INSERT(SUPREC,13,1,0,VNDKEY)
0111: GOSUB 7400* writes suprec
0112: RETURN
:

I have never been able to figure out why line 106 gets executed but 107 
- 110 do not.


My customer refers to it as "the lawnmower man".

dale

___
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users

Re: [U2] [UD] BASIC Code Failing

[Ed Clark]

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  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 
> To: 'U2 Users List' 
> 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

Re: [U2] [UD] BASIC Code Failing

[Bob Wyatt]

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 
To: 'U2 Users List' 
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

[Wjhonson]

Do you have the two-inch lead shielding around your server room to block cosmic 
rays?


 

 

 

-Original Message-
From: Bob Wyatt 
To: 'U2 Users List' 
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

[Bob Wyatt]

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

[Wjhonson]

You can turn off automatic reboots.
 

 

 

-Original Message-
From: Bill Haskett 
To: U2 Users List 
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 
*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

[Bill Haskett]

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 
*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

[Bill Haskett]

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

[Robert]

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]

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 I<10 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 
http://users.keyway.net/~ice/ 
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

[Woodward, Bob]

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

[Tony Gravagno]

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] [UD] BASIC Code Failing

[George Gallen]

It almost sounds like maybe the last time you did a major upgrade and had to 
recompile
Your code, rather than just port it to the new version, something didn't 
compile correctly
Maybe due to a bug, but then you upgraded without having to recompile, and that 
bug
Was fixed and only seems like recompiling fixed it??

Maybe a pre-emptive strike and recompile/catalog all your programs?

George

-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 3:25 PM
To: U2 Mail List
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

[Wjhonson]

Put the five into a single transaction.
You will never see the issue again

 

 

 

-Original Message-
From: Bill Haskett 
To: U2 Mail List 
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

[U2] [UD] BASIC Code Failing

[Bill Haskett]

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