|
I am beginning to have a concern about what I consider to be a series of adverse management decisions where I work. My concerns are not just disk space, but also performance accessing reports when there are tens of thousands owned by the guy who runs end fiscal stuff. 1. In end fiscal month we have reports that are like 100,000 pages in length, in which we print the total page only, then if some questions come up, we print selected sub-total pages, other chunks, but we NEVER print all 100,000.. Our auditors are on some system other than the 400 & they want copies of some of these end fiscal reports. I am saying that most any e-mail system will choke on any of these reports, and an XL user is not going to be able to cope with 100,000 rows. 2. They don't want to delete end fiscal reports from over a year ago, so now a considerable % of our disk space is this stuff. I have been suggesting we come up with storing end fiscal reports for each fiscal month, end year, physical inventory, on a different set of CD Rom, because I believe CD-Rom are like the 8" diskettes of the past, they good for 10-20 years, but other people here are pushing DVD and thumbnail drives, which I feel are here today, and no longer around in a couple years, due to rapid technology change. So for you learning from this: * What backup technology has reliability to store stuff off line to be retrieved many years later in usable form, at a time that we may now be on a different version of the OS, requiring some kind of upgrade to the backup to make it usable? * How long do you need what reports to be kept stored on any system, and how large are those reports? * Who will need to get copies of what reports on what other systems ... like customer vendor supply chain, auditor copies of some types of reports, government compliance reports, future audit like IRS. There is also the potential for waste in how data base files are structured. Fixed length is the norm there also. A file may have many fields that are unpopulated in most records, except for blanks or zeros. We can provide for files to eat more disk space as they grown, but need to take IT action to downsize files as they no longer need the extra disk space. - Al Macintyre http://en.wikipedia.org/wiki/User:AlMac http://www.ryze.com/go/Al9Mac BPCS/400 Computer Janitor ... see http://radio.weblogs.com/0107846/stories/2002/11/08/bpcsDocSources.html
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 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.