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



Chuck,

Thanks. Although not an alternative directly related to creating the
logical, I did come up with an option that negated even having to create the
LF. By using a dynamic SELECT in the instance which caused me to "think" I
needed the LF to replicate an old (S/36) process that I was re-writing in
RPG IV, the LF became unneeded since it was only used in that one process.
However, other LF's are not quite so singular.

What even made it necessary to create the LFs was that the S/36 BLDINDEX
started choking when I externally defined the master table. In a previous
existence (V5R3/R4) this did not seem to create a problem (if I'm
remembering right). The default at V5R1 for CRTPF is Re-Use Deleted Records
= *No (I thought it was *Yes at V5R3+, but may be misremembering), or
someone changed the default here. Anyway, I created the table with *Yes,
but BLDINDEX barfed on that (forget the exact message now, but something to
do with the DUPKEY parameter). Using CRTLF instead of BLDINDEX eliminated
that problem.

Creating the group file version of the master table (such as A.IVMAST and
D.IVMAST) is easily done from a single CRTPF command since the command wants
to know the name of the file to create. The CRTLF command, however, uses
the PFILE keyword in the DDS to determine on which table to base the
logical. At least I couldn't find an alternative shorter than creating
multiple DDS source members.

Jerry C. Adams
IBM i Programmer/Analyst
You can look it up. -Casey Stengel
--
A&K Wholesale
Murfreesboro, TN
615-867-5070


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Thursday, March 10, 2011 10:36 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Logicals Over Group Files

On 3/3/11 8:02 AM, Jerry C. Adams wrote:
I have an old S/36 application here that I am slowly trying to
convert. I.e., the files are not externally described, except for the
few I have converted so far. All of the files (physical and logical)
are contained in the same library (QS36F).

The application uses the old S/36 group file designation to
differentiate between companies, such as A.IVMAST and D.IVMAST. I
replace the BLDFILE commands with a CRTwhatever command to build the
physical, and the group file is not an issue at that time.

However, when I replace the BLDINDEX command with an equivalent
CRTsomelf command, the group file is a problem because the DDS for
the LF wants to know the name of the parent, such as:

R IVMASTR PFILE(A.IVMAST)

So far I have wound up creating multiple DDS definitions; one for
each possible parent. In the CRTsomelf program I know which group I'm
operating on so it's relatively easy to ascertain which DDS member to
use.

I was just wondering if there isn't an easier way to do this.

<<SNIP>>


As externally described single member group files the SQL CREATE
INDEX could be a reasonable replacement for a CRTLF:
create index "A.IVMASTIX" on "A.IVMAST" (fldname)

Other options do exist, but I would not expect any would be any
easier than using SQL CREATE INDEX or the multiple source member
approach already in use. Other options include one model file for each
group file then CRTDUPOBJ at run-time instead of creating the LF from
source, or one model logical file combined with RNMOBJ of the model
physical group file before CRTDUPOBJ, or allocating and updating one
specific source member before each CRTLF.

Regards, Chuck

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.