|
View previous topic :: View next topic
|
| Author |
Message |
sskpen
New User
Joined: 30 Aug 2006
Posts: 14
|
|
|
|
Hi All
I was trying to read an Input file and basing on the data in the file am trying to update a Db2 table,basing on my coding knowledge I had coded something similiar to this but came across with a strange situation
| Code: |
PERFORM UNTIL WS-EOF-TRUE-SW
READ xxx-file INTO WS-xxx-REC
AT END
SET WS-EOF-TRUE-SW TO TRUE
NOT AT END
PERFORM 2000-PROCESS-para THRU 2000-EXIT
END-READ
END-PERFORM.
2000-PROCESS-para.
PERFORM 2720-GET-xxx-ROW THRU 2720-EXIT UNTIL
WS-DUPLICATE-YES OR WS-FETCH-END-YES.
PERFORM 2730-CLOSE-xxx--CUR THRU 2730-EXIT.
IF WS-DUPLICATE-YES
PERFORM 3510-CAL-para THRU 3510-EXIT
PERFORM 3520-UPDATE-para THRU 3520-EXIT
ELSE
IF WS-FETCH-END-YES
PERFORM 3800-POP-para THRU 3800-EXIT
PERFORM 3850-INST-UPD-PARA THRU 3850-EXIT. |
after closing the cursor am doing a check and i want to execute the paragrpahs in the way mentioned above but the control is not returned back instead it is dropping off to the next statement which was coded in 2720-exit paragraph.Could someone suggest what might be the issue because this is the first time and infact its a strange situation wherein I had landed
Thanks
Sreekanth |
|
| Back to top |
|
 |
sskpen
New User
Joined: 30 Aug 2006
Posts: 14
|
|
|
|
after closing the cursor am doing a check and i want to execute the paragrpahs in the way mentioned above but the control is not returned back instead it is dropping off to the next statement which was coded after 2720-exit paragraph.Could someone suggest what might be the issue because this is the first time and infact its a strange situation wherein I had landed
small correction it is dropping off to the next statement which was coded after 2720-exit paragraph |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
| Usually when control drops through an exit paragraph, it is because the PERFORM is not active. Which in turn implies your program has a coding error allowing control to drop through the exit paragraph. |
|
| Back to top |
|
|
sskpen
New User
Joined: 30 Aug 2006
Posts: 14
|
|
|
|
Thanks for your reply
Initially I ran my code with good end of result.Basing on some requirement change Iam making a call to subroutine to pick up one of the fields and after incorporating the changes to make this call I had ended up with this scenario.
Is there a way to check where exactly my code is dropping off?
thanks in anticipation |
|
| Back to top |
|
|
CICS Guy
Senior Member
Joined: 18 Jul 2007
Posts: 2146
Location: At my coffee table
|
|
|
|
| I have found that displays showing location in the code and values of critical variables to be a very good aid. |
|
| Back to top |
|
|
sskpen
New User
Joined: 30 Aug 2006
Posts: 14
|
|
|
|
| Iam using IBM Debug in my shop ,tried setting couple of breakpoints and hitting the code them but still not able to trace where the code is dropping off.Could someone suggest where I can hit the point at which code is dropping off . |
|
| Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8796
Location: Welsh Wales
|
|
|
|
| CICS Guy wrote: |
| I have found that displays showing location in the code and values of critical variables to be a very good aid. |
|
|
| Back to top |
|
|
GuyC
Senior Member
Joined: 11 Aug 2009
Posts: 1281
Location: Belgium
|
|
|
|
dropping thru can have at least two causes :
1) you have a goto to somewhere outside para thru para-x .
This often happens when you copy source of para1 ... para1-x to create a new-para ... new-para-X and somewhere in newpara you forget to change "goto para1-x" to "goto newpara-x".
2) you're missing a goback/stop run in you first para or it is in an IF that wasn't true. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix
|
|
|
|
Hello,
Is the code you posted the actual code or just come bits you chose to post?
As written, the code will "fall thru" and execute the 2200-PROCESS para again after the end of file is detected. . . |
|
| Back to top |
|
|
sskpen
New User
Joined: 30 Aug 2006
Posts: 14
|
|
|
|
The problem with using host variables defined in LINKAGE SECTION is
>that it usually works
>Error appears when you call your program containing sql queries from
>two different programs.
>
>Example:
>PROG1 calls PROGX and PROGY.
>PROGX and PROGY call PROGSQL which uses LINKAGE SECTION variables as
>host variables.
>
>Then "strange" things could happen. I was getting SQLCODE +100 on the
>first query in the program. And I am sure that the record I was
>reffering to was present in the table. After some experimenting it
>turned out that the DB2 refers to a different place in memory than
>COBOL variables. It looks like during the first call of PROGSQL DB2
>remembers the addresses of host variables. During the second call the
>addresses are not "reinitialized" and DB2 refers to the wrong place in
>memory.
>If the variables from WORKING STORAGE are used as host variables
>everything is OK.
>
>My guess is that because WORKING STORAGE is allocated separately for
>each of the
>calls of the PROGSQL program - DB2 reinitializes the addresses every
>time the program is called. When the variables from LINKAGE SECTION are
>used as host variables DB2 decides that it is not necessery, to
>initialize the adresses again.
>
>If the PROGSQL would be called only from PROGX using LINKAGE SECTION
>variables as host variables it would propably cause no harm (although
>I'm not completly sure of it).
>
>Anyway - to solve the problem I decided to copy the contents of LINKAGE
>SECTION variables to some WORKING STORAGE variables and use them in
>queries. It helped.
>I learned that I could also set the SQL-INIT-FLAG at the beginning of
>the program to tell
>DB2 to reinitialize the addresses -
>
>I was wondering if someone have similar problems and maybe know some
>more about how DB2 decides to initialize or not to initialize the host
>variables addresses. |
|
| Back to top |
|
|
GuyC
Senior Member
Joined: 11 Aug 2009
Posts: 1281
Location: Belgium
|
|
|
|
@sskpen: 1) this should be a separate thread.
Yes, I had the same problem years ago when using variables from file-section. "read next" changes the address of the record in the buffer, but DB2 was always using the first record in the buffer.
You could mess around changing db2-internal flags, but who says this will work with the next version of DB2 . just use WS-variables |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
| sskpen wrote: |
>My guess is that because WORKING STORAGE is allocated separately for
>each of the
>calls of the PROGSQL program - DB2 reinitializes the addresses every
>time the program is called. When the variables from LINKAGE SECTION are
>used as host variables DB2 decides that it is not necessery, to
>initialize the adresses again. |
Bad guess
as you have read,
based on the SQL-INIT-FLAG, your program CAlls DB2 to provide the addresses of host variables.
The reason when using linkage as host-variables does not work when the SQL module is CALLed from more than one CALLing module,
is that the linkage points to different CALLing modules.
As long as a CANCEL command is not issued by a authorized module,
the working storage for the CALLed module remains the same for subsequent CALLs.
If the CALLed SQL module has the PROGRAM-ID INIT clause,
the SQL-INIT-FLAG would be the same on each invocation of the CALLed SQL module. |
|
| Back to top |
|
|
|
|
