ASE will continue writing to the same errorlog file even after you've moved/renamed it [NOTE: I don't know off the top of my head if this behavior has changed with ASE 15.7], so you need a way of telling ASE to change where it writes to (eg, sp_errorlog), or a method of copying/truncating the current errorlog file (eg, OS commands).
A few ideas ...
1 - use the sp_errorlog proc and OS commands to simulate the desired behavior:
sp_errorlog/SYB.log.tmp
mv SYB.log SYB.log.001
sp_errorlog/SYB.log
cat SYB.log.tmp >> SYB.log.001
rm SYB.log.tmp
Then schedule (eg, crontab) a job to run periodically that checks for the size of SYB.log > 10M and kicks off the above code.
NOTE: The above example assumes you want the current errorlog to be called SYB.log at all times (and also makes the RUNSERVER file definition easier to manage so that ASE always writes to SYB.log at startup]. If you can live with the currently-active log changing names then you just need a single invocation of sp_errorlog, though keep in mind that you'll need to figure out what to do with your RUNSERVER file so that a ASE reboot starts writing to the 'right' errorlog file.
2 - see if you can get (unix/linux) logrotate/copytruncate to copy SYB.log to SYB.log.001 and then truncate SYB.log; I know logrotate works on number of lines in a file (so you'd have to guesstimate the line count that's ~=10M), but not sure if logrotate can perform the copytruncate based on file size
Alternative: use basic OS commands to copy/truncate SYB.log (eg, cp SYB.log SYB.log.001, cat /dev/null > SYB.log); add a scheduled job to periodically check SYB.log file size and perform the cp/cat when appropriate
One potential downside is that you could lose a few errorlog lines if you happen to do the copy&truncate while ASE is writing to SYB.log
3 - [not sure if ASE can handle this but fwiw ...] see if you can get ASE to write to a named pipe, then have another process read from the pipe and write to SYB.log; I've seen some programs floating around that can take stdin from a pipe and write to different log files (eg SYB.log.001, SYB.log.002) based on number of lines read from stdin (eg, create new log file when 10K lines read)
this method should reduce (if not eliminate) the chance of losing some errorlog lines while making the split automatic (ie, no need to periodically run a scheduled job)
--------------
Of course, some of these options could cause problems with any other process that happens to be monitoring SYB.log (eg, custom scripting, SCC agent, etc).