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

Environment Issue in COBOL Program


IBM Mainframe Forums -> COBOL Programming
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Wed Aug 31, 2011 2:55 am
Reply with quote

Quote:
there is a difference creeping up in the fetch criteria of the SQL.
I've managed to control myself - til now. . .

Don't ya just hate it when things creep up in the fetch criteria. . . icon_cool.gif

Scope creep is rather common, but fetch creep. . .

@Vishwa
Just in fun - nothing personal icon_smile.gif

d
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Wed Aug 31, 2011 11:27 pm
Reply with quote

Ed Goodman wrote:
Could also be a compile difference. I got bit by the NUMPROC option once. In prod, a signed COMP-3 was being left as x'00000F', while in test, it was being converted to x'00000C'.

[...]


Ed,

Just out of interest, did you find the bug and fix the data, or just let it run with NUMPROC(NOPFD)?
Back to top
View user's profile Send private message
GuyC

Senior Member


Joined: 11 Aug 2009
Posts: 1281
Location: Belgium

PostPosted: Fri Sep 02, 2011 7:35 pm
Reply with quote

checking wrong tables because of different qualifiers was also a possibility.
Back to top
View user's profile Send private message
Ed Goodman

Active Member


Joined: 08 Jun 2011
Posts: 556
Location: USA

PostPosted: Sat Sep 03, 2011 1:15 am
Reply with quote

Bill,
The "shop standard" is NOPFD, so we changed our test compiler to be the same. Then we fixed the new code to work correctly (as expected) with that option active.
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Sat Sep 03, 2011 1:22 am
Reply with quote

Good-oh.

Do you remember how the field got to get an "F" sign in it? Just curious. PFD trips up (can) with the "F", NOPFD generate bus-loads of extra code. I'd like PFD, but if it can be too "easy" to get the "F"s, it is pretty useless.
Back to top
View user's profile Send private message
Ed Goodman

Active Member


Joined: 08 Jun 2011
Posts: 556
Location: USA

PostPosted: Sat Sep 03, 2011 1:45 am
Reply with quote

Bill,
In this case, the number NEEDED to be unsigned, so that the field could be used as the key for an IMS call. The "error" was that someone signed the working storage field.

So... with PFD, it changed the C to an F and worked during testing. Once it got to prod (or compiled for prod anyway) it quit working.

The fix was to remove the sign from the working storage field. then go to that developer's libraries and find all of their compiles and update the parms.
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 -> COBOL Programming Goto page 1, 2  Next

 


Similar Topics
Topic Forum Replies
No new posts Replace each space in cobol string wi... COBOL Programming 3
No new posts Using API Gateway from CICS program CICS 0
No new posts COBOL -Linkage Section-Case Sensitive COBOL Programming 1
No new posts SFTP Issue - destination file record ... All Other Mainframe Topics 2
No new posts COBOL ZOS Web Enablement Toolkit HTTP... COBOL Programming 0
Search our Forums:

Back to Top