Jump to content


Photo
- - - - -

5.5 Core dump with TYPE 2 SQL


1 reply to this topic

#1 Chris Pepper

Chris Pepper

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 369 posts
  • Gender:Male
  • Location:United Kingdom

Posted 09 June 2006 - 10:01 AM

We're trying to produce a simple version of this to submit to ProIV but I thought I'd run it past the people here to see if you've had experience with it.
We have a function using TYPE 2 SQL - to generate some totals into a dummy ProIV file definition. This has a set of IF statements to determine the exact SQL to be run e.g. on default logic of LU2
LU1 1-1
01 somefile
LU2 1-2
01 DUMMYFD

This works fine, except in a function where there are several LSCALLs. This introduces multiple LS with a similar structure into the Function. This allows for some more complicated options that require additional tables to be accessed. So there is a set of default logic with IF statements and TYPE 2 SQL in the default logics of LU2, LU3 etc. These are called by LSCALL from LU1 which will either call LU2 or LU3 or LU4 etc as appropriate.
LU1 1-1
01 somefile
LU2 2-2
01 DUMMYFD
LU3 3-3
01 DUMMYFD
02 someotherfile
LU4 4-4
01 DUMMYFD
02 someotherfile1
03 someotherfile2

This core dumps on 5.5 (but not on 4.6).
If the function is rewritten to use GLOBAL_LSCALL and the LU2 - -n moved into Global Functions with one use of DUMMYFD per function then it works.

Any thoughts? Anyone else tried to have the same DUMMYFD used more than once in a Function on V5.5?

#2 Chris Pepper

Chris Pepper

    ProIV Guru

  • Members
  • PipPipPipPipPip
  • 369 posts
  • Gender:Male
  • Location:United Kingdom

Posted 13 June 2006 - 11:02 AM

To continue with the group tradition of posting answers to your own posts.... (w00t)

This problem occurs because of the way ProIV attempts to optimise the SQL by working out which fields are being used in the function during the gen process.

Depending on the different requirements the SQL in the different LUs returned a different number of fields to the dummy table. So LU2 was expecting 3 fields back, and LU3 was expecting 4 fields back. ProIV was obviously spotting that a 4th field was being referenced in a different logic, and therefore tried to obtain a value for it. It was core dumping in the kernel routine that was trying to process null values - in LU2, trying to get back a value that was only used in LU3 - and therefore nothing to do with this SQL command.



Reply to this topic



  


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users