>Dropping any table required by a package will invalidate that package. And
>creating a new table, even if it has the same name, will not right your
>>package, because that new table is a _different_ object.
>Why not simply TRUNCATE your tables if you want to empty them out before your
>test ru
>HI Janet,
>I noticed that the bind is binding DALLASA.DB2ZP.ZPDB2
>but the error is for DB2ZP.ZPDB2.1A320A2A009C519E.
>It looks like a mis-match between local and remote versions of the package.
>Regards,
> Ron
I've been looking for a way to have both the BIND and the RUN statements
O, and BTW, there is an excellent body of knowledge and knowledgeable people at
http://www.idug.org/p/fo/si/topic=19
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with t
On Wed, 2 Nov 2016 13:39:48 -0500, Janet Graff wrote:
>Yes this is part of my test automation so to make sure the result sets are
>clean I am dropping and recreating the tables every time through.
>
>Are you saying I need to sequence this? So the Drop/Create is done and THEN
>then BIND?
>
Ye
>I am not getting the DROP/CREATE table part here... Are these the tables that
>are used in your program? Because if they are, then dropping them >will
>invalidate all packages accessing them. And re-creating the tables will *not*
>rebind your packages. After all, even if they have the same name
>HI Janet,
>I noticed that the bind is binding DALLASA.DB2ZP.ZPDB2
>but the error is for DB2ZP.ZPDB2.1A320A2A009C519E.
>
>It looks like a mis-match between local and remote versions of the package.
>
>Regards,
> Ron
Ron,
What step do I fix that on and what keyword do I specify?
Tha
On Tue, 1 Nov 2016 16:07:59 -0500, Janet Graff wrote:
> DSN SYSTEM(DBAG)
>
>DSN
>
> BIND PACKAGE(DB2ZP) MEMBER(ZPDB2) ACT(REP) ISO(CS) CURRENTDATA(YES)
> E
On Mon, 31 Oct 2016 14:01:56 -0500, Janet Graff wrote:
>Truncations on the right side of the JES output, let me know if you need that
>data
>
>
> J E S 2 J O B L O G -- S Y S T E M S 0 W 1 -- N O D
> E
I am afraid I'll need to see all sysout as well...
Cheers,
Jantj
gt;
To: IBM-MAIN@LISTSERV.UA.EDU,
Date: 02/11/2016 05:08 AM
Subject: Re: SQLCODE=-904 during RUN
Sent by:IBM Mainframe Discussion List
>On Fri, 28 Oct 2016 18:12:01 -0500, Janet Graff
wrote:
>>I have the program pre-compile, compile, pre-linking, linking and b
>On Fri, 28 Oct 2016 18:12:01 -0500, Janet Graff wrote:
>>I have the program pre-compile, compile, pre-linking, linking and binding all
>>with return code zeros.
>Can we see the JCL, or better still, the entire job log?
...
>Jantje.
Here's the output from the bind
Again JES data truncated on
>On Fri, 28 Oct 2016 18:12:01 -0500, Janet Graff wrote:
>>I have the program pre-compile, compile, pre-linking, linking and binding all
>>with return code zeros.
>Can we see the JCL, or better still, the entire job log?
>>
>>But when I try to RUN I get a -904 indicating that the resource is
>>
On Fri, 28 Oct 2016 18:12:01 -0500, Janet Graff wrote:
>I have the program pre-compile, compile, pre-linking, linking and binding all
>with return code zeros.
Can we see the JCL, or better still, the entire job log?
>
>But when I try to RUN I get a -904 indicating that the resource is unavailab
I have written a simple DB2 program that I'd like to run from Batch. I'm on
IBM's Dallas service so I have a limited access to certain datasets.
I have the program pre-compile, compile, pre-linking, linking and binding all
with return code zeros.
But when I try to RUN I get a -904 indicating th
13 matches
Mail list logo