× 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 09-Jun-2010 14:04, Crispin Bates wrote:

I am looking to see if I can replace existing LFs with SQL INDEX
at i 6.1. I thought that the new RCDFMT keyword would allow
that, and it certainly seems to work quite nicely.

I remember there being some PTFs (SI23355 and SI27866) for V5R4
issues where the newly created file had a different Record Format
Level Identifier (RFLI) and this was caused by files that had
Date Fields in them. I am finding that if my TABLE (PF) has a
DATE field in it, then I am getting a different RFLI.

To see what was happening I removed the Date Field, and I then
get the same RFLI as the original LF had (which is exactly what I
am after).

Is this a case of the same issue has raised its head at 6.1, but
for a different reason (because the INDEX now supports the RCDFMT
keyword)?, or am I completely missing something, and there is a
PTF for this that I need to apply?


Was the based-on SQL TABLE PF of the SQL INDEX LF created new in this scenario, or was it created on a prior release? If the SQL TABLE was created in the past [before the PTF was applied] but has never been re-created from source or modified by ALTER TABLE to effect the new\corrected FmtLvlId for the RcdFmt, then the DATE, TIME, or TIMESTAMP field definition still reflects a RcdFmtLvlID with the separator being incorrectly included in the hash. If so, then the scenario would seem to be an example of a side-effect for the fix having been implemented as "least impact" as described in my archived post and one of the APARs which intended to provide a fix:
http://archive.midrange.com/midrange-l/200706/msg01191.html

SE22099 - OSP-DB FMTLVLID GENERATED INCORRECTLY FOR TIMESTAMP FIELD
http://www-01.ibm.com/support/docview.wss?uid=nas2ede7e016599ca1268625707e003c87e4

The corrective actions need to be performed for any columns with those data types, which were created prior to the corrective PTF having been applied, as described in the informational APAR:
II14134 - RECORD FORMAT LEVEL IDENTIFIER CHANGING FOR SQL TABLES
http://www-01.ibm.com/support/docview.wss?uid=nas221529fcce2f4b070862571010041fe11

Regards, Chuck

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.