Does somebody know the difference between the ODATE and the RDATE? The manual says:
ODATE --> Original scheduling date of the job.
RDATE --> Installation current working date.
But that is not helpful for me.
Thanks a lot.
The ODATE is when the job is scheduled for originally and you need to take into account 2 things; i) when is your New Day Processing (i.e. if it's 06:00 am each day then the ODATE runs from 6am-6am and will be the same for that whole period) ii) you don't necessarily have to order with the date set as the current date - e.g. today you might want to order in jobs where some are scheduled for the last day of the month due to batch processing considerations.
%%$RDATE or %%RDATE (one value gives the year as yyyy, the other as yy) will resolve to the current system date. Whatever your server is saying the local date is now, regardless of Control-M settings, the RDATE will give you that. Often this setting is used if your job could run on different days but you really need to have today's date in the processing.
Of course, if your New Day Processing runs at midnight, you always clear all jobs away during NDP and you never order jobs into the future - then RDATE and ODATE will be basically the same.
Related
Description
While importing the XML in MS Project then the start and finish dates get changed.
Please find the dates in XML
Start and end date in XML
Please find the MS output
MS Project output
Get the XML file from here https://github.com/VigneshRameshh/GanttIssue
Help me to find the reason behind this?
Thanks in advance,
Vignesh Ramesh.
There are several factors that are affecting this.
The calendar that is applied to the project in the XML is the project's "Standard" calendar. This calendar only has 8 hour working days Monday-Friday, starting at 8:00 and ending at 17:00.
The amount of minutes of working time per day is set to 480, which is 8 hours
The task is Auto Scheduled, not manually scheduled (the value would be 1 if it was manually scheduled).
Given those parameters, MS Project cannot have the start of the task begin at 10/22/21 00:00 and finish on 10/23/21 00:00. Because the task is Auto scheduled, it must follow the Project's calendar and hours per day requirements. Therefore MS Project will start the task at the earliest point on 10/22/21 (8:00) and follow the 1 day duration applied to it, which will cause it to end on 10/22/21 17:00.
Note - it is not recommended to have tasks set to be Manually Scheduled. You want your tasks to be set to be Auto Scheduled.
I have a date field at front end. And I am saving it from a time zone say 19/04/2018 and I am on +8. When I load it on local datetime.ToLocalTime() works perfectly in +8 offset and it will show 19/04/2018 but a person sitting in +7 would get in 18/04/2018 23:00 and hence it will show 18/04/2018. How to handle this case.
In general: you should not convert date only to UTC, so you should keep it as local date.
But it really depend on the use of data.
If you are using for some synchronization (all invoices until a fix point), a time with timezone is good, but in such case, also hours and minutes should be included.
If you care about the date written in an invoice, you may not transform date to UTC (so keep local date). If you aggregate invoices, you may wait until the day is passed on all timezone (and people filled all invoices into the system).
When people are looking into the data, what they expect? (case #1 or case #2). Then evaluate what kind of data you need. In the first case, you should add also (at minimum) the hours and minute (timezones never have seconds).
In general, if you have only a date, you are mostly on second case.
so I have defined a periodic calendar with following periods,
Period A: to factor in start of every month
Period B: to factor in end of every month
Calendar
Now I am trying to schedule the job on every days marked as period A i.e. start of every month by doing the following settings,
Scheduling Setting
Schedule
My Problem
From July month the schedule is getting pre-shifted by 1. Any ideas why?
Also can someone guide me to a detailed documentation on periodic calendars and the values example?
Thanks.
I was not able to reproduce the specific issue you are having. I created the same periodic calendar (Per A = SoM, Per B = EoM) and my job schedule came out as expected.
Calendar
Job
Schedule
Solution
There is no need to use a periodic calendar for such a simple scheduling requirement. Making use of a periodic calendar incurs maintenance overhead as you need to ensure it is updated every year.
Instead of using a periodic calendar you could simply configure the job as below. This will result in a job that will always execute on the first day of each month, no maintenance required.
I have a Control-M job that runs every 20 min. Everything works great during that day's run. The issue is when we auto-order the next days jobs. If the current day's jobs are running we get 2 copies of the jobs running at the same time.
Is there a way to not start the new job if the previous day's job is executing?
The job starts every 20 minutes, but how long does it run? Set the end window for "submit between" time a few minutes before the new day build.
Let's say your new day builds at 0400. Since the job is intended to run every 20 minutes, you can have it run as late as 0340. Set the "to" time in Activity Window to 0340 and the job won't autosubmit after that time. The new day will build at 0400 and the new version of the job will start then - 20 minutes after the previous start.
You can also add a control resource to the job to prevent two of them from running at the same time. I don't know another way to do it. That's not a can of worms I'd open unless the activity period settings just won't work the way you want them to.
If you're referring to last day's job execution bleeding into current day, causing resource contention, your best bet (as Rob pointed out) is to define a resource with max count of 1 to be required by the job, so next day job instance cannot start until prev day job completes and release the resource. Alternatively you can have the job post a Condition for order date + 1, and have order date condition also be an In condition for the job.
I have a simple mobile app that schedules future events between people at a specified location. These events may be physical or virtual, so the time specified for the event may or may not be in the same timezone as the 'location' of the event. For example, a physical meeting may be scheduled for two people in London at local time 10am on a specified date. Alternatively, a Skype call may be scheduled for two people in different timezones at 4pm (in one person's timezone) on a specified date though the 'location' of the event is simply 'office' which means two different places in different timezones.
I wonder the following design is going to work for this application:
On the client, it asks user to input the local date and time and specify the timezone local to the event.
On the server, it converts the local date and time with the provided timezone into UTC timestamp, and store this timestamp only.
When a client retrieves these details, it receives the UTC timestamp only and converts it into local time in the same timezone as the client's current timezone. The client's current timezone is determined by the current system timezone setting, which I think is automatically adjusted based on the client's location (of course, assuming the client is connected to a mobile network).
My main motivations for this design are:
UTC is an absolute and universal time standard, and you can convert to/from it from/to any timezone.
Users only care about the local date and time in the timezone they are currently in.
Is this a feasible design? If not, what specific scenarios would break the application or severely affect user experience? Critiques welcome.
For a single event, knowing the UTC instant on which it occurs is usually enough, so long as you have the right UTC instant (see later).
For repeated events, you need to know the time zone in which it repeats... not just the UTC offset, but the actual time zone. For example, if I schedule a weekly meeting at 5pm in Europe/London with colleagues in America/Los_Angeles, then for most of the year it will occur at 9am for them... but for a couple of weeks in the year it will occur at 8am and for a couple of weeks in the year it will occur at 10am, due to differences in when DST is observed.
Even for a single event, you might want to consider what happens if time zone rules change. Suppose I schedule a meeting for 4pm on March 20th 2018, in the Europe/London time zone. Currently that will occur with a UTC offset of 0... but suppose between now and the meeting, the time zone rules change to bring British Summer Time in one hour earlier. If I've written it in my diary as 4pm, I probably don't want the software to think that it's actually at 5pm because that's the UTC instant we originally predicted.
We don't know your exact application requirements, but the above situations at least provide an argument for potentially storing the local time and time zone instead of the UTC instant... but you'll also need to work out what to do if the local time ends up being skipped or being ambiguous due to DST changes. (When the clocks fall back, some local times occur twice. When the clocks skip forward, some local times are skipped. A time that was unambiguous may become invalid or ambiguous if the rules change between the original planning time and the actual event. You should probably account for this in your design.)
To keep it simple, my answers are:
Timezone info is redundant if you want to define a single moment. A
UTC/Unix timestamp completely defines a moment.
Your design seems feasible but on point 2: i would convert to the UTC/Unix timestamp on the client-side and already give this timestamp
in its final form to the server. Reason: the client-side already has the info necessary to convert (see this time-keeping
client-server-db
architecture
example - it works based exactly on the principles you describe).
One possible problem (as described by Jon Skeet in his answer) are recurring events, but this should be reflected in the way you model
time. The difference between recurring events and fixed events is
that the latter completely define a moment (like a UTC/Unix
timestamp) while the first are only a 'function' which can be applied
to the current time to get the next trigger time of the recurring
event. But this might entirely be a different problem than what
you ask - in any case, somehow distinguishing between recurring
events (if you need them) and fixed events in your model is a good
idea.
One decision to make is: PULL or PUSH? Or both? Do you want the server to be able to send emails for example, when an event comes to
pass? Or do you want client-side alerts only when your client-side
app is running? The answers to these questions will help you come
towards a design suitable for you.