Identify obsolete online natural programs

Can anyone tell me the procedure to identify the obsolete online natural programs existing in all the libraries.

Thanks in advance

Regards
Sridevi

Hi Sridevi,

You may wish to implement some kind of NATRDC exit to capture library & program name of every program loaded into the Natural program buffer and store this over a period of time (ensure you run this through year-end to capture programs only run once a year).

Then you should be able to get a list of programs that aren’t run by comparing your set of all objects to this list.

Will you get LDAs/PDAs/Copycodes this way? AFAIK natural doesn’t need LDAs at runtime…

You can use PREDICT xref (L X) for this purpose: Create a list of objects not used/called. All these objects are candidates for deletion. Then you should create a list of all objects calling other objects dynamically (*DYNAMIC in L X listings) and analyze these objects for calling any of the deletion candidates.

You should repeat this for all libraries with different steplib pathes.

[quote="Wilfried B

For example L X VERIFY PROG REFERENCES (*)

[quote="Wilfried B

I read the documentation and did a consistency check. We got many many inconsistencies (“Xref invalid”). Don’t ask my why…

http://techcommunity.softwareag.com/ecosystem/documentation/natural/prd452/reference/natxref_verify_9.htm#Verify_Consistency

You can also check on the active monitoring tools such as REVIEW (from Software AG) - they can track which programs are actually called from Adabas command monitoring. Of course, you have to monitor the activity over a period (often a year) to ensure that all active modules are invoked, including those only used for annual processes.

A combination of XREF information and monitoring can probably yield more accurate results than either used alone.

Matthias - if your XREF is invalid, is XREF ON where modules are catalogued? Inconsistent XREF usually indicates that the source/object were saved/catalogued without XREF. Turn on XREF and do a CATALL to correct it, then make sure XREF is ON by default (through Natural Security profiles or NATPARMs)

A trick to XREF modules that are called dynamically is to add a dummy subroutine (or false condition) -
DEFINE SUBROUTINE XREF_DYNAMICS /* never PERFORMed
CALLNAT ‘MYSUBPRG’
CALLNAT ‘YRSUBPRG’
FETCH ‘MYPROG’
FETCH ‘YRPROG’
END-SUBROUTINE

CALLNAT #field
FETCH #field

Is this product available for Open Systems as well?

Yes, but our service provider obviously did an ftouch for all Modules last month… We think, that’s the reason. In fact we did a catall afterwards, but it seems that only a STOW helps.

Of course I thought about that but that’s not a really proper way … IMHO, special command lines would be better.