I am trying to set RFH2Header type to a message string. But it's not appending to the message.
Please help. Thanks in advance!!!!
Is My approach is correct ?? If i check in response queue, RFH Property gets added to bytes message.
String message1 = "MQ Message header test";
Message message11 = session.createTextMessage(message1);
MQRFH2 header = new MQRFH2();
ByteArrayOutputStream out = new ByteArrayOutputStream ();
DataOutput dout = new DataOutputStream(out);
header.write(dout);
byte[] outheaders = out.toByteArray();
byte[] bArray = message1.getBytes("UTF-8");
BytesMessage responseMessage = session.createBytesMessage(); // throws JMSException
responseMessage.writeBytes(outheaders);
responseMessage.writeBytes(bArray);
responseMessage.setJMSType("MQRFH2");
responseMessage.setJMSCorrelationID("12345678900000");
responseMessage.setJMSDeliveryMode(2);
responseMessage.setJMSPriority(4);
responseMessage.setJMSReplyTo(queue);
responseMessage.setStringProperty("JMS_IBM_Format", "MQRFH2");
responseMessage.setIntProperty("JMS_IBM_Encoding", MQConstants.MQENC_NATIVE);
responseMessage.setIntProperty("JMS_IBM_Character_Set", 1208);
responseMessage.setIntProperty("JMS_IBM_PutApplType", 11);
producer.send(responseMessage);
My output looks like below in response queue.., Please help , how to set header to a string
00000 4D 51 20 4D 65 73 73 61--67 65 20 68 65 61 64 65 |MQ Message heade|
00010 72 20 74 65 73 74 52 46--48 20 00 00 00 02 00 00 |r testRFH ......|
00020 00 24 00 00 00 00 00 00--00 00 20 20 20 20 20 20 |.$........ |
00030 20 20 00 00 00 00 00 00--04 B8 | .......� |
Not very clear about the question but in any case the following may be useful to you.
RFH2 is MQ specific while JMS is a standard. A MQ JMS application can not explicitly set RFH2 data as JMS message header. MQ JMS client internally sets the required RFH2 headers to build a JMS message while the message is being sent. The application can only set message body and a number of JMS properties using setJMSxxxx and user defined properties using setxxxProperty methods. For example the snippet below sets a string type property called MyStringProperty.
responseMessage.setStringProperty("MyStringProperty", "SomeString Data");
RFH2 data will be a stream of bytes with a fixed header part and variable data part as described here:http://www-01.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.dev.doc/q032000_.htm?lang=en. Hence you need to create BytesMessage if you want to send RFH2 data as part of message body.
Related
I will give you some information first!
I am currently trying to decode the server data socket.io sends as response to the client (when using Http long-polling) as I am trying to intercept the communication. I don't have access to the client-side socket instance.
Though I would like to be able to have the same JSON data the client-socket instance would end up with!
The content type of the socket.io responses is: 'application/octet-stream'
Calling Response.body() on the Response object returns the following Buffer:
<Buffer 00 01 02 08 ff 34 32 5b 22 75 70 64 61 74 65 55 73 65 72 73 52 6f 6f 6d 22 2c 7b 22 72 6f 6f 6d 22 3a 22 48 65 69 6c 69 67 74 75 6d 22 2c 22 75 73 65 ... 83 more bytes>
Calling Response.text() on the Response object returns the following string:
☺☻�42["updateUsersRoom",{"room":"Heiligtum","userid":13132,"imgthumb":"thumb_ffkqOEBwQXbf_pngfindcomrealisticspiderwebpngpng.png"}]
Now you might think that Response.text() looks okay-ish, however it is very 'inconsistent'. There are these random "broken" characters like '☺☻�42' every here and there and sometimes it even sends mutliple messages per response.
What I've tried is using the decode methods of both socket.io-parser and engine.io- parser, trying to feed it the data Request.body() returned. However it always returns:
{ type: 'error', data: 'parser error' }
I tried digging through the engine.io source code as well, trying to find out how they handle responses but I simply can't get it to work. This might require some deeper knowledge about socket.io, but I hope somebody can help me!
Thank you in advance.
I have this test wallet:
% solana account 9AYXoP3b22KHRhVuvjZbynpjNd2SXKFLoC1jrPMkyFkS
Public Key: 9AYXoP3b22KHRhVuvjZbynpjNd2SXKFLoC1jrPMkyFkS
Balance: 12.98943736 SOL
Owner: (removed by me)
Executable: false
Rent Epoch: 248
And I have this javascript snippet:
const SOURCE_TOKEN_ACCOUNT = new PublicKey('9AYXoP3b22KHRhVuvjZbynpjNd2SXKFLoC1jrPMkyFkS');
const sourceInfo = await connection.getParsedAccountInfo(
SOURCE_TOKEN_ACCOUNT,
);
console.log('tok ', sourceInfo);
When I run, I get this output:
tok { context: { slot: 191644 }, value: null }
I would like to note that I'm trying to get this to function with multiple accounts. They all have the same slot value.
I want to know why value would be coming back null. I have nothing to go on with why this would be happening. I just want some value to show up. Since I don't know what is supposed to show up when this works, I don't know what value is should be, short of showing some sort of SOL. All I know is, I'm getting the following error:
TypeError: Cannot read properties of null (reading 'data')
Accounts in Solana store lamports (SOL) and data, and in this case, your account only has SOL in it, and no data, which is why the value is coming up as null. For example, the token program at TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA will also show the bytes of the data in the account along with the balance:
$ solana account TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
Public Key: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA
Balance: 1.08999168 SOL
Owner: BPFLoader2111111111111111111111111111111111
Executable: true
Rent Epoch: 161
Length: 156480 (0x26340) bytes
0000: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 .ELF............
.... rest omitted for length ....
If you want data inside your account, you must allocate data to it, assign it to a program, and use a transaction on the program to modify the data.
I would highly recommend reading up more on how accounts work: https://docs.solana.com/developing/programming-model/accounts
I am trying to read data from sony felica card using pc/sc transparent session and transceive data object.
The response I am getting is for a read without encryption command is
c0 03 00 90 00 92 01 00 96 02 00 00 97 82 00 + Data
But according to the protocol, the response should be
c0 03 00 90 00 92 01 00 96 02 00 00 97 + Data
I am unable to figure out the last 82 00 appended in the response from the card.
Now when I try to authenticate with the card I get
c0 03 01 6F 01 90 00
which is a error in pc/sc. I want to resolve these extra bytes 82 00 which I believe will solve the issue with all the commands which require authentication and encryption.
The response data is BER-TLV encoded (see PC/SC 2.02, Part 3).
In BER-TLV encoding there are several possibilities to encode tag 0x97 with two octets of data 0xD0D1, e.g.:
97|02|D0D1 -- short form (see parsed)
97|8102|D0D1 -- long form with one octet with length (see parsed)
97|820002|D0D1 -- long form with two octets with length (see parsed)
97|83000002|D0D1 -- long form with three octets with length (see parsed)
...
Your reader is using two octets for sending the length of ICC Response data object (which is perfectly valid).
You should parse the response properly...Good luck!
PS: The above means, that the Data part of your truncated responses still contains one extra byte with the response length (i.e. Len|Data)
I would like to learn how to trace an Oracle client and view the SQL queries submitted.
I started by adding these lines to my client's sqlnet.ora file:
TRACE_LEVEL_CLIENT=16
TRACE_FILE_CLIENT=sqlnet.trc
TRACE_DIRECTORY_CLIENT=c:\temp
LOG_DIRECTORY_CLIENT=c:\temp
TRACE_UNIQUE_CLIENT=TRUE
TRACE_TIMESTAMP_CLIENT=TRUE
DIAG_ADR_ENABLED=OFF
Then I logged into the database on that same client using SQL*Plus. I submitted two queries:
select * from all_tables where table_name = 'ADDRESS';
select * from all_users where username like 'AB%';
Then I exited SQL*Plus. The trace file was created in c:\temp. The file is about 4000 lines long. I can definitely see my two SQL statements in there. The format is a pain to read though, as they are just hex dumps:
(10632) [29-AUG-2016 17:08:40:240] nsbasic_bsd: 00 00 31 73 65 6C 65 63 |..1selec|
(10632) [29-AUG-2016 17:08:40:240] nsbasic_bsd: 74 20 2A 20 66 72 6F 6D |t.*.from|
(10632) [29-AUG-2016 17:08:40:240] nsbasic_bsd: 20 61 6C 6C 5F 75 73 65 |.all_use|
(10632) [29-AUG-2016 17:08:40:240] nsbasic_bsd: 72 73 20 77 68 65 72 65 |rs.where|
(10632) [29-AUG-2016 17:08:40:240] nsbasic_bsd: 20 75 73 65 72 6E 61 6D |.usernam|
(10632) [29-AUG-2016 17:08:40:240] nsbasic_bsd: 65 20 6C 69 6B 65 20 27 |e.like.'|
(10632) [29-AUG-2016 17:08:40:240] nsbasic_bsd: 41 42 25 27 01 00 00 00 |AB%'....|
My research leads me to believe that tkprof is the way to get a readable report of my trace file. I tried the following:
tkprof c:\temp\sqlnet_10632.trc report.txt
But that gives me a pretty pointless file:
0 session in tracefile
0 user SQL statements in trace file.
0 internal SQL statements in trace file.
0 SQL statements in trace file.
0 unique SQL statements in trace file.
4361 lines in trace file.
0 elapsed seconds in trace file.
Ideally, I'd like to see a report that for this situation shows me easy-to-read SQL text submitted by the client (including the two I manually typed in), in the order they were submitted. Am I on the right track? What am I missing? If I'm not on the right track, what should I do instead to trace the SQL submitted by the client?
Note: I am using a 12c client. I do not have access to the database server.
Just for reference, Oracle provides the trcasst utility to perform this action:
$ORACLE_HOME/bin/trcasst client_Tract_file.trc > client_Tract_file.txt
The tkprof utility is used to generate reports from 10046 trace files.
These trace files show database operations.
Here is a good article to get you started with those:
sql trace 10046
tkprof would not be at all useful for sqlnet trace files.
For sqlnet trace files, you would want to use the trcasst utility.
While trcasst is useful, if you really want to find out what is going on, you will need to develop some understanding of the files themselves.
Here are some good references to get started with understanding sqlnet trace files:
Tracing Error Information for Oracle Net Services
If you have access to My Oracle Support, the following notes will be invaluable:
SQLNET PACKET STRUCTURE: NS PACKET HEADER (Doc ID 1007807.6)
Examining Oracle Net, Net8, SQLNet Trace Files (Doc ID 156485.1)
That second article has a PDF attached that explains quite a bit.
Documentation from 11g - 19c will all state that you should set the following in sqlnet.ora:
diag_adr_enabled=off
If you want accurate timestamps, then do this instead:
diag_adr_enabled=on
That is a bug that I hope to see fixed by the time Oracle 20c is released.
This isn't the answer I was hoping for, but I needed to get-r-done and move on, so I wrote a quick and dirty Windows console application (C#):
static void Main(string[] args)
{
using (var sr = new StreamReader(args[0]))
{
var line = string.Empty;
var parsingSqlHex = false;
var timestamp = string.Empty;
var parsedSql = string.Empty;
var patternStart = #"nsbasic_bsd\: packet dump";
var patternTimeStamp = #"\[\d{2}-[A-Z]{3}-\d{4} (\d\d\:){3}\d{3}\]";
var patternHex = #"nsbasic_bsd\: ([0-9A-F][0-9A-F] ){8}";
var patternEnd = #"nsbasic_bsd\: exit \(0\)$";
while (line != null)
{
if (Regex.IsMatch(line, patternStart))
{
timestamp = Regex.Match(line, patternTimeStamp).Value;
parsingSqlHex = true;
}
else if (parsingSqlHex)
{
if (Regex.IsMatch(line, patternEnd))
{
if (!string.IsNullOrEmpty(parsedSql))
{
Console.WriteLine(timestamp);
Console.WriteLine(parsedSql + "\r\n");
}
parsedSql = string.Empty;
parsingSqlHex = false;
}
else if (Regex.IsMatch(line, patternHex))
{
parsedSql += HexToString(line.Substring(line.Length - 35, 23));
}
}
line = sr.ReadLine();
}
}
}
static string HexToString(string hexValues)
{
var hexCodeArray = hexValues.Split(" ".ToCharArray());
var n = 0;
var s = string.Empty;
for (var i = 0; i < hexCodeArray.Length; i++)
{
n = Convert.ToInt32(hexCodeArray[i], 16);
if (n > 31 && n < 127) s += Convert.ToChar(Convert.ToUInt32(hexCodeArray[i], 16));
}
return s;
}
I'm using it to parse my trace files like so:
OracleTraceParser.exe c:\temp\trace.txt > report.txt
Then my report.txt file has some odd characters here and there, but nonetheless gives me what I'm after:
[30-AUG-2016 13:50:51:534]
i^qx(SELECT DECODE('A','A','1','2') FROM DUAL
[30-AUG-2016 13:50:51:534]
i
[30-AUG-2016 13:51:05:003]
^a5select * from all_tables where table_name = 'ADDRESS'
[30-AUG-2016 13:51:21:081]
i^a1select * from all_users where username like 'AB%'
I am using snmpV3 adapter and passing V2 traps to it by using commands as below. It looks like the range for type u (i.e. unsigned) is upto (2^31) - 1 (i.e. 2147483647). I was expecting it to be (2^32) - 1 (i.e. 4294967295).
snmptrap -c public -v 2c clm-pun-009642 '' 1.3.6.1.4.1.20006.1.0.5 1.3.6.1.4.1.12345.1 u 2147483647
Above command generates following log:
trace: ..\..\snmplib\snmp_api.c, 5293:
dumph_recv: Value
dumpx_recv: 42 04 7F FF FF FF
dumpv_recv: UInteger: 2147483647 (0x7FFFFFFF)
Where as for:
snmptrap -c public -v 2c clm-pun-009642 '' 1.3.6.1.4.1.20006.1.0.5 1.3.6.1.4.1.12345.1 u 2147483648
Above command generates following log:
enter code heretrace: ..\..\snmplib\snmp_api.c, 5293:
dumph_recv: Value
dumpx_recv: 42 05 00 80 00 00 00
dumpv_recv: UInteger: -2147483648 (0x80000000)
Refer to:
http://www.net-snmp.org/docs/man/snmptrap.html
I am using net-snmp v5.5.
Is this the correct behavior or am I missing something?
I have discovered various problems with net-snmp over the years. This is apparently one more. The standards are quite clear. RFC 2578 defines Unsigned32 as follows:
-- an unsigned 32-bit quantity
-- indistinguishable from Gauge32 Unsigned32 ::=
[APPLICATION 2]
IMPLICIT INTEGER (0..4294967295)
As noted, this is identical to Gauge32, which is identical to Gauge in SNMPv1 (RFC 1155):
Gauge ::=
[APPLICATION 2]
IMPLICIT INTEGER (0..4294967295)
The encoding is correct; all integers within SNMP are encoded as signed, meaning a value above 2^31-1 must be encoded in 5 bytes. Thus the proper translation of the encoding is:
42 Type: Gauge32 or Unsigned32
05 Length: 5 bytes
00 80 00 00 00 Value: 2^31
net-snmp is incorrectly decoding the value.