We have been using Websphere MQ 8.0.0.2 on windows machine.
We have configured server connection setup.
We are unable to start server connection channel since channel is in inactive state.
While application tried to pull the msg from queue, the SVRCONN channel went to inactive state.
I have checked ip/port number and channel name at client end, all are same as in server side.
Below errors are logged in qmgr error logs.
Error log:
12/28/2017 15:12:27 - Process(24316.247) User(SWIFTAMHMQ) Program(amqrmppa.exe)
Host(HYDSWIFTMQ2T1) Installation(AMHMQ)
VRMF(8.0.0.2) QMgr(SWIFTBACKOFFICE)
AMQ9492: The TCP/IP responder program encountered an error.
EXPLANATION:
The responder program was started but detected an error.
The host name was '10.24.187.121'; in some cases the host name cannot be
determined and so is shown as '????'.
ACTION:
Look at previous error messages in the error files to determine the error
encountered by the responder program.
----- amqrmrsa.c : 921 --------------------------------------------------------
12/28/2017 15:21:09 - Process(24316.603) User(SWIFTAMHMQ) Program(amqrmppa.exe)
Host(HYDSWIFTMQ2T1) Installation(AMHMQ)
VRMF(8.0.0.2
AMQ9207: The data received from host '10.24.187.121' on channel '????' is not
valid.
EXPLANATION:
Incorrect data format received from host '10.24.187.121' over TCP/IP. It may be
that an unknown host is attempting to send data.
An FFST file might be generated containing the invalid data received. It will
not be generated if this is the beginning of a conversation with the remote
side, and the format is a simple known format (example: a GET request from an
HTTP web browser). If you want to override this, to cause FFST files to be
written for any bad data, including simple known formats, then set the
environment variable AMQ_BAD_COMMS_DATA_FDCS=TRUE and restart the queue
manager.
The channel name is '????'; in some cases it cannot be determined and so is
shown as '????'.
ACTION:
Tell the systems administrator.
12/28/2017 15:21:09 - Process(24316.603) User(SWIFTAMHMQ) Program(amqrmppa.exe)
Host(HYDSWIFTMQ2T1) Installation(AMHMQ)
VRMF(8.0.0.2) QMgr(SWIFTBACKOFFICE)
AMQ9207: The data received from host '10.24.187.121' on channel '????' is not
valid.
EXPLANATION:
Incorrect data format received from host '10.24.187.121' over TCP/IP. It may be
that an unknown host is attempting to send data.
An FFST file might be generated containing the invalid data received. It will
not be generated if this is the beginning of a conversation with the remote
side, and the format is a simple known format (example: a GET request from an
HTTP web browser). If you want to override this, to cause FFST files to be
written for any bad data, including simple known formats, then set the
environment variable AMQ_BAD_COMMS_DATA_FDCS=TRUE and restart the queue
manager.
The channel name is '????'; in some cases it cannot be determined and so is
shown as '????'.
ACTION:
12/28/2017 15:21:09 - Process(24316.603) User(SWIFTAMHMQ) Program(amqrmppa.exe)
Host(HYDSWIFTMQ2T1) Installation(AMHMQ)
VRMF(8.0.0.2) QMgr(SWIFTBACKOFFICE)
AMQ9492: The TCP/IP responder program encountered an error.
EXPLANATION:
The responder program was started but detected an error.
The host name was '10.24.187.121'; in some cases the host name cannot be
determined and so is shown as '????'.
ACTION:
Look at previous error messages in the error files to determine the error
encountered by the responder program.
----- amqrmrsa.c : 921 ------
FDC file are
UTC Time Offset :- 330 ((UNKNOWN)) |
| Operating System :- Windows Ver 6.2 (7) Server Datacenter x64 Edition |
| LVLS :- 8.0.0.2 |
| Product Long Name :- WebSphere MQ for Windows (x64 platform) |
| Vendor :- IBM |
| O/S Registered :- 1 |
| Data Path :- E:\MQServer\IBM\MQ |
| Installation Path :- E:\MQServer\IBM\WebSphere MQ |
| Installation Name :- AMHMQ (1) |
| License Type :- Production |
| Probe Id :- CO618000
Application Name :- MQM |
| Component :- cciInvalidDataReceived |
| SCCS Info :- F:\build\slot1\p800_P\src\lib\comms\amqccita.c, |
| Line Number :- 4309 |
| Build Date :- Feb 17 2015 |
| Build Level :- p800-002-150217.2 |
| Build Type :- IKAP - (Production) |
| UserID :- SWIFTAMHMQ |
| Process Name :- E:\MQServer\IBM\WebSphere MQ\bin64\amqrmppa.exe |
| Arguments :- -m SWIFTBACK
Major Errorcode :- rrcE_BAD_DATA_RECEIVED
| Minor Errorcode :- OK |
| Probe Type :- MSGAMQ9207 |
| Probe Severity :- 2 |
| Probe Description :- AMQ9207: The data received from host '10.51.13.23' on |
| channel '????' is not valid
This is written in FDC file. I couldn't understand what invalid data means. Is it message size or message character?
Is there a message format? What is format and how to check it?
MQ client version 8.0.0.2
It is new issue, previously this channel was working fine, it's production server. After restarting queue manager and application, this issue got resolved.
What formats of messages do we have, can you please explain this?
# Hi all
can any one please help on this,
What formats of messages do we have, can you please explain this?
Related
Trying to build Bitcoin raw transaction for Bitcoin Testnet in Golang, but when trying to send getting an error:
mandatory-script-verify-flag-failed (Script evaluated without error but finished with a false/empty top stack element)
Here is raw transaction:
01000000014071216d4d93d0e3a4d88ca4cae97891bc786e50863cd0efb1f15006e2b0b1d6010000008a4730440220658f619cde3c5c5dc58e42f9625ef71e8279f923af6179a90a0474a286a8b9c60220310b4744fa7830e796bf3c3ed9c8fea9acd6aa2ddd3bc54c4cb176f6c20ec1be0141045128ccd27482b3791228c6c438d0635ebb2fd6e78aa2d51ea70e8be32c9e54daf29c5ee7a3752b5896e5ed3693daf19b57e243cf2dcf27dfe5081cfcf534496affffffff012e1300000000000017a914de05d1320add0221111cf163a9764587c5a171ba8700000000
Tried to debug with btcdeb:
./btcdeb --tx=01000000014071216d4d93d0e3a4d88ca4cae97891bc786e50863cd0efb1f15006e2b0b1d6010000008a4730440220658f619cde3c5c5dc58e42f9625ef71e8279f923af6179a90a0474a286a8b9c60220310b4744fa7830e796bf3c3ed9c8fea9acd6aa2ddd3bc54c4cb176f6c20ec1be0141045128ccd27482b3791228c6c438d0635ebb2fd6e78aa2d51ea70e8be32c9e54daf29c5ee7a3752b5896e5ed3693daf19b57e243cf2dcf27dfe5081cfcf534496affffffff012e1300000000000017a914de05d1320add0221111cf163a9764587c5a171ba8700000000 --txin=02000000000101394187cababd1c18dfc9d30d6325167aa654b1d35505ab77cd1b96562fda5d500000000017160014c0a4f9f451ea319f67c6d2535c1e41bd5d333214feffffff02f009aab80000000017a91455f5b5f3afa4751a54205941a45a14b27ad99be787ec8016000000000017a91435ac960b988964007c167c38ea724e034123e6b1870247304402205d6b22bcaf1a58bc41224eecc7437eef0db9b7e7fb709826314a8bd73adb330702204fbbbd49747d75331a89e2f7b486e0b7a786ecef3229b8e3fec0c4be491921c301210233eab1d60449c393c8f22d4b5d98ee103060d9644dc2af665e607a62e2151bbc30091e00
btcdeb 0.4.21 -- type `./btcdeb -h` for start up options
LOG: sign segwit taproot
notice: btcdeb has gotten quieter; use --verbose if necessary (this message is temporary)
input tx index = 0; tx input vout = 1; value = 1474796
got witness stack of size 0
14 op script loaded. type `help` for usage information
script | stack
-------------------------------------------------------------------+--------
30440220658f619cde3c5c5dc58e42f9625ef71e8279f923af6179a90a0474a... |
045128ccd27482b3791228c6c438d0635ebb2fd6e78aa2d51ea70e8be32c9e5... |
<<< scriptPubKey >>> |
OP_HASH160 |
35ac960b988964007c167c38ea724e034123e6b1 |
OP_EQUAL |
<<< P2SH script >>> |
5128ccd2 |
OP_DEPTH |
OP_SIZE |
OP_NOP4 |
OP_PICK |
28c6c438d0635ebb2fd6e78aa2d51ea70e8b |
OP_UNKNOWN |
#0000 30440220658f619cde3c5c5dc58e42f9625ef71e8279f923af6179a90a0474a286a8b9c60220310b4744fa7830e796bf3c3ed9c8fea9acd6aa2ddd3bc54c4cb176f6c20ec1be01
Can anybody give an advice on where to look at?
Judging from the examples in the btcdeb documentation, you should expect to see a valid script message when starting btcdeb, if the script validates correctly.
btcdeb will still allow you to step through the script with the step command, but because the script is invalid in the first place, this may not tell you much, except that it decides to halt after reaching <<< P2SH script >>>, thinking that is the end of the script.
The most obvious fix should be to remove OP_UNKNOWN, which represents an opcode that was not understood by btcdeb, but there are probably other errors lurking that prevent the script from validating also. You could try removing the end of the script, and building it back up incrementally, testing with the debugger, until it works.
I am using Windows 10 (despite MQ reporting it as Windows 8), the user starting the service is part of mqm group and was the same user used to do all the mq administrative work.
The FDC error file in the qmgr logs is showing these.
+-----------------------------------------------------------------------------+
| |
| IBM MQ First Failure Symptom Report |
| ========================================= |
| |
| Date/Time :- Sun October 04 2020 17:57:20 E. Africa Standard Time |
| UTC Time :- 1601823440.226000 |
| UTC Time Offset :- 180 ((UNKNOWN)) |
| Host Name :- |
| Operating System :- Windows 8 Enterprise x64 Edition, Build 9200 |
| PIDS :- 5724H7251 |
| LVLS :- 9.0.0.0 |
| Product Long Name :- IBM MQ for Windows (x64 platform) |
| Vendor :- IBM |
| O/S Registered :- 1 |
| Data Path :- D:\Installations\IBM\DataFiles\MQ |
| Installation Path :- D:\Installations\IBM\MQ |
| Installation Name :- Installation1 (1) |
| License Type :- Production |
| Probe Id :- ZT473001 |
| Application Name :- MQM |
| Component :- zutUpdateQMXADLLEntry |
| SCCS Info :- F:\build\slot1\p900_P\src\lib\zu\amqzutb0.c, |
| Line Number :- 4718 |
| Build Date :- May 12 2016 |
| Build Level :- p900-L160512.4 |
| Build Type :- IKAP - (Production) |
| UserID :- mquser |
| Process Name :- D:\Installations\IBM\MQ\bin64\strmqm.exe |
| Arguments :- -x -d all IIBQM |
| Addressing mode :- 64-bit |
| Process :- 00013196 |
| Thread :- 00000001 |
| Session :- 00000001 |
| QueueManager :- IIBQM |
| UserApp :- FALSE |
| Last HQC :- 0.0.0-0 |
| Last HSHMEMB :- 0.0.0-0 |
| Last ObjectName :- |
| Major Errorcode :- xecF_E_UNEXPECTED_SYSTEM_RC |
| Minor Errorcode :- OK |
| Probe Type :- MSGAMQ6119 |
| Probe Severity :- 2 |
| Probe Description :- AMQ6119: An internal IBM MQ error has occurred (IIBQM) |
| FDCSequenceNumber :- 0 |
| Arith1 :- 5 5 |
| Comment1 :- IIBQM |
| |
+-----------------------------------------------------------------------------+
The FDC reports that MQ is unable to access somthing (In this case, arith1 == 5 == access denied). The function doing this is trying to update a particular registry key which is outside the MQ tree and which is updated by the MQ installation.
It might potentially be caused if you have configured MQ so the user that the service runs under is not in the local mqm group, although that would not be a good thing, so you might want to fix that. To fix that, you would bring up an elevated (ie use the "run as administrator", not just one where you are logged in as an administrator) command prompt and issue
net localgroup mqm /ADD
Once you have done this, you might need to reboot the machine for it to be effective. Try restarting the service manually once, and if it doesnt help, try the reboot.
I've also seen this problem after a windows update which reset the registry permissions on a key which the MQ installation has previously updated, preventing it being updated when the queue manager starts.
When this occurs, depending on the version of MQ you might also get an error message in the global errors log (and possibly the event log) saying:
AMQ6509E: Unable to update registry value.
EXPLANATION: An attempt was made to update the value of 'WebSphere MQ
QMgr (myqm)' in registry key
'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTC\XADLL' to
'C:\mqinstalls\MQ9120\bin64\amqmtsxatm.dll', however a problem was
encountered when doing so. The system return code was 5. ACTION:
Verify that the permissions on registry key
'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTC\XADLL' allow the
executing user to modify values within it. Executing 'crtmqdir -f -a'
under a local computer administrator user account will restore any
missing permissions required by MQ.
You need to follow the instructions in the error message, ie To fix that, bring up an elevated (ie use the "run as administrator", not just one where you are logged in as an administrator) command prompt and issue
{path to MQ installation}\bin64\crtmqdir -f -a
If your version of MQ does not have such a binary, manually browse in regedit to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTC\XADLL and right mouse button on XADLL->permissions and give mqm rights to query and set values for that key.
In order to check that all the servers across a fleet aren't supporting deprecated algorithms, I'm (programmatically) doing this:
telnet localhost 22
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
SSH-2.0-OpenSSH_8.0p1 Ubuntu-6build1
SSH-2.0-Censor-SSH2
4&m����&F �V��curve25519-sha256,curve25519-sha256#libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1Arsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519lchacha20-poly1305#openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm#openssh.com,aes256-gcm#openssh.comlchacha20-poly1305#openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm#openssh.com,aes256-gcm#openssh.com�umac-64-etm#openssh.com,umac-128-etm#openssh.com,hmac-sha2-256-etm#openssh.com,hmac-sha2-512-etm#openssh.com,hmac-sha1-etm#openssh.com,umac-64#openssh.com,umac-128#openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1�umac-64-etm#openssh.com,umac-128-etm#openssh.com,hmac-sha2-256-etm#openssh.com,hmac-sha2-512-etm#openssh.com,hmac-sha1-etm#openssh.com,umac-64#openssh.com,umac-128#openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1none,zlib#openssh.comnone,zlib#openssh.comSSH-2.0-Censor-SSH2
Connection closed by foreign host.
Which is supposed to be a list of supported algorithms for the various phases of setting up a connection. (kex, host key, etc). Every time I run, I get a different piece of odd data at the start - always a different length.
There's an nmap plugin - ssh2-enum-algos - which returns the data in it's complete form, but I don't want to run nmap; I have a go program which opens the port, and sends the query, but it gets the same as telnet. What am I missing, and how do I fix it?
For comparison, here's the top few lines from the output of nmap script:
$ nmap --script ssh2-enum-algos super
Starting Nmap 7.80 ( https://nmap.org ) at 2019-12-27 22:15 GMT
Nmap scan report for super (192.168.50.1)
Host is up (0.0051s latency).
rDNS record for 192.168.50.1: supermaster
Not shown: 998 closed ports
PORT STATE SERVICE
22/tcp open ssh
| ssh2-enum-algos:
| kex_algorithms: (12)
| curve25519-sha256
| curve25519-sha256#libssh.org
| ecdh-sha2-nistp256
| ecdh-sha2-nistp384
| ecdh-sha2-nistp521
Opening a tcp connection to port 22, (in golang, with net.Dial) then accepting and sending connection strings leaves us able to Read() from the Reader for the connection. Thence the data is in a standard format described by the RFC. From this, I can list the algorithms supported in each phase of an ssh connection. This is very useful for measuring what is being offered, rather than what the appears to be configured (it's easy to configure sshd to use a different config file).
It's a useful thing to be able to do from a security POV.
Tested on every version of ssh I can find from 1.x on a very old solaris or AIX box, to RHEL 8.1.
In some cases you can specify an algorithm to use, and if you specify one that is not supported the server will reply with a list of supported algorithms.
For example, to check for supported key exchange algorithms you can use:
ssh 127.0.0.1 -oKexAlgorithms=diffie-hellman-group1-sha1
diffie-hellman-group1-sha1 is insecure and should be missing from most modern servers. The server will probably respond with something like:
Unable to negotiate with 127.0.0.1 port 22: no matching key exchange method found. Their offer: curve25519-sha256,curve25519-sha256#libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256
Exit 255
Typing: "ssh -Q cipher | cipher-auth | mac | kex | key"
will give you a list of the algorithms supported by your client
Typing: "man ssh"
will let you see what options you can specify with the -o argument, including Cipher, MACs, and KexAlgorithms
I have an XMEGA-A1 Xplained and a JTAG ICE mkII. I just tried to use avrdude on Linux. The first thing I did was to try to set the JTAG fuse off to use PDI (since the Hardware User's Guide said JTAG and PDI can't be used together - section 9.3), but now all I have is 8 rapidly flashing LEDs and no ability to communicate with the device. The LED by the USB connector is solid green/red, though the red flashes when you replug the USB. If I press SW0, the LEDs stop flashing, but they start again as soon as I let go, and pressing any of the 7 other buttons seems to have no effect.
When I try to communicate with the device now, all I get is:
$ avrdude -p x128a1 -c jtag2pdi -P usb -v
avrdude: jtagmkII_setparm(): bad response to set parameter command: RSP_FAILED
avrdude: jtagmkII_close(): bad response to GO command: RSP_ILLEGAL_EMULATOR_MODE
avrdude done. Thank you.
If I use jtag2slow (which worked before), I get:
avrdude: jtagmkII_setparm(): bad response to set parameter command: RSP_FAILED
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.
avrdude: jtagmkII_close(): bad response to GO command: RSP_ILLEGAL_EMULATOR_MODE
avrdude done. Thank you.
The command I used to set the fuses was taken from what Eclipse generated: -Ufuse4:w:0x1:m
Is there a way to "break into" the device and re-establish communication?
This was caused by a failure of the JTAGICE mkII to communicate over the PDI connection due to a bad connection in the (homemade) squid cable. I made a new one and all is OK. It took a bit of messing around to work out the right connections again, since no-one seems to have put the two connection tables together (i.e. the "Connecting to a PDI target" in AVR Help and "Table 4.1: Programming Headers" in the Xplained user Guide), my squid cable is all grey, and I disconnected it before writing down the connections (don't do this!). So, here it is.
How to connect XMega-A1 Xplained via PDI with JTAGICE mkII
------------------------------------------------------
| JTAGICE mkII | XMEGA-A1 Xplained |
|--------------------------------+-------------------|
| Pin | JTAG Name | Squid Colour | Pin | PDI Name |
|-----------------+--------------+-------------------|
| 2 | GND | White | 2 | GND |
| 4 | VTref | Purple | 4 | VCC |
| 6 | nSRST | Green | 6 | PCI_CLK |
| 9 | TDI | Red | 3 | PDI_DATA |
------------------------------------------------------
Setting fuses
This is mentioned in the documentation, but it's worth repeating here: once you set the JTAGEN fuse to 1 (i.e. disable JTAG) the only way to get back to JTAG is to make a PDI connection and set the fuse back to 0.
Be very careful when setting the fuse if you can't program by PDI, as if you set fuse byte 4 to 0x01, as well as setting JTAGEN, you will also disable external reset (bit 4) and be unable to use ISP programming. If you look above, you will see this is what I did.
Apparently, not all JTAGICE mkII's can do PDI (mine can), so make sure before you blow this fuse!
I had the same problem and it was induces because I was flashing the .elf file instead the .hex.
To solve it I did the next:
Disconnect the xplained usb cable in order to Unpowered the micro.
Reconnect the USB cable and as fast as you can send the command to reprogramm the micro. If someone can help is better.
It worked for me.
I want to load files in the file system to a WebSphere MQ Queue. There are couple of support pacs - Q Program and MO03: WebSphere MQ Queue Load / Unload Utility
that come close but they mandate the files to be in a specific format. I have the messages which are XML files and want a quick way to load them to a queue. The number of files run into a few hundred so looking for an utility to do this job instead of having to write an application to achieve this.
I could not locate some general purpose application to achieve this. So looking for some help here
Thanks
Why do you believe that the Q program requires a specific file format? According to the README.TXT file, the following options are available:
-f<filename>
Input file.
Each line of the file will be put to output queue as a different
message.
See "Z/OS FILE NAME FORMAT EXAMPLES" for specific z/OS details.
-F[+]<filename>
Input/output file.
Entire file will be put to the output queue as a single message.
If '+' is specified the dataset attributes will be retained if
the output dataset exists - z/OS only.
See "Z/OS FILE NAME FORMAT EXAMPLES" for specific z/OS details.
So if you specify -F (without the +) all lines in the the XML file are loaded into a single message. You can also specify the message options using the -a parameter:
-a<Opts> Sets message attributes when put to the output queue
n - forces non-persistence
p - forces persistence
q - uses queue default persistence
d - put a datagram message type
r - put a reply message type
R - put a request message type
t - put a report message type
x - don't treat lines starting with '#' as special
Although the Q program will interpret files by default, note that the -ax option above tells it to ignore lines with # which it would ordinarily interpret as commands. This allows you to load XML files or source code with comments or even binary files such as a PDF or JPG.
Was there a specific limitation in Q that you are unable to work with? If so, it would be helpful to know what that is so we might point you to something that would better fit your purpose.
UPDATE
Responding to Spyro's comments, Q is not limited to 1000 characters. Here's an example where the README file from the Q distribution is written to a single message and read back.
D:\WMQ\MA01>q -m JMSDEMO -OSYSTEM.DEFAULT.LOCAL.QUEUE -FREADME
MQSeries Q Program by Paul Clarke [ V6.0.0 Build:May 1 2012 ]
Connecting ...connected to 'JMSDEMO'.
D:\WMQ\MA01>echo dis q(SYSTEM.DEFAULT.LOCAL.QUEUE) curdepth | runmqsc JMSDEMO
5724-H72 (C) Copyright IBM Corp. 1994, 2011. ALL RIGHTS RESERVED.
Starting MQSC for queue manager JMSDEMO.
1 : dis q(SYSTEM.DEFAULT.LOCAL.QUEUE) curdepth
AMQ8409: Display Queue details.
QUEUE(SYSTEM.DEFAULT.LOCAL.QUEUE) TYPE(QLOCAL)
CURDEPTH(1)
One MQSC command read.
No commands have a syntax error.
All valid MQSC commands were processed.
D:\WMQ\MA01>q -m JMSDEMO -dl -iSYSTEM.DEFAULT.LOCAL.QUEUE
MQSeries Q Program by Paul Clarke [ V6.0.0 Build:May 1 2012 ]
Connecting ...connected to 'JMSDEMO'.
MQGET 24309 bytes
============================================================================
Message Descriptor (MQMD)
Report :00000000
Message Type :8 (Datagram)
Format :'MQSTR '
Priority :0
Persistence :0 (Not Persistent)
Message Id :A M Q J M S D E M O . . . R . * .
414D51204A4D5344454D4F20202020201DDEA052200B2A02
'AMQ JMSDEMO ...R .*.'
ReplyToQ :' '
ReplyToQMgr :'JMSDEMO '
----------------------------------------------------------------------
| |
| |
| DESCRIPTIVE NAME WebSphere MQ Q Program |
| |
------- 8><-------------------------------------------------------------
REMAINDER OF MSG OUTPUT OMITTED FOR BREVITY. PRINT-OUT RESUMES...
------- 8><-------------------------------------------------------------
No more messages.
D:\WMQ\MA01>
Note the header lines where the message was printed. The -dl option tells Q to print the message length which, in this case, was 24309 bytes. I downloaded the current version to perform this test so this is accurate as of 7 December 2013.
If you are looking for loading the file to queue.. Its easy to work with RFHUtil s/w or application.
In RFHUtil you can easily load the file to MQ and clear the Queue, purge ect...
Many more options are provided .