This content has been marked as final. Show 6 replies
Ive not experienced the problem you describe in your Adobe Output Server posting of this morning and Ive been using these products for more than 3 years. I suspect it may be something about the way the form is designed. Im willing to take a look at the .ifd form file and the .dat file that uses it if you will send them to me. If I dont see anything obvious, I could then run it on my test server to see what happens.
If you were to also send the jfserver.ini & jfmerge.ini files from your server I could compare them to mine. Those are two of the files where settings are stored (main control file and the print agent control file). I dont know of any setting that causes what you describe but comparing your files to mine might trigger something to occur to me.
What version of the software are you using (Windows, something else) and, if Windows, what version number?
i (I sent personal email of the above so the requested files could be emailed back.)
The server is on a Windows NT server, I do believe. I'm not sure of the version number... being just a programmer, I don't have free access to server itself and have to go through our LAN people. But I can check and see.
I'll also need to get permission to send out files, or else send a truncated version. :)
I'm wondering now, though, if it's really not server related, but more designer related. I created a brand new form in Adobe Ouput Designer and put one field on that form, and named it a corresponding name from the .dat file. Then I printed through that form.
When doing that, each field in the .dat file was fed through the form sequentially, regardless of the name of the field on either the form or in the .dat file.
Perhaps I have a setting wrong in designer, so it is not recognizing the field names properly? Maybe I need to go post in the designer forum...
Thanks for your reply.
I responded to your posting in the Designer forum with what I think is the cause of your problem (you need to use the -afxon option).
I hope you have remote access to the server. There are some things that need to be done at the server or files located on the server to be looked at that are necessary. For example, the "Central Control" program runs on the server and gets you access to the log file and the "job management database". The log file will show you errors that might be occurring. The job management database is where you define printers, tasks & jobs. I suppose someone else could maintain the "database" but having access to that log file can be extremely handy. In addition, there are times that you may need to temporarily increase the "verbosity" level to get more stuff into the log file.
I may be spoiled. We have a test server with a development copy of Central Pro on it so we can do whatever we want.
I have limited access to the server... through our LAN persons, who double as our DBAs. Today, the regular LAN person is off, and so I'm sitting waiting for another person to get with me, that is his backup.
He did give me read access to the server, in a limited way. I can see the data subdir where the .dat files are loaded before they print, and the backup subdir where the .dat files are stored after they are printed. That is a help. I can also see the ini configuration files, but I cannot edit them. (We say here that we sometimes work with one hand tied behind our backs.) Maybe we'll get a development server working we can play with, which would be nice.
I can see one .log file in the main subdir.. it's called jfserver.log. There are a great deal of messages in there that I do not understand. Here is a subset:
jfserver.exe: Processing file '361.dat', '^job DISB_PRN_FORM -zFISOBBACK'.
jfserver.exe: Launching task '"C:\...\jfmerge" "DISB_PRN_FORM" "C:\...\Data\361.dat" -l -apr"" -all"C:\A...\jfserver.log" -asl1 -amq0 -ams"" -m -z"FISOBBACK" -aii"C:\...\jfmerge.ini"'.
jfmerge: * Processing data file: 'C:\...\Data\361.dat'.
jfmerge: MDF file `c:\...\forms\DISB_PRN_FORM.mdf' opened.
jfmerge: Field 'AD_DOC_HDR__DOC_ACTN_CD' not found on subform/page 'JFMAIN'.
jfmerge: Field 'AD_DOC_HDR__DOC_S_ACTN_CD' not found on subform/page 'JFMAIN'.
jfmerge: Data exceeds field '$POSITION'. Spillage may be discarded.
jfmerge: Field 'AD_DOC_HDR__DOC_CMNT_FL' not found on subform/page 'JFMAIN'.
jfmerge: Data exceeds field 'PO_DOC_HDR__DOC_CD'. Spillage may be discarded.
jfmerge: Field 'AD_DOC_HDR__DOC_CREA_DT' not found on subform/page 'JFMAIN'.
jfmerge: Data exceeds field 'PO_DOC_HDR__DOC_DEPT_CD'. Spillage may be discarded.
jfmerge: Field 'AD_DOC_HDR__DOC_CREA_DT_FRMT' not found on subform/page 'JFMAIN'.
jfmerge: Field 'AD_DOC_HDR__DOC_CREA_USID' not found on subform/page 'JFMAIN'.
jfmerge: Field 'AD_DOC_HDR__DOC_FUNC_CD' not found on subform/page 'JFMAIN'.
jfmerge: Data exceeds field 'PO_DOC_HDR__DOC_PHASE_CD_DISP'. Spillage may be discarded.
jfmerge: Field 'AD_DOC_HDR__DOC_FUNC_CD_DISP' not found on subform/page 'JFMAIN'.
jfmerge: Field 'AD_DOC_HDR__DOC_S_FUNC_CD' not found on subform/page 'JFMAIN'.
jfmerge: Field 'AD_DOC_HDR__DOC_LAST_DT' not found on subform/page 'JFMAIN'.
And on and on. This is, actually, from a test i recently did. I took a different form and piped it through a .dat file that only had one corresponding field. So perhaps this is why the fields are not found.
Perhaps the parameters on the second line are the ones I'm mostly interested in... I'll look at the documentation. I do have copies of the documentation fortunately. :)
Message 108 is exactly what I get from my testing:
jfmerge: MDF file `c:\jetform\forms\test.mdf' opened.
jfmerge: Field 'JF02' not found on subform/page '1'.
jfmerge: Field 'JF03' not found on subform/page '1'.
jfmerge: Field 'JF04' not found on subform/page '1'.
jfmerge: One surface was printed.
This is from my test with the -afxon parameter. Message 209 had "4 surfaces" when it was missing.
Message 166 might be indicating that the length of the actual data is longer than the receiving field. It might also be bogus. I get it all the time and it is bogus so I set the print agent vebosity level to 10 so it wouldn't be getting into the log file. This also shuts off a bunch of other log entries that I normally have no interest in. Having a development system I can temporarily set the verbosity to 0 or even -10 (trace level) when I have a need to.