RE: SQL function for module information -- MIDRANGE-L

A module is always bound into programs or service programs.
There is no need to archive/save/keep modules separately, au contraire it may cause problems when binding an wrong module.

Mit freundlichen Grüßen / Best regards

Birgitta Hauser
Modernization – Education – Consulting on IBM i

IBM Champion since 2020

"Shoot for the moon, even if you miss, you'll land among the stars." (Les Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them and keeping them!"
"Train people well enough so they can leave, treat them well enough so they don't want to. " (Richard Branson)
"Learning is experience … everything else is only information!" (Albert Einstein)

-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Peter Dow
Sent: Friday, 6 October 2023 02:37
To: midrange-l@xxxxxxxxxxxxxxxxxx
Subject: Re: SQL function for module information

Yes, but it's in QTEMP. It won't be around for his archiving process.

On 10/5/2023 3:51 PM, Jon Paris wrote:

All ILE compiles do. CRTBNDRPG =for example will create a *Module in QTEMP and then invoke CRTPGM.

Jon P.

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

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 messageemail:MIDRANGE-L@xxxxxxxxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,
visit:https://lists.midrange.com/mailman/listinfo/midrange-l
oremail:MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.

Pleasecontactsupport@xxxxxxxxxxxxxxxxxxxx for any subscription
related questions.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a messageemail:MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:https://lists.midrange.com/mailman/listinfo/midrange-l
oremail:MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives athttps://archive.midrange.com/midrange-l.

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