HP3000-L Archives

May 1995, Week 4

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Jeff Brown <[log in to unmask]>
Reply To:
Jeff Brown <[log in to unmask]>
Date:
Wed, 24 May 1995 19:26:46 GMT
Content-Type:
text/plain
Parts/Attachments:
text/plain (70 lines)
In article <[log in to unmask]>, [log in to unmask]
says...
>
>We are migrating piecemeal to native mode. So far, we haven't had
>many major problems (knock on simulated woodgrain laminate) but the
>one that's taking the largest chunks out of our posteriors is invalid
>ASCII digit errors.
>
>It seems that when we get a not found condition on a DBGET, random
>garbage is left in the record space. This is understandable but our
>old classic didn't seem to mind. The new box is giving us fits! All
>the programs running in compatibality mode handle this just fine but
>kick it up to native mode and WHAM!
>
>To date, our solution is to initialize the record space after an
>unsuccessful DBGET. Is there a simpler answer?
>
>===========================================================================
=====
>Michael A. Vealey                       = We will conserve only what we
love.
>University Computing Services           = We will love only what we
understand.
>University of Maryland Baltimore County = We will understand only what we
are
>[log in to unmask]        =                        taught.
>===========================================================================
=====
> * All opinions expressed are mine and mine alone. You can't have 'em.
Nyah! *
 
*************************************
 
I believe that the following is the case:
 
-       The buffer variable used to receive the DBGET results is
        not being initialized explicitly in your program.
 
-       That DBGET does not change the contents of the buffer if
        no record is found.
 
-       That your program references some part of the buffer that
        is defined as numeric, but at the time of use actually contains
        a non-numeric value.
 
-       That in compatibility mode illegal ASCII digits were tolerated
        (translated to zero, and processing continues), and that in
        native mode there is no toleration.
 
Solutions:
 
1)      Don't reference the undefined value.  That's a good answer
        whether or not you compile the program in compatibility mode
        or native mode.
 
2)      If your code logic is such that you want to reference the
        value anyway, initialize either the particular values used
        or the entire buffer to appropriate values.  The values to
        use will depend upon your program.
 
3)      I believe there is a way with a compiler setting ($CONTROL option)
        to change how illegal ASCII digits are handled.  But I don't
        remember how.  Maybe someone else does?
 
Good luck.  This still bites us, both through the compatibility mode
tolerance and the native mode intolerance.
 
Jeff Brown
[log in to unmask]

ATOM RSS1 RSS2