It has been a while since I figured out the logic to do this, but can look it up if Y"all need it. I use it to identify queries/400 which have been setup but are no longer being used ... when I think I have found one, I move it to an archive library, from which i can recover it if need be, then if still not needed, after a year I can kill it.

There is a DAYS COUNT value in one of the DSP lists of software objects that we can created. This represents the # of days anyone used it since creation / update.

We can create two copies of this thing, say at beginning of two consecutive months, then have another query to compare the two dumps, and list those pieces of software not used in the intervening time.

If you sign on as master security officer, there's a disk space analysis you can run ... I've got mine setup to run automatically at end calendar month, to regurgitate the data ... you can use it to find out which files software etc. eating most disk space. What percent of disk space for spool files etc. This helps prioritize what is worth attacking.

One of the DSP object dumps will tell you how many records coded for deletion by file, which you can then input to query or program to calculate from record length how much disk space to recover via reorganizations. I now do reorgs every weekend.

There are also soft coded deletions within applications.

So, Charles, what you are trying to determine, if I understand
correctly, is whether or not a particular OCL member in QS36PRC has ever
been used or not? To the best of my knowledge there is no way to
determine this. (That said, IBM may have something hidden in the bowels
of the system, but I've never found it.)

Even the "Date last Used" in DSPFD is misleading (to my way of
thinking). I just looked at our QS36PRC source file and every OCL
member had yesterday's date as "Last Used". Probably because that's
when it was backed up. The information available from DSPFD is
generally intended for analyzing data files (OK, QS36PRC is a physical
file, but a special one - Source Physical).

I am guessing that you want to remove unused OCL36 members. First off,
you're not going to save a huge amount of space by doing that. But more
to the point, the only way that I have ever found to do this (find out
if a procedure is used) on both a /36 and i5 is to use the FNDSTRPDM
command to trace it, plus looking on the menus (source) to see if its
reference. After I "think" it's unused, I archive it and then delete it.

* Jerry C. Adams
*IBM System i Programmer/Analyst
B&W Wholesale Distributors, Inc.* *
voice
615.995.7024
fax
615.995.1201
email
jerry@xxxxxxxxxxxxxxx <mailto:jerry@xxxxxxxxxxxxxxx>



Charles St-Laurent wrote:
> Hi!
>
> No, I really have OCL statements in OCL/36 sources, placed in QS36PRC of a
> library
>
> Charles
>
>
> "PaulMmn" <PaulMmn@xxxxxxxxxxxxx> a écrit dans le
> message de news: p06110404c335394da1f7@[10.1.1.2]...
>
>> Charles--
>>
>> If I understand your question, you're looking at the source code in
>> file QCLSRC... Or do you really have OCL statements?
>>
>> If it's source code on QCLSRC, it's entirely likely that the source
>> code may not have been touched recently, because most source in
>> QCLSRC is compiled into programs, often with the program having the
>> same name as the source member. You'd have WRKOBJ or DSPOBJD and
>> look at the information for the compiled program.
>>
>> --Paul E Musselman
>> PaulMmn@xxxxxxxxxxxxxxxxxxxx
>>
>>
>>
>> At 10:19 AM -0400 10/12/07, Charles St-Laurent wrote:
>>
>>> Hi!
>>>
>>> I try to know if OCL has never been interpreted since we have our new
>>> server. I tried the DSPFD command with the *MBR attribute and I wonder if
>>> Logical Reads = 0 means that the OCL has never been interpreted...
>>>
>>> Can someone answer my question?
>>>
>>> Charles
>>>
>> --
>> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
>> list
>> To post a message email:
>> MIDRANGE-L@xxxxxxxxxxxx
>> To subscribe, unsubscribe, or change list options,
>> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
>> or email: MIDRANGE-L-request@xxxxxxxxxxxx
>> Before posting, please take a moment to review the archives
>> at http://archive.midrange.com/midrange-l.
>>
>>
>>
>
>
>
>

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




This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 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].