× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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 thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.