|
David Morris >>> "Jon Paris - jonp@vnet.ibm.com - AS/400 AD" <jonp@VNET.IBM.COM> 09/04 3:02 pm >>> Why do you not know the data type? You say that the called routine knows the type, so I'm a little confused as to why you can't simply code it in the PR. All of this is a long winded way of saying that if you tell us what you're trying to do we may be able to offer alternative suggestions. We generate our database files from a set of files that describe the files. Keys, unique keys, candidate keys, attributes, etc. I am currently designing a set of standard functions to replace the chain, read, setll, open, etc. opcodes. Why? To allow dynamic database changes (without recompilation), custom opcodes, simplify database access, ensure data integrity, provide standard trigger feedback, dynamic journaling, seamless SQL, etc. This question arose while defining prototypes for procedures that will require a list of key values passed from an application. During development, testing, or when in debug, each procedure implements a routine that verifies the passed and returned parameters. In this routine we would like to be able to type check that the key field attributes passed match the keys field attributes of the file (which we know). IE: GetRcd(FileHandle: *equal: RtnFieldStruct: Key1: Key2: Key3). I could pass the names of the keys in a string like 'key1, key2, key3', but I would have to require that the return structure be I/O and the keys be defined in the return structure. The goal here is to catch errors while a program is still in development. When we implement this new interface it will be utilized in every application. A little work here could save many hundreds of hours down the road. ILE is enabling us to create very dynamic applications. The compiler type checking is great but a way to turn it off and perform this function at run time would greatly enhance the flexibility of RPG. We have coded around this situation many times. The difference here is that these procedures will be used in hundreds of programs. Thanks for your help * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This is the RPG/400 Discussion Mailing List! To submit a new * * message, send your mail to "RPG400-L@midrange.com". To unsubscribe * * from this list send email to MAJORDOMO@midrange.com and specify * * 'unsubscribe RPG400-L' in the body of your message. Questions should * * be directed to the list owner / operator: david@midrange.com * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
As an Amazon Associate we earn from qualifying purchases.
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.