It depends on how you measure efficiency. For example the generated C code is not as fast as well crafted code. However the user response time difference is likely to be trivial. For developer efficiency, I can build, test and deploy 3 SQL stored procedures in a half hour while an RPG developer takes 2 days. Different skill sets, different tools have a big impact. The important point for you to consider is that the RPG precompiler generates the same C code for the embedded SQL as the stored procedure does. How can you make that more efficient by wrapping it in a bunch of RPG code? =================================================== The SQL pre-compiler for RPG generates RPG for the embedded SQL; not C code. It's visible in the generated source. It's similar for COBOL. Generally, C can be more efficient when optimized. That's sometimes because the C optimizers have usually been the best. Also, RPG can contain additional language-supplied code such as for "the cycle" that might consume some CPU cycles. I wouldn't pay much attention either way until any actual performance issue arises. However, the reason to embed SQL would be to execute procedural code around SQL. Without that, there's no point to create anything but a pure SQL procedure. Or, if there is no embedded SQL, then the complex procedural code can be written explicitly in an originally optimal form, perhaps taking advantage of numerous built in language facilities. Tom

It depends on how you measure efficiency. For example the generated C code is not as fast as well crafted code. However the user response time difference is likely to be trivial. For developer efficiency, I can build, test and deploy 3 SQL stored procedures in a half hour while an RPG developer takes 2 days. Different skill sets, different tools have a big impact. The important point for you to consider is that the RPG precompiler generates the same C code for the embedded SQL as the stored procedure does. How can you make that more efficient by wrapping it in a bunch of RPG code? =================================================== The SQL pre-compiler for RPG generates RPG for the embedded SQL; not C code. It's visible in the generated source. It's similar for COBOL. Generally, C can be more efficient when optimized. That's sometimes because the C optimizers have usually been the best. Also, RPG can contain additional language-supplied code such as for "the cycle" that might consume some CPU cycles. I wouldn't pay much attention either way until any actual performance issue arises. However, the reason to embed SQL would be to execute procedural code around SQL. Without that, there's no point to create anything but a pure SQL procedure. Or, if there is no embedded SQL, then the complex procedural code can be written explicitly in an originally optimal form, perhaps taking advantage of numerous built in language facilities. Tom