Long variable name losing value

[Bruce Easton]

Bruce Easton wrote Friday, February 15, 2008 9:05 PM:
>
> Barry Wiseman wrote Friday, February 15, 2008 8:29 PM:
> >
> > Bruce Easton wrote:
> > > Barry Wiseman wrote Friday, February 15, 2008 6:47 PM:
> > >
> > >> Bruce Easton wrote:
> > >>> I'm seeing something kooky today where it appears that a long
> > >>> variable is losing its value.
> > >>>
> > >>> Here is not all, but what I hope are the relevant parts of the
> > >>> prc table (runs from clerk - 5.014):
> > >>>
> > >>>   1  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -
> > >>>          If:
> > >>>        Then: exit
> > >>>   2  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -
> > >>> @menu    If:
> > >>>        Then:
> > >>>   3  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -
> > >>>          If:
> > >>>        Then: declare GLOBAL log_name(14,*)
> > >>>   4  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -
> > >>>          If:
> > >>>        Then: '
> > >>>   5  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -
> > >>>          If: '[this is the ONLY called table (no chained tables)]
> > >>>        Then: CALL "setup"      '[setup does not reference
> "log_name"]
> > >>>   6  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -
> > >>> .
> > >>> .            '[debugger here shows log_name has a value]
> > >>> 158  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -
> > >>> process  If:
> > >>>        Then: 'process file
> > >>> 159  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -
> > >>> .     [there are a couple of sys commands in here that are running
> > >>> .      to completion OK]
> > >>> 233  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -
> > >>>          If:  '[debugger shows log_name is blank and so is new(323)]
> > >>>        Then: new(323)=log_name
> > >>> 234  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -
> > >>> .     [there is an import here that is successfully assigning
> > >>> .      to other 'new' fields]
> > >>> 375  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -
> > >>> enndd    If:  '[the record is being created, all but field new(323)]
> > >>>        Then: close new                         '[populated OK]
> > >>> 376  -------   -   -   -   -   -   -   -   -   -   -   -   -   -   -
> > >>>
> > >>>
> > >>> To get around this, I have assigned a field ln(14,*)=log_name up
> > >>> on line 4, then below that I now only assign 'new(323)' from ln.
> > >>> Field new(323) is now getting its value OK this way.
> > >>> Does anyone know why the long variable could lose its
> > >>> value?
> > >> Probably due to something that happens on lines 7-232. :-)
> > >>
> > > :):) That's exactly what I might have written had someone
> > > posted an example like this.  I was very careful to check
> > > all labels and refs to the variable, but I'll try to provide
> > > more code and info in another post.  I am showing all refs
> > > to "log_name."
> > >
> > > Bruce
> >
> > I'm sure there are no intervening references to the variable, but
> > nevertheless some intervening *event* is at issue.  Does the value go
> > away following a CALL?  Following a SYSTEM command?  Following a popup?
>
> It may go away following a system command - I'm just not sure yet
> how soon after.  I just got access again and what I did discover
> which really surprised me is that following Scott's suggestion
> also makes it work - that is making the long-var cross-rec global
> as in ,g.  As I said, this whole process runs just from @menu (and
> since it is a web event - it really has no choice but to run the
> table once from top to bottom - at least that is the intention).
> When I substitute the long_var with the dummy ln (not global) in
> all the places log_name exists in the table, it also works.
> Just to make sure - I put it back to not using log_name instead
> of ln and without the ,g - and it's broken again losing that value
> somewhere in the middle.
>
> Since this is part of a web process, I first was careful to make sure
> I was getting name value pairs everywhere I was expecting them.
> No problem there - that's when I went to the debugger and found that
> it is losing it mid-stream in a fairly simple top-down process.
> Also since it is a web process there are no popups or processes that
> require user input prior to a page being rendered.
>
> But I know the importance of your concern.  Quite often I see
> where someone fails to look at all the entry and exit points
> of the process while trying to debug or understand the program,
> whether they be goto's within the code, external calls or
> entry points from the outside (and of course - in what state does
> it terminate in the eyes of the database manager, were records
> locked, etc.).
>
> Bruce
>

OK - I've found where the long var is losing its value.

There is a short bit of code in this program that does a
protected lookup to the current file (aliased with sessnum)
to get a control number and bump it up one.  After I've
closed this lookup, the long var value in my current table
for log_name is blank, unless I make it record-global with
a ,g, or unless I use a regular dummy field.

So, in code/pseudo code:

@menu  (top-down process for file bbbctl@ - never
supposed to lock any record - no real fields referenced,
ends with an exit command)
.
.
lookup sessnum = bbbctl@  r=("1") -np
tryaginIf: not sessnum
Then: sleep some ;goto tryagin
If:
Then: get my ctrl#; bump my ctrl#; close sessnum
If:
Then: '(any time from here on log_name is blank
if it is defined as GLOBAL(14,*), but retains
its value if it is GLOBAL(14,*,g) or if I use
ln(14,*).

So I'm now really wondering what the dbm is
up to at this point.  Is it just losing the
value - or is it also thinking it is locking
the current record and getting ready to run
auto, etc. just because I looked up into
the same file to write.

I'm pretty sure I didn't see this behavior from
my unix version of this, but I haven't tested
it tonight.

Bruce

Bruce Easton
STN, Inc.