ACIF INDEXER ISSUE

[DDP021]

Does anyone know of a way to ignore a invalid character in column 1 of the data when using the ACIF indexer?...We have a report that has x'c5' in column 1 on the LAST page...It does have a channel 1 in column one on this page but then it has these x'c5' in column 1 also...This report was originally defined using OS/390 and it didn't have an issue with this type of file...We even attempted to add another trigger and go off of indexing using it and NOT channel 1...Still had an issue..

APK346W DATA IN AN INPUT RECORD OR PAGEDEF RESOURCE IS INVALID: A SKIP TO A NONEXISTENT CHANNEL = 'C5'X ON RECORD NUMBER = 468645 WAS DETECTED WITHIN THE LND STRUCTURED FIELDS.
APK346W DATA IN AN INPUT RECORD OR PAGEDEF RESOURCE IS INVALID: A SKIP TO A NONEXISTENT CHANNEL = 'C5'X ON RECORD NUMBER = 468646 WAS DETECTED WITHIN THE LND STRUCTURED FIELDS.
APK346W DATA IN AN INPUT RECORD OR PAGEDEF RESOURCE IS INVALID: A SKIP TO A NONEXISTENT CHANNEL = 'C5'X ON RECORD NUMBER = 468647 WAS DETECTED WITHIN THE LND STRUCTURED FIELDS.

[rick]

Is it a line data report? If then and defined as CC, then the data need to be preprocessed to remove the non carriage control characters.

[DDP021]

yes it is line data with CC...Understood that it's a data issue...But sometimes going back to an Application telling them THEY need to change their data is a bit like pulling teeth...Especially when this same data loaded fine using OS/390 which doesn't care how this page is formated...The reason for trying to switch to ACIF is they were looking to modify the indexng on this report...This particular report has multiple applications using the same application group..So we are just looking to create a new application and application group for this one report...Was just looking to see of anyone knew how to work around this one page when using ACIF indexer...

[Justin Derrick]

Sadly, sometimes you get to be the dentist and pull those misbehaving teeth.

If their reports are poorly (incorrectly) formatted, you need to be able to show them the specification, and how they're not complying with it.

When I've had customers who couldn't (or, more accurately, wouldn't) make a change to bad data, the culprit was usually the cost of changing the existing code.

Slow, steady, even pressure in one direction (fix the code!) over a long period of time (sometimes years) can have moderate success.  Good luck!

[DDP021]

I hear ya Justin!....As you said, it normally always comes down to cost...In allot of our cases, the data is so old the people "supporting" it now don't even know what to do with it..So it's like chasing our tails trying to get ANYONE to even look into it....

[jeffs42885]

I had this issue a couple days ago and I added the invalid characters in my case it was ^L to the new line.

Bandaid on a bullet wound. Garbage in, garbage out

[jeffs42885]

So what happens if theres no ^M ^L or any kind of hidden buggers.

 DATA IN AN INPUT RECORD OR PAGEDEF RESOURCE IS INVALID: A SKIP TO A NONEXISTENT CHANNEL

Any thoughts?

[Justin Derrick]

Just ran across this today.

Manually remove the 'NEWPAGE=1' line from the ACIF indexing parameters, and try loading again.

I believe this is caused by defining the App as being codepage 850 (ASCII) and populating the 'New Page' field with a 1, then switching the codepage to 500 (EBCDIC).  This can happen when you're indexing reports you're not familiar with.

-JD.