I am very new to log parser. I tried using the different formats and delimiters but that that does not work for me. My log file looks like below..
# Version xx
# Feilds: date time c-ip
# Software : Weblogic
# Startdate : 2013-08-15 17:39:09
date value time ipaddress
When I appplied the following code
logparser.exe -o:DATAGRID "select * from abc.log_tmp"
where abc.log_tmp is the log file that contains the information
it gives the information in the following way:
******************************************************************
logfilename index content
********************************************************************
C:xyx\abc.log_tmp 3 date time
C:xyx\abc.log_tmp 4 date time
**********************************************
when actually it should come like
date time c-ip
xxx xxx xxx
xxx xxx xxx
from this I came to know that it is taking date time c-ip value as one, but it should take it as different....
You should explicitly tell LogParser which input format it should expect (when you don't, Log Parser tries to figure it out from the filename or from the first few lines of the log file); in this case, it should work as you expect if you added "-i:W3c" to the command-line.
Related
I am trying to code a macro that:
Import the columns year, month, id, value and motive from several .csv sequential files to SPSS. The files are named like: DATA_JAN_2010, DATA_FEB_2010 [...], until DATA_DEC_2019. These are the first variables of the csv files (the code I am using to import this variables is provided in the end).
Alter type of columns id to (a11), motive to (a32), if necessary (needed to stack all files).
Stack all these datasets in a new dataset named: DATA_2010_2019.
For now, what I am doing is to import each file separately, stacking and saving two by two. But this is so repetitive and irrational from the efficiency standpoint. Moreover, if in the future I need to import additional variables, I would need to rewrite all the code for each file. That is why I believe that a loop or a macro would be the smartest way of dealing with this repetitive codes. Any help is really appreciated.
A sample of my code so far:
GET DATA /TYPE=TXT
/FILE="C:\Users\luizz\DATA\DATA_JAN_2010.csv"
/ENCODING='Locale'
/DELCASE=LINE
/DELIMITERS=";"
/ARRANGEMENT=DELIMITED
/FIRSTCASE=2
/IMPORTCASE=ALL
/VARIABLES=
YEAR F4.0
MONTH F1.0
ID A11
VALUE F4.0
MOTIVE A8.
CACHE.
EXECUTE.
DATASET NAME JAN_2010 WINDOW=FRONT.
ALTER TYPE MOTIVE (a32).
GET DATA /TYPE=TXT
/FILE="C:\Users\luizz\DATA\DATA_FEB_2010.csv"
/ENCODING='Locale'
/DELCASE=LINE
/DELIMITERS=";"
/ARRANGEMENT=DELIMITED
/FIRSTCASE=2
/IMPORTCASE=ALL
/VARIABLES=
YEAR F4.0
MONTH F1.0
ID A11
VALUE F4.0
MOTIVE A8.
CACHE.
EXECUTE.
DATASET NAME FEB_2010 WINDOW=FRONT.
DATASET ACTIVATE FEB_2010.
ALTER TYPE MOTIVE (a32).
DATASET ACTIVATE JAN_2010.
ADD FILES /FILE=*
/FILE='FEB_2010'.
EXECUTE.
SAVE OUTFILE='C:\Users\luizz\DATA\DATA_JAN_FEV_2010.sav'
/COMPRESSED.
Assuming the parameters for all the files are the same, you can use a macro like this:
define !getfiles ()
!do !yr=2010 !to 2019
!do !mn !in("JAN FEB MAR APR MAY JUN JUL AUG SEP OCT NOV DEC")
GET DATA
/TYPE=TXT /FILE=!concat('"C:\Users\luizz\DATA\DATA_', !mn, '_', !yr, '.csv"')
/ENCODING='Locale' /DELCASE=LINE /DELIMITERS=";" /ARRANGEMENT=DELIMITED
/FIRSTCASE=2 /IMPORTCASE=ALL /VARIABLES=
YEAR F4.0
MONTH F1.0
ID A11
VALUE F4.0
MOTIVE A8.
CACHE.
EXECUTE.
ALTER TYPE id (a11) MOTIVE (a32).
dataset name tmp.
dataset activate gen.
add files /file=* /file=tmp.
exe.
!doend !doend
!enddefine.
The macro as defined will read each of the files and add it to a main file. Before we call the macro we will create the main file:
data list list/YEAR (F4) MONTH (F1) ID (A11) VALUE (F4) MOTIVE (A8).
begin data
end data.
exe.
dataset name gen.
* now we can call the macro.
!getfiles .
* now the data is all combined and we can save it.
SAVE OUTFILE='C:\Users\luizz\DATA\DATA_JAN_FEV_2010.sav' /COMPRESSED.
NOTE: I used your code from the original post in the macro. Please make sure all the definitions are right.
I'm using logparser.exe (http://www.microsoft.com/en-us/download/details.aspx?id=24659) to process a captured trace (in a .etl file). The output however is not proving the high resolution timestamp that I know is recorded in the .etl file.
The output is spitting out timestamps only up to the seconds (i.e. 2014-07-24 18:52:39)
Answered my own question:
Logparser.exe by default formats the timestamps to exclude the milliseconds / nanoseconds. You have two options to view a higher resolution timestamp:
1. Verbosely convert your specific fields using TO_STRING(Timestamp, 'HH:mm:ss.ln'). An example useage is below:
c:>"c:\Program Files (x86)\Log Parser 2.2\LogParser.exe" -i:ETW -o:CSV "SELECT TO_STRING(Timestamp, 'HH:mm:ss.ln') AS Timestamp,
EventTypeName FROM 'c:\PerfLogs\ASP\LocalSystem\20140724-000003\Verbose Trace.etl'" > verbose.csv
2. Change all timestamp output regardless of which field using the -oTsFormat argument:
c:>"c:\Program Files (x86)\Log Parser 2.2\LogParser.exe" -i:ETW -o:CSV -oTsFormat "HH:mm:
ss.ln" "SELECT * FROM 'c:\PerfLogs\ASP\LocalSystem\20140724-000003\Verbose Trace.etl'" > verbose.csv
Time Format Strings:
More time format strings are listed here: http://strivinglife.com/words/post/Microsoft-Log-Parser-timestamp-formats
HH - Hour
mm - Minute
ss - seconds
l - milliseconds
n - nanoseconds
I have a report which takes timezone as input parameter, picks date from a table and converts this date to the user selected time zone.
User can select timezones from a dropdown which contains both US and European timezones.
When I select the European timezones, I see #Error in the date cell in the report.
I have no clue what so ever about reports and I need to fix this error in the inherited report.
The conversion is done by a little VB script embedded in the report.
Shared Function ConvertTimeZone(ByVal systemDate As Date, ByVal timeZoneId As String) As Date
Dim timeZoneInfo As TimeZoneInfo
timeZoneInfo = timeZoneInfo.FindSystemTimeZoneById(timeZoneId)
Return (timeZoneInfo.ConvertTimeFromUtc(systemDate, timeZoneInfo))
End Function
If EET is passed as timezone id - I see #Error in the date cell.
Could this be because both European and US timezones cant be used together?
Can someone guide me through this issue?
If EET is passed as timezone id - I see #Error in the date cell
That's because "EET" is not a valid time zone identifier. You can see all of the valid identifiers by examining the output from TimeZoneInfo.GetSystemTimeZones(), which returns a collection of TimeZoneInfo objects. Each one has an Id and a DisplayName. The Id is what needs to be passed in your timeZoneId parameter, while the DisplayName can be shown to your end user in the dropdown list. (You probably don't want to use the StandardName or DaylightName properties, unless you have a specific reason to.)
You are probably looking for the identifier "E. Europe Standard Time". Don't get confused by the name, it's the correct identifier covering both Eastern European Time (EET) and Eastern European Summer Time (EEST). The Microsoft time zone database is a bit strange in that way.
You can also see the valid time zones by running tzutil /l on the command line. Each time zone will emit two lines, where the top line is the display name, and the bottom line is the ID.
EDIT
Another suggestion, VB is case insensitive, but you have your variable named timeZoneInfo, which is the same as the class TimeZoneInfo. This would normally work ok, but I see that you have the lower case form on the ConvertTimeFromUtc method, and it should be upper case. Since this is VBScript, you might not be seeing this error until runtime. Try changing the case, or just use a different variable name so you don't get them confused.
Shared Function ConvertTimeZone(ByVal systemDate As Date, ByVal timeZoneId As String) As Date
Dim tzi As TimeZoneInfo
tzi = timeZoneInfo.FindSystemTimeZoneById(timeZoneId)
Return (TimeZoneInfo.ConvertTimeFromUtc(systemDate, tzi))
End Function
Here's another idea you can check if that doesn't fix it. The input systemDate should have come from your data, which should have DateTimeKind.Unspecified when you examine it's .Kind property. If for some reason you are taking it from DateTime.Now instead, then it would have a DateTimeKind.Local, which would through an exception.
If you still get the error, please see if you can find out what exception or error is actually occurring. Check log files, event viewer, etc.
I am trying to make a simple batch file to change a user's ADUC expiration to a specified date.
Using the below command the date always appears in ADUC as one day prior to what I set:
net user myname /expires:09/17/13 /domain
In ADUC, the date will be: 09/16/2013. No matter what, the date that appears in ADUC is one day before the day I set.
The documentation I found for this indicates
Note that the account expires at the beginning of the specified date.
So does this mean, If i wanted the account to be expired today, I would send the command for today and ADUC would interpret that as yesterday?
Thanks in advance, I just want to get this right.
As a wild guess, since you're UTC-savvy - is the date UTC date, so 130917T0000Z=130916T1900 local?
I have a date field which accepts system date in AS400
Display file contains a date field by *DATE
I have a physical file that has a date column.When i try saving the other fields of my screen onto this physical file,i would also like to save this system date.
But i am unable to add a field name to this inbuilt Date function.
How else can i have a date field in my display screen that will automatically accept system date and have format in DD/mm/yy format for input but internally in database it must save it as yy/mm/dd.
For the purpose of having this internal conversion in my database of date format,i have initialized a date field named "date" of length 6,Packed decimal,0 decimal position.
Please guide how to save system date from screen in this format into the physical file.
Reedited:
I have a PF of grade received date defines as follows.(Its DDS)
0004.00 A GRCVDT 6P 0
I refrain to use 'L' data type for date as i want to perform date conversion as i have above explained.
On a display file, *DATE is output-only. It cannot be read by a program.
It sounds like the database table has a decimal field called DATE; not a date field called DATE. Using a date data type will make date manipulation so much easier - see Dennis' answer for advice on that. If it is impossible to use a date data type, and you must use a decimal data type to hold the date value, look at the RPG TIME operation code. That will allow you to extract the current system date into a program variable. The exact format the date will be returned depends on your job date format setting. (WRKJOB to see that). You can use a data structure and a series of EVAL statements to rearrange the date elements if you need to.
EDIT Code sample to convert EUR to YYMMDD
d eur ds qualified
d ddmmyy 6s 0
d dd 2s 0 overlay(ddmmyy: 1)
d mm 2s 0 overlay(ddmmyy: 3)
d yy 2s 0 overlay(ddmmyy: 5)
d ymd ds qualified
d yymmdd 6s 0
d yy 2s 0 overlay(yymmdd: 1)
d mm 2s 0 overlay(yymmdd: 3)
d dd 2s 0 overlay(yymmdd: 5)
c/free
eur.ddmmyy = 020812;
ymd.yy = eur.yy;
ymd.mm = eur.mm;
ymd.dd = eur.dd;
dsply ymd.yymmdd;
*inlr = *on;
/end-free
Is this file created via DDS or SQL? If DDS, then please add the field of your choice to the DDS specs, and specify a Data Type of L:
A MYDATE L
Then use CHGPF, specifying the source file and member name; the system will add the new column.
CHGPF FILE(MYLIB/MYFILE)
SRCFILE(MYSRCLIB/MYSOURCE)
SRCMBR(MY_MBR)
Even if your file is DDS described, you could add the date column by using an SQL statement like:
alter table mytable add column mydate date not null default
(But of course, if you do that, you cannot recreate the file from DDS anymore without losing the new column)
Then in your program, just before the WRITE to the data, do:
mydate = %date
There are many assumptions here: you are using ILE, you know how to modify and recompile the program, you are using free form or can translate the "variable = value" syntax above, ...)
There are also other ways to get the system date into a file without your program having to do anything special; we actually need to know more about the application in order to help much beyond this high-level advice.