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
Hi Navin, Thanks for replying back....
I tried truncating the POL file, even with that my approach is not working. Please let me know, how dynamic form ordering can be achieved in GENDATA it self?...
1 person found this helpful
I am not sure about your scenario..
Maybe consider this - you can add a dummy variable (yes - dummy FAP too, or in footer) to every form which calls a DAL and use addform() there
The last FAP of your FORM1 has a variable which has the DAL like this
Sounds good ?
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??...
Hi, I tried to move the PostTransDAL to the bottom of the list...that didn't work.. Do u have any idea abt how ;RunTriggers;2;; will work during post???
I think the issue is not with the POSTTRANSDAL.. I guess AddForm() in even GENDATA is throwing the error.
Have you used AddForm() in any other DAL within the same MRL ?
Maybe can you remove the optional parameters (just to test) and run once ?
1 person found this helpful
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.
Section 1: Header
Section 2: Body
If overfow occur and body content move to next page, "continue on next page" should be printed without any spaces before it.
Issue: Some 500 fap space occur, before "continue on next page" is printed
Can anyone solve this issue
Maybe "Copy on Overflow" is set to some FAP in the header ?