Hello,
I've seen something that seems wrong... but I'm not 100% sure yet, could you also do the following?
1) Generate the output file that will be archived in CMOD
the command is something like
arsload -h CMOD -u user -p passwd -g AG -p APP -nvf -i file.afp
by doing this command (adapt it to your environment), arsload will not archive the document, but will only index the file and generate 2-3 files:
- file.afp.ind
- file.afp.out
- file.afp.res
2) After point 1) has created these 2-3 files, then run the following command:
arsafpd -d -i file.afp.out |grep -E '[[:space:]]([BE]DT|[BE]NG|[BE]PG|TLE)[[:space:]]'
and post the output, please.
My feeling/theory/supposition/... is the following, and I want to be sure of it...
In the CMOD documentation, there is this sentence:
Although the input file may contain multiple BDT structured field, the ACIF output will contain only one BDT structured field. (The same is true of End Document (EDT) structured fields.)
(source:
http://www-01.ibm.com/support/knowledgecenter/SSEPCD_9.5.0/com.ibm.ondemand.ir.doc/dodif194.htmAnd I'm wondering if the OS/390 Indexer allows multiple BDT/EDT in the input/output, but ACIF allows only the first BDT/EDT found in the input to put it in the output.
If that's the case, this is one of the differences between OS/390 and ACIF indexer.
And in that case, you must keep using OS/390 indexer for these AFP. Of course for that, you must use AIX or a os/390 server... If you are using Linux/Solaris/Windows, then you are out of luck.
If you want to load these documents in Linux/Solaris/Windows and you MUST use ACIF indexer, then the only choice would be:
A) Write a AFP parser to rebuild the AFP in a supported form for the ACIF Indexer
or
B) Ask the people in charge of the generation of the AFP to create a OnDemand ACIF Indexer compliant AFP to be archived.
I would say, that B) is the most clean way to do it... and the one I strongly advise.
Well, before going to far, I'm waiting for your input.