I would recommend Hawkeye from Pathfinder, if it is still out there. Been awhile.

PDM can do a lot of the same chores.

But it sounds like it is time to attach some journals to files, then watch over the course of a year, who opens files and who doesn't, and which files.

From a DSPJRN command, you can build an extensive data collection and then just use query to compile a list of who is used. Then use a DSPOBJD and hit it against your production libraries, selecting files only, then compare the two. Your non-matches should be investigated and then deleted or archived, if applicable.

Not a quick process and nothing looks worse than accidentally whacking a end-of-year object when year closing occurs.

Just a suggestion. But it is something easily done by you and your peeps.

-----Original Message-----
From: cobol400-l-bounces@xxxxxxxxxxxx [mailto:cobol400-l-bounces@xxxxxxxxxxxx] On Behalf Of cobol400-l-request@xxxxxxxxxxxx
Sent: Thursday, October 07, 2010 1:00 PM
To: cobol400-l@xxxxxxxxxxxx
Subject: COBOL400-L Digest, Vol 8, Issue 40

Send COBOL400-L mailing list submissions to
cobol400-l@xxxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.midrange.com/mailman/listinfo/cobol400-l
or, via email, send a message with subject or body 'help' to
cobol400-l-request@xxxxxxxxxxxx

You can reach the person managing the list at
cobol400-l-owner@xxxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of COBOL400-L digest..."


Today's Topics:

1. Cobol/DDS Consulting Groups (Jeff Buening)


----------------------------------------------------------------------

message: 1
date: Thu, 7 Oct 2010 11:42:28 -0400
from: Jeff Buening <JeffBuening@xxxxxxxxxxxxxxxxxxx>
subject: [COBOL400-L] Cobol/DDS Consulting Groups


Working at a small company that has your basic DDS file structure and
Normal I/O access besides some embedded SQL in COBOL mixed in. We use IBM
for the server/software, but seems like biggest issues for us is adding
fields to our main files. One issue is for all these years there never was
a logical layer standard put in place, so most programs read the physical
directly and some do use logicals. Most logicals were compiled and have
not been look at for years. Just wondering what other places that mostly
use COBOL have done, do you use a change management system, have a logical
layer in place, or like us just have to recompile bunch of programs?

Also, does anyone have any good references of companies or consultants that
have come in and given some recommendations of processes and things you
could change mostly database design?




Thanks,
Jeff
Located in Ohio



------------------------------

--
This is the COBOL Programming on the iSeries/AS400 (COBOL400-L) digest list
To post a message email: COBOL400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/cobol400-l
or email: COBOL400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/cobol400-l.



End of COBOL400-L Digest, Vol 8, Issue 40
*****************************************

Important Confidentiality Notice: This email message, including all attachments is for the exclusive use by the person(s) to whom it is addressed, and may contain information that is confidential or privileged. Any unauthorized review, use, disclosure or distribution is prohibited under applicable law. If you have received this email in error, please notify me immediately by reply email and delete this message and any attachments. Thank you.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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

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

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.