Help needed on V5R2 problem with BPCS CEA and CCSID

["Clare Holtham" <Clare.Holtham@xxxxxxxxxxxxxx>]

This is a multi-part message in MIME format.
--
[ Picked text/plain from multipart/alternative ]
Hi everyone,

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

The client has several companies running BPCS (and CEA) on an AS/400 in 
Gothenburg Sweden. The CCSID of the system is 278 (Swedish). They upgraded to 
V5R2 on 23/24 November from V4. There is a company based in Stockholm, also 
running BPCS (but with their own libraries of files and pgms) which was moved 
onto the same AS/400 recently. They previously used system CCSID 65535 (no 
translation) as advised by SSA for BPCS. They have therefore set their users' 
profiles to CCSID 65535. This worked OK before the v4-V5 upgrade.

Note: the CEA part of BPCS uses client/server.

Since upgrading, program CEA502B2 falls over with a decimal data error. We have 
tried fixing the data (in the ZPA file - system parameters, every record is 
different, they are accessed via external data structures) from both CCSIDs, 
restoring the file, rebuilding the data, etc.

In the Swedish environment everything works OK.

In the 65535 environment it doesn't work.

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??

If we change the pgm SQL statements as a workaround, that works OK, but the 
next pgm then goes to the GJW (GL Workfile) and retrieves the first record 
multiple times.

To summarise, the problem seems to be caused by some combination of the factors 
V5R2, SQL, and CCSID.

Any ideas anyone? Joe? Al?

Thanks in advance,

Clare

Clare Holtham
Director, Small Blue Ltd - Archiving for BPCS
web: www.smallblue.co.uk
IBM Certified AS/400 Systems Professional
E-Mail: Clare.Holtham@btinternet.com
Mobile: +44 (0)7960 665958
--