We Keep Coding

What is the purpose of setting QueueManager property for IBM MQ?

Following this example of sending messages to queue let's look at the part of setting connection factory properties
cf.setStringProperty(WMQConstants.WMQ_HOST_NAME, HOST);
cf.setIntProperty(WMQConstants.WMQ_PORT, PORT);
cf.setStringProperty(WMQConstants.WMQ_CHANNEL, CHANNEL);
cf.setIntProperty(WMQConstants.WMQ_CONNECTION_MODE, WMQConstants.WMQ_CM_CLIENT);
cf.setStringProperty(WMQConstants.WMQ_QUEUE_MANAGER, QMGR);
cf.setStringProperty(WMQConstants.WMQ_APPLICATIONNAME, "JmsPutGet (JMS)");
cf.setBooleanProperty(WMQConstants.USER_AUTHENTICATION_MQCSP, true);
cf.setStringProperty(WMQConstants.USERID, APP_USER);
cf.setStringProperty(WMQConstants.PASSWORD, APP_PASSWORD);
When the line cf.setStringProperty(WMQConstants.WMQ_QUEUE_MANAGER, QMGR); is removed then nothing changes: the client still can successfully send and receive messages.
What is the purpose of setting WMQConstants.WMQ_QUEUE_MANAGER property here?
IBM MQ server is a container based on this Dockefile:
FROM ibmcom/mq:9.2.2.0-r1
ENV LICENSE=accept
ENV MQ_DEV=true
ENV MQ_APP_PASSWORD=app-password
ENV MQ_ADMIN_PASSWORD=admin-pwd
ENV MQ_QMGR_NAME=KUPOL_DEV_QM
Additionally:
In the same example we see the line
destination = context.createQueue("queue:///" + QUEUE_NAME)
and it does not break the app if the prefix "queue:///" is removed, leaving the line as
destination = context.createQueue(QUEUE_NAME).
And I see similar things in multiple examples for IBM MQ across the web.
What is going on with this code? Is it blind copy-pasting or is there an intention?

If you leave queue manager unset or specify a value that is prefixed with a * you can connect to any queue manager name listening on the host and port you specify.
If you specify a queue manager name that is not prefixed with a * then it must match the name of the queue manager listening on the host and port.
You can also use a CCDT to hold the the connection details, in this case (in addition to the above points) the queue manager name you specify is used to look up the connection details in the CCDT. If it is prefixed with a * it will look up the name without the * in the CCDT.
In addition to specifying queue names with the queue:/// prefix, you can also specify topics with the prefix topic:///, my guess is createQueue defaults to assume you are specifying a queue name.

Your sample code appears to be JMS. IBM MQ supports a couple of addressing models for queues.
All three of these mean the same thing:
context.createQueue("MY.QUEUE");
context.createQueue("queue://MY.QUEUE");
context.createQueue("queue:///MY.QUEUE");
However, with the triple-slash you can also fully-qualify REMOTE queues
context.createQueue("queue://QMGRB/MY.OTHER.QUEUE");
This tells IBM MQ to send the message to the QMgr and have it deliver the message to the Remote Queue 'MY.OTHER.QUEUE' on 'QMGRB'.
Note: IBM MQ also supports destination options, so you can modify persistence, priority, character encoding, targetClient, etc. This is useful so you can externalize the configuration and change the message pattern without having to change the code!
ref: https://www.ibm.com/docs/en/ibm-mq/9.0?topic=applications-creating-destinations-in-jms-application

How to write java code for file transfer to IBM MQ preserving the file name

I am trying to write a script in java to automatically do the file transfer to IBM MQ. Note, that even if I get the message on the other end, I still want that message to preserve the original file name.
Basically, I want the equivalent of this command prompt in java:
-bash-4.1$ /opt/mqm/java/jre64/jre/bin/java -jar imqsput.jar --channel=REMOTE.ADMIN.... --host=.... --input=test/20190918_153009858_Test.txt --manager=... --port=1414 --queue=... &>> testoutput1.out
The file name must be preserved in this case as it is read by the app from the message later.
So far I've got something standard like this:
import javax.jms.Connection;
import javax.jms.Session;
import javax.jms.Message;
import javax.jms.MessageProducer;
import com.ibm.jms.*;
import com.ibm.mq.jms.*;
MQConnectionFactory factory = new MQConnectionFactory();
factory.setHostName("tcp://.......");
factory.setPort(1414);
factory.setQueueManager(".......");
factory.setChannel("REMOTE.ADMIN........");
Connection connection = factory.createConnection("......", "........");
Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
String content=vars.get("processedTestData");
MQQueue queue = (MQQueue) session.createQueue("queue:///.......");
MessageProducer producer = session.createProducer(queue);
Message message = session.createTextMessage(content);
producer.send(message);
connection.close();
But instead of String content I want to send a file in the same way as the imqsput does. Any way of doing it in java?
Description for the imqsput:
IMQsPUT allows loading files into IBM message queues.
-c,--channel <CHANNEL> The channel used to access the
queue. Alternatively can be
replaced by specifying a client
definition.
--ccsid <CCSID> The target encoding/charset/ccsid
to be used for messages being
written to the queue. The default
is '1208'.
The following CCSIDs can be used:
http://www-01.ibm.com/software/glo
balization/ccsid/ccsid_registered.
html
--charset <CHARSET> The charset to be used for reading
input files. The default is
'UTF-8'. The following values are
valid: 'US-ASCII', 'ISO-8859-1',
'UTF-8', 'UTF-16BE', 'UTF-16LE',
'UTF-16'.
--cipher-suite <SUITE> The cipher suite for the secure
connections.
-d,--definition <URL> URL to the client channel
definition (CCDT). Must include
the protocol like file:///. If
this is not set, then the host,
post and channel parameters must
be set.
-h,--host <HOST> The hostname/IP address of the
machine hosting the queues.
-i,--input <FILE1/PATH1,FILE2/PATH2> A comma separated list of files
and directories which should be
loaded onto the queue.
--keystore-file <FILE> Sets the keystore, used for secure
connections.Establishes a secure
connection to the queue.
--keystore-password <PASSWORD> Optional password for the keystore
to be used with the
--keystore-file option.
-m,--manager <MANAGER> The name of the queue manager.
Alternatively can be replaced by
specifying a client definition.
-p,--port <PORT> The port used to access the queue
manager. If not set 1414 is used.
Alternatively can be replaced by
specifying a client definition.
-q,--queue <QUEUE> The name of the Queue.
-r,--remove-original Deletes the original input file
when it was successfully written
to the queue.
-R,--rename-failed <EXTENSION> When set, files which failed to
transmit will be renamed by
appending the given extension to
the filename. Files which already
have this extension will not be
processed again (only relevant
when transmitting a folder).
--ssl-debug If this is enabled, then a SSL
trace will be generated.
--truststore-file <FILE> Sets the truststore, used for
secure connections.
--truststore-password <PASSWORD> Optional password for the
truststore to be used with the
--truststore-file option
-u,--unique-message-id When set, the message ID is set to
a randomly generated String,
otherwhise, the filename is used.
Class diagram for imqsput

PCFMessageAgent - Authentication

How does the PCFMessageAgent with the following constructor gets authenticated. What are the user/configuration permissions required to be set. I connect to MQ of version 8.0.0.4.
public PCFMessageAgent(java.lang.String host,
int port,
java.lang.String channel)
throws MQException

You do not provide enough details to give an exact answer. That constructor does not allow for authentication, it connects to the host/port/channel specified but does not pass a username/password or allow for the use of a cetificate.
If the channel on the queue manager does not require CONNAUTH (ex: "CHKCLNT(OPTIONAL)") or TLS (ex: SSLCIPH/SSLPEER) and you are not blocked by CHLAUTH rules, you may be able to connect.
To determine what user MQ would use for authorization would depend on what user your java process is running under, the MCAUSER attribute of the channel, and any CHLAUTH rules that could map you to a different MCAUSER. Based on the final MCAUSER value, MQ would check if you have permission to the SYSTEM.ADMIN.COMMAND.QUEUE and the model queue used to create a temporary dynamic queue for replies.
If you want to provide a username and password or use certificates you would need to create a MQQueueManager and pass this instead of host/port/channel using this constructor:
PCFMessageAgent(MQQueueManager qmanager)
Initializes a new PCFMessageAgent with an existing queue manager connection.

can't connect to MQ from java in windows

I have installed Websphere MQ 8 server in my Windows 8,
using MQ Explorer :
I created a queue manager MAJID.QUEUE.MANAGER with port 1419.
I created a TCP listener on port 1419.
I tried one of the java programs that Tools from MQ8 installation, it runs like this :
PCF_ListQueueNames MAJID.QUEUE.MANAGER 10.196.67.99 1419
but I only got :
Completion Code '2', Reason '2035'.
UPDATE:
the log file says :
AMQ9777: Channel was blocked
EXPLANATION:
The inbound channel 'SYSTEM.DEF.SVRCONN' was blocked from address 'ITD- 968735
(192.168.56.1)' because the active values of the channel matched a record
configured with USERSRC(NOACCESS). The active values of the channel were
'CLNTUSER(alotfi) ADDRESS(ITD-968735)'.
ACTION:
Contact the systems administrator, who should examine the channel
authentication records to ensure that the correct settings have been
configured. The ALTER QMGR CHLAUTH switch is used to control whether channel
authentication records are used. The command DISPLAY CHLAUTH can be used to
query the channel authentication records.
----- cmqxrmsa.c : 1461 -------------------------------------------------------
1/13/2016 15:55:13 - Process(9988.27) User(MUSR_MQADMIN) Program(amqrmppa.exe)
Host(ITD-968735) Installation(Installation1)
VRMF(8.0.0.4) QMgr(MAJID.QUEUE.MANAGER)
AMQ9999: Channel 'SYSTEM.DEF.SVRCONN' to host '192.168.56.1' ended abnormally.
EXPLANATION:
The channel program running under process ID 9988(8292) for channel
'SYSTEM.DEF.SVRCONN' ended abnormally. The host name is '192.168.56.1'; in some
cases the host name cannot be determined and so is shown as '????'.

There is a great MQ security blog article which describes how to configure MQ to let clients connect securely (i.e. without just turning the security features off).
However to address your specific question, the default channel authentication rules for new MQ 8 queue managers prevent client connections to the queue manager via SYSTEM.* channels. If you run DIS CHLAUTH(*) ALL on a new MQ 8 queue manager you'll see:
DIS CHLAUTH(*) ALL
2 : DIS CHLAUTH(*) ALL
AMQ8878: Display channel authentication record details.
CHLAUTH(SYSTEM.ADMIN.SVRCONN) TYPE(ADDRESSMAP)
DESCR(Default rule to allow MQ Explorer access)
CUSTOM( ) ADDRESS(*)
USERSRC(CHANNEL) CHCKCLNT(ASQMGR)
ALTDATE(2016-01-14) ALTTIME(16.15.20)
AMQ8878: Display channel authentication record details.
CHLAUTH(SYSTEM.*) TYPE(ADDRESSMAP)
DESCR(Default rule to disable all SYSTEM channels)
CUSTOM( ) ADDRESS(*)
USERSRC(NOACCESS) WARN(NO)
ALTDATE(2016-01-14) ALTTIME(16.15.20)
AMQ8878: Display channel authentication record details.
CHLAUTH(*) TYPE(BLOCKUSER)
DESCR(Default rule to disallow privileged users)
CUSTOM( ) USERLIST(*MQADMIN)
WARN(NO) ALTDATE(2016-01-14)
ALTTIME(16.15.20)
The second rule prevents all client connections to channels named SYSTEM.*. This applies to you because you are connecting to SYSTEM.DEF.SVRCONN.
You probably want to define a new SVRCONN channel for your application to connect to and use that instead of SYSTEM.DEF.SVRCONN.
When defining a new channel MQ security best practice is to set the MCAUSER field of the channel to a user that doesn't exist - for example 'nobody'. You can then define a new channel authentication rule that allows your Java application to adopt the user ID you have chosen instead of the default user 'nobody'. The rule could for example be an ADDRESSMAP rule that allows any clients connecting from a specific IP address to connect to the new channel and to adopt the user ID you have chosen.
In summary:
1) Choose a valid user that exists on your system (but that isn't in the 'mqm' group)
2) Define a new non-SYSTEM channel, with MCAUSER set to 'nobody', e.g.
DEFINE CHANNEL(MY.FIRST.CHANNEL) CHLTYPE(SVRCONN) MCAUSER('nobody')
3) Define a new channel auth rule that allows connections from the IP address of you client, and adopts the user you have defined, e.g.
SET CHLAUTH(MY.FIRST.CHANNEL) TYPE(ADDRESSMAP) ADDRESS('192.168.56.1') USERSRC(MAP) MCAUSER('validuser') ACTION(REPLACE)
You will have one further step to perform. You need to tell MQ that 'validuser' is allowed to connect, put, and/or get messages. You can use SET AUTHREC to define the authorities the client should have. See the KnowledgeCenter for the valid AUTHREC options.
The above is an example of how to configure MQ to let your client connect. You should use a combination of blog articles like the one I've linked to and the KnowledgeCenter to set up your security in the way want. For example you might want to use TLS certificates to authenticate your Java client which I haven't described above.

How do I communicate with a specific process in one Erlang node?

I have an Erlang server which is spawning a new process for each client that connects. Then the Pid of this new process is passed to the client (to make a connection to the new process.) Is that enough to make a connection from a jinterface client?
I am using this to connect from the client first:
final String SERVERNAME = "server";
final String SERVERNODE = "bertil#computer";
mbox.send(SERVERNAME, SERVERNODE, connectClient);
And those names is set in the server when it starts:
start() ->
net_kernel:start([bertil, shortnames]),
register(server, self()).
Do I have to register a new name for each spawned process? That would not be so dynamic... How do I solve this? Should I use the main process at the server as a router to send all traffic through?

Once you have a pid, you should be able to send a message directly to it. In Erlang you don't have to specify a node if you got a pid. You only need a node if you are sending to a registered name since names are only unique per nod. Pids are unique in the whole cluster.
If you have a varable my_pid as an OtpErlangPid object you can send like so:
mbox.send(my_pid, message);
See the documentation for the send function and chapter 1.6 Sending and Receiving Messages in the Jinterface User's Guide.