× 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.



Antonio,

See comments inline:

> On Behalf Of afvaiv
> Subject: SQL using access paths NOT meant for his use ...
>
> I guess, when using SQL from a BPCS program, if the Optimizer finds
> there is "somewhere" (???) (my library ???) a logical file that has an
> access path that would be very convenient for the work it has been
asked
> to perform, maybe it is using that logical access path even though it
is
> not in the Library list ???

This sounds accurate.  The query engine will use whatever access path
most closely approximates its task.  The word "convenient" is very
appropriate.

> IF this is the case (I'm just guessing, since can't find a better
reason
> for what I've mentioned we saw when doing the DSPJOB / Open Files
...),
> the problem comes from the fact many of these "private logicals"  do
NOT
> include ALL the fields from the physical file, but just those fields
we
> felt were convenient for our needs.
> So, if SQL is using this access path for "its own convenience...",
> some/many of the fields it expects to read will be read as
> blanks,zeroes, nulls, or whatever, and the the BPCS program will
> fail/produce erroneous results...

I would not worry.  Each of the logical files contains pointers back to
the physical file.  What the optimizer is doing is using the access path
(record sequencing) of the logical to get the data from the physical.
The fact that your private logicals do not contain all of the fields is
not really relevant because the access path back to the physical is
still valid.  If you had select/omit criteria specified in the logical,
then you would have a problem.

> Am I correct interpreting SQL might be using our logicals "as
convenient
> paths" even though they are not in the BPCS job's library list ?
> If the answer is YES, how can we prevent it without recompiling
programs
> (BPCS source is, of course NOT available) nor going into securing
these
> logicals are restricted access thru special authoritites, groups, etc?
>
> Any suggestions will be welcome! Regards,

I would suggest that you don't worry about it.  If for some reason, you
get invalid results, then the BPCS folks and IBM need to fix it.  You're
doing nothing improper.  I also don't think that there is anything you
can do.  The system will use whatever it can find to process a query,
security won't prevent this unless you're doing an explicit open of the
file in your programs.

Regards,
Andy Nolen-Parkhouse



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.