Loads Failing after upgrade to 10.1 - Possible change needed in parms?

[htees]

Hi Folks; One day in to the 10.1.0.5 upgrade we are getting failures for Line data Type reports with the below error:

  ARS5481I TRIGGER1=*,1,X'F1',(TYPE=GROUP)                                     /* 1            */
 ARS5481I TRIGGER2=*,4,X'D1D6C2D5C1D4C5',(TYPE=GROUP,RECORDRANGE=(25,35))     /* JOBNAME      */
ARS5488E INVALID INDEXING PARM. ERROR OCCURS NEAR RECORDRANGE
 ARS5481I FIELD1=0,14,8,(TRIGGER=2,BASE=0)
 ARS5481I FIELD2=0,59,8,(TRIGGER=2,BASE=0)
 ARS5481I INDEX1=X'D1D6C2D5C1D4C5',FIELD1,(TYPE=GROUP,BREAK=YES)              /* JOBNAME      */
 ARS5481I INDEX2=X'D7D6E2E3C9D5C76DC4C1E3C5',FIELD2,(TYPE=GROUP,BREAK=NO)     /* POSTING_DATE */
 ARS5481I DCFPAGENAMES=NO


Do you see any issues with the indexing code here?

[Greg Ira]

Which Indexer are you using?

[Ed_Arnold]

I've run into this before:

http://www.odusergroup.org/forums/index.php?topic=2252.msg9928#msg9928

I'm guessing that it's a parentheses thing.

Ed

[htees]

using 390 indexer.   Started moving RECORDRANGE to it's own line, and it started working....... is comma no longer a good separator?

[Ed_Arnold]

Hmmm  - this is interesting:

https://www.ibm.com/support/knowledgecenter/en/SSEPCD_10.1.0/com.ibm.ondemand.ir.doc/dodif008.htm

The OS/390 Indexer was rewritten starting in CMOD V10.1 as it was ported to multiplatforum (LUW) CMOD.

Some restrictions previously unenforced now are.

Could it be connected to this?

The TYPE=GROUP,RECORDRANGE=(start,end format is not supported by the 390 indexer.

Ed

[htees]

WHAT i HAVE FOUND TODAY.......

Ed's response "Some restrictions previously unenforced now are."

Truth.......it appears some things that were a default (I.E. excluding quotes around index names) and other parms that may have been ignored by previous versions (I.E.  GROUPMAXPAGES values)  are now throwing errors and causing loads to fail.

It appears there is a new indexing sheriff in town, and the 390 indexer is a bit more discerning.

[Greg Ira]

Yes.  We just ran into this when running test on V 10.1  Previously recordrange was working with OS/390 indexer (despite saying it didn't in 9.5)  At 10.1 applications using it started failing.

[htees]

If RECORDRANGE is longer valid, what is our option?  Do we just remove it and hope that the indexer will find our triggers in the position where they exist?
For the below definition, we are telling it to look in a specific  location......does it now just look at the entire page?

TRIGGER2=*,4,X'D1D6C2D5C1D4C5',(TYPE=GROUP,RECORDRANGE=(25,35))

Or do we now just have to evaluate each report for better trigger setup?

[Greg Ira]

Can you use the ACIF indexer instead of the OS/390?

[Ed_Arnold]

Aha! 

Apologies for not catching this quicker.

PTF UI65475

PH15018 -                                                           
  OS/390 INDEXER V10.1 NOT IGNORING RECORDRANGE PARAMETER.           
  PROBLEM SUMMARY:                                                   
  ****************************************************************   
  * USERS AFFECTED: All Content Manager OnDemand for z/OS 10.1   *   
  *                 and above                                    *   
  ****************************************************************   
  * PROBLEM DESCRIPTION: When using the 390 indexer a            *   
  *                      RECORDRANGE with two closing            *   
  *                      parenthesis is flagged as an error.  A  *   
  *                      RECORDRANGE with one closing            *   
  *                      parenthesis is ignored.                 *   
  ****************************************************************   
  ARGL390Z was not ignoring a syntactically valid RECORDRANGE       
  specification.                                                     
  PROBLEM CONCLUSION:                                               
  ARGL390Z is changed to ignore a RECORDRANGE with two closing       
  parenthesis. It will continue to ignore a RECORDRANGE with only   
  one closing parenthesis.                                           

Ed

[Ed_Arnold]

If I understand and recall correctly, RECORDRANGE has been completely ignored since the demise of CMOD V2.

It has been tolerated to save folks from having to update indexing parms.

The APAR/PTF came about because under certain circumstances as noted in the APAR description it was no longer being ignored.

Ed