System Date Time, Not Job Start Time

[MuckMoses]

Hi All

 

Ive got a job that runs continually that's called via ACTIVATE_UC_OBJECT, not a scheduel, checking for a specific file but this doesn't want to check on weekends.

 

I tried the &$PHYS_DATE_WEEKDAY_NR# function but this returns the date the JOB started to run not the system time when the FUNCTION is run.

 

What I want to do is check for the file every hour for 48 hours but if it's saturday or Sunday I just want to go back to WAIT.

 

:SET &Loop1# = 1
:WHILE &Loop1# < 48

:   IF &$PHYS_DATE_WEEKDAY_NR# < 6

!      DO MY THING......
:       SET &Loop1# = &Loop1# + 1

:   END IF

:   WAIT 3600

:ENDWHILE

[LuuLe]

As is posted is in the CA Automic Community and there is no tags/categories selected but from the post content (as it mention ACTIVATE_UC_OBJECT) it appear to be regarding the Automic Workload Automation / Automation Engine product line. I have move this to the CA Automic Workload Automation section to better reach the product user audience.

[MuckMoses]

Hi Luule

 

I thought I’d put some tags on it. Thanks for moving this to a more appropriate location.

 

 

Mick Moses

 

Software Configuration Analyst

 

Lowell Financial Ltd, part of Lowell

 

T:

 

[phone] (Ext: 30498)

[FrankMuffke]

Hi

 

what about a EVNT.FILE object if you search for the appearance of a file?

 

here you can define the file specifics, check interval and CALE options...

 

and your activate_uc_object(...) belongs to the !PROCESS tab...

 

cheers, Wolfgang

[MuckMoses]

Hi Wolfgang

 

Thanks I'll have a look at that.

[Alain Moisy]

Question :

 

Does anybody has a Basic training on the product before using it ? This is a question that should never be asked as it is one of the very first things you see when talking about Event object ....

 

Now some companies are saving money by not giving any training to their people. They got to pay anyway in delay, errors and extra software/hardware to do what is included in the product from years.

 

Sorry but I'm alway upset to see that people are getting a sort of training through the community instead of a proper one done by people who knows really the product.

[Pete Wirfs]

Yes formal training does exist.  I went to a CA-World training session a few years back and it was taught by very knowledgeable CA-Automic staff.  You should speak with your CA-Automic sales rep for class availability.

[Alain Moisy]

Hi Pete,

 

I started with the product in 2001 and I'm a former employee of SBB/UC4 Software for those who remember the original of the company. So I got all the training I needed thanks      .. and even have done tons of training for customers ....

 

I was more concern by the number of basic request coming into the forum that are showing an increasing number of people using the product without any or minimal training. It makes people spending time to explain, with tons of question & answers sometimes, a basic knowledge concerning something that is built in the product for ages ....

 

Just getting old and tired of the cost saving / stupidity of some management levels ....   

[MuckMoses]

Well that put the cat amongst the pigeons!

 

I did a 3 day Basics course 2 years ago - 2 years ago!! Since then I've been happily using JOBS, SQL objects, VARAs, workflows, filters, connections SFTP, File copies etc. etc.

 

I've done all sorts of clever stuff over that time (well I think it is) 2 years is a long time to remember details of a course you did 2 years ago & then not used a function in that time.

 

I'm more perplexed that when I run a command like "IF &$PHYS_DATE_WEEKDAY_NR# < 6" I get a completely irrelevant return. I've been working as a programmer/Programmer Analyst etc. This is the first product that, when I ask it what the date/time is I don't get the answer I expect.

 

Thanks for your help guys, I'll try not to bother you again.

[Alain Moisy]

Strange, I tried the following "code" and it works ... in version 10, now I can try it in version 11, 12, 12.2 to check if you want. Object type Script, option "Generate at runtime" set.

 

:SET &dayweek# = &$PHYS_DATE_WEEKDAY_NR#

 

:PRINT ""
:PRINT "  Day of the week founded = &dayweek#"
:PRINT ""

 

:IF &$PHYS_DATE_WEEKDAY_NR# < 6
!
:  PRINT ""
:  PRINT "  Found day of week LESS than 6 => &dayweek#"
:  PRINT ""
!
:ELSE
!
:  PRINT ""
:  PRINT "  Found day of week GREATER than 6 => &dayweek#"
:  PRINT ""
!
:ENDIF

 

 

My comment was based on the fact that the thing you where doing was a typical programming answer rather than using an already build simple basic solution that is events and calendar functions. When you are used to work with the product, you are knowing those basics even if you do not use them on a daily basis. And the online help and training manuals are here as a possible reminder of what you have seen years ago ...

 

Sorry if you take it personnaly but my comment was more about the number of people that are effectively not trained, just because they are taking over a position that involved the use of the product and no one think that it may be good to have some training on it. Plus many people don't cares about the fact that using properly the product is a full time job or at least a half-time job plus a good knowledge of the functionalities. And more important how to navigate in the online help !!!  =-)

[MuckMoses]

On my system it always returns the same date/time. That when the job started.

:SET &Loop1# = 1
:WHILE &Loop1# < 24
   echo Week Day: &$PHYS_DATE_WEEKDAY_NR# Time: &$PHYS_TIME_HH_MM_SS#
:  WAIT 3600
:  SET &Loop1# = &Loop1# + 1
:ENDWHILE
echo Finished: &$PHYS_DATE_WEEKDAY_NR# Time: &$PHYS_TIME_HH_MM_SS#

 

 

c:\>echo Week Day: 4 Time: 10:33:37
Week Day: 4 Time: 10:33:37

c:\>echo Week Day: 4 Time: 10:33:37
Week Day: 4 Time: 10:33:37

c:\>echo Week Day: 4 Time: 10:33:37
Week Day: 4 Time: 10:33:37

c:\>echo Week Day: 4 Time: 10:33:37
Week Day: 4 Time: 10:33:37

c:\>echo Week Day: 4 Time: 10:33:37
Week Day: 4 Time: 10:33:37

c:\>echo Week Day: 4 Time: 10:33:37
Week Day: 4 Time: 10:33:37

c:\>echo Week Day: 4 Time: 10:33:37
Week Day: 4 Time: 10:33:37

c:\>echo Week Day: 4 Time: 10:33:37
Week Day: 4 Time: 10:33:37

c:\>echo Week Day: 4 Time: 10:33:37
Week Day: 4 Time: 10:33:37

c:\>echo Week Day: 4 Time: 10:33:37
Week Day: 4 Time: 10:33:37

c:\>echo Week Day: 4 Time: 10:33:37
Week Day: 4 Time: 10:33:37

c:\>echo Week Day: 4 Time: 10:33:37
Week Day: 4 Time: 10:33:37

c:\>echo Week Day: 4 Time: 10:33:37
Week Day: 4 Time: 10:33:37

c:\>echo Week Day: 4 Time: 10:33:37
Week Day: 4 Time: 10:33:37

c:\>echo Week Day: 4 Time: 10:33:37
Week Day: 4 Time: 10:33:37

c:\>echo Week Day: 4 Time: 10:33:37
Week Day: 4 Time: 10:33:37

c:\>echo Week Day: 4 Time: 10:33:37
Week Day: 4 Time: 10:33:37

c:\>echo Week Day: 4 Time: 10:33:37
Week Day: 4 Time: 10:33:37

c:\>echo Week Day: 4 Time: 10:33:37
Week Day: 4 Time: 10:33:37

c:\>echo Week Day: 4 Time: 10:33:37
Week Day: 4 Time: 10:33:37

c:\>echo Week Day: 4 Time: 10:33:37
Week Day: 4 Time: 10:33:37

c:\>echo Week Day: 4 Time: 10:33:37
Week Day: 4 Time: 10:33:37

c:\>echo Week Day: 4 Time: 10:33:37
Week Day: 4 Time: 10:33:37

c:\>echo Finished: 4 Time: 10:33:37
Finished: 4 Time: 10:33:37

[Pete Wirfs]

Timing issue.

 

Your process script, complete with the :WAIT function, must complete before it will execute the DOS commands that they constructed.   The DOS commands are all executed in a collected batch of commands after the UC4 script finishes.

[Pete Wirfs]

I have to agree though that it still doesn't make sense that &$PHYS_TIME_HH_MM_SS# always returned the same value.

[Alain Moisy]

Seems normal for me as all the commands are executed at the same time and build based on the initial values of the variables.

 

To check if there is a real waiting time between commands, there should be 2 lines in the commands to execute :

 

echo ......

time /T    =>  on window as it seems that he sample above is done on a window box. This is giving the system time whenj the command is executed. You should normally have a gap of one hour between each "time" command ... Now how about "generate at runtime" option ? always the big question when having such behaviour.

[FrankMuffke]

Good evening everyone,

 

Just to agree (partly...mostly) to Alain, a 3 day training is way to less for an Automation engine Admin/Developer.
As its not a trivial software, there are (unfortunately) many many things and facts you simply have to know.
- see explanation below.
At least a Basics (5days) and Admin(5 Days) and Script(5 Days) training is a good start.

 

As example I worked at Automic for 5 years in support and it took me about 1,5 years to be "mostly on the safe side".

 

So and now to your script issue:
As Pete stated correctly, Automic SCRIPT language is always processed first (and completely), afterwards the JCL lines.
so basically your script shoukd work, but Unfortunately it seems to me that there is a bug or undocumented property or
misleading naming of the predefined variable &$PHYS_TIME_HH_MM_SS#.

 

This predefined variable returns the time from start of (!!) script generation similar to SYS_TIME.

 

You can check this easily using following testscript:

 

: SET &TIME# = SYS_TIME("HH:MM:SS","TZ.MEZ")
: PRINT "SYS_TIME                 &TIME#"
: PRINT "&&$PHYS_TIME_HH_MM_SS#    &$PHYS_TIME_HH_MM_SS#"
: SET &TIME1# = SYS_TIME_PHYSICAL("HH:MM:SS")
: PRINT "SYS_TIME_PHYSICAL        &TIME1#"
: PRINT
: wait 5
: SET &TIME# = SYS_TIME("HH:MM:SS","TZ.MEZ")
: PRINT "SYS_TIME                 &TIME#"
: PRINT "&&$PHYS_TIME_HH_MM_SS#    &$PHYS_TIME_HH_MM_SS#"
: SET &TIME1# = SYS_TIME_PHYSICAL("HH:MM:SS")
: PRINT "SYS_TIME_PHYSICAL        &TIME1#"
: PRINT
: wait 5
: SET &TIME# = SYS_TIME("HH:MM:SS","TZ.MEZ")
: PRINT "SYS_TIME                 &TIME#"
: PRINT "&&$PHYS_TIME_HH_MM_SS#    &$PHYS_TIME_HH_MM_SS#"
: SET &TIME1# = SYS_TIME_PHYSICAL("HH:MM:SS")
: PRINT "SYS_TIME_PHYSICAL        &TIME1#"

 

Report:
2018-11-27 19:33:36 - U00020408 SYS_TIME                                  19:33:36
2018-11-27 19:33:36 - U00020408 &$PHYS_TIME_HH_MM_SS#    19:33:36
2018-11-27 19:33:36 - U00020408 SYS_TIME_PHYSICAL               19:33:36
2018-11-27 19:33:36 - U00020408
2018-11-27 19:33:41 - U00020408 SYS_TIME                                  19:33:36
2018-11-27 19:33:41 - U00020408 &$PHYS_TIME_HH_MM_SS#    19:33:36
2018-11-27 19:33:41 - U00020408 SYS_TIME_PHYSICAL               19:33:41
2018-11-27 19:33:41 - U00020408
2018-11-27 19:33:46 - U00020408 SYS_TIME                                   19:33:36
2018-11-27 19:33:46 - U00020408 &$PHYS_TIME_HH_MM_SS#    19:33:36
2018-11-27 19:33:46 - U00020408 SYS_TIME_PHYSICAL               19:33:46

 

Conclusion: only SYS_TIME_PHYSICAL() returns the correct physicl time
(thats one of the things you simply have to know :-)  )

 

if you replace &&$PHYS_TIME_HH_MM_SS#  with SYS_TIME_PHYSICAL() part 1 of your script will work.

 

regarding &$PHYS_TIME_HH_MM_SS# I would check documentation - there is the answer to your issue/question:
https://docs.automic.com/documentation/webhelp/english/AWA/11.2/AE/11.2/All%20Guides/help.htm#ucactr.htm?Highlight=predefined

 

Hint: always check documentation if you want to use any script commands or variables or functions, there are many limitations or exceptions marked with a yellow exclamation mark :-)

 

cheers, Wolfgang

[Pete Wirfs]

Yup, I just tested with SYS_TIME_PHYSICAL() instead of &$PHYS_TIME_HH_MM_SS#, and it provided the results that I was expecting from &$PHYS_TIME_HH_SS#.

[MuckMoses]

Thanks Wolfgan

As usual you comments & insite are brilliant.

[FrankMuffke]

welcome :-)

THX :-)

[Legacy User]

Hi Wolfgang ;-)

[...Automic SCRIPT language is always processed first (and completely), afterwards the JCL lines. ...]

I'm afraid, this is not correct.

Correct is:

• Pre-Process and Process of a JOBS are processed in one go. 
• If the server recognizes a line starting with ":" in the first column, he knows: I have to process this, as it is "my script"
• If a line doesn't start with a ":" the server knows: this is JCL, I have to check, whether the line contains any script variables (declared beforehand), if so, replace them by its actual content and than put the whole line into a temporary bat-file (for Windows, sh-file under UNIX).
  • Exception =>       : DATA echo Hello World.
    • : DATA tells the server: what's following is meant to be JCL

Conclusion => the content of an Automic Process tab is always processed sequentially - and completely - before the JCL is send towards the agent

 

Example:

:set &counter# = "1"

:while &counter# <= "5"

ping localhost -n &counter#

:wait 5

:set &counter# = &counter# + 1

:endwhile

 

The processing of the Automic Script takes 5 loops * 5 seconds wait each = 25 seconds. Only after 25 seconds a bat file will be send towards the agent with the following JCL lines:

ping localhost -n 1

ping localhost -n 2

ping localhost -n 3

ping localhost -n 4

ping localhost -n 5

 

The Job execution on OS level will take 15 seconds ;-)

 

 

Cheers

Christoph 

 

[FrankMuffke]

Hi Christoph,

 

sorry, my fault I was to inprecise...

 

absolutely correct!

 

cheers, Wolfgang

[MuckMoses]

Thanks all for your input to this.

 

I've asked the company I work for several times for, at least, the scripting course.  Everything I've done scripting wise has been self taught or gained from help received here or the online documentation. Technically it works but I have no idea if it is the best way to do it, efficient, reliable, robust etc.

[Legacy User]

@MuckMoses

 

I don't know the reason why you took a JOBS to check for a file, but if it's just about the existence of a file I would recommend the EVNT.FILE - as show above. If it's still the JOBS that needs to be started you could use a EVNT.TIME with ACTIVATE_UC_OBJECT in !PROCESS or "Execute Recurring":

 

 

 

Cheers

Christoph