Re: i/o module

I concur with what David Gibbs and others are suggesting.

Do not make "i/o modules" that only provide the same level of file I/O capabilities as RPG, e.g. READ, READE, SETLL, etc.

Create "business objects" that encapsulate all access to one or more related files or tables, for example, an "order" business object provides access to the order header and order detail tables. The "user" (consumer of the "order" business object) does not even need to know, or care, that this "order" business object is implemented using two tables, order-header and order-detail.

Also, consider that if you enforce all of your "business rules" solely within these business objects, anyone who can access the files directly (whether an RPG programmer, or a Java developer using ODBC/JDBC/SQLJ, etc.) can circumvent those business rules and perhaps harm the "integrity" of your data. So, you should also give proper consideration to pushing as many of these "business rules" into the database, either by using constraints or triggers, or both. (NOTE: this can be done using either SQL DDL or using the OS/400 ADDPFCST and ADDPFTRG commands, or a mixture of both.)

I also advocate using OS/400 security and authorization to prohibit anyone from directly accessing or updating those database tables (or files). If you require that all applications must access the files via "business objects" then you can grant *PUBLIC *EXCLUDE to the *FILEs and have the files owned by an applicaiton-owning profile, and have the "business objects" *PGM or *SRVPGM adopt authority of the owner.

HTH,

Mark S .Waterbury