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



Diane,

I had a similar logic in a few very old CL programs. I replaced it with
a single command - CLRPFM. Everything works much faster and with the
same result. Command CLRPFM does 2 things: removes the data and
reorganizes physical file member (RGZPFM). The only advantage I can see
in your logic is the following. If you specify Access path maintenance
*DLY on CRTLF command the total time of the whole process will be
shortened. But you will "pay" at the time when this logical file is
opened by other program.

-Phil

Philip Kolomeysky | IT Consultant
t: 203-899-6932 | m: 516-987-5635 | www.tauck.com



-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
midrange-l-request@xxxxxxxxxxxx
Sent: Friday, October 20, 2017 3:09 PM
To: midrange-l@xxxxxxxxxxxx
Subject: MIDRANGE-L Digest, Vol 16, Issue 1676

Send MIDRANGE-L mailing list submissions to
midrange-l@xxxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.midrange.com/mailman/listinfo/midrange-l
or, via email, send a message with subject or body 'help' to
midrange-l-request@xxxxxxxxxxxx

You can reach the person managing the list at
midrange-l-owner@xxxxxxxxxxxx

When replying, please edit your Subject line so it is more specific than
"Re: Contents of MIDRANGE-L digest..."


*** NOTE: When replying to this digest message, PLEASE remove all text
unrelated to your reply and change the subject line so it is meaningful.

Today's Topics:

1. Questionable practice in file handling in CL (Duane Scott)
2. RE: Ruby status (Richard Schoen)
3. RE: Questionable practice in file handling in CL (Alan Shore)
4. resave levels and technology refresh levels (Jerry Draper)
5. RE: Questionable practice in file handling in CL (Duane Scott)


----------------------------------------------------------------------

message: 1
date: Fri, 20 Oct 2017 18:39:07 +0000
from: Duane Scott <dscott@xxxxxxxxxxx>
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.



------------------------------

message: 2
date: Fri, 20 Oct 2017 18:45:24 +0000
from: Richard Schoen <Richard.Schoen@xxxxxxxxxxxxxxx>
subject: RE: Ruby status

Maybe Aaron Bartell can provide some commentary since I believe he was
involved in the project at some point. Could be wrong.

Not sure if he still visits here.

He now seems to have switched core focus to Node.Js.

Not sure if that means Ruby didn't go over as super-hot on the i or he
found Node more compelling.

Regards,

Richard Schoen
Director of Document Management
e. richard.schoen@xxxxxxxxxxxxxxx
p. 952.486.6802
w. helpsystems.com

----------------------------------------------------------------------

message: 1
date: Fri, 20 Oct 2017 17:23:32 +0000
from: Justin Taylor <JUSTIN@xxxxxxxxxxxxx>
subject: RE: Ruby status

My curiosity is piqued now, so I did a little digging.

-The initial release was 4 years ago, but the Developer and Enterprise
editions still show coming soon.
-The site shows 2017, but a number of the links are dead (apparently
links to articles dating back to 2009).
-I don't do Twitter, but it looks to me like the last post to their
Twitter feed was 2015.

Agreed, not being IBM official is a hindrance.

________________________________________
From: John Yeung [gallium.arsenide@xxxxxxxxx]
Sent: Thursday, October 19, 2017 10:38 PM
To: Midrange Systems Technical Discussion
Subject: Re: Ruby status

I haven't heard anything about Ruby on i for so long, I kind of
thought it was a dead project. Am I wrong?

I doubt it's dead. This site doesn't look neglected:

https://powerruby.com/

My sense (completely unsubstantiated) is that it doesn't have the same
level of backing as PHP on i, and of course it's not in the 5733-OPS
suite of open source. In other words, less money and less shiny. But I
would think far from dead.

John Y.





------------------------------

message: 3
date: Fri, 20 Oct 2017 18:52:48 +0000
from: Alan Shore <ashore@xxxxxxxx>
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



------------------------------

message: 4
date: Fri, 20 Oct 2017 12:01:53 -0700
from: Jerry Draper <midrangel@xxxxxxxxxxxxx>
subject: resave levels and technology refresh levels

How do resave levels and technology refresh levels relate?

For example: We PTFed our machine to TR level 11; what would be the
corresponding resave level.

We need to get the corresponding iBase for DR purposes.

Jerry


--
Jerry Draper, Trilobyte Software Systems, since 1976 IBMi, Network, and
Connectivity Specialists, LAN/WAN/VPN Representing WinTronix, Synapse,
HiT, and others .....
(415) 457-3431 opt-1 . www.trilosoft.com



------------------------------

message: 5
date: Fri, 20 Oct 2017 19:08:35 +0000
from: Duane Scott <dscott@xxxxxxxxxxx>
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



------------------------------

Subject: Digest Footer


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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.