Bala, I do not have any answer but when i look at the error code, the documentation says that POL file is being corrupted - maybe you can truncate the POL file and run again ? Looks like the above stuff can be achieved within GENDATA ?! In posttransDAL, I guess you are parsing through all the forms and insert the enclosure wherever you need
If you have you PostTransDAL between updating the NA and POL then your saved formset information will be out of sync and you will get the error you describe when attempting the GenPrint process.
Make sure that the PostTransDAL occurs below (in the list) whatever rules you have that update the NA and POL files. Rules operate in the reverse direction during the Post, so in general you want the PostTransDAL closer to the bottom of the list. I'm not saying that you use these specific rules, but in general something like this:
<Base Form Set Rules>
;WriteOutput;;; (or UpdatePOLFile)
Actually tried it in GENDATA, but even after that also i'm getting the same error. I think something in AFBJOB.JDT blocking the approach..i dont know what/where exactly it is,
<Base Form Set Rules>
;NoGenTrnTransactionProc;2;required to combine gentrn/gendata into single step;
This is how, i have the base fome set rules in it, Could u jst help me in this??...
I assuming by "didn't work" that you mean you received the same error as before and not a new error. If you have received a new error, please include that information.
Short answer: Try changing your WriteOutput rule in the AFGJOB to PurgeOutput.
(The /* will effectively comment out the line. You can delete it later if you decide that PurgeOutput works.)
The error mentioned, DM17059, would not occur in the Gendata run, but would occur during GenPrint. Therefore the error is not being thrown by the AddForm functionality specifically, but could be a side effect of the way you add that form.
The error means there is a mismatch between the NA (DAT) file and the POL file which defines the document structure. Normally, such an error can be traced to where one or more recipients are assigned a zero count and were not purged from the document before writing the NA/POL output.
The final act of triggering will remove sections where all the recipients are set to zero. In older versions of the product, like yours, this was the only place where that clean-up process occurred. Later versions of the product have additional checks for this discrepancy and will do the necessary purging.
Since you are using a script to add the form - and not Triggering - I'm going to guess that the form has one or more sections where the recipient count is set to zero. Either that or your script is further changing the recipient count on some sections to become zero. So, when the process gets around to unloading the document, the sections are written to the NA, but not the POL. This leads to your subsequent error message from GenPrint.
This is a long story to suggest that you try the rule change to unload the NA after first purging unused sections where the recipient counts are zero.
Now you may find at this point that you no long get the error, but you also don't get your form. If this is the case, we go back to the difference between triggering and adding the form via script. Adding the form via script does not look at triggers and therefore you would not get recipient counts set as they do from triggering. A later version of the product adds TRIGGERFORM() as a possible script function. You would not have that in 11.3. Therefore, you may have to use SETRECIP() to assign counts to your form recipients. Or you have to go back and actually assign an explicit count of 1 on the form sections and check it back into the library. If you do that, then when the script adds the forms, the recipient counts will have defaults.
Apologies for the long answer. Limited information in the question leads to a shotgun answer in the hope that I hit something.