RE: DSKIFS job takes a long time on occasion. -- MIDRANGE-L

Can you parse the results of df -T in qshell? There are some unix type api's but don't appear to be any good examples in anything other than C.

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

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

[https://www.medtronsoftware.com/img/MedtronMinilogo.bmp] Kevin Bucknum
Senior Programmer Analyst
MEDDATA / MEDTRON
120 Innwood Drive
Covington LA 70433
Local: 985-893-2550
Toll Free: 877-893-2550
https://www.medtronsoftware.com

CONFIDENTIALITY NOTICE

This document and any accompanying this email transmission contain confidential information, belonging to the sender that is legally privileged. This information is intended only for the use of the individual or entity named above. The authorized recipient of this information is prohibited from disclosing this information to any other party and is required to destroy the information after its stated need has been fulfilled. If you are not the intended recipient, or the employee of agent responsible to deliver it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or action taken in reliance on the contents of these documents is STRICTLY PROHIBITED. If you have received this email in error, please notify the sender immediately to arrange for return or destruction of these documents.