Adobe Output Server: Message Msg210 not in .ini file

Problem

Ever got:

2010/02/02 14:19:46 d:\Adobe\Central\Common\Bin\jfserver.exe: [314]Agent exit message: [210]** Message Msg210 not in .ini file **

in Adobe Central Output Server (formerly known as JetForm)?

And the error message makes no sense or gives any clue to what's wrong, what so ever...

Background

It is jfmerge.exe that is throwing this error message, and jfserver.exe is just relaying it in the jfserver.log file.

Normally the Msg210 is present in jfmerge.ini, and if not, you need to get hold of a new uncorrupted version.

The problem is that jfmerge.exe is not reading the correct jfmerge.ini, or any file at all.

Possible solution 1 - quote your paths

Check your log file (turn verbosity on) for 'Launching...':

Do you see:

-aiiC:\Program Files\Adobe\Central\Server\jfmerge.ini

which must be:

-aii"C:\Program Files\Adobe\Central\Server\jfmerge.ini"

Otherwise, jfmerge is trying to open the ini file "C:\Program".

And while you're at it, quote the other paths including spaces, or swap them to relative paths (from 'data'): '..\jfmerge.ini'.

Possible solution 2 - Set inifile path -aii

Check and verify the -aii as above. If the launching line does not have any -aii at all, we must add it to the Task's Program options. Either explicitly, or as -aii""@IniFileName."", which gets the ini file name from jfserver.ini - [JFMERGE] - IniFileName.

Remember double double quotes if you edit jfserver.jmd directly.

Possible solution 3 - The quotes don't match

Check the 'Launching...' in the log file (as above).

Example: ^job JOBNAME -zprinter -agvVAR="value -aduON

Since the first double quote didn't have a matching quote, the rest of the options (@OtherTokens) got muddled up, and -aii got lost inside the variable VAR: "value -aduON -aii".

Possible solution 4 - The 1st line is too long

I have also encountered this if the whole file contains no line breaks at all, leaving the whole file as one long line.

This even breaks Central, stopping the instance, leaving the whole queue down.

I have no good solutions for this, apart from not sending files where the first line is longer than 256 characters.