We are using lsconf|grep -i "Machine Serial Number" to get Machine's Serial information on AIX Operating System. But on some of the machines it is not returning any information, just blank result. What can possibly the reason that lsconf not giving any result and what should I use instead.
Any help would be much appreciated
Related
I found that ps aux lists processes that are currently running and I found other people mentioning ps auxwww . I am wondering what this means? or what it does? What's the difference between ps aux and ps auxwww ?
To quote the man page (on Mac OS, other systems will vary slightly, but the idea is the same):
-w
Use 132 columns to display information, instead of the default which is your window size. If the -w option is specified more than once, ps will use as many columns as
necessary without regard for your window size. When output is not to a terminal, an unlimited number of columns are always used.
ps auxwww is useful when you have a lot of data (how many columns you want)
When dealing with multiple variable-bindings in 1 snmp packet, tshark cannot parse it properly such that the OID-to-value can be determined. Therefore, I have to query the packet by value type and use the results to figure out which OID was set to what. For this to work, I need to know each OID's value type beforehand.
Is there a way to query an OID (even if the instance is not created) and have it return the type (such as Integer32, Gauge32, OctetString, etc)?
I also tried using snmpwalk but that only returns the value when the OID instance is already set. If it is not set it returns "no such instance currently exists at this OID"
The MIB must already know what type it is expecting because if you try to set it to the wrong type you get an error... I am just trying to figure out how to access this information
Thanks!
No, there is no way to query a running SNMP Agent for anything other than variables that have been instantiated.
If you need to know which type a variable will have, there is help for you in the MIB document. It specifies, for each scalar variable and for each table column, what the appropriate type is.
When it receives a query for a variable, the Agent is obliged to provide a value of the type specified in the MIB. If it returns a different type, that's a bug in the agent.
You should be able to get the MIB document from the vendor of the SNMP Agent you are querying. Often it's published as part of the system administrator's guide or similar, or you might have to request it from their customer support.
I need to determine "TOTAL" hard disk space of the remote Windows host using wmic call.
I have tried executing wmic /node:<IP-ADDRESS> diskdrive get Size on some systems. For most of the systems, it worked well. But, for a few of them, it displayed multiple values, which are the total sizes of the partitions available.
H:\>wmic /node:172.22.248.112 diskdrive get size
Size
36273484800
293621594112
In order to get unique value for the total hard disk space (addition of sizes of all partitions), what should be done?
try to use
C:\>wmic /node:<IP-ADDRESS> logicaldisk get Size
I am running Linux on 32-nm Intel Westmere processor. I have a concern with seemingly conflicting data on DTLB miss numbers from performance counters. I ran two experiments with a random memory access test program (single-threaded) as follows:
Experiment (1): I counted the DTLB misses using following performance counter
DTLB_MISSES.WALK_COMPLETED ((Event 49H, Umask 02H)
Experiment (2): I counted the DTLB misses by summing up following the two counter values below
MEM_LOAD_RETIRED.DTLB_MISS (Event CBH, Umask 80H)
MEM_STORE_RETIRED.DTLB_MISS (Event 0CH, Umask 01H)
I expected the output of these experiments to be similar. However I found that numbers reported in experiment (1) is almost twice that of in experiment (2). I am at a loss why this is the case.
Can somebody help shed some light on this apparent discrepancy?
That is expected since the first event counts the number of misses to all TLB levels caused by all possible reasons (load, store, pre-fetch), including memory accesses performed speculatively, while the other two events count only retired (that is, non-speculative) load and store operations, and only those among them that didn’t cause any fault.
Please refer to Chapter 19.6 of Volume 3 of Intel® 64 and IA-32 Architectures Software Developer’s Manual.
Thanks,
Stas
I'm using SQLite to store some data. The primary database is on a NAS (Debian Lenny, 2.6.15, armv4l) since the NAS runs a script which updates the data every day. A typical "select * from tableX" looks like this:
2010-12-28|20|62.09|25170.0
2010-12-28|21|49.28|23305.7
2010-12-28|22|48.51|22051.1
2010-12-28|23|47.17|21809.9
When I copy the DB to my main computer (Mac OS X) and run the same SQL query, the output is:
2010-12-28|20|1.08115035175016e-160|25170.0
2010-12-28|21|2.39343503830763e-259|-9.25596535779558e+61
2010-12-28|22|-1.02951149572792e-86|1.90359837597183e+185
2010-12-28|23|-1.10707273937033e-234|-2.35343828462275e-185
The 3rd and 4th column have the type REAL. Interesting fact: When the numbers are integer (i.e. they end with ".0"), there is no difference between the two databases. In all other cases, the differences are ... hm ... surprising? I can't seem to find a pattern.
If someone's got a clue - please share!
PS: sqlite3 -version output
Debian: 3.6.21 (lenny-backports)
Mac OS X: 3.6.12 (10.6)
In release 3.4.0 of SQLite there was a compile time flag added.
Added the SQLITE_MIXED_ENDIAN_64BIT_FLOAT compile-time option to support ARM7 processors with goofy endianness.
I was having this same problem with an Arm920Tid device and my x86 based VM. The arm device was writing the data, and I was trying to read it on the x86 VM (or on my Mac).
After adding this compile time flag to my makefile for my arm build I was able to get sane values when I queried the DB on either platform.
For reference I am using sqlite 3.7.14
It should be, the file format says that REAL is stored in big-endian format, which would be architecture-invariant if serialized correctly by both builds.
A value of 7 stored within the database record header indicates that the corresponding database value is an SQL real (floating point number). In this case the blob of data contains an 8-byte IEEE floating point number, stored in big-endian byte order.