I was plagued this week by an odd problem on one of our i5 boxes. I was trying to use the CPYFRMIMPF & CPYTOIMPF to pull in data from a new Japanese division that uses nothing but Japanese characters in their data. This of course means UTF-8 / Unicode data, which can be a bit of a pain to set up in a DB2/i5 data table (particularly if someone forgets to make fields something other than CCSID 65535!)
Anyway.... I could get data off the system using the CPYTOIMPF into the IFS no problem at all, DBCS to UNICODE worked like a treat and everything was well with the world ... BUT ... try as I might I could not get CPYFRMIMPF to bring the data back into the DB2 file again.
There was a rather odd CPE3025 message that told me the input file or path did not exist (error code 3025) and yet there is was, I could open it, read it, edit and save it and everything seemed perfect .. but time after time I got the CPE3025 error and no data was transferred. I tried all day with no sucess and eventually went home hoping that a nights sleep would clear the mind and inspiration would come in the morning.
This morning came in an did a CPYTOIMPF which worked fine, did a CPYFRMIMF .. and .. it worked perfectly with no errors
After a bit of experimenting the culprit was discovered to be the fact that I had opened the file using Operations Navigator and even though the file had been closed normally Ops Navigator holds a lock on the file until Ops Nav is closed, the net effect of this is that the file is unavailable for the CPY* command.
Part of this analysis used a rather useful but lesser known API that you can use to track locks on objects in the IFS .. the api is this :
CALL QP0FPTOS PARM(*LSTOBJREF '/ifspath/ifsfile'
*FORMAT2)
You need to have the *SERVICE special authority and the api dumps the locks to a spool file.
Easy when you know how but not an obvious tool for this particular problem
No comments:
Post a Comment