- The Windows batch script has been replaced by a PowerShell script.
- There is now one UCDJ binary directory per UCDJ version, instead of one per Automation Engine system.
- The startup script now copies configuration and help stub files to a subdirectory of the user’s home directory, if not already there.
- Log and trace files are now also written to sub-directories of the user’s home directory.
- The JRE version can now be specified as an argument to the startup script.
UC4 User Interface — multiple configurations
InstructionsThis folder contains a set of scripts and files to aid running the Automic ONE Automation Java User Interface (UCDJ) with multiple different configurations. It facilitates running:
- Different versions of UCDJ
- Under different JREs
- With different initial environment variables
- With different XML configuration files (uc4config.xml and login_dat.xml)
- Against different Automation Engine systems (development, test, production)
- With a color-coded environment-specific application icon that matches the color hard-coded in the uc4config.xml file
- Place the contents of this folder in the directory
"C:\UC4\UC4 User Interface".
The shortcuts will not work unless everything is put into this exact location.
- Download and extract the ONE Automation Java User Interface from downloads.automic.com. Place the files in a sub-directory under UCDJ in this directory. The name of the sub-directory should be based on the version of the UI. E.g., if you use version 11.2.2, place the files in UCDJ\v11.2.2\bin.
- Download the Java Runtime Environment (JRE) you wish to use, or more than one if you like. Place the binaries under the Java folder, in a sub-directory named based on the JRE version. E.g, jre1.8.0_102.
- For each Automation Engine system to which you wish to connect, create a copy of the ucdj.jar file, with the system abbreviation in the name. E.g., if have three systems named DEV, TEST, and PROD, create three copies of the ucdj.jar file: ucdj-DEV.jar, ucdj-TEST.jar, and ucdj-PROD.jar.
- Optionally, if you wish to color-code the application icons, replace the application icon uc432.png located in com\UC4\ucdf\images inside each ucdj-XXX.jar file. You can choose one of the icons from the icons sub-directory or use your own icon. It should be a 32x32 pixel PNG file. To replace the icon in the JAR file, rename the .jar file to .zip, open the ZIP file in WinZIP, replace the pertinent icon file, save the ZIP, and then rename it back to .jar.
- For each Automation Enigine system you have created, create a pair of XML configuration files in the config sub-directory. E.g., for the AE system named DEV, create uc4config-DEV.xml and login_dat-DEV.xml. Modify the connection information in each uc4config-XXX.xml file so that it contains only the host name and CP socket details for that particular AE system. If desired, modify the color definitions too.
- Configure the properties of the shortcuts (or create new ones), so that the UC4.vbs script is called with three arguments:
- The name or abbreviation of the AE system
- The version number (folder name under UDCJ where the UI binaries reside)
- The JRE version (folder name under Java where the JRE binaries reside)
- Orange: EXP2
- Yellow: EXP
- Blue: DEV
- Green: ITE (TEST)
- Red: PROD
The UC4.vbs script is simply a wrapper that runs the UC4.ps1 script. The only reason the VBS script is there at all is to prevent a command window from appearing. The UC4.ps1 script copies config and help files to a sub-directory of the user's home directory, and then starts the requested UI in the requested JRE and with the requested configuration. At the top of the PowerShell script, you can set the default JRE version, if desired.
I have attached a ZIP file containing a skeleton of this directory. You must provide the UCDJ & JRE binaries.
- UC4 EXP.lnk
- UC4 EXP2.lnk
- UC4 DEV.lnk
- UC4 ITE.lnk
- UC4 PROD.lnk
- UC4 User Interface instructions.txt
We are very excited to share with you a 50% off registration code* for CA World ‘17!
When you register between now and September 22nd, you can not only take advantage of the Early Bird Rate, but you will also be able to apply this 50% off registration code, bringing your total registration price down to just $647.50.
We look forward to seeing you in Las Vegas!
*Please see full code details below:
· 50% off current registration fee
· Does not include training/certifications
· Is not valid for $195 government rate
· Code is not retro-active
· Code must be entered upon registration to receive discount
· Code valid until November 11, 2017
It works in Java UI and in ECC/AWI with AE11.2 and AE12
Just run SCRI.MASTERMIND
The Automation Engine is not a real time engine. All time based actions are triggered by a so called “Timer” transaction. This transaction is executed every 20 seconds. (In realty it is a little more complex, however knowing this is sufficient to understand the behavior explained below.)
A UNIX job executing the os command “sleep 30” will have a runtime of approximately 30 seconds:
Using maximum runtime – MRT – of 15 seconds, else cancel, should abort the job:
However it may happen, that the job is not canceled:
Let’s think about 2 scenarios:
Timer take place 5 seconds after job start – MRT still ok.
Next Timer will be 25 seconds (= 5 + 20) after jobs start. Job is still active and will be canceled, because MRT is violated.
Timer take place 12 seconds after job start – MRT still ok.
Next Timer will be 32 seconds (= 12 + 20) after jobs start. Job has finished in the meantime (2 seconds before), so it cannot be canceled, even MRT is violated.
Note: In addition the timing mid also be influenced by the current load of the system.
Knowing this it is understandable, that maximum runtime setting below 1 minute do not make sense.
Most of you probably already know about it, but I'm putting the link here just in case:
It features tutorials and covers some features for AWA and ARA.
There are different ways to find out what WP is the PWP.
E.g., the following script command shows the role of a WP:
:SET &RET# = GET_UC_SETTING(SERVER_MODE, "WS10#WP001") :print "WS10#WP001 is &RET#"
2016-11-15 07:57:05 - U0020408 WS10#WP001 is P
"C" - Communication process(CP)
"P" - Primary work process (PWP)
"W" - Work process (WP)
"D" - Dialog process (DWP)
"N" - NonStop process (NWP)
" " - The server process is inactive.
I.e., if you execute this for all WPs, you get a list oft he WPs and their roles.
Following command returns the primary:
:SET &sernam# = GET_UC_SERVER_NAME()
2016-11-15 07:57:05 - U0020408 WS10#WP005
In the log oft the WP that becomes PWP during a failover, you can find:
20161114/153248.878 - U0003475 Server 'WS10#WP004' is the primary server of the system 'WS10'.
20161114/153248.909 - U0011818 Server 'WS10#WP004': Mode changes from 'NORMAL' to 'PRIMARY'.
In the other WP's logs:
20161114/153250.159 - U0003475 Server 'WS10#WP004' is the primary server of the system 'WS10'.
Changing to DWP gives this log line:
20161114/153920.081 - U0003389 Server 'WS10#WP003' has changed its mode from 'WP' to 'DWP'.
Ando f course, you can use the select below to find the PWP:
select * from mqsrv where mqsrv_type = 4;