DB2-V8 Vs DB2-V9 problem

dbzTHEdinosauer · Posted: Fri Sep 07, 2012 10:45 pm

just for grins,
what is the pic clause for f1-print-a?

dick scherrer · Posted: Fri Sep 07, 2012 11:35 pm

Hello,

dbzTHEdinosauer · Posted: Fri Sep 07, 2012 11:53 pm

is f1-print-a a PIC 9(?) or PIC S9(?) (display).
db2 stopped messing with that garbage cobol data type.

also, the reason SPUFI works:
you are using Literals and not HOST-VARIABLES.
db2 can determine the data type from the literal
(maybe not what you mean, but db2 can determine a definite data type)
but has stopped trying to figure out some host variables.

when you use functions like DEC, you should CAST the host-variable.
DISPLAY is really x-type and if you try to use a scalar function
that requires a numeric data type, you are going to have problems.
(trying to blame it on anyone except your sub-par coders)

even though IBM has really dumbed-down COBOL,
if you think db2 vsn9 is strict,
wait til you migrate to 10.
all the BS SQL your people have written, is going to keep you busy.

razesh84 · Posted: Sat Sep 08, 2012 1:20 am

Rohit,

I don't consider myself a sql expert,but seriously that case statement makes no sense.When you have all the information why ask DB2 to manipulate data for you.Use cobol logic to get the value & pass DB2 for insert(As Dick already suggested).

Also the problem is nothing to do with GTT.you can code such query against any tables & run in DB2V9.You'll be getting the same error.

And now comes how to solve this issue?

1> you can always fight with IBM
2> accept the fact(that it was really bad programming) & change the code
3> change the code under performance initiative bucket.though I'm not sure how many times the insert was executed but still if you follow dick's approach you will get some savings.

This is a real good example of Dick's signature comment.

dbzTHEdinosauer · Posted: Sat Sep 08, 2012 8:38 am

and another thing.

it appears that there is no CALL to DSNTIAR,
otherwise you would have told us the offending host-variables name, n'est-ce pas?

If not, suggest that your site enter the computer age
and incorporate a CALL DSNTIAR for every SQLCODE < 0
in all of your programs.

If so, it would help to know what variable was mentioned.

dbzTHEdinosauer · Posted: Sat Sep 08, 2012 10:52 am

and yet another thought.

I imagine that you have not compile/bind your system under 9 since
installing and running on vsn9.

good chance this -312 would have shown-up in pre-compile or
bind at a vsn 9 level.
(obviously the vsn 8 pre-compiler/bind allowed it)

yes, stuff compiled/bind under vsn 8 will run in 9,
but that is based on the fact that the vsn8 sql is good sql.
if it is not, you end-up with runtime negative sql codes.

and I reiterate,
code in CALL's to DSNTIAR for negative SQLCODEs.
it will make solving your problems a lot easier.

and learn to read all of the documentation about each negative SQLCODE.
to have read about a -312 and then respond with
'it is not dynamic or trigger'
indicates you have a long way to go before you are proficient in solving problems.
you need to change the way you go about analyzing problems
and utilizing the information provided.

Rohit Umarjikar · Posted: Mon Sep 10, 2012 4:33 pm

dick scherrer · Posted: Mon Sep 10, 2012 6:56 pm

Hello,

As you have continuing issues with GTT (or something), it would be best to have IBM in the loop and learn if this is something they have seen before and what they have done about it (if anything).

If some developer(s) implemented code that IBM does/did not support, they may answer that the code has to be changed, but maybe they can provide info on situations where this has happened to others. Then you will have a better idea what to look for (rather than having production processes misbehave).

Rohit Umarjikar · Posted: Mon Sep 10, 2012 7:35 pm

Thanks Dick. I shall let this get noticed to IBM.