NSLog() uses timestamps with millisecond resolution, but is a blunt instrument because all its log messages are at the Warning level.
Apple System Log is a much more fine-grained system, with 8 different levels. BUT... its timestamps have only 1-second resolution. I read the man page about time formats, but they all seem to be to the second only.
Clearly this information is available, at least to NSLog. A lot can go on in a second; is there a way to get better resolution with ASL?
You can append ".#" to the time format in ASL (and syslog) to specify the precision. Thus "utc.3" would format in UTC format with milliseconds. You can add this to both the msg_fmt or time_fmt arguments.
Time format precision appears to only be documented in syslogd(1). I am not sure why it didn't make it to asl(3).
For example, using asl_add_output_file and specifying in the time_fmt might look like this:
// setup, do once!
aslclient log = asl_open(NULL, NULL, 0);
asl_add_output_file(log, STDERR_FILENO,
"$Time $((Level)(str)) - $Message", // $Time here uses time_fmt arg on next line
ASL_TIME_FMT_UTC ".3", // time_fmt: append ".3" for milliseconds here
ASL_FILTER_MASK_UPTO(ASL_LEVEL_DEBUG), ASL_ENCODE_SAFE);
// example log
asl_log(log, NULL, ASL_LEVEL_INFO, "Hello");
// Note in the above ASL_TIME_FMT_UTC is #defined to "utc", so the we're
// using compile-time string concatenation of "utc" ".3" to "utc.3".
// Alternately you can just specify "utc.3" directly.
and output:
2016-02-01 19:16:39.561Z Info - Hello
Specifying in msg_fmt argument of asl_add_output_file might look like this:
// setup, do once!
aslclient log = asl_open(NULL, NULL, 0);
asl_add_output_file(log, STDERR_FILENO,
// in msg_fmt below, use ISO8601 + ".6" for microseconds
"$((Time)(ISO8601.6)) $((Level)(str)) - $Message",
ASL_TIME_FMT_UTC,
ASL_FILTER_MASK_UPTO(ASL_LEVEL_DEBUG), ASL_ENCODE_SAFE);
// example log
asl_log(log, NULL, ASL_LEVEL_INFO, "Hello");
and output:
2016-02-01T14:16:39.562030-05 Info - Hello
(I would caution that the above snippets of code are only meant to demonstrate specifying the time format precision in ASL. Actual usage should likely involve a dispatch_once for setup, use a serial dispatch queue for logging.)
Use ts shell command to add milliseconds to any log.
idevicesyslog | ts '[%Y-%m-%d %H:%M:%.S]'
Related
I have business logic in CICS, we want to replace maps/ mapsets with distributed systems, so we want our CICS programs to provide service and have distributed system (to replace maps/ mapsets) that sends request and receive response from CICS are processing. This is for Legacy payment application and is non-SSP environment.
As first step, I am trying to submit JCL that creates WSDL and WSBIND files using CICS webservice assistant tool (DHFLS2DS) but I am not sure about the parameters to be passed, that executes BPXBATCH.
//JAVAPRG1 EXEC PGM=BPXBATCH,REGION=400M,
// PARM=('SH &PATHPREF/usr/lpp/cicsts/&USSDIR/lib/wsdl/DFHLS2WS ', X
// '&JAVADIR &USSDIR &TMPDIR./&TMPFILE. &SERVICE &PATHPREF')
Can someone please help with required parameters to be passed to execute CICS webservice assistant tool?
Not answering your parameter question, but commenting on the JCL.
//JAVAPRG1 EXEC PGM=BPXBATCH,REGION=400M,
//*.+....1....+....2....+....3....+....4....+....5....+....6....+....7..
// PARM=('SH &PATHPREF/usr/lpp/cicsts/&USSDIR/lib/wsdl/DFHLS2WS ', X
// '&JAVADIR &USSDIR &TMPDIR./&TMPFILE. &SERVICE &PATHPREF')
Note that the maximum length of the PARM= data is 100 characters. This is a JCL limit. Your PARM will probably exceed 100 characters after symbolic parameter resolution.
BPXPATCH has implemented the //STDPARM DD statement as an alternative way to pass parameters. There is a limit of 65536 characters on //STDPARM. See here for details: Running shell scripts or executable files under MVS environments - Topic BPXBATCH.
The modified JCL for the step would look smoething like this:
//JAVAPRG1 EXEC PGM=BPXBATCH,REGION=400M
//... put any other DD statements for BPXBATCH phere
//...
//STDPARM DD *
SH
&PATHPREF/usr/lpp/cicsts/&USSDIR/lib/wsdl/DFHLS2WS
&JAVADIR &USSDIR
&TMPDIR./&TMPFILE. &SERVICE &PATHPREF
/*
But there is the problem of resolving the JCL symbolic parameters within SYSIN data, which is not done by default. You need to enable symbolic parameter resolution by changing the DD statement to look like this:
//STDPARM DD *,SYMBOLS=(JCLONLY)
Additionally, you need tell which parameters you want to be eligible for resolution in SYSIN data. This is done with the following statement before your EXEC statement, and before any symbolic parameter that you might SET. Best place is immediately following the JOB statement.
// EXPORT SYMLIST=*
Note that your systems programmer must have allowed this for the job class your job will run in. The job class must have been set to SYSSYM=ALLOW.
The final JCL looks like this:
//jobname JOB ....
//... any job level parameters you need go here
//*
// EXPORT SYMLIST=*
//*
//... any additional symbolic parameters are set here
//*
//JAVAPRG1 EXEC PGM=BPXBATCH,REGION=400M
//... put any other DD statements, BPXBATCH requires here
//...
//STDPARM DD *,SYMBOLS=(JCLONLY)
SH
&PATHPREF/usr/lpp/cicsts/&USSDIR/lib/wsdl/DFHLS2WS
&JAVADIR &USSDIR
&TMPDIR./&TMPFILE. &SERVICE &PATHPREF
/*
Warning: I have not actually run that JCL, since I do not know what all the symbolic parameters are set to in your environment.
Final note: Enabling Symbolic parameter resolution in SYSIN data doesn't look like a straight forward process, does it?. IBM had to implement this in a way that guaranteed not to break any existing job (JCL). Once you get used to it, it is nevertheless a very useful thing, IMHO.
The JOB Symbolic parameters and SYSIN parameters are explained in this official IBM document
Mainly, we need to check the location of DFHLS2WS program present in the Z/OS Unix file path and pass in the symbolic parameter - JAVADIR and we can use the default parameters for the remaining symbolic parameters unless you have a requirement to change it.
Note : all parameters are not required.
Please pass the SYSIN parameters as per your application and requirement. The significance of all the parameters are explained in the above document.
I need some sort of schedule thing to schedule a task to happen at x:y (12:00 for example) in Tcl.
The scenario is a router using Openwrt with Tcl 8.6.10 with limited RAM and storage where I have some sort of IRC client "bot" (using socket to connect). The "bot" was just a barebone that I modify to suit my needs. Most of the things work fine, except that I don't have way to schedule easily things. I wanted something like how eggdrop has "bind time" where the bind thing is "bind time flag "cron-style string" caller".
The "bot" scheme is like:
Main Tcl script:
<info+code to connect to IRC>
<while loop>
<some code in case of IRC disconnection>
<list of files with tcl code aka sub-scripts>
<usage of source based from a list of the filenames>
<code for error handling>
<end of while loop>
The list of files is source filelist.tcl, where filelist.tcl is a set var {filename1.tcl filename2.tcl...}. The filenamex.tcl has some basic code to respond to IRC server or IRC input from channels and reply to channels.
I can make some sort of schedule if I base a execution like if {[clock format [clock seconds] -format "%H:%M"]=="12:00"} {code to execute} and hopefully wait for a server ping/pong but that can lead to repeated code inside of the if body.
I been looking around and found a package called cron but I don't know how to use it correctly because there are not many examples and I don't know to use vwait properly and I don't want vwait to hang the bot waiting for a value to change. I also read about tcl threads for maybe parallel execution.
So I need some code inside of a sub-script that looks like (a package cron style):
#beginning of file
#add a task specifying hour and minute
task-at "12:00" proccaller
proc procname {optional} {
<some code to be executed at specific hour+time>
}
#end of file
I also don't know how to use after command to use it.
How can I accomplish I want?
Thanks for the replies and yes, it would help if I study event loops and coroutine, which probably comes next.
Some time has passed since I posted the question and kinda sorted the thing by creating a sub-script in a folder named scripts with the following structure:
#beginning of the script
if {![file exists executed]} {set executed "no"}
#the following clock instruction returns for example: Tuesday 22:14
switch -glob -- [clock format [clock seconds] -format "%A %H:%M"] {
"*12:00" - "*12:01" {
#Basic example of sending a message to the irc channel when it's midday
if {$executed=="no"} {
puts $fd "PRIVMSG #CODE :It's midday right now."
flush $fd
set executed "yes"
}
}
#...more time comparisions and code
default {set executed "no"}
}
#end of script
And the script is almost the top of the list of scripts to be loaded so if I wish to send some command down stream at giving time, the command can be executed.
There is double timings because the "bot" reacts, at least at minimum, to the irc server's ping which happens each 90 seconds and it may skip some minutes.
This is not an answer but an unproper workaround.
I'm using LabVIEW and its VISA capabilities to control a Keithley 2635A source meter. Whenever I try to identify the device, it works just fine, both in reading and writing.
viWRITE(*IDN?) /* VISA subVI to send the command to the machine */
viREAD /* VISA subVI to read output */
However, as soon as I set the voltage (or current), it does so. Then I send the command to perform a measurement, but I'm not able to read that data, with the error
VISA: (Hex 0xBFFF0015) Timeout expired before operation completed.
After that, I can not read the *IDN? output either anymore.
The source meter is connected to the PC via a National Instrument GPIB-USB-HS adaptor.
EDIT: I forgot to add, this happens in the VISA Interactive Control program as well.
Ok, apparently the documentation is not very clear. What the smua.measure.X() (where X is the needed parameter) command does is, of course, writing the measurement outcome on a buffer. In order to read that buffer, however, the simple viREAD[] is not sufficient.
So basically the answer was to simply add a print command: this way I have
viWRITE[print(smua.measure.X())];
viREAD[]
And I don't have the error anymore. Not sure why such a command is needed, but that's that. Thank you all for your time answering me.
As #Tom Blodget mentions in the comments, the machine may not have any response to read after you set the voltage. The *IDN? string is both command and query. That is, you will write the command *IDN? and read the result. Some commands do not have any response to read. Here's a quick test to see if you should be reading from the instrument. The following code is in python; I made up the GPIB command to set voltage.
sm = SourceMonitor()
# Prints out IDN
sm.query('*IDN?')
# Prints out current voltage (change this to your actual command)
sm.query('SOUR:VOLT?')
# Set a new voltage
sm.write('SOUR:VOLT 1V')
# Read the new voltage
sm.query('SOUR:VOLT?')
Note that question-marked GPIB commands and the query are used when you expect to get a response from the instrument. The instrument won't give a response for the write command. Query is a combination of write(...) and read(...). If you're using LabView, you may have to write the write and read separately.
If you need verification that the machine received your instruction and acted on it, most instruments have the following common commands:
*OPC? query to see if the operation is complete
SYST:ERR? query to see if any error was generated
Add a question mark ? to the end of the GPIB command used to set the voltage
I'm trying my driver with Driver Verifier turned on in Windows 7 x64, and get IRQL_NOT_LESS_OR_EQUAL(0A) bugcheck. From analyze -v info, it seems that the memory page of RtlAnsiCharToUnicodeChar function gets paged out, so calling that function causes bugcheck 0A . RtlAnsiCharToUnicodeChar is an ntoskrnl.exe exported function. Can it really be paged out? If so, how can I prevent it?
On spot debug info screen shot below:
yes. of course - very many ntoskrnl routines in PAGE* section.
RtlAnsiCharToUnicodeChar also paged - read in documentation:
IRQL <= APC_LEVEL
also read about DbgPrintEx routine
DbgPrint and DbgPrintEx can be called at IRQL<=DIRQL. However, Unicode
format codes (%wc and %ws) can be used only at IRQL = PASSIVE_LEVEL.
and
However, the Unicode format codes (%C, %S, %lc, %ls, %wc, %ws, and
%wZ) can only be used with IRQL = PASSIVE_LEVEL.
so if you not use Unicode format you can use DbgPrint or KdPrint(this is macro) at any IRQL but if you use Unicode format - only on PASSIVE_LEVEL or APC_LEVEL (about APC_LEVEL i say by self)
You can try to use the MmLockPagableCodeSection on that specific routine to prevent it being paged out, however it's probably not advisable (and you don't know what dependencies it has, if they're located in pagable sections as well). In any case, make sure you read the documentation thoroughly.
A better approach is to run at Passive/APC level in the first place before invoking the printing function - e.g., by scheduling work item (you can also force lowering the IRQL with KeLowerIrql function but it's not advisable by MSFT).
I am using Verilator to incorporate an algorithm written in SystemVerilog into an executable utility that manipulates I/O streams passed via stdin and stdout. Unfortunately, when I use the SystemVerilog $display() function, the output goes to stdout. I would like it to go to stderr so that stdout remains uncontaminated for my other purposes.
How can I make this happen?
Thanks to #toolic for pointing out the existence of $fdisplay(), which can be used thusly...
$fdisplay(STDERR,"hello world"); // also supports formatted arguments
IEEE Std 1800-2012 states that STDERR should be pre-opened, but it did not seem to be known to Verilator. A workaround for this is:
integer STDERR = 32'h8000_0002;
Alternatively, you can create a log file handle for use with $fdisplay() like so...
integer logfile;
initial begin
$system("echo 'initial at ['$(date)']'>>temp.log");
logfile = $fopen("temp.log","a"); // or open with "w" to start fresh
end
It might be nice if you could create a custom wrapper that works like $display but uses your selected file descriptor (without specifying it every time). Unfortunately, that doesn't seem to be possible within the language itself -- but maybe you can do it with the DPI, see DPI Display Functions (I haven't gotten this to work so far).