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



Thanks to all who answered. Unless anybody else has something new to add, I've got my answers.

I agree with all about the quantity of records (in my case) being insignificant, as well as having to run my own diagnostics just to determine what my machine would do.

And Roger's assessment that already more time has been spent is somewhat true in this case and could be made for quite a few coding practices that are being considered for updating. I'm rewriting (modernizing) the process and in the process attempting to update the code notes so as not to further do this again in the future. (now I've just spent more time. Dangit)

The code itself, not being documented and not even knowing who wrote it, being probably 12 years old, may have been written by someone who knew more about it than I do, or could have been written by someone who just didn't know any better. I suspect they knew what others considered to be the "best practice" for such an effort.

Duane

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Gad Miron
Sent: Saturday, October 21, 2017 3:59 AM
To: midrange-l@xxxxxxxxxxxx
Subject: RE: Questionable practice in file handling in CL

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.

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.