Conference orarep::nomahs::sql_services

2134.0. "SQLBUGCHK.DMP on VAX, OK on AXP with NSDK ?" by 8292::PJACOB (Patrick [email protected]) Fri Jan 31 1997 06:56

A customer has problem accessing his Rdb database in client-server throuh NSDK
only when the target is VAX. He has a mixed cluster VAX/VMS  and OpenVMS Alpha
with Rdb 6.0-11 and SQL/Services 6.0-1 with the same configuration file. The 
SELECT he submits from his client is a large SELECT one but it is supposed to 
returns few rows. It works when he goes through the AXP machine but it 
generates a SQLBUGCHK.DMP when he goes through the VAX . There is no exception
in the SQLBUGCHK.DMP. 

Below are the trace of the log on VAX and on Alpha. The only thing I can see 
is the different packet length : 107 for the VAX , 315 from the AXP . 

Is it the cause of the problem ? any ideas ?

Patrick 

On the VAX where it does not work:
=================================
--------END OF MESSAGE

PROTOCOL LEVEL LOG CLIENT: read
----PACKET LENGTH: 107

PROTOCOL LEVEL LOG CLIENT: read
----PACKET ID: 392, PACKET SEQUENCE: 0
--------ERROR ACK
------------ERROR_VALUE_TAG
----------------SQLSRV_GENERALIZED_NUMBER, len: 2
--------------------len: 2, value: -1
------------SPECIFIC_ERROR_TAG
----------------SQLSRV_GENERALIZED_NUMBER, len: 1
--------------------len: 1, value: 0
------------SPECIFIC_ERROR_TEXT_TAG
----------------SQLSRV_ASCII_STRING, len: 82
--------------------len: 82, value: %SQL-F-BUGCHK, There has been a
fatal error.
-------------------- Please submit an SPR. SQL$SEMCUR - 17
--------END OF MESSAGE

On the AXP where it works:
=========================
--------END OF MESSAGE

PROTOCOL LEVEL LOG CLIENT: read
----PACKET LENGTH: 315

PROTOCOL LEVEL LOG CLIENT: read
----PACKET ID: 392, PACKET SEQUENCE: 0
--------SQLSRV_PREPARE ACK
------------STATEMENT ID
----------------SQLSRV_GENERALIZED_NUMBER, len: 8
--------------------len: 8, value: 14485840
------------SQLERRD[1]
----------------SQLSRV_GENERALIZED_NUMBER, len: 1
--------------------len: 1, value: 1
------------SELECT LIST SQLDA
----------------len: 2, value: 6
------------SQLVAR
----------------len: 2, value: 0
------------SQLTYPE
----------------len: 2, value: 129
------------SQLLEN
----------------SQLSRV_GENERALIZED_NUMBER, len: 1
--------------------len: 1, value: 5
------------SQLNAME
----------------SQLSRV_ASCII_STRING, len: 4
--------------------len: 4, value: GARE
------------OCTET LEN
----------------SQLSRV_GENERALIZED_NUMBER, len: 1
--------------------len: 1, value: 5
------------CHARACTER SET NAME
----------------SQLSRV_ASCII_STRING, len: 7
--------------------len: 7, value: DEC_MCS
------------SQLVAR
----------------len: 2, value: 1
------------SQLTYPE
----------------len: 2, value: 129
------------SQLLEN
----------------SQLSRV_GENERALIZED_NUMBER, len: 2
--------------------len: 2, value: 24
------------SQLNAME
----------------SQLSRV_ASCII_STRING, len: 10
--------------------len: 10, value: NOMGAREPHY
------------OCTET LEN
----------------SQLSRV_GENERALIZED_NUMBER, len: 2
--------------------len: 2, value: 24
------------CHARACTER SET NAME
----------------SQLSRV_ASCII_STRING, len: 7
--------------------len: 7, value: DEC_MCS
------------SQLVAR
----------------len: 2, value: 2
------------SQLTYPE
----------------len: 2, value: 129
------------SQLLEN
----------------SQLSRV_GENERALIZED_NUMBER, len: 2
--------------------len: 2, value: 44
------------SQLNAME
----------------SQLSRV_ASCII_STRING, len: 16
--------------------len: 16, value: VERSION_COURANTE
------------OCTET LEN
----------------SQLSRV_GENERALIZED_NUMBER, len: 2
--------------------len: 2, value: 44
------------CHARACTER SET NAME
----------------SQLSRV_ASCII_STRING, len: 7
--------------------len: 7, value: DEC_MCS
------------SQLVAR
----------------len: 2, value: 3
------------SQLTYPE
----------------len: 2, value: 129
------------SQLLEN
----------------SQLSRV_GENERALIZED_NUMBER, len: 2
--------------------len: 2, value: 16
------------SQLNAME
----------------SQLSRV_ASCII_STRING, len: 17
--------------------len: 17, value: DATMISES_COURANTE
------------OCTET LEN
----------------SQLSRV_GENERALIZED_NUMBER, len: 2
--------------------len: 2, value: 16
------------CHARACTER SET NAME
----------------SQLSRV_ASCII_STRING, len: 7
--------------------len: 7, value: DEC_MCS
------------SQLVAR
----------------len: 2, value: 4
------------SQLTYPE
----------------len: 2, value: 129
------------SQLLEN
----------------SQLSRV_GENERALIZED_NUMBER, len: 2
--------------------len: 2, value: 44
------------SQLNAME
----------------SQLSRV_ASCII_STRING, len: 14
--------------------len: 14, value: VERSION_FUTURE
------------OCTET LEN
----------------SQLSRV_GENERALIZED_NUMBER, len: 2
--------------------len: 2, value: 44
------------CHARACTER SET NAME
----------------SQLSRV_ASCII_STRING, len: 7
--------------------len: 7, value: DEC_MCS
------------SQLVAR
----------------len: 2, value: 5
------------SQLTYPE
----------------len: 2, value: 129
------------SQLLEN
----------------SQLSRV_GENERALIZED_NUMBER, len: 2
--------------------len: 2, value: 16
------------SQLNAME
----------------SQLSRV_ASCII_STRING, len: 15
--------------------len: 15, value: DATMISES_FUTURE
------------OCTET LEN
----------------SQLSRV_GENERALIZED_NUMBER, len: 2
--------------------len: 2, value: 16
------------CHARACTER SET NAME
----------------SQLSRV_ASCII_STRING, len: 7
--------------------len: 7, value: DEC_MCS
--------END OF MESSAGE

>
>Below are the trace of the log on VAX and on Alpha. The only thing I can see 
>is the different packet length : 107 for the VAX , 315 from the AXP . 
>

Weren't there some packet splitting bugs fixed in SQL/Services V6.1 with ECO 2?

Can the customer upgrade to the latest SQL/Services version and try it again?

Renee

Hi Patrick,

The reason you are seeing different message sizes is because the PREPARE is
succeeding on Alpha, so SQL/Services returns a PREPARE-ACK message to the
client, whereas it fails on VAX, so SQL/Services returns an ERROR message to
the client. In other words, in both cases, SQL/Services is just returning the
result it got back from SQL. 

The fact that there's no exception in the SQL log is probably because its in
the error message:

------------SPECIFIC_ERROR_TEXT_TAG
----------------SQLSRV_ASCII_STRING, len: 82
--------------------len: 82, value: %SQL-F-BUGCHK, There has been a fatal error.
-------------------- Please submit an SPR. SQL$SEMCUR - 17

Specifically the bit about "SQL$SEMCUR - 17" (Internal error 17 in the
SQL$SEMCUR module). Don't ask me what it means though. (I did do a quick search
of the SQL source and found the place where its doing the bug check and the
comments seem to indicate that its something to do with DBkeys and aggregates
or unions, but beyond that, the insides of SQL are a complete mystery to me.)

I can only suggest that you submit this problem to the SQL folks, along with
the exact error message above, the SQL statement the application is trying to
prepare, plus all the metadata information for the tables being accessed. 

Si

    Thank you.
    
    I submitted bug # 448984 for this.
    
    Patrick

    
    FYI,
    
    On VAX where the problem exists Rdb version is 6.0-11.
    On Alpha where it works Rdb version is 6.0-13.
    A change has been made in Rdb 6.0-13 which avoid the bugcheck. ECO 6 of 
    Rdb 6.0A has been sent to the customer. It should fix the problem.
    However, I did not get the confirmation of this because the customer
    implemented a workaround ( by using a view ) and thus delay the
    installation of the ECO to a later date.
    
    Patrick