HolderAndrew
Well Known Member
Hi everybody,
First time in a while that I have posted an issue, I hope there is some guru out there that can help!
I have been working on a new development request on an E1 9.0 system on iseries to get the IFS file listing (which contains a list of inbound orders) to an E1 described table.
There are various ways to do this, but one simple way is to use the native commands DSPLNK OBJ('/IFSDir/Orders/*') OUTPUT(*PRINT) and then CPYSPLF FILE(QSYSPRT) TOFILE(LIBRARY/F55XXXX) to a file. (I have also used QSH commands to get IFS listing but ends up with same issue as described below). The F55XXXX table contains one column only having length 132 and when generated from within E1 I can see the attributes on iseries are 132G for Graphic ie. total length 264 and CCSID(13488) *CONVERT for unicode conversion.
The big problem that I have is that the CPYSPLF command only seems to work when copied to a table having non-unicode characteristics since I was getting CCSID conflict messages. So I deleted the F55XXXX and F55XXXX_1 (which were created from E1 earlier) and then created a DDS for the F55XXXX having single field defined as 132G graphic and CCSID(65535) and compiled. The CPYSPLF command above then works ok and all the spool file contents are copied ok to F55XXXX and I can see the details inside E1 ok (either in application or in UTB for example).
I have a simple UBE report R55XXXX which reads data from F55XXXX and then does some processing. The UBE R55XXXX report works perfectly when ran locally on dev client but not on the server. Debug logging from server shows no detailed information as the process terminates immediately after the “SELECT * FROM LIBRARY/F55XXXX” line of code. We have tried usual things, redeploying packages, removing sql packages, new versions etc. with no luck. I suspect that the problem is with the server failing to retrieve the data from F55XXXX due to the CCSID conflicts but I have no evidence of this.
Have you please any ideas how or why this might be happening? We did try to setup a non unicode database source and then set up OCM mapping for the F55XXXX table but this didnt work either.
Is there any other way that you know of to get the spool file contents into an E1 unicode defined table that has CCSID of 13488? Or indeed a better method to get IFS details into E1?
Any assistance would be appreciated.
Best Regards
Andrew
First time in a while that I have posted an issue, I hope there is some guru out there that can help!
I have been working on a new development request on an E1 9.0 system on iseries to get the IFS file listing (which contains a list of inbound orders) to an E1 described table.
There are various ways to do this, but one simple way is to use the native commands DSPLNK OBJ('/IFSDir/Orders/*') OUTPUT(*PRINT) and then CPYSPLF FILE(QSYSPRT) TOFILE(LIBRARY/F55XXXX) to a file. (I have also used QSH commands to get IFS listing but ends up with same issue as described below). The F55XXXX table contains one column only having length 132 and when generated from within E1 I can see the attributes on iseries are 132G for Graphic ie. total length 264 and CCSID(13488) *CONVERT for unicode conversion.
The big problem that I have is that the CPYSPLF command only seems to work when copied to a table having non-unicode characteristics since I was getting CCSID conflict messages. So I deleted the F55XXXX and F55XXXX_1 (which were created from E1 earlier) and then created a DDS for the F55XXXX having single field defined as 132G graphic and CCSID(65535) and compiled. The CPYSPLF command above then works ok and all the spool file contents are copied ok to F55XXXX and I can see the details inside E1 ok (either in application or in UTB for example).
I have a simple UBE report R55XXXX which reads data from F55XXXX and then does some processing. The UBE R55XXXX report works perfectly when ran locally on dev client but not on the server. Debug logging from server shows no detailed information as the process terminates immediately after the “SELECT * FROM LIBRARY/F55XXXX” line of code. We have tried usual things, redeploying packages, removing sql packages, new versions etc. with no luck. I suspect that the problem is with the server failing to retrieve the data from F55XXXX due to the CCSID conflicts but I have no evidence of this.
Have you please any ideas how or why this might be happening? We did try to setup a non unicode database source and then set up OCM mapping for the F55XXXX table but this didnt work either.
Is there any other way that you know of to get the spool file contents into an E1 unicode defined table that has CCSID of 13488? Or indeed a better method to get IFS details into E1?
Any assistance would be appreciated.
Best Regards
Andrew