This test1.sql file works OK...

PARAMETERS value;

SET OPTION PUBLIC.Global_database_id = '{value}';

MESSAGE STRING ( 'GlobalDBId = ', DB_PROPERTY ( 'GlobalDBId' ) ) TO CLIENT;

when processed using SQL Anywhere 9 dbisql as follows...

"%ASANY9%\win32\dbisql.exe"^
  -c "ENG=ddd;DBN=ddd;UID=dba;PWD=sql"^
  READ ENCODING Cp1252 test1.sql [123]

displaying this correct result...

GlobalDBId = 123
Execution time: 0 seconds

However, if fails when processed using SQL Anywhere 10, 11 or 12 dbisql as follows...

"%SQLANY10%\win32\dbisql.exe"^
  -c "ENG=ddd10;DBN=ddd10;UID=dba;PWD=sql"^
  READ ENCODING Cp1252 test1.sql [123]

"%SQLANY11%\bin32\dbisql.com"^
  -c "ENG=ddd11;DBN=ddd11;UID=dba;PWD=sql"^
  READ ENCODING Cp1252 test1.sql [123]

"%SQLANY12%\bin32\dbisql.com"^
  -c "ENG=ddd12;DBN=ddd12;UID=dba;PWD=sql"^
  READ ENCODING Cp1252 test1.sql [123]

throwing this error message...

Could not execute statement.
  Invalid setting for option 'global_database_id'
  SQLCODE=-201, ODBC 3 State="42000"
  File: "test1.sql" on line 3, column 40
  SET OPTION PUBLIC.Global_database_id = '{value}'

The workaround is to wrap everything in a BEGIN block to force dbisql to apply the PARAMETERS string substitution and sending it to the server instead of trying to process the naked SET by itself:

PARAMETERS value;

BEGIN
   SET OPTION PUBLIC.Global_database_id = '{value}';

MESSAGE STRING ( 'GlobalDBId = ', DB_PROPERTY ( 'GlobalDBId' ) ) TO CLIENT;
END;

According to the docs SET OPTION PUBLIC... is not an ISQL statement. Even if it was, it should be subject to string substitution; after all, a READ statement embedded in a SQL file does have {values} substituted, and it's an ISQL-only statement.