Author Topic: ACIF Indexer and Posting Date  (Read 9976 times)

DDP021

  • Sr. Member
  • ****
  • Posts: 343
    • View Profile
ACIF Indexer and Posting Date
« on: October 17, 2017, 04:42:57 AM »
Hi, we are ATTEMPTING to convert reports we have defined using the "old" OS390 indexer to ACIF Indexer...The issue we are having is, these reports want to use a Posting Date on the data.  Unfortunately the date isn't on every page of the report which we believe the ACIF indexer requires.  Is that correct?  If so, is there ANY way of converting these reports to ACIF and using the date on the data?

Greg Ira

  • Full Member
  • ***
  • Posts: 240
    • View Profile
Re: ACIF Indexer and Posting Date
« Reply #1 on: October 17, 2017, 06:01:07 AM »
There shouldn't be a problem using ACIF on data that doesn't have a date on every page you just have to get a little more creative in your indexing.  At the most basic you can put another trigger (or mask) in that lets the indexer know if there is a date there or not, for example trigger on '/' in mm/dd/yyyy.  Index the date off that trigger.  If no date exists ACIF won't complain.

DDP021

  • Sr. Member
  • ****
  • Posts: 343
    • View Profile
Re: ACIF Indexer and Posting Date
« Reply #2 on: October 17, 2017, 06:54:53 AM »
Greg, this is what is on the first page of the input file (along with other verbiage)....But this page is the ONLY page that has any date on it...

1*** FNI ON DEMAND REPORT ******************************************* PAGE     1
 FNI Messages for Date:10/16/17       

On the Indexer we have 2 triggers defined (see below)...There is no reference on the indexer for posting date...Its defined on the app grp as a filter and on the application, we have the 't'  in the default value so it just uses the ingestion date..

TRIGGER1=*,1,X'F1',(TYPE=GROUP)                                  /* 1              */
TRIGGER2=*,2,X'C1C3C3D6E4D5E37A',(TYPE=GROUP,RECORDRANGE=(1,4))  /* ACCOUNT:        */   

Are you indicating we should add another trigger (TRIGGER3) and specify the first "/" character on the date that's found on the first page? So it would look like this:

TRIGGER3=*,26,X'61',(TYPE=GROUP) 

Then indicate also add the following to the indexer:

FIELD19=*,24,10,(TRIGGER=3,BASE=0)                                  /*  POSTING DATE  */
INDEX19=X'D7D6E2E3C9D5C76DC4C1E3C5',FIELD1,(TYPE=GROUP,BREAK=NO)    /*  POSTING_DATE  */
                                     

Greg Ira

  • Full Member
  • ***
  • Posts: 240
    • View Profile
Re: ACIF Indexer and Posting Date
« Reply #3 on: October 17, 2017, 07:14:29 AM »
Yes, Something like that.  It doesn't have to be the '/' though that should work as long as there is no / in that same column on later pages.  You could be more specific and use 'Date:'   Either way it should do what you're asking.

DDP021

  • Sr. Member
  • ****
  • Posts: 343
    • View Profile
Re: ACIF Indexer and Posting Date
« Reply #4 on: October 17, 2017, 07:17:09 AM »
Thanks Greg!..We'll give it a try..should the POSTING DATE on the Application group be defined as an INDEX or left as a FILTER?

DDP021

  • Sr. Member
  • ****
  • Posts: 343
    • View Profile
Re: ACIF Indexer and Posting Date
« Reply #5 on: October 17, 2017, 07:49:31 AM »
Well must be doing something wrong....Tried loading and all I get is whats below..No actual error I can see..Just that it failed..tried having POSTING DATE set as an index and a filter on app group, same result

TRIGGER3=*,19,X'C481A3857A',(TYPE=GROUP)                         /* Date:          */
FIELD19=0,24,8,(TRIGGER=3,BASE=0)                               /* POSTING DATE        */
INDEX19=X'D7D6E2E3C9D5C76DC4C1E3C5',FIELD19,(TYPE=GROUP,BREAK=NO)    /*  POSTING_DATE  */

This is all the 88 msg shows at bottom

APK440I ACIF AT IM43P11 HAS COMPLETED NORMALLY WITH RETURN CODE 0.
arsload: 10/17/17 10:44:52 Indexing completed
arsload: 10/17/17 10:44:52 -- Loading started, 1149386 bytes to process
Loaded 0 rows into the database
Document compression type used - OD77.  Bytes Stored = >148< Rows = >0<
arsload: 10/17/17 10:44:54 Loading failed
arsload: Processing failed for file >/prod/ode/cmod/arsload3/GSYS.SRACDP2M.FNIAU2LX.FNIAU2LX.2017290.10303959987.ARD<

« Last Edit: October 17, 2017, 08:24:43 AM by DDP021 »

Greg Ira

  • Full Member
  • ***
  • Posts: 240
    • View Profile
Re: ACIF Indexer and Posting Date
« Reply #6 on: October 17, 2017, 08:30:26 AM »
Based on the sample you listed before try this for the trigger:
TRIGGER3=1,19,X'C481A3857A',(TYPE=GROUP)                         /* Date:          */

I think your issue might be you had * for record but type group instead of float.

DDP021

  • Sr. Member
  • ****
  • Posts: 343
    • View Profile
Re: ACIF Indexer and Posting Date
« Reply #7 on: October 17, 2017, 08:43:29 AM »
Still no good...I just wished the damn 88 message gave you SOMETHING to track down....Below is the entire indexer we're using....for the remainder of the indexing fields, we use the GROUP RANGE Trigger based on ACCOUNT ..whats strange is, prior to trying to use the Posting Date, we got the file to load, BUT the first page (where the date is) was dropped...Doesn't show anywhere in the version..We thinking because  of the RecordRange being used it wouldn't be indexed...Just thought it would be appended on some other page. But its like that page got discarded entirely

TRIGGER1=*,1,X'F1',(TYPE=GROUP)
TRIGGER2=*,2,X'C1C3C3D6E4D5E37A',(TYPE=GROUP,RECORDRANGE=(1,4))
TRIGGER3=1,19,X'C481A3857A',(TYPE=GROUP)
FIELD1=19,50,16,(TRIGGER=2,BASE=0)
FIELD2=5,11,4,(TRIGGER=2,BASE=0)
FIELD3=1,16,11,(TRIGGER=2,BASE=0)
FIELD4=0,10,35,(TRIGGER=2,BASE=0)
FIELD5=1,57,3,(TRIGGER=2,BASE=0)
FIELD6=7,19,6,(TRIGGER=2,BASE=0)
FIELD7=4,51,8,(TRIGGER=2,BASE=0)
FIELD8=3,49,3,(TRIGGER=2,BASE=0)
FIELD9=3,9,25,(TRIGGER=2,BASE=0)
FIELD10=8,11,10,(TRIGGER=2,BASE=0)
FIELD11=7,54,1,(TRIGGER=2,BASE=0)
FIELD12=5,52,3,(TRIGGER=2,BASE=0)
FIELD13=15,23,35,(TRIGGER=2,BASE=0)
FIELD14=13,14,17,(TRIGGER=2,BASE=0)
FIELD15=9,22,12,(TRIGGER=2,BASE=0)
FIELD16=9,58,1,(TRIGGER=2,BASE=0)
FIELD17=10,18,15,(TRIGGER=2,BASE=0)
FIELD18=6,58,16,(TRIGGER=2,BASE=0)
FIELD19=0,24,8,(TRIGGER=3,BASE=0)
INDEX1=X'E2E6C9C6E36DE3D9D5',FIELD1,(TYPE=GROUP,BREAK=YES)
INDEX2=X'D4E2C76DE3E8D7C5',FIELD2,(TYPE=GROUP,BREAK=YES)
INDEX3=X'C3D6D9D96DC2C9C3',FIELD3,(TYPE=GROUP,BREAK=YES)
INDEX4=X'C1C3C3E36DD5',FIELD4,(TYPE=GROUP,BREAK=YES)
INDEX5=X'C2D5E86DC2C3D6C4C5',FIELD5,(TYPE=GROUP,BREAK=NO)
INDEX6=X'C9E2D56DD6E2D5',FIELD6,(TYPE=GROUP,BREAK=YES)
INDEX7=X'E5C4C1E3C5',FIELD7,(TYPE=GROUP,BREAK=NO)
INDEX8=X'C3E4D9D9C5D5C3E8',FIELD8,(TYPE=GROUP,BREAK=NO)
INDEX9=X'C1D4E3',FIELD9,(TYPE=GROUP,BREAK=NO)
INDEX10=X'C6E4D5C3E3C9D6D5',FIELD10,(TYPE=GROUP,BREAK=NO)
INDEX11=X'C4C9D96DC9D6',FIELD11,(TYPE=GROUP,BREAK=NO)
INDEX12=X'C1D7D7D36DC9C4',FIELD12,(TYPE=GROUP,BREAK=YES)
INDEX13=X'C6C9D56DC9D5E2E3',FIELD13,(TYPE=GROUP,BREAK=NO)
INDEX14=X'D9E2D56DE3E8D7C5',FIELD14,(TYPE=GROUP,BREAK=NO)
INDEX15=X'E2C5E36DD7D3C1C3C5',FIELD15,(TYPE=GROUP,BREAK=NO)
INDEX16=X'D6C6C1C36DE2E3C1E3',FIELD16,(TYPE=GROUP,BREAK=NO)
INDEX17=X'E2C5D5C46DD4E2C7',FIELD17,(TYPE=GROUP,BREAK=NO)
INDEX18=X'D9C5D36DD9C5C6',FIELD18,(TYPE=GROUP,BREAK=NO)
INDEX19=X'D7D6E2E3C9D5C76DC4C1E3C5',FIELD19,(TYPE=GROUP,BREAK=NO)

Here is a screen shot of actual database where the date appears

=COLS> ----+----1----+----2----+----3----+----4----+----5----+----6----+----7--
****** ***************************** Top of Data ******************************
000001 1*** FNI ON DEMAND REPORT ******************************************* PA
000002  FNI Messages for Date:10/16/17                                         
000003                                                                         
000004     KINDLY NOTE THAT FNI ONDEMAND REPORT CREATION STARTED SEPTEMBER 1, 2
000005     MERVA MESSAGES. MRV REPORTS WILL CONTINUE TO BE PRODUCED FOR NEW MSG
000006     GRACE PERIOD THROUGH NOVEMBER, 2009. MERVA (MRV) ONDEMAND REPORTS WI
000007     BE NEEDED, TO LOOK UP MERVA MESSAGES PROCESSED PRIOR SEPTEMBER 1, 20
000008                                                                         
000009     FOR THE BENEFIT OF NEW USERS, A COMPUTER BASED TRAINING IS AVAILABLE
000010     THE INTRANET  http://xsa00x02:9212/fni/training/on_demand_reports.ht
000011                                                                         
000012     ADDITIONAL TRAINING ISSUES MAY BE ADDRESSED TO THE EFM SERVICE DESK
000013     VILLAGE. ON DEMAND ACCESS ISSUES SHOULD BE ADDRESSED via e-mail grou
000014     AND CC THE EFM SERVICE DESK.                                       
000015                                                                         
000016 1*** ACK/NAK AND/OR MSG KEYS **************************************** PA
« Last Edit: October 17, 2017, 09:15:12 AM by DDP021 »

Greg Ira

  • Full Member
  • ***
  • Posts: 240
    • View Profile
Re: ACIF Indexer and Posting Date
« Reply #8 on: October 17, 2017, 12:24:12 PM »
Yes, it's tough without meaningful 88 error messages.  Usually I can find an error somewhere when using ACIF either in the log or sometimes intermixed with the indexing echoing.  I can say for sure that you can pull the date from one page, we do it often here.

Darrell Bryant

  • Full Member
  • ***
  • Posts: 104
  • Sed fugit interea fugit inreparabile tempus-Virgil
    • View Profile
Re: ACIF Indexer and Posting Date
« Reply #9 on: October 17, 2017, 02:18:51 PM »
I believe the first page is dropped because ACIF must find all the group triggers before it starts collecting fields.

From the indexing reference manual: 'All fixed group triggers must match before ACIF can generate index information.'
#IBMi #iSeries #PDF #XML #400 Indexer #ASM

DDP021

  • Sr. Member
  • ****
  • Posts: 343
    • View Profile
Re: ACIF Indexer and Posting Date
« Reply #10 on: October 23, 2017, 04:53:28 AM »
I just tried flip flopping the triggers putting the trigger looking for the Posting Date ahead of the RecordRange trigger that looks for all the other indexing info....Still didn't work...88 Message gives you NOTHING to key off of that's causing the issue...VERY Frustrating....

APK415I TRIGGER1=*,1,X'F1',(TYPE=GROUP)
APK415I TRIGGER2=*,19,X'C481A3857A',(TYPE=GROUP)
APK415I TRIGGER3=*,2,X'C1C3C3D6E4D5E37A',(TYPE=GROUP,RECORDRANGE=(1,4))

88msg

APK440I ACIF AT IM43P11 HAS COMPLETED NORMALLY WITH RETURN CODE 0.
arsload: 10/23/17 07:44:15 Indexing completed
arsload: 10/23/17 07:44:15 -- Loading started, 1149386 bytes to process
Loaded 0 rows into the database
Document compression type used - OD77.  Bytes Stored = >148< Rows = >0<
arsload: 10/23/17 07:44:17 Loading failed
arsload: Processing failed for file >/prod/ode/cmod/arsload3/GSYS.SRACDP2M.FNIAU2LX.FNIAU2LX.2017296.07354833593.ARD<

Greg Ira

  • Full Member
  • ***
  • Posts: 240
    • View Profile
Re: ACIF Indexer and Posting Date
« Reply #11 on: October 23, 2017, 05:30:55 AM »
Odd.  If it was an issue with the triggers you would be getting an error message, in fact it appears you are successfully indexing the report:
arsload: 10/23/17 07:44:15 Indexing completed

Something is happening during the load.  It clearly identifies the input file, starts the load, then fails to complete.  Look for error messages elsewhere.  If you're on z/OS look in the SDSF log for SMS, OAM, DB2, or security error messages at the same time of the attempted load.

DDP021

  • Sr. Member
  • ****
  • Posts: 343
    • View Profile
Re: ACIF Indexer and Posting Date
« Reply #12 on: October 23, 2017, 06:09:15 AM »
EXACTLY!...No matter what changes I've done, same exact 88 message...The thing is, prior to attempting to make this update, this same exact file loaded successfully...We just had the POSTING DATE set to take the default load date...Its defined in the app grp as a Filter with Data Type equal to Date..we had no mention of POSTING DATE in the Indexer itself...And it loaded successfully using the load date...Only thing we noticed was, the first page (that contains the date itself) was dropped...Guessing this was because of using the RECORDRANGE on the Trigger we use for all the indexing...Thought maybe moving the new trigger ahead of that one would work...But maybe the first page is still getting dropped so the new trigger isn't seeing it...I would still think we'd have SOME type of error...Just wanted to get this to work because we've had other reports like this that don't have a date on every page...We had assumed if we were using ACIF indexer, that we just had to always use the load date.....

DDP021

  • Sr. Member
  • ****
  • Posts: 343
    • View Profile
Re: ACIF Indexer and Posting Date
« Reply #13 on: October 23, 2017, 07:00:07 AM »
Found this on the IBM Knowledge Center...But its in IBM Content Manager OnDemand for Multiplatforms, Version 9.0...We are running 8.5.0...Looks like there is a parameter (KEEP=YES) you can add to an index which appears to fall under exactly what we would need (highlighted in red)...I did try adding it to my posting date index line but it errorred indicating THE PARAMETER KEEP IS INVALID.

When you specify TYPE=GROUP, you can optionally specify |the KEEP={YES | NO} parameter. This parameter can be used with any |TYPE=GROUP index. |
When KEEP=NO is used, this is the same as not |specifying the KEEP parameter at all. Each document in the load file |must provide all of its own index values.
|
When KEEP=YES is used, |the index value found for the first document in the load file is used |for that index across all remaining documents in the load file. Two |examples of when this might be useful are:
|
|
The posting date field exists only in the first document of the |load file.
|
An AFP file generates multiple index rows per document, but the |posting date TLE does not repeat for each generated index row.
Refer to the INDEXSTYLE parameter for examples.

DDP021

  • Sr. Member
  • ****
  • Posts: 343
    • View Profile
Re: ACIF Indexer and Posting Date
« Reply #14 on: October 23, 2017, 07:48:07 AM »
Just for fun, I changed the Trigger used for the Posting date to FLOAT instead of Group...The file loaded and got the date page...But all it did was group the first data page that was after the date page..basically created on index, with one page using that date...Then it broke down the remainder of the report using todays date for the posting date...Apparently the FLOAT parameter only works under the OS/390 indexer...