I can only speculate as to the reason why, but it's probably related to the
fact that they have to be fully compatible with the DB2 LUW and DB2 for z
design, as well as comply with the SQL standards. Effort involved in
maintaining compatibility and standards compliance should not be
underestimated.

Elvis

Celebrating 11-Years of SQL Performance Excellence on IBM i, i5/OS and
OS/400
www.centerfieldtechnology.com


-----Original Message-----
Subject: Re: DB2 stored procedure not shown by DSPSAVF

I think he's suggesting that there should've been a *SRDPRC object type
(much like we have *CMD objects) that kept track of the stored procedure
definition instead of simply having records in physical files. That
would've made it more like the rest of the OS.

Personally, it doesn't really matter to me. But, I think that's what
Steve is calling "interesting."


Charles Wilt wrote:
How do you figure stored procedures are not objects?

Every stored procedure is either a *PGM or a proc in a *SRVPGM.

The only thing funky is that there's a catalog table that tracks the
names.



http://www.mcpressonline.com/programming/sql/procedures-and-functions-and-ca
talogs-oh-my.html
wow, good article. Interesting how the pure as400 design of
implementing everything as objects was not adhered to for stored
procedures.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.