Corrupt original order type (OCTO) in F4211 during SOE

HolderAndrew

Well Known Member
Hi all,

here's a strange one. A few weeks ago in our PY test environment (E1 8.11 base on iseries) we started to get corrupt values in the original order type column (F4211.SDOCTO) when creating sales orders. The problem on Jas server (JPYxx811) environment is repeatable every time but I get different corrupt value on dev client (ie, in PYxx811) env. When I debug on dev clientI cannot see the problem and OCTO is ok! Here are a few test orders that I have created. All were created in standard (non-modified as far as I know!) P42101. (We can also repeat this in P4210 but because we have modifications in that app I concentrated on P42101).

SDDOCO SDDCTO SDOCTO SDOORN
4092267 SO 0
4092270 SO
4092272 SO 
4092271 SO

Orders 4092270 and 4092271 were created on dev client in debug session and these are ok. Order 4092267 was created on dev client in normal (non-debug) session and OCTO got a value of '0'. On Jas server the value looks even worse with a value of ''.

We have now identified that this is a problem when we genuinely have original order number populated (eg. when creating credits).

I would really appreciate any help with this as it is a peculiar one!

Andrew
 
Hi Andrew,

Could be corrupted GLBLTBL/DDDICT/DDTEXT specs on your
Enterprise Server.
If I were you, I would do the following :

1. Build a full PY package
2. Stop JAS and JDE services
3. On the AS/400, delete GLBLTBL.*, DDDICT.* and DDTEXT.*
files under /PY811/specfile
4. Delete all *SQLPKG files except for those Q*.
5. Restart JDE services
6. Deploy your full PY package
7. Run a full webgen for PY
8. Restart JAS services
 
Hi Sebastian,

many thanks for the reply. This got me looking at package history and I can see that the problem started around same time as last full PY package so I think we'll try this asap.

Regards

Andrew
 
Back
Top Bottom