1748252 Members
3953 Online
108760 Solutions
New Discussion юеВ

Re: DECSCHEDULER

 
Ian Miller.
Honored Contributor

Re: DECSCHEDULER

you may also want to tidy your VSS.DAT with DB_UTILITY or the new command in V3 which I can't remember at present.

A VSS.DAT of that size will probably cause you performance issues.
____________________
Purely Personal Opinion
cdan
Frequent Advisor

Re: DECSCHEDULER

Same problem here with one job running every 15 minutes, with scheduler version 3.0 (I think the last).
Not solved by db_utility.
I had this problem before and I think it was resolved by a reboot but can't be sure.
VERMONT_CREAMERY.LOG may look dormant but it's not.
I would be happy if there was a way to delete history only for one job.
Kevin Raven (UK)
Frequent Advisor

Re: DECSCHEDULER

Ladies and Gents,
Thanks for all the responses to my issue.
We have found the cause and a resolution.

On one of our test clusters , i have been able to reproduce the problem.
It appears that when the history record for the job show it has run 260,080 times , you get the error message during the sched show history command for the job in question.
You then get the error from then on ....
When you next issue the command to close the schedule log file with the /summ switch , the log file rolls over and all job history are retained in the new log file. With the exception of the job that has the issue. This job has it's count reset to 0. Thus the error then goes away.

In production we roll over the sched log file every 90 days , with the /summ switch.
Thus on at the end of august the error will go away.
They will live with it until then. It's easier than navigating the change and testing process to get the log file rolled over as an exception.

Thanks everyone for the input...
Kevin
cdan
Frequent Advisor

Re: DECSCHEDULER

Raven,
The solution is not working for me.
I already tried scheduler close log/summary and also scheduler close log (without the sum).
The log is not not rolled over and renamed to .old , despite the -I- message that log has been closed.
In the other log file (nsched$:nodename.log) there is an "error renaming log".
I see a possible solution by shutting down scheduler, rename the file manually then start the scheduler. Needs to be tested though.
If history is only needed for manual research , it should be still accessible by sched sho hist /file=vermon_creamery.old

Cheers.
Yves HUDON
Advisor

Re: DECSCHEDULER

Hi,

I don't know if it will help you but there is
a strange log file called : VERMONT_CREAMERY.LOG

When you do a report this file is involved.

Also, it is a good idea to recreate it when you can. Here each day we stop the scheduler and make a cold backup of VSS.DAT file and rename the VERMONT_CREAMERY.LOG ... to VERMONT_CREAMERY.OLD!

When the Cremery is to large, it has an impact on performance !... ;)

Also, each Weekend the VSS.dat Data Base is compressed with the DB_UTILITY.EXE utility after taking a backup of it.

Regards
YH

sys>dir/col=2 disk_ced:[nsched.data]*cream*

Directory DISK_CED:[NSCHED.DATA]

VERMONT_CREAMERY.LOG;1
VERMONT_CREAMERY.OLD;884
VERMONT_CREAMERY.OLD;883
VERMONT_CREAMERY.OLD;882
VERMONT_CREAMERY.OLD;881
VERMONT_CREAMERY.OLD;880
VERMONT_CREAMERY.OLD;879
VERMONT_CREAMERY.OLD;878

sys>dir nsched$data:vss.dat /dat

Directory DISK_CED:[NSCHED.DATA]

VSS.DAT;513 12-SEP-2009 06:46:58.06
cdan
Frequent Advisor

Re: DECSCHEDULER

For some reason, my vermont_creamery.log file was in subfolder [ALPHA]. I guess it has something to do with a change in the logical name NSCHED$ , a search list in which [DATA] was moved to the first position instead of [ALPHA].
After moving the log to [DATA] (using RENAME) the command $ sched close log/summary did not fail anymore, vermont_creamery.log was rolled-over normally and also got rid of the SYSTEM-F-HPARITH error in history reports.
Did'n't even need to stop scheduler for this.

Kevin Raven (UK)
Frequent Advisor

Re: DECSCHEDULER

Our log file in production did indeed rollover as it should every 90 days and fixed the issue.
So for the next 2 years + x months we are error free again .....lol

Based on the fact we are moving to a Solaris/ Java / VCS based solution ...in the next 12 months , this is no longer an issue.


gunners
Frequent Advisor

Re: DECSCHEDULER

Hi Everyone ,

Would anyone know how to change the location of where the VERMONT_CREAMERY.LOG files are created in. ?

So for example if I want to change the location they go from dsa100:{vermont] to dsa300:[vermont] , how do I change this , is there a parameter file ? (struggling for a few hours trying to solve this)

Thanks,

Dave

Hoff
Honored Contributor

Re: DECSCHEDULER

Google is your friend.

 

 "Note: You can set the name of the log    file by modifying a line in the startup file    SYS$STARTUP:SCHEDULER$STARTUP.COM. If    you do not modify this file, the default file name    is NSCHED$:VERMONT_CREAMERY.LOG. This    command file is placed in your SYS$STARTUP    directory when you install DECscheduler."

 

Here's the Google sequence I used.  "VERMONT_CREAMERY.LOG".  First hit in what is returned an index from a DECscheduler manual.  Search in the index page (via Cmd-F here, probably Ctrl-F in your browser to find the string), and locate the index entry "NSCHED$:VERMONT_CREAMERY.LOG", follow that index entry link, and find above text.

gunners
Frequent Advisor

Re: DECSCHEDULER

Brilliant Hoff , I was googling but I didnt get that at all hmmm . Thats a great help I will follow it up myself and see how I go.

Many thanks indeed