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



Simon,

I'm not disagreeing with anyone anymore. I did say that it was probably a
case of me not having seen it on the 38 and then seen it on the 400 (in
'89), and that was where I had mistakenly thought that had been a change to
os/400. As I pointed out, it was 19 years ago that I made the move from the
38 to the 400. My old brain obviously isn't as good at remembering things
from that long ago anymore, and I muddled up the circumstances. :-)

The link I provided was purely something I came across while googling in an
attempt to find some confirmation of the behavior. Both yourself and Chuck
have now done that.

Now, Alan did say that it was automatically sharing back on release 3. Chuck
has since confirmed that was not the case, and that it was release 7.

Anyway, now that we know, not much point in laboring on it. Sorry if I
offended anyone...

Crispin.


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Simon Coulter
Sent: Thursday, March 13, 2008 9:59 PM
To: Midrange Systems Technical Discussion
Subject: Re: Are we insane? Unique use of native DB2


On 14/03/2008, at 12:23 PM, Crispin wrote:

On page 10 of the document in the following link, Dan Cruikshank
says it
wasn't on the S/38, and you had to use REFACCPTH.

http://www-03.ibm.com/servers/eserver/iseries/db2/pdf/
Performance_DDS_SQL.pdf

He says:
"In order for the HLL applications to use the 64K access path we need
to take advantage of the
built in access path sharing support of OS/400 (i5/OS). This support
is not new. On the
System/38 you needed to specify the REFACCPTH file level keyword
within your DDS source
for the keyed logical file you were creating. Those of us who were
aware of this keyword used it
to minimize access path maintenance."

He's wrong on two counts:
1) REFACCPTH was not available on CPF. It is new with OS/400 (and
it's not listed in my CPF 8.0 Programming Reference Summary)
2) Implicit access path sharing was available on CPF (at least on
Rel. 8.0) so it was not necessary to specify sharing

ACCPTH is listed in my S/38 Programming Reference Summary:

"Explicitly specifies that the keyed-sequence access path of a
previously created logical or physical file is to be shared by the
file you are creating."

Keyword is valid for LF only at the File level. Not valid for Join LF.

Compare with REFACCPTH from current DDS reference.

"You can use this file-level keyword to specify that the access path
information for this logical file is to be copied from another
physical or logical file."

Note the use of "copied" in REFACCPTH? This just copies the
definition. Sharing still happens automatically.

Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists

http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------




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.