IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

misleading SQLCODE (apparently)


IBM Mainframe Forums -> DB2
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
Ricardo Viegas

New User


Joined: 18 Oct 2012
Posts: 39
Location: Brasil

PostPosted: Wed Jan 30, 2013 1:34 am
Reply with quote

Because our problem, apparently, is related to DB2/SQL, I decided to post it at this section of the forum. If, by any chance, any forum moderator/administrator concludes that it should be posted elsewhere, please, move it to the appropriate section.

We are moving our TDSz-1.8.0 (Tivoli Decision Support for z/OS, version 1.8.0) from a z/OS-1.9 + DB2-V8 environment to a z/OS-1.13 + DB2-V10 one.

TDSz works intertwined with DB2/SQL. In a extremely brief explanation, TDSz reads any kind of log (SMF, IMS, CICS, DCOLLECT, or any other log the user could define the records) and populates DB2 tables with the data.

We have TDSz working for many years now in the z/OS-1.9 environment, and successfully installed it in the z/OS-1.13, including the DB2 tables needed, copied data (from z/OS-1.9) using DB2 unload/load and where able to access this data through TDSz panels or TDSz jobs.

The problem arises when we try to feed new data, using the COLLECT function of TDSz to read data from a log (we tried with many diferent SMF logs and some DCOLLECT logs). As far as I can understand (but not totally sure about that), the COLLECT somehow is “translated” into DB2 INSERTs.

The COLLECT job (it doesn’t matter wich log we use as input and wich DB2 tables as output) always end with the message:

DSNT408I SQLCODE = -302, ERROR: THE VALUE OF INPUT VARIABLE OR PARAMETER NUMBER 1 IS INVALID OR TOO LARGE FOR THE TARGET COLUMN OR THE TARGET VALUE

For sure, the values are not invalid or too large, and besides that, the collect, with the same logs and DB2 tables works perfectly well in the z/OS-1.9 environment.

I’m posting this problem here in the hope that some DB2/SQL user could have received the same SQLCODE but the reason for that was not what the sqlcode text says.

Any other hint/suggestion will be also very much appreciated. Please, note I understand TDSz reasonably well, but from DB2/SQL only as much as needed in order to interact with TDSz.
Thanks in advance!
Back to top
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10873
Location: italy

PostPosted: Wed Jan 30, 2013 1:46 am
Reply with quote

why not ask directly IBM ???
Back to top
View user's profile Send private message
PeterHolland

Global Moderator


Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen

PostPosted: Wed Jan 30, 2013 1:17 pm
Reply with quote

Maybe the following is relevant to you :

3. Processing SMF data generated by DB2 10 for z/OS subsystems

You must apply maintenance to your TDSz system before processing data produced by DB2 10 for z/OS. TDSz support for processing SMF data generated by DB2 10 for z/OS is provided by the following APARs:

■PM18699 provides toleration support for DB2 10 for z/OS data.
■PM25741 provides support for DB2 10 z/OS compressed records.

found here :

www.ibm.com/developerworks/wikis/display/tivoli/Tivoli+Decision+Support+for+zOS+Installation+Scenarios+Installation+and+Migration#TivoliDecisionSupportforzOSInstallationScenariosInstallationandMigration-6
Back to top
View user's profile Send private message
Ricardo Viegas

New User


Joined: 18 Oct 2012
Posts: 39
Location: Brasil

PostPosted: Wed Jan 30, 2013 9:05 pm
Reply with quote

Quote:
"why not ask directly IBM ???"

if that were possible, I would have certainly done

Quote:
"Processing SMF data generated by DB2 10 for z/OS subsystems"

we are not using DB2 SMF records; we use mainly RMF/MVS/VSAM SMF records and a few others, like DCOLLECT, IMS, etc. Collecting any of them results in the same problem (SQLCODE=-302).
Just emphasizing observation from the initial post: Exactly the same collects works perfectly well in the z/OS-1.9 + DB-v8 environment.

thx!
Back to top
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10873
Location: italy

PostPosted: Thu Jan 31, 2013 1:41 am
Reply with quote

Quote:
if that were possible, I would have certainly done


there is no reason for us to spend our time just to let Your organization save money on maintenance contracts

icon_evil.gif
Back to top
View user's profile Send private message
Ricardo Viegas

New User


Joined: 18 Oct 2012
Posts: 39
Location: Brasil

PostPosted: Thu Jan 31, 2013 11:19 am
Reply with quote

we are an ibm business partner; our agreement does not entitle us to have technical support.
Back to top
View user's profile Send private message
Ricardo Viegas

New User


Joined: 18 Oct 2012
Posts: 39
Location: Brasil

PostPosted: Sat Feb 23, 2013 3:10 am
Reply with quote

I posted this same problem in an IBM Forum for TDSz. A few days ago I received following info that I would like to share with everybody:

Quote:
You need to first put on the PTFs for APARs PM47009 and PM50083 (and all their pre-requisite PTFs) to upgrade your new TDSz to zOS V1R13 toleration support level, before you collect V1R13 SMF records. When you put on these PTFs, please follow the HOLD actions carefully.


In our condition of an IBM business partner we most probably will go through a longstanding process to get all the needed PTFs. But, as soon as we get and install them, I will post informing the results.

Regards, Ricardo
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> DB2

 


Similar Topics
Topic Forum Replies
No new posts SQLCODE = -122 while using the scalar... DB2 4
No new posts SQLCODE = -16002 when using XMLEXISTS DB2 1
No new posts Is SQLCODE -811 possible while fetchi... DB2 1
No new posts SQLCODE=-204 SQLSTATE=42704 DB2 4
No new posts Getting sqlcode 805 while executing R... DB2 10
Search our Forums:

Back to Top