Re: [U2] Justification for removal of savedlists
If it is at its default of ON, you save a command stack every time you log out. These are saved with a name of S.username.userno. The theory is that when you log back in, the system can reload your stack and you carry on as Isn't there a limit that can be set in Universe as to how much of a stack history is kept ? I just don't see people doing .L 200 to re-run a command they did 5 years ago. One place I've worked at had this standard. If a program creates a SAVEDLISTS for a task, it or the program the list is destined for must delete it when it is done with it. Adherance to this rule would leave save lists made by users by hand and the stack stuff mentionned above. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Justification for removal of savedlists
Hi Jaques, Isn't there a limit that can be set in Universe as to how much of a stack history is kept ? I just don't see people doing .L 200 to re-run a command they did 5 years ago. The stack is 99 commands (by default, it can be changed). The problem here is not that it is saving a longer stack but that it is saving the last 99 commands separately every time you log out. Martin Phillips Ladybridge Systems 17b Coldstream Lane, Hardingstone, Northampton NN4 6DB +44-(0)1604-709200 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Justification for removal of savedlists
I once wrote a wraparound to the savelist commands which datestamps the lists on creation and use. Also allows the user to flag a savelist as one that should not be overwritten or deleted. A purge program allows them to purge out savelists that are no longer necessary or haven't been accessed in a given period of time. Really helps keep the items in that file down. But, like Jeff Butera said, colleges especially might need to keep lists around for a while and this really helped some of our schools manage that. -Dianne Jeffrey Butera wrote: On Monday 06 February 2006 09:51, [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: I wrote a small routine that will go through Savedlists, HOLD files, ST.PPROCES records, etc. and selectively delete the records that are no longer needed but I have been stopped by my VP. She wants justification for the process. I don't have the knowledge to be able to give her what she wants. I've tried the following arguments with no luck: Savedlists can be outdated as soon as they are created. Taking up too much server room. Savedlists should never be re-used. By their very nature they are ephemeral. The above statement is application specific and not always true, particularly colleges running Unidata (Datatel). Yes, we do purge _HOLD_ and other things out but savedlists are generally held. Many institutions (for research purposes) may used savedlists for cohort tracking across many semesters or years. In these situations you *cannot* recreate the savedlist everytime as you have to ensure the group you initially select is the same group used months/years later - savedlists give you an easy method to acheive this (whereas the various data fields you may query against are constantly changing). With the myraid of reports colleges need (both internal and federally mandated IPEDS, etc) savedlists provide an extremely useful tool. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] Justification for removal of savedlists
I wrote a small routine that will go through Savedlists, HOLD files, ST.PPROCES records, etc. and selectively delete the records that are no longer needed but I have been stopped by my VP. She wants justification for the process. I don't have the knowledge to be able to give her what she wants. I've tried the following arguments with no luck: Savedlists can be outdated as soon as they are created. Taking up too much server room. Any one have any others to try? - Bill Pizer --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Justification for removal of savedlists
[EMAIL PROTECTED] wrote: I wrote a small routine that will go through Savedlists, HOLD files, ST.PPROCES records, etc. and selectively delete the records that are no longer needed but I have been stopped by my VP. She wants justification for the process. I don't have the knowledge to be able to give her what she wants. I've tried the following arguments with no luck: Savedlists can be outdated as soon as they are created. Taking up too much server room. Savedlists should never be re-used. By their very nature they are ephemeral. If a program created them, they should be recreated every time. If a user created them, they should be recreated every time. Pretty much the same holds true of the hold file. And ime, a full hold file can noticeably impact system performance - okay we're running on Windows, but when I filled the hold file with temporary files, I regularly got user complaints. Tell your VP you'll back SAVEDLISTS, HOLD to CD before you clean them up, and no you should not get any complaints because those files were *designed* as temporary work areas, not as data storage places. Cheers, Wol --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Justification for removal of savedlists
SAVEDLISTS is usually a directory file. Depending on your OS, putting a lot of files in a directory can be very innefficient. Records in HOLD can be very large, so disk space could be a good argument there. On the other hand, deleting saved lists can be problematic: are you sure no one wants that list anymore? Are you sure that that list you identified as being old and are about to delete hasn't just been re-written by a program reusing the name? I don't think the list verbs do a lot with locking. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Pizer Sent: Monday, February 06, 2006 9:33 AM To: u2-users@listserver.u2ug.org Subject: [U2] Justification for removal of savedlists I wrote a small routine that will go through Savedlists, HOLD files, ST.PPROCES records, etc. and selectively delete the records that are no longer needed but I have been stopped by my VP. She wants justification for the process. I don't have the knowledge to be able to give her what she wants. I've tried the following arguments with no luck: Savedlists can be outdated as soon as they are created. Taking up too much server room. Any one have any others to try? - Bill Pizer --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 267.15.2/251 - Release Date: 2/4/2006 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 267.15.2/251 - Release Date: 2/4/2006 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Justification for removal of savedlists
We would run out of disk space if we did not clean this stuff up. We have a
UNIX file system just for SAVEDLISTS, _PH_ and _HOLD_ items. That way if the
file system does fill up, it will not cause file corruption on Unidata
files. We run a UNIX 'find /mccdata/spool -mtime +15 -exec rm {}\;'. So we
only keep 15 days of these types of data around on our production machine.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Bill Pizer
Sent: Monday, February 06, 2006 8:33 AM
To: u2-users@listserver.u2ug.org
Subject: [U2] Justification for removal of savedlists
I wrote a small routine that will go through Savedlists, HOLD files,
ST.PPROCES records, etc. and selectively delete the records that are no
longer needed but I have been stopped by my VP.
She wants justification for the process. I don't have the knowledge to be
able to give her what she wants. I've tried the following arguments with no
luck:
Savedlists can be outdated as soon as they are created.
Taking up too much server room.
Any one have any others to try?
- Bill Pizer
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Justification for removal of savedlists
Try Savedlists do not contain data. They are collections of record keys selected for processing as a group (reports, postings, etc.), and deleting them does not change or delete the actual data. The records pointed to by the keys still exist as-is in their original files/tables. Keeping them does not add value to the system, as the records represented by the keys in the saved list may no longer exist in the file, or may have been updated since the saved list was created.. --Ron P. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Pizer Sent: Monday, February 06, 2006 8:33 AM To: u2-users@listserver.u2ug.org Subject: [U2] Justification for removal of savedlists I wrote a small routine that will go through Savedlists, HOLD files, ST.PPROCES records, etc. and selectively delete the records that are no longer needed but I have been stopped by my VP. She wants justification for the process. I don't have the knowledge to be able to give her what she wants. I've tried the following arguments with no luck: Savedlists can be outdated as soon as they are created. Taking up too much server room. Any one have any others to try? - Bill Pizer --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Justification for removal of savedlists
I'm torn on the issue. On one hand I completely agree with Wol (though I need to look up the word ephemeral just to be sure). Saved lists should be created each time they're needed - MOST of the time. There are other perfectly valid reasons why one program might create a list for another program to consume at some later moment. It's all a matter of how the app is designed to use the lists. On the other hand, I have to give some creedence to the caution of the VP. You certainly don't want to be removing items from the saved lists file while folks might be using them. Especially with Unidata, where the list is fragged into a whole bunch of smaller records, you could really damage the list if you happened to remove part of a list while the rest of the list were being created. A two-phase strategy might be the best course of action. Backup the items to some temporary place and then a week later roll those out when you backup the current crop of files. Over time when nobody needs those items you'll be able to skip that step, but until then, caution should be the order of the day to keep everyone comfortable. -Kevin [EMAIL PROTECTED] http://www.PrecisOnline.com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Justification for removal of savedlists
On Monday 06 February 2006 09:51, [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: I wrote a small routine that will go through Savedlists, HOLD files, ST.PPROCES records, etc. and selectively delete the records that are no longer needed but I have been stopped by my VP. She wants justification for the process. I don't have the knowledge to be able to give her what she wants. I've tried the following arguments with no luck: Savedlists can be outdated as soon as they are created. Taking up too much server room. Savedlists should never be re-used. By their very nature they are ephemeral. The above statement is application specific and not always true, particularly colleges running Unidata (Datatel). Yes, we do purge _HOLD_ and other things out but savedlists are generally held. Many institutions (for research purposes) may used savedlists for cohort tracking across many semesters or years. In these situations you *cannot* recreate the savedlist everytime as you have to ensure the group you initially select is the same group used months/years later - savedlists give you an easy method to acheive this (whereas the various data fields you may query against are constantly changing). With the myraid of reports colleges need (both internal and federally mandated IPEDS, etc) savedlists provide an extremely useful tool. -- Jeff Butera, Ph.D. Administrative Systems Hampshire College [EMAIL PROTECTED] 413-559-5556 Hindsight alone is not wisdom. George W. Bush --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Justification for removal of savedlists
SAVEDLISTS is a directory file. Searching a directory requires (on average) that you examine half the items in the directory before you find the one you want. Given a large directory, this can be very slow. (I once saw an example of a SAVEDLISTS directory with 275000 items in it!!) If this is UniVerse, also check that the STACKWRITE record in your VOC says X OFF If it is at its default of ON, you save a command stack every time you log out. These are saved with a name of S.username.userno. The theory is that when you log back in, the system can reload your stack and you carry on as though you had not gone home. This was fine in the days of async comms lines where you got the same user number each time you logged in. With modern networks this is not true. The command stack you recover is yours but potentially from ages ago and hence totally useless. If you have, say, 100 users each with a unique user name, given long enough you will have 1 totally useless command stack records killing performance of select list access. Scale this up to larger systems and the results are fascinating! [ Perhaps it's about time IBM reworked this feature. I have been telling people to turn it off the the last ten years or so ]. Martin Phillips Ladybridge Systems 17b Coldstream Lane, Hardingstone, Northampton NN4 6DB +44-(0)1604-709200 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Justification for removal of savedlists
I wrote a small routine that will go through Savedlists, One must be wary, as some VARs use SAVEDLISTS for storing permanent data. For example, one of Epicor's applications saves an index of all user-created report definitions in SAVEDLISTS. If you were to delete this file (which I have done), all user-created reports evaporate. Barry --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Justification for removal of savedlists
quote who=Jeffrey Butera On Monday 06 February 2006 09:51, [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: I wrote a small routine that will go through Savedlists, HOLD files, ST.PPROCES records, etc. and selectively delete the records that are no longer needed but I have been stopped by my VP. She wants justification for the process. I don't have the knowledge to be able to give her what she wants. I've tried the following arguments with no luck: Savedlists can be outdated as soon as they are created. Taking up too much server room. Savedlists should never be re-used. By their very nature they are ephemeral. The above statement is application specific and not always true, particularly colleges running Unidata (Datatel). Yes, we do purge _HOLD_ and other things out but savedlists are generally held. Many institutions (for research purposes) may used savedlists for cohort tracking across many semesters or years. In these situations you *cannot* recreate the savedlist everytime as you have to ensure the group you initially select is the same group used months/years later - savedlists give you an easy method to acheive this (whereas the various data fields you may query against are constantly changing). With the myraid of reports colleges need (both internal and federally mandated IPEDS, etc) savedlists provide an extremely useful tool. This is a case of poor programming practice. With QSELECT, and the nature of the SAVEDLISTS file (similar in design to /tmp), any select list that needs to be re-used should NOT be kept in SAVEDLISTS. There should be another file created and used for this purpose. The 2 reasons for this are: 1. cleaning out SAVEDLISTS doesn't develop into a 'political' issue, and 2. The file used instead can be a hashed file, thus eliminating the headaches of having a directory holding large numbers of records, such as the need to tune the inode kernel parameter(s). My $0.02 (USD) Karl -- Jeff Butera, Ph.D. Administrative Systems Hampshire College [EMAIL PROTECTED] 413-559-5556 Hindsight alone is not wisdom. George W. Bush --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ -- karl _/ _/ _/ _/_/_/ __o _/ _/ _/ _/_/ _-\._ _/_/_/ _/_/_/ (_)/ (_) _/ _/ _/ _/ .. _/ _/ arl _/_/_/ _/ earson[EMAIL PROTECTED] -- IT Director, ATS Industrial Supply, Inc. http://www.atsindustrial.com Toll-free: 800-789-9300 x29 Direct2Desk: 801-978-4429 Facsimile: 801-972-3888 -- --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Justification for removal of savedlists
While this may be true it is a poor design. The savedlists, hold, ph, and como directories are traditionally temporary directories. If you must save these lists then you should store them as you do other data in a file of a different name. If you need the select list in a processes in the future you can then copy it back or use a qselect. - Original Message - From: Jeffrey Butera [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org; [EMAIL PROTECTED] Sent: Monday, February 06, 2006 10:10 AM Subject: Re: [U2] Justification for removal of savedlists On Monday 06 February 2006 09:51, [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: I wrote a small routine that will go through Savedlists, HOLD files, ST.PPROCES records, etc. and selectively delete the records that are no longer needed but I have been stopped by my VP. She wants justification for the process. I don't have the knowledge to be able to give her what she wants. I've tried the following arguments with no luck: Savedlists can be outdated as soon as they are created. Taking up too much server room. Savedlists should never be re-used. By their very nature they are ephemeral. The above statement is application specific and not always true, particularly colleges running Unidata (Datatel). Yes, we do purge _HOLD_ and other things out but savedlists are generally held. Many institutions (for research purposes) may used savedlists for cohort tracking across many semesters or years. In these situations you *cannot* recreate the savedlist everytime as you have to ensure the group you initially select is the same group used months/years later - savedlists give you an easy method to acheive this (whereas the various data fields you may query against are constantly changing). With the myraid of reports colleges need (both internal and federally mandated IPEDS, etc) savedlists provide an extremely useful tool. -- Jeff Butera, Ph.D. Administrative Systems Hampshire College [EMAIL PROTECTED] 413-559-5556 Hindsight alone is not wisdom. George W. Bush --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Justification for removal of savedlists
I personally purge my saved-lists periodically and do not rely on saved-lists for permanent storage. For permanent storage I've created a program that saves the records from a select to a hashed file as one item with the file, date time saved as well as a comment as to the reason that I'm saving the records. The first field is the comment with each original record a field with the @id concatenated to the lowered data. The IDs to the archive records are stored in a control record. I have a restore program that displays the stored records displaying the file name, date, time and comment. I can select to delete the archived records or to restore the original records to the original file or any other file. These were very simple programs to write, but if anyone is interested in the concept, I will email you copies. Mel Maresh Senior IT Developer NextiraOne, LLC --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Justification for removal of savedlists
I have cured this problem by turning off the stackwrite and have a log on process that loads the stack by the users ID and saves the stack to the users ID when they exit. That way they always have the same stack no matter how they log in. - Original Message - From: Martin Phillips [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Monday, February 06, 2006 10:46 AM Subject: Re: [U2] Justification for removal of savedlists SAVEDLISTS is a directory file. Searching a directory requires (on average) that you examine half the items in the directory before you find the one you want. Given a large directory, this can be very slow. (I once saw an example of a SAVEDLISTS directory with 275000 items in it!!) If this is UniVerse, also check that the STACKWRITE record in your VOC says X OFF If it is at its default of ON, you save a command stack every time you log out. These are saved with a name of S.username.userno. The theory is that when you log back in, the system can reload your stack and you carry on as though you had not gone home. This was fine in the days of async comms lines where you got the same user number each time you logged in. With modern networks this is not true. The command stack you recover is yours but potentially from ages ago and hence totally useless. If you have, say, 100 users each with a unique user name, given long enough you will have 1 totally useless command stack records killing performance of select list access. Scale this up to larger systems and the results are fascinating! [ Perhaps it's about time IBM reworked this feature. I have been telling people to turn it off the the last ten years or so ]. Martin Phillips Ladybridge Systems 17b Coldstream Lane, Hardingstone, Northampton NN4 6DB +44-(0)1604-709200 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Justification for removal of savedlists
- Original Message - From: Martin Phillips [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Monday, February 06, 2006 10:46 AM Subject: Re: [U2] Justification for removal of savedlists ... If this is UniVerse, also check that the STACKWRITE record in your VOC says X OFF Anybody know the UniData equivalent to this? I've been digging around and can't find anything. Ray -- .=. | =-=-=-=-=-=-= Eagle Rock Information Systems Corp =-=-=-=-=-=-= | | -=-=-=-=-=-=- web and database business solutions -=-=-=-=-=-=- | | http://www.eriscorp.commailto:[EMAIL PROTECTED] | |Midwest Regional Office: 815-547-0662 (voice) 815-547-0353 (Fax)| .=. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Justification for removal of savedlists
Hi Raymond, If this is UniVerse, also check that the STACKWRITE record in your VOC says X OFF Anybody know the UniData equivalent to this? I've been digging around and can't find anything. The problem doesn't occur on Unidata which adopts a far more sane approach to saving command stacks. Martin Phillips Ladybridge Systems 17b Coldstream Lane, Hardingstone, Northampton NN4 6DB +44-(0)1604-709200 --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Justification for removal of savedlists
At 20:29 + 2006/02/06, Martin Phillips wrote: The problem doesn't occur on Unidata which adopts a far more sane approach to saving command stacks. True, but unfortunately, it's not perfect. We've had troubles at a client site where the command stack gets so full, the user core dumps as soon as UDT is started. Ray -- .=. | =-=-=-=-=-=-= Eagle Rock Information Systems Corp =-=-=-=-=-=-= | | -=-=-=-=-=-=- web and database business solutions -=-=-=-=-=-=- | | http://www.eriscorp.commailto:[EMAIL PROTECTED] | |Midwest Regional Office: 815-547-0662 (voice) 815-547-0353 (Fax)| .=. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Justification for removal of savedlists
On Behalf Of Bill Pizer I wrote a small routine that will go through Savedlists, HOLD files, ST.PPROCES records, etc. and selectively delete the records that are no longer needed but I have been stopped by my VP. She wants justification for the process. I don't have the knowledge to be able to give her what she wants. I've tried the following arguments with no luck: I'd go with the savedlists files are functionally equivalent to the \temp directory in Windows. It needs to be cleaned up periodically. I agree with the others and make sure that the entries are older than a certain date before removing them...just in case. - jmh --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Justification for removal of savedlists
I've seen instances of 'permanent' save lists but I've converted them to control records in a separate files. I like Microdata's date time stamp of their lists. UD/UV certainly have these in the unix level. I wish D3 had some because when looking only at the pointer-file, you really can't tell when they're made. And hunting down their source is not that easy with both SAVE-LIST, WRITELIST and writing directly to the POINTER-FILE. My 1 cent. - Original Message - From: Pingilley, Ron [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Monday, February 06, 2006 10:38 AM Subject: RE: [U2] Justification for removal of savedlists Try Savedlists do not contain data. They are collections of record keys selected for processing as a group (reports, postings, etc.), and deleting them does not change or delete the actual data. The records pointed to by the keys still exist as-is in their original files/tables. Keeping them does not add value to the system, as the records represented by the keys in the saved list may no longer exist in the file, or may have been updated since the saved list was created.. --Ron P. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Pizer Sent: Monday, February 06, 2006 8:33 AM To: u2-users@listserver.u2ug.org Subject: [U2] Justification for removal of savedlists I wrote a small routine that will go through Savedlists, HOLD files, ST.PPROCES records, etc. and selectively delete the records that are no longer needed but I have been stopped by my VP. She wants justification for the process. I don't have the knowledge to be able to give her what she wants. I've tried the following arguments with no luck: Savedlists can be outdated as soon as they are created. Taking up too much server room. Any one have any others to try? - Bill Pizer --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Justification for removal of savedlists
The best reason I know of to save SAVE.LISTs is to have a record of the data selected for a particular report or download (such as to SQL) so if there are any questions, the selected records can be easily re-selected verified. I usually name the SAVE.LIST the same as my program, with a month and year suffix, such as SIMULATOR.REVENUE.BUILD.2006.02 so I can easily identify both the program and the period in question. If the SAVELIST file is getting too full, it would be easy enough to have a separate directory like SAVE.HIST and a simple routine to get SAVE.LISTsfrom the history file. -- Louie Bergsagel On 2/5/06, Mark Johnson [EMAIL PROTECTED] wrote: I've seen instances of 'permanent' save lists but I've converted them to control records in a separate files. I like Microdata's date time stamp of their lists. UD/UV certainly have these in the unix level. I wish D3 had some because when looking only at the pointer-file, you really can't tell when they're made. And hunting down their source is not that easy with both SAVE-LIST, WRITELIST and writing directly to the POINTER-FILE. My 1 cent. - Original Message - From: Pingilley, Ron [EMAIL PROTECTED] To: u2-users@listserver.u2ug.org Sent: Monday, February 06, 2006 10:38 AM Subject: RE: [U2] Justification for removal of savedlists Try Savedlists do not contain data. They are collections of record keys selected for processing as a group (reports, postings, etc.), and deleting them does not change or delete the actual data. The records pointed to by the keys still exist as-is in their original files/tables. Keeping them does not add value to the system, as the records represented by the keys in the saved list may no longer exist in the file, or may have been updated since the saved list was created.. --Ron P. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Pizer Sent: Monday, February 06, 2006 8:33 AM To: u2-users@listserver.u2ug.org Subject: [U2] Justification for removal of savedlists I wrote a small routine that will go through Savedlists, HOLD files, ST.PPROCES records, etc. and selectively delete the records that are no longer needed but I have been stopped by my VP. She wants justification for the process. I don't have the knowledge to be able to give her what she wants. I've tried the following arguments with no luck: Savedlists can be outdated as soon as they are created. Taking up too much server room. Any one have any others to try? - Bill Pizer --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
