|
> Remember, I am about as clueless here as they get, but let me make a > comment. While I agree that a hardcoded signature is sort of like > LVLCHK(*NO), it's more like an intelligent LVLCHK(*NO). No, it's pretty much exactly like LVLCHK(*NO). Wait, are we talking about the LVLCHK(*NO) on a PF/LF, or are we talking about the LVLCHK keyword on the STRPGMEXP statement? In either case, I'll argue that setting the signature manually is about the same thing as LVLCHK(*NO). > Let's carry the analogy forward. This is LVLCHK(*NO) when you know all > the original fields are the same and you're only adding fields to the > end of the record. But, you don't know that the fields are the same. You can add exports on the top, bottom, middle... doesn't matter, since the signature hasn't changed, it won't ever raise an alarm. > Now, if I had applications that read a file, and I knew that the record > format was the same and that those applications had no need for the new > fields, I'd be fine with LVLCHK(*NO). Sure, but you have to manually change the signature to something different each time the order of the exports has changed. If you don't do that, it will just call the wrong procedures. It's equivalent to keeping your PF at LVLCHK(*NO) until you add new fields in the middle of the record, and then changing it to LVLCHK(*YES). But, as Barbara pointed out, using *CURRENT/*PRV with SIGNATURE(*GEN) isn't any better. You still end up with the same problems. Really, this whole signature thing was poorly designed.
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.