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



Read the EXPORTS file an omit the directories in there ? Might not be
complete but it’ll get most of them.

On Tue, Nov 12, 2019 at 7:59 AM Rob Berendt <rob@xxxxxxxxx> wrote:

Is there an attribute on a directory which says that it is an NFS mount?
I'd rather not rely upon some naming convention or other such standard to
determine this.
Basically a program which has worked for years is now getting dragged down
by drilling down into NFS directories. IBM is aware of this issue but I
don't see it getting resolved any time soon. These NFS directories have
been there for quite some time also. IDK why this just started cropping up
but IBM has seen this elsewhere also.
7.4
A job which used to run in just a few minutes now takes 18 hours. If I
remove the NFS mounts it drops back down to 2 minutes. Based on what this
program is trying to do I'd like to omit drilling down into NFS mounts to
other machines.

Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
<https://www.google.com/maps/search/2505+Dekko+Drive?entry=gmail&source=g>
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com


-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Rob
Berendt
Sent: Tuesday, November 5, 2019 7:37 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: DSKIFS job takes a long time on occasion.

I have a job which basically lists the contents of the IFS into a table.
It uses IFS APIs in RPG to do so. Yes, I know about RTVDIRINF, and new
capabilities in SQL for 7.4, but let's concentrate on this, please. It
writes the results out to a partition (aka member) in this table. That
should let you know that this program has been around a long time as I'm
not a big fan of multipartition tables on systems without DB2 multisystem
(which basically is too stupid crazy expensive to only use it for
multipartition tables on a single system).

Regular day:
Job 685679/ROB/DSKIFS started on 11/01/19 at 08:00:00 in subsystem QBASE
in QSYS. Job entered system on 11/01/19 at 08:00:00.
IFSLIST OBJ(/) OBJTYPE(*ALL) TREELIST(Y)
Member D201911011 added to file IFSLIST in ROUTINES.
Job 685679/ROB/DSKIFS ended on 11/01/19 at 08:33:13; 19.588 seconds used;
end code 0 .

The first executable line is that IFSLIST command and that started
promptly at Time sent . . . . . . : 08:00:00

Yesterday morning:
Job 687350/ROB/DSKIFS started on 11/04/19 at 08:00:00 in subsystem QBASE
in QSYS. Job entered system on 11/04/19 at 08:00:00.
Job 687350/ROB/DSKIFS submitted.
IFSLIST OBJ(/) OBJTYPE(*ALL) TREELIST(Y)
Member D201911041 added to file IFSLIST in ROUTINES.
Job 687350/ROB/DSKIFS ended on 11/05/19 at 03:10:21; 264.148 seconds used;
end code 0 .
Again, the first executable line started promptly at Time sent . . . . .
. : 08:00:00. Therefore it wasn't hung up on a job queue or some such
thing. No obvious MSGW replies. Just to verify
DSPLOG PERIOD((*AVAIL 110419)) JOB(687350/ROB/DSKIFS)
Job 687350/ROB/DSKIFS started on 11/04/19 at 08:00:00 in subsystem QBASE
in Q
Job 687350/ROB/DSKIFS ended on 11/05/19 at 03:10:21; 264.148 seconds used;
en

System is dedicated for Domino work. Probably the biggest object in DB2
is that IFSLIST file. Not a whole lot of work going on in DB2.
% of Size in
Description Disk 1,000,000 bytes
User libraries 7.21 112870.08
User directories 60.39 945608.90
Folders and documents .00 4.26
QSYS .20 3118.63
Other IBM libraries 2.09 32703.36
Licensed Internal Code .60 9397.75
Temporary space 1.62 25426.99
Unused space 27.74 434323.76
System internal objects .03 482.61
Objects not in a library .00 .02
QTEMP libraries .00 16.86
TOTAL 99.88 1563953.22

I suppose one hypothesis might be stream file locking.
DSPJOBD JOBD(ROUTINES/DSKSUM)
Routing data . . . . . . . . . . . . . . . . . . : QCMDI
DSPSBSD SBSD(QBASE)
7. Routing entries
Routing entry sequence number . . . . . . . : 50
Program . . . . . . . . . . . . . . . . . . : QCMD
Library . . . . . . . . . . . . . . . . . : QSYS
Class . . . . . . . . . . . . . . . . . . . : QINTER
Library . . . . . . . . . . . . . . . . . : QGPL
Maximum active routing steps . . . . . . . : *NOMAX
Pool identifier . . . . . . . . . . . . . . : 2
Compare value . . . . . . . . . . . . . . . : 'QCMDI'

DSPCLS CLS(QGPL/QINTER)
Default wait time in seconds . . . . . . . . . . : 30

I could modify that somehow.

DSPFD FILE(ROUTINES/IFSLIST)
File is currently journaled . . . . . . . . : No
So I cannot see when the writes were happing. The table has no row change
timestamp type column.

Do you think the hypothesis is the way to go, or look at something else?
Why would stream file locking be such a factor on any particular run?
Perhaps a server wide Domino database maintenance run like
compact/fixup/updall?

Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
<https://www.google.com/maps/search/2505+Dekko+Drive?entry=gmail&source=g>
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
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: https://amazon.midrange.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
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: https://amazon.midrange.com


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.