|
View previous topic :: View next topic
|
| Author |
Message |
pshongal
New User
Joined: 14 Jun 2012
Posts: 96
Location: India
|
|
|
|
Hi all,
I have a strange issue as bellow.
Step 1: Unloading records from table TABLE1 using IKJEFT01 and writing to a file. These are KEY records.
Step2: Execute a Cobol program to fetch full record from VSAM using the keys fetched from step 1.
Step3: When the fetch is successful, delete that key record from TABLE1. If record is not found, write to reject.
Issue: first 2 steps are working perfectly. But facing issue in 3rd step. Here the first record is getting deleted, but for subsequent DELETES, it is throwing sqlcode 100.
What could be the issue? |
|
| Back to top |
|
 |
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8797
Location: Welsh Wales
|
|
|
|
| What did Mr Google say when you asked him ? |
|
| Back to top |
|
|
pshongal
New User
Joined: 14 Jun 2012
Posts: 96
Location: India
|
|
|
|
No response from google for this behavior.  |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
| Quote: |
Step 1: Unloading records from table TABLE1 using IKJEFT01 and writing to a file. These are KEY records.
|
You might want to review Your understanding of the terminology
telling that You are using iIKJEFT01 is a useless information
IKJEFT01 is the TSO terminal monitor program which just reads from the SYSTSIN DD a sequence of commands to be executed
( could be any sequence of arbitrary commands as defined by the product/application invoked - not necessarily DB2 or QMF or ISPF )
If You want to provide useful information You should tell the name of the DB2 Utility used/ the command invoked |
|
| Back to top |
|
|
Nic Clouston
Global Moderator
Joined: 10 May 2007
Posts: 2455
Location: Hampshire, UK
|
|
|
|
Step 2 is, presumably, an in-house program. But what about steps 1 and 3? Are they in-house, DB2 utilities or some 3rd party utilities? Any old way - nothing is "throwing" anything because nothing is "thrown" on a mainframe.
Do you know what an SQLCODE of 100 means? |
|
| Back to top |
|
|
pshongal
New User
Joined: 14 Jun 2012
Posts: 96
Location: India
|
|
|
|
Step 1 is not DB2 utility, but just a select statement in SYSIN of IKJEFT1A as below
| Code: |
SELECT * FROM DELTA1
WHERE DB2_TIMESTMP <= CURRENT_TIMESTAMP
WITH UR;
|
Step 3 is part of cobol program itself (of step2), where a successfully fetched record is being deleted as below.
| Code: |
EXEC SQL
DELETE FROM DELTA1
WHERE INST = :WSC-INST
AND CUST = :WSC-CUST
AND LDGR = :WSC-LDGR
AND ACCT = :WSC-ACCT
AND REC_TYP = :WSC-REC-TYP
AND NBR = :WSC-NBR
AND ACTION = :WSC-ACTION
AND DB2_TIMESTMP = :WSC-DB2-TIMESTAMP
END-EXEC.
|
I can see that record is present in DELTA1, but I am getting SQLCODE 100(record not found). I displayed the values to see whether correct values are populated in host variables, that also looks fine. |
|
| Back to top |
|
|
Nic Clouston
Global Moderator
Joined: 10 May 2007
Posts: 2455
Location: Hampshire, UK
|
|
|
|
Well, if you delete it then it will not be found subsequently unless you update the host variables. Are they being updated correctly?
As to the select statement in IKJEFT1A - I have no ide what that would do because, as Enrico pointed out, IKJEFT1A is TSO in batch and nothing more. What is your output from that? What is your JCL for that? Perhaps there is a prgram being run via the PARM to IKJEFT1A? |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
the TS did not get my hint about SYSTSIN  |
|
| Back to top |
|
|
Rohit Umarjikar
Global Moderator
Joined: 21 Sep 2010
Posts: 3053
Location: NYC,USA
|
|
|
|
I highly suspect you are incorrectly populating :WSC-DB2-TIMESTAMP .
| Quote: |
| I can see that record is present in DELTA1, but I am getting SQLCODE 100(record not found). I displayed the values to see whether correct values are populated in host variables, that also looks fine. |
Try to run sql by itself outside the program and see what happens. |
|
| Back to top |
|
|
Marso
REXX Moderator
Joined: 13 Mar 2006
Posts: 1353
Location: Israel
|
|
|
|
Instead of unloading a DB2 table and then reading the resulting sequential file, why don't you read the table directly from your cobol program:
1. Fetch one row
2. Use the key to read from VSAM file
3. If found, delete current row
4. If not found, write to reject
5. go to step 1
Declare the cursor WITH HOLD (so you can COMMIT from time to time) and FOR UPDATE.
Use DELETE WHERE CURRENT OF.
One step, one program, everything is under control.
| pshongal wrote: |
| Step 1 is not DB2 utility, but just a select statement in SYSIN of IKJEFT1A |
Best answer ever !!
| Quote: |
| nothing is "throwing" anything because nothing is "thrown" on a mainframe. |
Similarly, you do not fetch records from a VSAM file, you read them. |
|
| Back to top |
|
|
pshongal
New User
Joined: 14 Jun 2012
Posts: 96
Location: India
|
|
|
|
| Quote: |
| Well, if you delete it then it will not be found subsequently unless you update the host variables. Are they being updated correctly? |
| Quote: |
| I highly suspect you are incorrectly populating :WSC-DB2-TIMESTAMP |
Yes, TS is populated correctly. And other variables also are populated correctly. When I checked this outside the program, it works fine.
| Quote: |
| Instead of unloading a DB2 table and then reading the resulting sequential file, why don't you read the table directly from your cobol program |
Hi Marso, I had thought of this approach. My worry was whether this cause any outage? Because this is the trigger table and will have continuous inserts/Updates based on some online activity. |
|
| Back to top |
|
|
Nic Clouston
Global Moderator
Joined: 10 May 2007
Posts: 2455
Location: Hampshire, UK
|
|
|
|
| Quote: |
| When I checked this outside the program, it works fine. |
How can you check that the variables are filled correctly outside of the program? Have you displayed them immediately before executing the sql statement? And I mean immediately before, not 5, 10 whatever lines of code before. |
|
| Back to top |
|
|
Marso
REXX Moderator
Joined: 13 Mar 2006
Posts: 1353
Location: Israel
|
|
|
|
Whether you use your cobol program to fetch and delete (as I suggested) or to only delete (as you plan to do), you face the same problem: you have a cobol program updating a "live" DB2 table.
You have to check the locking level for this table, find which isolation clause fits best (not sure UR is what you need), and get a recommendation for your commit rate.
If you can contact a DBA, discuss all this with him.
I think that doing many DELETE WHERE CURRENT will be much faster than doing many individual DELETEs. |
|
| Back to top |
|
|
|
|
