ARS5479E INVALID INDEXING PARM

[hbusk]

Hi

I'm doing an upgrade of z/OS OnDemand from V7.2.1.6 to V8.5.0.6 via V7.1.2.9 and V8.4.1.7.

I have now reached the final level and suddenly I get the above error when running a load job.
The same load job ran without errors on the two intermediate levels.

Full error message:

arsload: Using /tmp/arstmp for temporary files                                                                                     
arsload: Processing file >/tmp/arstmp/67114011 (DD:INPUT-NULLFILE)<                                                               
arsload: Load Version <8.5.0.6> Operating System <z/OS> <04.24.00>                                                                 
arsload: Server Version <8.5.0.6> Operating System <z/OS> <04.24.00> Database <DB2> <10.01.0005>                                   
arsload: 10/16/15 11:09:38 -- Loading started, --UNKNOWN-- bytes to process                                                       
The following message was returned from the OS/390 indexer (ARSZSTDR error_message = ARS5479E INVALID INDEXING PARM. NUMERIC VALUE
XPECTED AT COL 00008. FOUND >0.1< INSTEAD. PARM STARTS WITH FIELD1=0.1,30,(TRIGGER=1).                                             
The OS/390 indexer failed with the specified return code. (Arsl390 return code is 4).                                             
Loaded 0 rows into the database                                                                                                   
arsload: 10/16/15 11:09:39 Loading failed                                                                                         
arsload: Processing failed for file >/tmp/arstmp/67114011 (DD:INPUT-NULLFILE)<                                                     
arsload: Processing has stopped.  The remaining files will NOT be processed.                                                       


And here are the Indexer Parameters:

CPGID=277
FILEFORMAT=RECORD
TRIGGER1=*,1,X'F1',(TYPE=GROUP)
FIELD1=0.1,30,(TRIGGER=1,BASE=0)
INDEX1='index_key',FIELD1,(TYPE=GROUP,BREAK=YES)
ANYEXIT=NFOSXANY


Found this on ibm.com...

Additional syntax checking for the indexing parameters


Technote (FAQ)

Question

Does the OS/390 Indexer of Content Manager OnDemand for z/OS have additional syntax checking functionality for indexing parameters?


Answer

The indexing parameters are text strings. Several parameters contain values that must be converted to integers.
All string values from the indexing parameters that get converted to integers are now checked to ensure they can successfully be converted to integers.

The ARS5479E message is generated when an invalid string value is found which causes the load to fail.

An example of this message is:

ARS5479E INVALID INDEXING PARM. NUMERIC VALUE EXPECTED AT COL 00008. FOUND >=1< INSTEAD. PARM STARTS WITH TRIGGER=1=*,1,X'F1',(TYPE



My guess is that the period in "FIELD1=0.1" is the problem, but what contents should I end up with in the FIELD1 parameter when trying to solve the problem?

We have had an IBM consultant coding all the OnDemand definitions around the application using the above Indexer Information including the ANYEXIT in use.
So I can't assess the impact of fx changing the parameter to

FIELD1=0,1,30,(TRIGGER=1,BASE=0) or something else.


I am also curious to know this apparently has been working without problems on V7... and V8.4.


Any help will be highly appreciated.



Regards
Hans Busk 

 

[Justin Derrick]

I'm not familiar with the OS/390 indexer, but that looks like a simple typo.  I'd change it and let the loads run.  (It's already failing, you're not going to make it any worse!)

-JD.

[Ed_Arnold]

There have been several PTFs to the OS/390 Indexer since 8.5.0.6.

Any chance of coming up to 8.5.0.10 and putting on all service to date?

Ed

[Alessandro Perucchi]

Hello Hans,

you wrote

The following message was returned from the OS/390 indexer (ARSZSTDR error_message = ARS5479E INVALID INDEXING PARM. NUMERIC VALUE
XPECTED AT COL 00008. FOUND >0.1< INSTEAD. PARM STARTS WITH FIELD1=0.1,30,(TRIGGER=1).                                             

and also:

My guess is that the period in "FIELD1=0.1" is the problem, but what contents should I end up with in the FIELD1 parameter when trying to solve the problem?

We have had an IBM consultant coding all the OnDemand definitions around the application using the above Indexer Information including the ANYEXIT in use.
So I can't assess the impact of fx changing the parameter to

FIELD1=0,1,30,(TRIGGER=1,BASE=0) or something else.

and if you look at this link: http://www-01.ibm.com/support/knowledgecenter/SSEPCD_9.5.0/com.ibm.ondemand.ir.doc/dodiz007.htm
it says clearly:

FIELDn=record,column,length,(TRIGGER=n,BASE={0|TRIGGER})

so the 0.1 is wrong, it should be 0,1

Why does it work before with v7 and v8.4? All I know is that there are a lot more checks in CMOD as before, and even more in V9+.

The consequencee for already archived document is null. The consequence for new documents would be that they can be loaded today, instead of not being loaded.
After you can load a document, please check that all your indexes have been extracted as wanted.

If not, then reuse the graphical gui from the admin client, and redo your ACIF indexing.


As Ed said, if you are going to upgrade to 8.5.0.6... why are you not upgrading to 8.5.0.10? That doesn't make any sense, especially that 8.5.0.6 is already several years old...

And don't forget that cmod 8.5 is end of support in less that 6 month... so I would go to V9 and skip 8.5, if you are already in the upgrade mode.
--
Alessandro

[hbusk]

Hi all

Thanks for your answers. They helped me out. The documents are loading now. Huge difference between  a   ,   and a   .   

And why not push on to the next levels?
Well this upgrade was planned many months back. But due to different set backs in my company it was never executed.
Furthermore my close are more experienced colleague on OnDemand chose to retire during a restructuring period. So suddenly I had it all for my self. And I chose to carry out this already described plan instead of adding more steps to.
Hopefully I gain some knowledge so I feel confident to make an attempt for V9+ in a not so far future.

Regards and thanks again
Hans   

[Alessandro Perucchi]

Hi Hans,

I understand, not an easy situation you are in.

If we can help you, we will :-)

Kind regards,
Alessandro

[hbusk]

Hi Alessandro,

Thanks.

Really nice to know that there is someone to turn to if it gets too rough :-)


Kind regards
Hans