× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On 21-Oct-2015 10:10 -0500, John Yeung wrote:
On Wed, Oct 21, 2015 at 10:29 AM, CRPence wrote:
FWiW: That the GENLVL(31) was not sufficiently effective seems
troublesome. Indeed, again, that situation would appear to be
"something the pre-compiler ought to be able to deal with". There
seems quite possibly to be a defect, at least as described; a
defect, that if not there, would have allowed that Severity Level
specification to overcome the issue. Effectively, by deleting the
file, the problem has been circumvented, but not resolved; i.e. the
apparent defect remains to be encountered again in another [or a
repeat] incident.

To be completely honest, I haven't fully followed your analysis, so
maybe you're saying what I'm thinking, just in different words; or
maybe you're saying something different.

I am totally with you on the "seems like a defect" language. ;)

From where I'm sitting, it feels like the compilation (of correct
*syntax*) should either (1) always succeed whether or not the file
is found, and if there's a runtime error, so be it; or (2) never
succeed when the file is not found.

I would be comfortable with "default GENLVL" behavior to be either
of the above. That is, I could make sense of "default GENLVL"
resulting in behavior (1) (and possibly no way of achieving (2)); or
of "default GENLVL" behavior being (2) and "permissive GENLVL"
behavior being (1).


That what the OP describes seems an apparent defect, apparently we are in agreement. As for the rest, not so much.

With regard to how the SQL deals with [non]existent references for validity checking statements, I am quite content with the compromise and the apparent rationale behind the choice to ignore the missing-references, whilst not ignoring those located-references for which the validity checking fails. Maybe that is, arguably, just a reflection of familiarity.? But in my opion:

While those absolutes might fit, in a /logical/ sense, they tend not to fit, in a /practical/ sense. Perhaps strangely, most people are [begrudgingly] joyful when the pre-compiler diagnoses that their reference is problematic. That although they may have to make changes to their source, and then issue the pre-compile request again, they usually have fared better than if they had only learned of the likely failure *after* they also ran their test suite. In the end, they have saved possibly huge amounts of time. In rare exception cases, when a program needs to be aware of the existence of both a prior and a present [or both the present and a future] _description of_ the reference [e.g. the Record Format (RCDFMT) of an altered or eventually to be altered TABLE], they can easily enough adjust their Severity Level (GENLVL) specification to ignore the error. Given the simultaneous-two-world-view scenario is atypical, IMO tending towards placating that small minority would just make the SQL seem less nice and less helpful for the vast majority.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.