Re[2]: qsys2.IFS_OBJECT_STATISTICS won't return anything under /QNTC. Other SQL options?

Carsten's utility is great, and I use it quite often, just not on QNTC.


--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


------ Original Message ------

From "Dan Bale" <dan.bale@xxxxxxxxxxxxxxxxxxxxx>

To "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxxxxxxxx>
Date 10/8/2024 9:35:38 AM
Subject RE: qsys2.IFS_OBJECT_STATISTICS won't return anything under /QNTC. Other SQL options?

It's been so long since I last worked with QNTC that I forgot how "foreign" it is. So, what you say makes a lot more sense now.

Honestly, I only brought up Carsten's utility to see how the "get" of the Qp0lGetAttr API works; not looking to change anything on the objects in QNTC. But from what I could tell, that API doesn't take a generic /QNTC/* parameter.

- Dan

-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Jim Oberholtzer
Sent: Tuesday, October 8, 2024 8:52 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: qsys2.IFS_OBJECT_STATISTICS won't return anything under /QNTC. Other SQL options?

Think about what QNTC is. It is a method to create a shared drive on IBM i that resides in a different system, usually a Microsoft based system.

Given that, would you allow a foreign system using a share on your system to make those types of changes? Also, how is IBM i going to get statistics from a different system that has different architecture and rules surrounding its file structures?

The rules for QNTC are different than local IFS objects.

You need to get that foreign system on the other end of the QNTC to make those changes.

Jim Oberholtzer
Agile Technology Architects

On Oct 7, 2024, at 9:32 PM, Dan Bale <dan.bale@xxxxxxxxxxxxxxxxxxxxx> wrote:

I also found Carsten Flensburg's CHGIFSATR (Change IFS Attributes) command/program. I compiled it and tried to change the Read Only attribute on one of the directories under /QNTC/. It returned an error CPD0085 "Range of parameter CCSID does not include 0." It turns out that directories created under /QNTC/ are "assigned" a CCSID = 0.

Command RTVDIRINF also ignores anything under /QNTC/.

- Dan

-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of
Dan Bale
Sent: Monday, October 7, 2024 6:58 PM
To: Midrange Systems Technical Discussion
<midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: qsys2.IFS_OBJECT_STATISTICS won't return anything under /QNTC. Other SQL options?

IBM docs says: "No rows are returned for remote file system objects. This means that for the QNTC file system, only a row for /QNTC is returned."

I need to find all the directories under /QNTC. Am I limited to "DSPLNK OBJ('/qntc/*') OUTPUT(*PRINT) OBJTYPE(*ALLDIR) DETAIL(*NAME) DSPOPT(*ALL)", then copying the spool file to disk and reading that?

I did see an idea (IBMI-I-2844) submitted by Darren Strong 4 years ago, which has been under "Future consideration" for 3 years. Yay?

Per Rob's response to Darren, I found the Qp0lGetAttr API and then found Scott Klement's headers for this. Great, but holy smokes, after reviewing the Qp0lGetAttr prototype and the Qlg_Path_Name_t and Qp0l_AttrTypes_List_t data structure definitions, I feel like DSPLNK, CPYSPLF, and querying the outfile (and hope there are no really long directory names) is the way to go.

Has anyone already invented this wheel and would they be willing to share?

- Dan

*** CONFIDENTIALITY NOTICE: The information contained in this communication may be confidential, and is intended only for the use of the recipients named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please return it to the sender immediately and delete the original message and any copy of it from your computer system. If you have any questions concerning this message, please contact the sender. ***
--
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@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.