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



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



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.