We have been working on the IFS replication process for RAP and came across a problem with the rename process. When a rename of an IFS object takes place a T OM audit entry is generated in the Audit journal when the object is set up for Audit control.
We wanted to be able to to create a RNM command from the information supplied allowing us to run the command against a target IFS with the objective of keeping each side in synch. We coded up the process to carry out the request but it failed every time on the target stating the NEWOBJ parameter was incorrectly formed, we had taken the New Absolute Path information and used it define the new object information. The problem was the Absolute Path has the complete path including the object name so the fact that it started with a ‘/’ caused the request to error. Reading the help text showed us the error of our ways!
This led us to start looking at the New Object Name information, we could use the Old Absolute Path Name for the OBJ part of the command and use the New Object Name for the NEWOBJ part of the command. But when we coded this up we also found the command would fail every time on the target! This time no information was copied from the journal entry into the NEWOBJ part of the command string!
We looked at the data in the journal entry and noticed it was not as we expected (according to the manual it should be a NULL terminated string) but was infact what appeared to be a set of ASCII characters each with a 0x00 character between each one, translation of the ASCII characters did correctly translate to our required information. After some discussions with IBM we found out the data was stored in CCSID 1200, further investigation also showed that this CCSID was wide character based which explained the 0x00 between each of the characters. So we now had the right information to work with!
Initial attempts to code up the conversion from 1200 to 37 failed at various stages, we are using the iconv() API for the conversion which would throw out errors after doing part of the conversion. Again we found out more by trial and error than information from the documentation that when you pass in a wide string to the iconv() API it has to be told the full length of the string as multiples of 2. We had been working out the length of the string using wcslen() and adding 1 for the NULL termination, we needed to add 2 for the NULL termination for the inconv() API to correctly carry out the conversion without errors.
Once we had that figured out, the program correctly formed the command string and it runs with out error on the target system. Having gone through all of that we did however stick with our original solution which was to take the New Absolute Path Name and extract the object name from it. We felt the overhead of running the iconv() process for every request would add to much overhead especially as the data is already provided in the correct CCSID for us to work with.
I have suggested IBM review the detail in the Manual, the information could be misleading to some as it was to us. Our assumption that the CCSID defined at offset 885 only referred to the Old Object Name was incorrect. The Old Object Name is also length specified which the New Object Name is not. So if you are going to work with the IFS audit journal entries please bear this in mind, it could save you a lot of time..
I hope that helps others avoid the silly mistakes we made… Thanks to IBM for the support they provided us in tracking down the real reason for the missing data…