AFP files won't load

[fnb4321]

  We are in the process of upgrading from 9.5.0.11 to 10.1.0.5 and are currently testing sending different report formats to the 10.1 cert server.

  Line mode reports are loading with no issue but AFP files are failing with the APK448S error (indexing was requested but no trigger info was found, etc..). I verified the trigger info is there and the same files load into the same version of the app group/application on our 9.5 CMOD server with no issue.

  I am basically doing a dual load - sending the file(s) to both the 9.5 server and the other to the new 10.1 cert server.  The files load on the 9.5 server but fail on the 10.1 server.  The app groups/applications were copied from the 9.5 server to the 10.1 server so they are identical.
  I am stumped..  Anyone ever ran into this issue ?

[Ed_Arnold]

Could this be your situation?

PH18294 - V10.1 ANYEXIT is not called when INDEXSTYLE=AFP

The APAR is still open but there is a ++APAR test fix available.

Ed

[fnb4321]

Thanks Ed - I don't think it is related to that but I will look into it.  Below are the actual indexer parameters being used - I do not see any exit or INDEXSTYLE=AFP reference.

cc = yes
cctype = a
convert = yes
cpgid = 500
field1 = 0,18,7                     
field2 = 0,25,5                     
field3 = 0,30,17                   
field4 = 0,47,40                   
field5 = 0,87,8                     
field6 = 0,87,8                     
fileformat = record
imageout = asis
index1 = X'E2E3A89785',field1                               
index2 = X'C2819592D596',field2                             
index3 = X'C18383A3D596',field3                             
index4 = X'C3A4A2A3D5819485',field4                     
index5 = X'E2C481A385',field5                               
index6 = X'E2D78599899684',field6                       
indexstartby = 99
formdef=F1CSFCRE                   
reslib = /arscfg/resources:/arscfg/fonts
restype  = fdef,pseg,ovly
trigger1 = *,1,X'5A008AD3EEEE000000'
INDEXOBJ=ALL

[fnb4321]

  So I have a little more info.

When attempting to load/index the AFP files on Linux server (using version 10.1.0.5) it is not recognizing the AFP NO-OP records that we are using as the base trigger info.

  The arsafpd command shows that the NO-OP records are there.  If I change the trigger to something other than the X'5A' NO-OP then the files load with no issue.

 The same exact files loading on to current prod AIX server (using version 9.5.0.11) load with no issues.

Could there be some difference between AIX and Linux servers in regards to codepage that would cause the NO-OP records not to be recognized on the Linux server ?

[frasert]

The app groups/applications were copied from the 9.5 server to the 10.1 server so they are identical

I've seen instances where "copying" the application group and application objects can produce discrepancies between the copies.  I haven't really nailed this down as to exactly how and when this happens but I've seen "Date(old)" fields change to "Date" fields just from doing a copy, for example.

So I would run an 'arsxml export' on your original App Group and compare that with another 'arsxml export' of the copied App Group to see if there are any differences.

I know this has surprised me before!

[frasert]

With that 'arsxml export' make sure to use the '-r a' parameter to include application objects.

[frasert]

Found this from the Help pages of the Administrator Client.  Apparently changing Date(old style) to Date is normal behavior, or at least called out in the Help:

Content Manager OnDemand Version 9.0 introduced a new style for Date, Date/Time, or Date/Time (TZ) fields that increases the range of dates. An application group cannot contain Date, Date/Time, or Date/Time (TZ) fields of both styles; those fields in an application group must use one style or the other. When you copy or export application groups, Content Manager OnDemand changes Date, Date/Time, or Date/Time (TZ) fields from the old style to the new style. If you do not want to use the new style when you copy an application group, you can change those fields to the old style before adding the application group.

Anyways, this is likely not even your issue.  Just wanted to call that out in case folks were not aware.

[Lars Bencze]

The app groups/applications were copied from the 9.5 server to the 10.1 server so they are identical

I've seen instances where "copying" the application group and application objects can produce discrepancies between the copies.  I haven't really nailed this down as to exactly how and when this happens but I've seen "Date(old)" fields change to "Date" fields just from doing a copy, for example.

So I would run an 'arsxml export' on your original App Group and compare that with another 'arsxml export' of the copied App Group to see if there are any differences.

I know this has surprised me before!

If you don't feel like comparing XML files, you could also use the "Compare" functionality in the OD Administrator tool. It highlights any differences found, which makes them super easy to spot.

[fnb4321]

OK - finally figured out what the issue was in case anyone else runs into.

For this upgrade we will be moving from AIX to Linux servers.

The reason the AFP files would not load on the Linux servers is because AIX is big endian and Linux is little endian.

So - I have to change the NO-OP trigger so that the least significant value in the sequence is stored first at the lowest storage address.

[Justin Derrick]

Wow.  That's the first time I've seen that be an issue in relation to CMOD.

Sounds like that should be a bug report to IBM for improvement -- either identifying BE/LE data in AFP files, or offering the option to correct the interpretation of those records on the way in. 

Would you consider posting to the Enhancements Forum?

-JD.