Q: Do Stored Procedures actually degrade performance?

Hello All We just implemented a module in our application with Stored Procedures. The module was originally written in 4GL with SQLs embedded in the code. All the SQLs have been checked with SET EXPLAIN ON and all the sequential scans we found were for tables with very small number of rows. In an effort to move the database calls to a seperate access layer, we moved all the SQLs (as is, so the optimizer access paths are the same) to some stored procedures which become 4GL callable database services. There are 29 Stored Procedures for this module (we have a total of 60 stored procedures in the entire system). Each stored procedure has 40 - 1500 lines of SPL code. Doing a before and after we found that performance actually degraded with the stored procedures by around 20%. The primary cause seems to be larger number of buffer reads, isam reads and lock requests on the larger tables in the system. Although we had expected lock requests to go up on sysprocedures, it went up only slightly. The bulk of the lock requests went up on the application tables. Our PC_POOLSIZE value is set to 60. All SPs have had UPDATE STATISTICS FOR PROCEDURE run on them. Does anyone have any ideas as to what could be wrong here? Conventional wisdom suggests that SPs should perform better than regular 4GL if the SPs contain 3-4 SQLs each, thereby combining the results from the server. Is there a chance that optimizer access paths actually change inside a SP? If so, is there a way I could view the access path? Thanks in advance for any insights into this problem. Sujit Pal