Hi John,
I'm wondering if you are really seeing problems with syscomments itself (as per your title), or just sysdepends. I'm not aware of any issues with syscomments not being updated with the new script when procedures are created. sysdepends, on the other hand, has had a design flaw (at least in my opinion) from day one. The issue with it, for those that don't know, is that it only stores references by object id. If you create a table and then create a stored procedure, a row is inserted into sysdepends showing the procedure depends on the table. If you then drop the table, the row in sysdepends is deleted because the object id no longer exists. When you create a new table with the same name, the create table command doesn't know the procedure references this new table by name and no row showing the dependency is inserted in sysdepends. You have to drop and recreate the procedure to get the row back in sysdepends. So sysdepends really isn't dependable in a database where objects are sometimes dropped and recreated. It really needs to be redesigned to include fully qualified object names in addition of the object ids, and to only null out the object id when an object is dropped unless both objects are being dropped.
Enough background.
You can use the ddlgen utility to create a script that drops and recreates all stored procedures using the source text currently stored in syscomments, I think this will do the trick for you. You should take a fresh backup of the database before doing doing it so you can recover if it doesn't work as expected.
Syntax:
ddlgen -Ulogin -Ppassword -SASEhost:port -Tobjecttype -Ddatabasename -Nobjectname -Ooutputfile
Example:
ddlgen -Usa -Psybase -Sredhead:5220 -TP -Dtest -N% -OINSTALL_test_procs.sql
isql -Usa -Psybase -i INSTALL_test_procs.sql
-bret