|
Joe, Yes, we did try just a program with the SQL fetches in it, and a ZPA file with just those records. It still failed. My colleague Sally has managed to get CEA502B2 to retrieve the correct CEAAPCTL data from ZPA by adding another SQL statement specifically to do that. But this just moves the problem to the next program, CEA510D, which tries to retrieve records from the GWF file but gets the first record multiple times. She is now looking at using a Prepare statement to force it to rebuild the ODP. (Hope that makes sense, I'm the systems person, she's the programmer). It is strange though isn't it? It worked at V4 but doesn't work at V5R2, also it works on the other company's environment. I suspect SQL, because the database monitor is also not working - we have the same problem I saw at an earlier version of OS/400, where if you run the monitor it crashes the BPCS jobs. Any more thoughts? Thanks, Clare ----- Original Message ----- From: "Joe Pluta" <joepluta@PlutaBrothers.com> To: <midrange-l@midrange.com> Sent: Wednesday, December 04, 2002 7:44 AM Subject: RE: Help needed on V5R2 problem with BPCS CEA and CCSID > > From: Clare Holtham > > > > We have a strange problem at a client in Sweden, can anyone help? > > Or can anyone suggest a change to SQL or ODPs or CCSIDs at V5 > > which might affect the way these things work?? (IBM are looking > > at the problem...) > > > > If we remove the SQL statement and use an RPG Chain, that works. > > If we do the SQL interactively, that works. > > If we use ISDB on the pgm, this is what appears to happen - > > The pgm retrieves a record from ZPA (PLANLCTN) with the correct data (01) > > The pgm then goes to record CEAAPCTL in ZPA, but comes back with > > the previous record's data (01). > > So is it not resetting the pointer, or not flushing the buffer, > > or not moving the new data into the fields?? > > Clare, this is a very strange problem. The fact that interactive SQL works > but embedded SQL does not really bothers me. > > Have you tried writing a simple program that does just the two SQL fetches > using embedded SQL and see if that works? I'd like to try to isolate this > down to the very minimum required to blow up. > > My initial thought is that maybe (just maybe) there's some sort of ALIAS or > VIEW in place that's pointing you at the wrong data. But at this point, SQL > becomes a magic black box, and this is just one more reason I prefer to use > native access. > > Joe > > _______________________________________________ > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list > To post a message email: MIDRANGE-L@midrange.com > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l > or email: MIDRANGE-L-request@midrange.com > Before posting, please take a moment to review the archives > at http://archive.midrange.com/midrange-l. > >
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.