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



The query optimiser will consider all logicals over a file when deciding how
to open a file.

You just happened to create one that is better suited then the BPCS supplied
logicals.

The fields defined in the file bear no relation to the access path, they are
separate components.  Therefore the fields you are expecting are coming from
the logical/physical specified in the SQL.

Regards
Adam White
adam@slic-systems.com
www.slic-systems.com/

-----Original Message-----
From: midrange-l-admin@midrange.com [mailto:midrange-l-admin@midrange.com]On
Behalf Of afvaiv
Sent: 05 July 2002 00:12
To: MIDRANGE-L
Subject: SQL using access paths NOT meant for his use ...

Today we discovered something that strikes me:

We are using BPCS, but I think this has nothing to do with it.
Anyway, many BPCS programs use embebed SQL ... Not good performance at
times, but it works.

For some different reasons, I have created some logical files over BPCS
physical files, these logicals just intended for some other applications
that will use part of the BPCS data.

No problem with that. But, occasionally, we are having some "strange"
problems with some ot the BPCS data , programs, ...
Today we found out that doing a DSPJOB of a certain BPCS job, looking
into "Open files"... we were surprised to see some of our "logicals" as
being used by the BPCS job !!!

These "logicals" are on a separate library, NOT included, by no means,
in the jobs library list !
How come is BPCS using them ?
These logicals are NOT secured (not protected as public use of
*EXCLUDED) for different reasons... So, in theory, anyone could use
them, though normal users will never have access to them. Still...

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 ???

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

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,
-------------------------
Antonio Fernandez-Vicenti
afvaiv@wanadoo.es


_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.



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.