ABF ACCVIO?

ABF ACCVIO?

Post by Bruce E. Golightl » Thu, 22 Apr 1993 06:51:11



I'm getting some very odd behaviour in a 4GL application I am working
on. I have a frame that is causing a system fatal abort. The problem is
that I cannot determine any real season for this. I put "message"
statements in the code to try to determine where it was going wrong.
They all execute just fine. Based on that finding, it almost looks like
the OSQ code is failing on the "}" at the end of the activation block,
but I don't see how that could be happening.

Environemt:
  VAX/VMS 5.4
  Ingres  6.4/01 (vax.vms/01)

The 4GL code:
   This is the code segment where it actually blows up:
   (frskey23 is defined as the "Select" key on VT200 keyboards)

'S.O.', key frskey23 =
  {
    clear field 'imsg';
    imsg := callframe signoff(signoff.workordernum = :workordernum,
                              signoff.wo_sequence  = :wo_sequence);
    if imsg = -1
     then
       msg := 'SIGNOFF aborted because user CANCELED action';
     elseif imsg = 0 then
       clear field all;
       record_pointer = -1;
     elseif imsg != 0 then
       message 'Unable to SIGNOFF Work Order' + X'0D' +
               'Please report the error NOW' with style = popup;
       msg := 'Work Order could NOT be signed off';
    endif;
    redisplay;
  }

  All fields referenced are simple fields in the VIFRED form associated
with the frames. IMSG is an i4 field and MSG is quite large enough to
contain the text stirngs being loaded there. WORKORDERNUM and
WO_SEQUENCE are char(12) and i4, respectively, in both forms.

  This is the pertinent code in the frame SIGNOFF:

'Exit', key frskey3 =
  {
    return(-1);
  }

The error:

SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=001FAA00,
PC=01ADAAC, PSL=03C00000
Please contact your Technical Support representative.
%SYSTEM-F-ABORT, abort
%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=001FAA00,
PC=01ADAAC, PSL=03C00000
%SYSTEM-F-ABORT, abort

 
 
 

ABF ACCVIO?

Post by Bill Dill » Thu, 22 Apr 1993 10:15:55




> I'm getting some very odd behaviour in a 4GL application I am working
> on. I have a frame that is causing a system fatal abort. The problem is
> that I cannot determine any real season for this. I put "message"
> statements in the code to try to determine where it was going wrong.
> They all execute just fine. Based on that finding, it almost looks like
> the OSQ code is failing on the "}" at the end of the activation block,
> but I don't see how that could be happening.

> Environemt:
>   VAX/VMS 5.4
>   Ingres  6.4/01 (vax.vms/01)

> The 4GL code:
>    This is the code segment where it actually blows up:
>    (frskey23 is defined as the "Select" key on VT200 keyboards)

> 'S.O.', key frskey23 =
>   {
>     clear field 'imsg';
>     imsg := callframe signoff(signoff.workordernum = :workordernum,
>                               signoff.wo_sequence  = :wo_sequence);
>     if imsg = -1
>      then
>        msg := 'SIGNOFF aborted because user CANCELED action';
>      elseif imsg = 0 then
>        clear field all;
>        record_pointer = -1;
>      elseif imsg != 0 then
>        message 'Unable to SIGNOFF Work Order' + X'0D' +
>                'Please report the error NOW' with style = popup;

   Please expain the part of the message " + X'OD' + "
That does not look correct.  Are you trying to do some sort of HEX of the
work order number?? If so use the HEX() function, if not, that could be
your problem...

Good Luck -

William R. Dillon
Apple Computer, Inc.

/*   My opinions aren't really worth disclaiming, but they are anyway!!!
*/

|--------------------------------------------------------------------------|
|   Dillon's Database Rule:  All unwatched databases will expand to fill  
|
|                            ANY available storage.                      
|
|--------------------------------------------------------------------------|

 
 
 

ABF ACCVIO?

Post by M Darrin Chan » Fri, 23 Apr 1993 03:01:40




>>        message 'Unable to SIGNOFF Work Order' + X'0D' +
>>                'Please report the error NOW' with style = popup;

>   Please expain the part of the message " + X'OD' + "
>That does not look correct.  Are you trying to do some sort of HEX of the
>work order number?? If so use the HEX() function, if not, that could be
>your problem...

Ack!  Think first, post later, please.  If the "X'0D'" was wrong, don't
you think that would give a compile-time error instead of a run-time
error?  (Here's a clue: the answer is "compile-time error")

If you don't understand something, look it up.  Don't ask the original
poster to clarify something that needn't be clarified.

To save you the trouble of looking up, I'll explain it.  Looking in the
SQL manual (Constants, Hex in the index), page 2-27, you find that the
mysterious X'hex number' represents a string literal in hexidecimal
format.  The X'0D' above is a carriage return.

        Darrin
--
M Darrin Chaney, Senior Database Programmer, University Computing Services, IU


"I want- I need- to live, to see it all..."

 
 
 

ABF ACCVIO?

Post by M Darrin Chan » Fri, 23 Apr 1993 03:13:16



Quote:>I'm getting some very odd behaviour in a 4GL application I am working
>on. I have a frame that is causing a system fatal abort. The problem is
>that I cannot determine any real season for this. I put "message"
>statements in the code to try to determine where it was going wrong.
>They all execute just fine. Based on that finding, it almost looks like
>the OSQ code is failing on the "}" at the end of the activation block,
>but I don't see how that could be happening.

>Environemt:
>  VAX/VMS 5.4
>  Ingres  6.4/01 (vax.vms/01)

>The 4GL code:
>   This is the code segment where it actually blows up:
>   (frskey23 is defined as the "Select" key on VT200 keyboards)

>'S.O.', key frskey23 =
>  {
>    clear field 'imsg';
>    imsg := callframe signoff(signoff.workordernum = :workordernum,
>                              signoff.wo_sequence  = :wo_sequence);
>    if imsg = -1
>     then
>       msg := 'SIGNOFF aborted because user CANCELED action';
>     elseif imsg = 0 then
>       clear field all;
>       record_pointer = -1;
>     elseif imsg != 0 then
>       message 'Unable to SIGNOFF Work Order' + X'0D' +
>               'Please report the error NOW' with style = popup;
>       msg := 'Work Order could NOT be signed off';
>    endif;
>    redisplay;
>  }

>  All fields referenced are simple fields in the VIFRED form associated
>with the frames. IMSG is an i4 field and MSG is quite large enough to
>contain the text stirngs being loaded there. WORKORDERNUM and
>WO_SEQUENCE are char(12) and i4, respectively, in both forms.

>  This is the pertinent code in the frame SIGNOFF:

>'Exit', key frskey3 =
>  {
>    return(-1);
>  }

>The error:

>SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=001FAA00,
>PC=01ADAAC, PSL=03C00000
>Please contact your Technical Support representative.
>%SYSTEM-F-ABORT, abort
>%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=001FAA00,
>PC=01ADAAC, PSL=03C00000
>%SYSTEM-F-ABORT, abort

This smells strongly of bug #46472.  To quote directly from the 6.4/03
"Generic Release Notes", page 82:

"ABF/4GL: IF, ELSEIF, and WHILE blocks are now executed correctly in all
situations.  Previously, a run time [sic] could occur if an array
element or record attribute was referenced in the boolean expression of
the IF, ELSEIF or WHILE statements.  This problem has been corrected."

When I called in with a very similar problem (actually, almost exactly
what the text of the bug description is about), the tech rep said that
the bug depended on a) using an array in the IF part; b) having an
ELSEIF; and c) referencing the array within the part of the IF block
that gets executed.

I helped them narrow it down, since it bombed with or without the ELSEIF.
It could be that you don't need an array.  You do reference imsg in all
three parts (note that the last elseif just needs to be an else since it
is the opposite of the previous comparison).

Anyway, if I were you, I'd do what the error says and give Tech Support
a call.  Be prepared to hear "Yeah, that's a known bug.  You'll need to
upgrade to 6.4/03 to fix it".

        Darrin
--
M Darrin Chaney, Senior Database Programmer, University Computing Services, IU


"I want- I need- to live, to see it all..."

 
 
 

1. ABF ACCVIO

For those of you who were confused or concerned by the "X'0D'", that is
a mechanism for embedding a carriage return in the text of a MESSAGE
statement. I don't recall where I first ran across that one, but it is
in the Ingres docs somewhere, and we are using it in other applications
without problem.

As a followup on the problem I reported in the first place, I have
gotten the application working. The solution turned out to be quite
simple - remove the REDISPLAY. Everything is now working just fine.

This is, of course, quite bizarre. CMU will be filing a bug report on
this one as soon as I can collect copies of all the pertinent code to
fax to them.

Thanks.
Bruce

2. odbc

3. DMF ACCVIO: Segmentation Violation

4. Mid West - Oracle Manufacturing - Contract- BOM,WIP, OE, Inventory, MRP

5. ABF) Resetting auto-increment numbers in tables

6. MSSQL7 running slow.

7. ABF software, Inc. products

8. HELP: context intermedia question

9. ANN: ABF VCL 1.9 released

10. Ingres ABF/RW to OpenROAD/Oracle

11. ABF: Paradox SQL reference manual???

12. ABF linking problems?