T.R | Title | User | Personal Name | Date | Lines |
---|
413.1 | see p a-42, doc for abs save /inter=one_time | COOKIE::LEWIS | | Mon Mar 31 1997 14:57 | 8 |
| The doc says
"After a successful operation and 72 hours have passed, the job is deleted
from POLYCENTER Scheduler and from ABS by its cleanup utility routine.
Is that what was being asked?
jim
|
413.2 | | CX3PST::BSS::SAUL | | Tue Apr 01 1997 13:02 | 16 |
| Hi Jim,
>"After a successful operation and 72 hours have passed, the job is deleted
>from POLYCENTER Scheduler and from ABS by its cleanup utility routine.
Saw that but we have seen some jobs hanging around longer and not getting cleaned up.
So that brings up more two more questions...
- 72 hours from when...creation or the last time it ran?
- It says successful completion...does this mean if it failed it doesn't get cleaned
up?
Just trying to figure out what might keep the job from getting purged. Thanks.
Ted
|
413.3 | checking on this | COOKIE::LEWIS | | Thu Apr 03 1997 09:13 | 8 |
| I Ted,
I'm looking in to this a little more. I believe it should remove the scheduler
job, and cleanup the "expired" entries from the catalog, 72 hours after a
SUCCESSFUL completion. If the job fails, it should stay. However, in
looking at some of our catalogs, I find entries that I don't think they should
be there. I'll do some more checking and keep you posted.
Jim
|
413.4 | are you seeing catalog entries, or scheduler entries, or policy database entries ?? | COOKIE::LEWIS | | Thu Apr 03 1997 18:19 | 7 |
| Hi Ted, When you say there are some entries that you don't think should be
there, are you talking about scheduler entries, or policy database entries
(you do an abs show save ... and the save request is still there, but it
has been three days), or catalog entries, (from abs lookup)?
Thanks.
jim
|
413.5 | | CX3PST::BSS::SAUL | | Thu Apr 10 1997 13:26 | 73 |
| >Hi Ted, When you say there are some entries that you don't think should be
>there, are you talking about scheduler entries, or policy database entries
>(you do an abs show save ... and the save request is still there, but it
>has been three days), or catalog entries, (from abs lookup)?
Here is one on my machine that has been there a while...
Job Name Entry User_name State Next Run Time
-------- ----- --------- ----- -------------
SAUL_25-MAR-1997_11_50_38_16
208 ABS Scheduled Never
VMS_Command : @abs_system:coordinator.com
DDD77C93-A9B4-11D0-9DC5-08002BBFCCF2
Group : (none) Type : ABS
Last Start Time : 31-MAR-1997 10:52
Last Finish Time : 31-MAR-1997 10:53 Last Exit Status : SUCCESS
Schedule Interval : NONE Mode : Detached
Mail to : ABS (No Mail)
Days : ALL
Output File : ABS_LOG:SAUL_25-MAR-1997_11_50_38_16.LOG
Cluster_CPU : AXPBRD Notify user upon completion
$ abs show save SAUL_25-MAR-1997_11_50_38_16/full
Save Request
Name - SAUL_25-MAR-1997_11_50_38_16
Version - 6
UID - DDD77C93-A9B4-11D0-9DC5-08002BBFCCF2
Movement Type - SELECTIVE_ARCHIVE
Data Object Set
Sequence Option - OVERLAP
Commit Option - KEEP_PARTIAL
Node Name - AXPBRD
Include Spec - USER$:[SAUL]*.*;*
Exclude Spec -
Object Type Name - VMS_FILES
Agent Qualifiers - /list=abs$listings
Data Safety Options - FULL_DATA_VERIFICATION, CRC_VERIFICATION
Compression Options - None
Source File System Options - None
Span Filesystem Options - SPAN FILESYSTEMS
Symbolic Links Option - LINKS_ONLY
Object Date Options - None
Selection Options - None
Restore Options - RETAIN_EXISTING_VERSIONS
Date Identifier - NONE
Low Limit Date - 17-NOV-1858 00:00:00.00
High Limit Date - 17-NOV-1858 00:00:00.00
Owner - AXPBRD::SAUL
Access Right - AXPBRD::SAUL
Access Granted - READ, WRITE, SET, SHOW, DELETE, CONTROL, EXECUTE
Media Management Info
Storage Class Name - SYSTEM_BACKUPS
Media Type - None
Device Name - None
Start Time - NOW
Schedule Interval - ONE_TIME_ONLY
Explicit Interval -
Special Day On - None
Special Day Off - None
Execution Envir - SYSTEM_BACKUPS_ENV
Storage Class retention value used.
Original Object Action - NO_CHANGE
Restart Interval - 17-NOV-1858 00:00:00.00
Wait Flag - NO
Prologue Command - None
Epilogue Command - None
$
|
413.6 | | CX3PST::BSS::SAUL | | Tue Apr 15 1997 12:08 | 1 |
| Any ideas on this. These still aren't cleaning up.
|
413.7 | ONE_TIME_ONLY bug | COOKIE::HELLWIG | | Tue Apr 15 1997 12:50 | 7 |
|
Looks like this is a bug. We've been able to reproduce it and
have found the problem. Expect to see it fixed in the next
release of ABS.
Kim
|
413.8 | found the problems (there were several) | COOKIE::LEWIS | | Tue Apr 15 1997 12:55 | 11 |
| Hi Ted,
Sorry to take so long. I started looking at this, and I found several
problems. I have just now finished testing the last fix, and I think it
looks ok. There were several bugs in the code. The fixes will be included
in the next version, (and in and eco which we are planning to do).
Based on the number of bugs that were causing or masking the problem, I don't
think there is anything to be done as a work around, other than manually
deleting the entries from the policy database, and from the scheduler.
jim
|
413.9 | qar #1734 | COOKIE::LEWIS | | Tue Apr 15 1997 17:23 | 1 |
| qar for this is 1734.
|