"When" processing

Rodgers Hemer r.hemer at w-link.net
Wed Jul 2 13:38:48 PDT 2008


On Jul 2, 2008, at 10:55 AM, Bruce Easton wrote:

> Rodgers Hemer wrote Wednesday, July 02, 2008 10:19 AM:
>>
>> On Jun 30, 2008, at 9:00 PM, Rodgers Hemer wrote:
>>
>>> SCO 6.0, filePro 5.0.14
>>>
>>> A "called" table from input processing has stopped working.  It was
>>> processing data to real fields from wef and wlf lines.  No other
>>> processing in the called table.  The cursor follows the path  
>>> specified
>>> in the screen definition.  Debug is not recognized unless it is  
>>> placed
>>> before the screen command.  Data is entered but no processing sees  
>>> or
>>> uses it.
>>>
>>> I have checked all of the ownership and permission issues.  And I  
>>> have
>>> copied the process and the screen to new filenames and then changed
>>> the names with no effect.  As far as I can tell, this problem does  
>>> not
>>> occur elsewhere but I have few other called tables to compare.
>>>
>>> I can't come up with anything else to try.   Does anyone have any
>>> suggestions.
>>
>>
>>  I have solved my problem but I have not
>> answered the question I had posed.  The call table WAS working
>> before the problem arose and no changes had been made to the call  
>> table
>> or the line in the input table that made the call.  The call table is
>> not large, about
>> 120 lines.  I could not find any configuration element that addressed
>> this issue,
>> so my only solution was to insert the call table processing into the
>> input
>> process.  This of course works just fine but does not explain why   
>> the
>> call stopped working correctly.
>>
>> Thanks to those who tried to help.
>>
>> Rodgers Hemer
>
> This is a late response, and this is a long shot, but I
> do see how a called table could stop working without 'modifications'
> to it or the input table.  Example:
>
> Developer A tokenizes input and called tables against auto table
> 'AUTOSPECIAL'
> and keeps it a secret.
>
> (Maybe auto table 'AUTOSPECIAL' differs slightly from the default  
> AUTO table
> in that dummy XX has different lengths.)
>
> Not knowing the secret, Developer B comes along and tokenizes the  
> input
> table
> (without changing any code) against the default auto table.  The  
> called
> table then
> might be confused by the new length of XX if it were, for instance,  
> the key
> for a lookup.
>
> So, if the filepro executable line for this function uses the -y to  
> specify
> a particular auto
> table, then that would be a sign to check for this situation.
>
> (Also, if Developer A is at least my age, then Developer A and  
> Developer B
> might be the same person.)
>
> Bruce
>
Bruce:

There are no tok tables, auto or otherwise, and the menu line does not  
specify a special auto table.
And, Developer A *is* the same person as Developer B which causes me  
to do a lot of checking of my work.

Rodgers Hemer


More information about the Filepro-list mailing list