RE: Questionable practice in file handling in CL

Duane--

A slightly different sequence that I've heard about (and considered for some of our large (ie millions of records) files:

1) RMVLFM (remove logical file member - effectively blows away the index) of the 6 logical files
2) CLRPFM (this is a very efficient function!)
3) ---
4) Write the records. If the PF has its own index, this is built as the records are written.
5) ADDLFM (Add Logical File Member) for each of the 6 LFs. Assuming your system has enough horse power, they can run in parallel.

This avoids the need to find the DDS, and avoids the (potential) risk of changing the file/format level identifier and ending up with Level Checks all over the place!

One other comment-- unless you system is terribly slow, 20-30K records should be considered a teensy-weensy file! Even if you just start with CLRPFM and then write the records, the system should be able to handle updating 6 LFs at once. Your mileage may vary.

Paul E Musselman
PaulMmn@xxxxxxxxxxxxx

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Duane Scott
Sent: Friday, October 20, 2017 2:39 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: Questionable practice in file handling in CL

I'm looking at a CL that:

1. deletes the 6 logicals on a single physical file
2. deletes the physical file
3. recreates the physical from the DDS
4. runs an RPG program that writes (20k to 30k) records to the physical
5. recreates the 6 logicals

The only explanation I can come up with is that it once was thought that the system would be faster if the logicals were built one at a time after the physical was built rather than during the running of the RPG program.

Does anybody have stats to back this up.

I think it's not needed and that a CLRPFM on the physical is all that would be necessary and allow each logical to remain during the run of the RPG build program.

Duane