As “plumbers” for 17 databases and over a hundred application servers, we really do not have the time to sit there and watch them all. We design things so problems are pushed up to our attention. We are still getting point of predictive alerts to failures like we were on RHEL/Weblogic/Oracle, so usually we only get an alert after the failure.
The lack of a log for a component means when it fails, we know nothing of why. In this case the vendor setup the component and wants to know why it failed even though they did not set it up to collect any information. Playing with this component manually I noticed it sends information to the screen, so I wrote my own wrapper script to capture this information.
First stab at it used the vendor’s timestamp method:
These values were plugged into other variables for the log names so I get a log for each run. (standard out log and standard error log)
The afternoon I worked on this script appeared to have no problems. The script was scheduled for the morning which is when the vendor had it run. Review of those logs showed instead of being “name_2014_01_23_04_51.log,” I got “name_2014_01_23_.” It was clear it broke on the hour. So I ran:
This returned a time with a leading space instead of a leading zero. That seemed strange. So I started Googling. Turns out this is a very common problem. The solution I chose came from Need leading zero for batch script using %time% variable.
:prepare time stamp
:replace leading space with 0 for hours < 10
if “%hour:~0,1%” == ” ” set hour=0%hour:~1,1%
Uglier. Though, it did remind me to use the call command to put this logic into a another script file so I can easily re-use it for another script I will inevitably need to write.
And how I much prefer Powershell or batch scripts.
P.S. I left out the first solution was to put the log file names in double quotes. This is a common way to deal spaces in Windows file names. That was in no way satisfactory to me. It more just confirmed the problem. So I went Googling.