OnDemand User Group
Support Forums => Report Indexing => Topic started by: DDP021 on March 22, 2018, 03:22:26 AM
-
Currently, when we defined an indexer in the Application definition, we define a Trigger, Field and the index(s)...For the Index, we've always used the hex representation of the specific index defined...Ex
TRIGGER1=*,1,X'F1',(TYPE=GROUP) /* 1 */
FIELD1=3,20,8,(TRIGGER=1,BASE=0) /* PARTICIPANT */
FIELD2=1,38,8,(TRIGGER=1,BASE=0) /* POSTIN_DATE */
INDEX1=X'D7C1D9E3C9C3C9D7C1D5E3',FIELD1,(TYPE=GROUP,BREAK=YES) /* PARTICIPANT */
INDEX2=X'D7D6E2E3C9D5C76DC4C1E3C5',FIELD2,(TYPE=GROUP,BREAK=NO) /* POSTING_DATE */
We were told that we don't have to use the hex representation. We can just use the name itself. So for example, INDEX1 we would just use the word PARTICIPENT instead of the hex representation. When I tried that, first putting PARTICIPENT in quotes, INDEX1=X'PARTICIPENT',FIELD1,(TYPE=GROUP,BREAK=YES) it error indicating, The field name '& кисдс& +и' found in the index file does not match any expected fields. The field will be ignored....When I removed the quotes, then I received this error, PARTICIPANT WAS SPECIFIED WHEN QUOTED STRING EXPECTED. , WAS SPECIFIED WHEN = EXPECTED.
A side note, this data is coming from the MAINFRAME which I believe is in EBCIDIC and we're using F1 for our trigger. This maybe why the indexes are using HEX. I assumed that the parameter specified on the Indexer just had to match the name on the LOAD INFORMATION tab
Does anyone know what I'm missing or if you HAVE to use HEX?
Appreciate any input!
Take care
Dave
-
You didn't include all of your ACIF index parameters, but I'm guessing you have a bad CodePage ID specified...
I've only ever used hex definitions for field names, where were the instructions that you can use strings? (Admittedly, it's been over a decade since the last time I read the IBM CMOD ACIF manuals from cover-to-cover.)
-JD.
-
Justin, below is the entire indexer, with my changes to the indexes using the "literal" names of the indexes
CC=YES
CCTYPE=A
CONVERT=NO
CPGID=500
MCF2REF=CPCS
TRC=NO
FILEFORMAT=RECORD,133
DCFPAGENAMES=NO
UNIQUEBNGS=YES
IMAGEOUT=ASIS
INDEXOBJ=ALL
INDEXSTARTBY=0
INSERTIMM=NO
RESTYPE=NONE
TTRIGGER1=*,1,X'F1',(TYPE=GROUP)
FIELD1=3,20,8,(TRIGGER=1,BASE=0) /* PARTICIPANT */
FIELD2=1,38,8,(TRIGGER=1,BASE=0) /* POSTIN_DATE */
INDEX1='PARTICIPANT',FIELD1,(TYPE=GROUP,BREAK=YES) /* PARTICIPANT */
INDEX2='POSTING_DATE',FIELD2,(TYPE=GROUP,BREAK=NO) /* POSTING_DATE */
Here is the original where the INDEX are using the HEX value for the index names defined on the Application Group
CC=YES
CCTYPE=A
CONVERT=NO
CPGID=500
MCF2REF=CPCS
TRC=NO
FILEFORMAT=RECORD,133
DCFPAGENAMES=NO
UNIQUEBNGS=YES
IMAGEOUT=ASIS
INDEXOBJ=ALL
INDEXSTARTBY=0
INSERTIMM=NO
RESTYPE=NONE
TRIGGER1=*,1,X'F1',(TYPE=GROUP) /* 1 */
FIELD1=3,20,8,(TRIGGER=1,BASE=0) /* PARTICIPANT */
FIELD2=1,38,8,(TRIGGER=1,BASE=0) /* POSTIN_DATE */
INDEX1=X'D7C1D9E3C9C3C9D7C1D5E3',FIELD1,(TYPE=GROUP,BREAK=YES) /* PARTICIPANT */
INDEX2=X'D7D6E2E3C9D5C76DC4C1E3C5',FIELD2,(TYPE=GROUP,BREAK=NO) /* POSTING_DATE */
We know when we run data through the report wizard, the actual string names of the indexes are used. My guess is because this is using mainframe data, we HAVE to use hex values even though I thought it was based on the LOAD ID name on the LOAD INFORMATION tab...Our Engineering team indicated we could use strings instead of hex value but they may have based that on it NOT being mainframe data
-
Well, your codepage appears set correctly. If this is a new report, double check to see that your file transfer method isn't attempting to convert EBCDIC to ASCII on the fly. (In FTP, use the 'BIN' command to transfer the files in 'Binary' mode, that is, byte-for-byte, without text translation.)
-JD.
-
Well IRONICALLY after speaking to our engineer again and explaining to him the issues I'm having, he indicated that he misspoke and should have said you can't use string values for EBCDIC value data!!!...So mystery solved!!....I couldn't find anything anywhere that indicated that prior...As always Justin, I appreciate your input and time...Apologize for wasting it this time!!...;-)....Take care...Dave
-
No worries. I'm happy to have the answer here for future users to find. :) Take care.
-JD.
-
Reading this with interest. We converted from InfoPac to CMOD this week...and are working with all of the applications that refused to load with the indexing copied over from InfoPac.
I wonder, if there is some numeric value of discrepancy between InfoPac and CMOD?
For example in one application the Hierarchy Code in InfoPac was: 00602305 and
the Field1 in CMOD was defined as: FIELD1=5,24,5,(TRIGGER=1,BASE=0)
While the length is the same (thank goodness), neither the line nor the column are identical. They are each off by one. This appears on the surface to be an indexing description that does not match between the two systems.
Any thoughts?
Rod
-
I don't know anything about InfoPac, but it could be that the carriage control column is being counted differently? Or could it be as simple as counting starting from 0 instead of starting at 1?
-JD.
-
Yep, that is what we thought too.
We'll play around with it. It's all so new . ;)