OnDemand User Group
Support Forums => Report Indexing => Topic started by: DDP021 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?
-
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.
-
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 */
-
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.
-
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?
-
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<
-
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.
-
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
-
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.
-
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.'
-
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<
-
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.
-
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.....
-
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.
-
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...
-
Decided to try different data that had only one true index...Trigger1 is based on Carriage control (1 in column) and is used to index off the account number...Added a separate Trigger2 to look for the verbiage "Run Date" and then create a new index based off of it to capture the date that's only on the first page....Report collects and does get the date from the first page, HOWEVER, it just creates a single index Off of the first page that contains the account number..In other words, its not breaking on the account number even though its set to BREAK=YES on the index...It combines everything under one index
-
I know there are improvements in the OS/390 Indexer in the latest release including new and better error messages.
I can't speak to ACIF, but are you on the latest release and service level?
On z I'm on ACIF V4.5.0 and APAR PI72113.
Ed
-
Hi Ed.....Currently running 8.5.0...Will be upgrading, I believe, to 9.5.....
Well I did finally get things to work after much trial and error...what I did was add another Trigger based on the date that was found only on the first page..Had to make it a "FLOAT"
TRIGGER2=*,2,X'D9E4D540C4C1E3C5',(TYPE=FLOAT) /* RUN DATE */
Then added a Field based on the actual date location and then added the INDEX...
The FINAL step I needed was to remove the small 't' for the POSTING DATE Default Value under the LOAD INFORMATION tab in the Application. After doing that, all the indexes created had the Posting date that was shown on the first page and not todays Load Date....
-
Glad you got it working. Sorry I couldn't have been more help.
-
Currently running 8.5.0...Will be upgrading, I believe, to 9.5....
First off, glad you resolved your issue.
On z/OS, at least, ACIF is a separate product from CMOD and can be separately ordered.
Hopefully you're on ACIF V4.5 with all service applied, independent of whatever level of CMOD you're running.
Ed
-
Absolutely NO need to apologize Greg!! I appreciate all your input and time!!!!!!,,,
Ed, I'll check with our engineering team as they are the ones who handle the upgrade
Take care
Dave