Re: SQL function for module information

On Oct 5, 2023, at 5:53 PM, Peter Dow <petercdow@xxxxxxxxx> wrote:

I'm curious - DSPMOD will only show information for *MODULE objects. Does your compile process always produce a *MODULE object, then bind it into a program?


On 9/7/2023 8:43 AM, smith5646midrange@xxxxxxxxx wrote:

For a little more clarity, I am working on an application to archive obsolete stuff. This will be a manual process where the user tells it what to archive. Its primarily purpose is to track and archive objects that are being obsoleted by a new project. For example, if we have interfaces from a specific vendor and we are changing vendors and need new objects and programs, the old vendor objects would be added to the application and at a future date (probably 30 - 90 days after implementation), someone will execute the archive part of the project and the objects will be archived. Currently we are relying on the user to do the due diligence to ensure the objects should be archived. I'm guessing after someone archives something that shouldn't have been archived, there will be logic added to do a deeper dive on the objects to be archived. Since I know this WILL happen at some point, there will also be a restore function in the application.

BOUND_MODULE_INFO only works if the module still exists in a program and I'd rather not "dump" the entire system to look for something using a specific module. We also have a bunch of obsolete modules that aren't bound into anything anymore because someone already archived the program(s) that used them. DSPMOD give me the module details whether the module is bound into a program or not.

I will be also writing a mass cleanup program that will populate a project in this new application to clean up the old stuff that has been laying around for YEARS that nobody knows anything about but that is a future phase. That is probably where the restore function and the deeper dive will come into play. :)



-----Original Message-----
From: MIDRANGE-L<midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Rob Berendt
Sent: Thursday, September 7, 2023 11:10 AM
To: Midrange Systems Technical Discussion<midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: SQL function for module information

https://www.ibm.com/docs/en/i/7.5?topic=services-bound-module-info-view

On Thu, Sep 7, 2023 at 10:15 AM<smith5646midrange@xxxxxxxxx> wrote:

Is there an SQL function that provides the information that DSPMOD
provides?
I am specifically looking for the source member information. I'd
prefer to use SQL if something is available instead of DSPMOD to an
outfile or the QBNRMODI api.

--
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 contactsupport@xxxxxxxxxxxxxxxxxxxx for any subscription
related questions.

--
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 athttps://archive.midrange.com/midrange-l.

Please contactsupport@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.

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