Result row ordered-ness is not guaranteed unless an ORDER BY is present in the SQL select (which has not been provided here).
Orderedness has not been guaranteed since ASE 11.5 (parallel worker threads) and especially since 11.9.2. when data-only locking was introduced and the clustered index became a real index (does not guarantee sorted order on disk unless the table is rebuilt).
ASE long ago stopped returning results in clustered index order, if that is the issue here.
Apart from the other answers here, you are also on different hardware platforms, versions, etc, etc.There are too many variables to solve here, unless you can provide the SQL statement.
Make sure your 'optimizer level' configuration setting is also at ASE_CURRENT.
You are also using Roman-8, which is an HP-specific character set, so the heritage of your database is most likely originally migrated from HP-UX to Linux to Solaris (unless you did create the database as a new database in Linux timeframe) - so there is the possibility that you are also battling some legacy issues.
One area where this character set has been an issue in the past is with JDBC connections (via jConnect). The OpenClient libraries provide character set translation between server character set and client character set within the OC localization capabilities.
This is not the case with Java. The java.io package used by jConnect does not have a translation for Roman-8. The lower 127 characters match the ISO1 character set, so often, you must add the 'CHARSET=ISO1' parameter to a jConnect connection when connecting to a Roman-8 server with jConnect to use the correct translation when running JDBC. Using another character set in the ASE will eliminate this requirement.
You may seriously want to consider migrating to a larger page size, character set (e.g. ISO1/UTF8) and sort order
Chris