SELECTs are not replicated so yes, replicating the stored proc would be the easiest method for what you're doing.
-----------
I would be more worried about what happens if/when PDS or RDS is shutdown hard (eg, ASE crashes, OS/machine crashes, ASE is 'shutdown with nowait') and a gap in identity values is introduced in the myLog table, thus leading to reserve_identity() generating different values in PDS and RDS.
While you could write some code to periodically check to make sure both copies of myLog are kept in sync, this won't provide 100% insurance against unwanted gaps in your identity values (and therefore reserve_identity() generating different results in PDS and RDS).
Based solely on what you've posted it appears you're using myLog as a key generator. Assuming you want/need a guaranteed method of ensuring no problems with (primary) key generation I'd probably want to look at a new method of generating keys that will eliminate the potential problems with identity column gaps, eg:
1 - redefine myLog with a non-identity value; update this value using a 'generate next key' stored proc; values of myLog will be replicated to ensure the primary and replicate copies of myLog are kept in sync, plus you eliminate the issue of identity column gaps
2 - maintain the current myLog/identity table design but add some logic to your current stored proc which resyncs the replicate copy of myLog (if/when a gap is experienced) via 'set identity_update'; this would insure a gap in the primary database is 'replicated' to to the replicate database; if coded correctly this should also 'fix' an unwanted gap in the replicate copy of myLog (ie, reset the replicate copy to look like the primary copy); obviously the stored proc would need to be able to ascertain whether it's being executed in the primary or replicate database in order to fire the correct logic