RE: Questionable practice in file handling in CL -- MIDRANGE-L

My to bits..

I periodically re-create 50M-records file
(combining about a 100 MBRs to a single-MBR file for DWH purposes)
This file has 6 LFs over it.

I've found that deleting the LFs , clearing the file , re-populating it and
then re-creating
the LFs (one at time)
is (slightly) *faster* then just doing a CLRPFMBR and re-populating the
file.

This was way back at Ver 6.1 but it may still hold.

BUT, in case of a 30K-records file I believe the difference is negligible.

HTH
Gad

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

Interesting concept. I want to argue, but I just can't.

At some point, I think I heard that argument before, but as it doesn't
TYPICALLY come up that a complete set of files are deleted and recreated
each night, I can't think that I would think of that as an excuse.

Using the same logic, should all logicals be deleted and then recreated on
a regular basis so as to ensure that the most efficient pathing is used?
Or should it be a "Once and Done"?

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

Hi Duane
I don't have what you are looking for - but I do have some statements
about what you wrote (nothing bad - don't worry - just something to make
someone think - or for someone else to tell me that I am wrong)

The original intention of this program may have been to recreate the
logicals in a better order

For example - if the first logical - logical1 - built over the physical
created keys using field A and Field B Then a subsequent logical -logical2
- was built over the same physical creating keys using field A, Field B AND
field C There would be 2 separate paths created

It would be MUCH more efficient to delete those logicals and re-create
them in a different order Logical 2 THEN logical 1, because logical 1 will
use the paths already created with logical 2

At least that was how things were explained to me once

Alan Shore
E-mail : ASHORE@xxxxxxxx
Phone [O] : (631) 200-5019
Phone [C] : (631) 880-8640
'If you're going through hell, keep going.'
Winston Churchill

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

CONFIDENTIALITY NOTICE: This electronic message transmission is intended
only for the person or entity to which it is addressed and may contain
information that is privileged, confidential or otherwise protected from
disclosure. If you have received this transmission, but are not the
intended recipient, you are hereby notified that any disclosure, copying,
distribution or use of the contents of this information is strictly
prohibited. If you have received this e-mail in error, please contact NALC
Health Benefit Plan at 703-729-4677 and delete and destroy the original
message and all copies.

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

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD

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

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD

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

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD

---