WAS - pmt.sh 沒有任何回應

WAS pmt.sh 執行後無任何反應

ENV:

Centos Stream 9 

WAS v8.5.5.18

Problem:

pmt.sh 執行後無任何反應, 並未如預期起動

Solution:

https://yummy-mint-210.notion.site/WAS-pmt-sh-b780a8dd34844f0aab9a536449ccdc3e?pvs=4

How to get the last column by Linux command

 A.txt

+++ begin A.txt +++ 

ABC/123/xyz

DEF/456/uvw

+++ end A.txt +++

Would like to get the last column: ( / as the delimiter)

expect output:

xyz

uvw

Method 1: 

awk -F"/" '{print $NF} A.txt

Method 2:

rev A.txt|cut -d '/' -f 1|rev

Method 3:

grep -o '[^/]*$' A.txt

Method 4:

perl -pe 's/(.*)\/(.*)$/$2/' A.txt

ref:

https://stackoverflow.com/questions/22727107/how-to-find-the-last-field-using-cut

鹹粥

• 材料﹕
• 白米一杯
• 香菇 2 ~3 朵
• 青蔥 - 切蔥花(綠色)和小段(白色)
• 豬肉少許切絲
  
  
•  作法﹕
• 1. 白米一杯加入7杯水(量米杯), 加入鍋中煮, 要攪拌避免白米在鍋底燒焦
• 2. 香菇
• 泡水15分鐘至軟
• 擠乾水
• 加少許塩
• 切細絲
• 3. 爆香:
• 先放入油
• 加入香菇
• 加入白色小段蔥
• 將香菇和蔥放鍋邊
• 再加入肉絲, 炒至變白色
• 加入醬油
• 全部一起拌炒
• 加入少許水炒均勻
  
• 4. 將爆香完的料加入白飯中, 一起煮, 約25分左右
• 5. 上桌前2分鐘加入蔥花後,即可完成

how to make such video

Now, I get it!!  


complete:

https://www.youtube.com/watch?v=kBF6Bvth0zw


how to make it:
https://www.youtube.com/post/Ugzf5SL_yh9NglCJzgF4AaABCQ

IBM Cloud
6 個月前
Since the launch of the New Builders light board video series, we've received a lot of questions about exactly how we did it.

We decided to pull back the curtain and answer your questions about this successful series.

1. No, the speaker doesn’t write backwards. We flip the video horizontally in post-production.(see the photo of our set below)

2. No, there are no mirrors involved - it does look backwards, but ... (see #1)

3. We just use standard fluorescent markers. No lasers or light-up pens, sorry.

4. The light comes from LEDs in a strip around the edge of the glass within the frame.

Below is a behind-the-scenes photo of one of our speakers, Sai Vennam, on set in our  Austin, TX studio. 

We hope this answers your questions. If you have more, please comment below.

To check out the entire New Builders video playlist, visit: https://ibm.co/2Z5XKLb

How to check and modify pids.max of user

1. find out the cgroup of the user

#echo $$|xargs -I '$' cat '/proc/$/cgroup'

/user.slice/user-1000.slice is the cgroup of the user

2. check the pids.max (TasksMax) setting for the user
(1) method 1:
#cgget -a /user.slice/user-1000.slice

(2) method 2:
#cat /sys/fs/cgroup/pids/user.slice/user-1000.slice/pids*

3. modify the pids.max
# systemctl set-property user-1000.slice TasksMax=512

4. verify (using python script)

import time
import threading

def worker():
    while True:
        time.sleep(1000)
        

threads = []
num_worker_threads = 19000
for i in range(num_worker_threads):
    t = threading.Thread(target=worker)
    try:
        t.start()
        threads.append(t)
        print(i)
    except:
        print("EX")
        time.sleep(2000)

for t in threads:
    t.join()

python script:
https://zhuanlan.zhihu.com/p/29192624

cgroup information:
https://access.redhat.com/documentation/zh-tw/red_hat_enterprise_linux/6/html/resource_management_guide/sec-obtaining_information_about_control_groups

xargs:
https://superuser.com/questions/401614/inserting-string-from-xargs-into-another-string

Access control for the multiple cluster transmission queue

https://www.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.con.doc/q017170_.htm

Choose between three modes of checking when an application puts messages to remote cluster queues. The modes are checking remotely against the cluster queue, checking locally against SYSTEM.CLUSTER.TRANSMIT.QUEUE, or checking against local profiles for the cluster queue, or cluster queue manager.

IBM® WebSphere® MQ gives you the choice of checking locally, or locally and remotely, that a user has permission to put a message to a remote queue. A typical IBM WebSphere MQ application uses local checking only, and relies on the remote queue manager trusting the access checks made on the local queue manager. If remote checking is not used, the message is put to the target queue with the authority of the remote message channel process. To use remote checking you must set the put authority of the receiving channel to context security.

The local checks are made against the queue that the application opens. In distributed queueing, the application usually opens a remote queue definition, and access checks are made against the remote queue definition. If the message is put with a full routing header, the checks are made against the transmission queue. If an application opens a cluster queue that is not on the local queue manager, there is no local object to check. The access control checks are made against the cluster transmission queue, SYSTEM.CLUSTER.TRANSMIT.QUEUE. Even with multiple cluster transmission queues, from Version 7.5, local access control checks for remote cluster queues are made against SYSTEM.CLUSTER.TRANSMIT.QUEUE.

The choice of local or remote checking is a choice between two extremes. Checking remotely is fine-grained. Every user must have an access control profile on every queue manager in the cluster to put to any cluster queue. Checking locally is coarse-grained. Every user needs only one access control profile for the cluster transmission queue on the queue manager they are connected to. With that profile, they can put a message to any cluster queue on any queue manager in any cluster.

Since Version 7.1, administrators have another way to set up access control for cluster queues. You can create a security profile for a cluster queue on any queue manager in the cluster using the setmqaut command. The profile takes affect if you open a remote cluster queue locally, specifying only the queue name. You can also set up a profile for a remote queue manager. If you do so, the queue manager can check the profile of a user that opens a cluster queue by providing a fully qualified name.

The new profiles work only if you change the queue manager stanza, ClusterQueueAccessControl to RQMName. The default is Xmitq. You must create profiles for all the cluster queues existing applications use cluster queues. If you change the stanza to RQMName without creating profiles the applications are likely to fail.

ClusterQueueAccessControl usage and its implications

https://www.ibm.com/developerworks/community/blogs/messaging/entry/ClusterQueueAccessControl_usage_and_its_implications?lang=en

From MQ 7.1 onwards, there is a new option made available for the users who can access cluster queue even though they do not have access to SYSTEM.CLUSTER.TRANSMIT.QUEUE. This is made possible with the introduction of ClusterQueueAccessControl attribute in the Security stanza of the qm.ini file.

The ClusterQueueAccessControl attribute takes two values, Xmitq or RQMName. The default value is Xmitq and the behavior is same as seen in previous versions where the access to remote cluster queues gets resolved to the access of the SYSTEM.CLUSTER.TRANSMIT.QUEUE. By setting the ClusterQueueAccessControl to RQMName, the profiles of remote cluster queues will be resolved to locally defined profiles of named queues or named queue manager.

Consider two Qmgrs QM1 & QM2 are part of cluster CLUS1

Create a queue on QM2 and make it part of cluster CLUS1.

  DEFINE QL(MYQ) CLUSTER(CLUS1)

A user who is part of a group called dev_group connects to Qmgr QM1 and wants to put a message to the cluster queue MYQ. By either creating a local named queue profile and giving the user put access on it or by creating a local named queue manager profile and then giving it the required access, the user will be able to put message to the remote cluster queue even though he does not have access over SYSTEM.CLUSTER.TRANSMIT.QUEUE.

1. By creating queue profile :

setmqaut -m QM1 -t queue -n MYQ -g dev_group +putamqsput MYQ QM1

2. By creating queue manager profile :

setmqaut -m QM1 -t rqmname -n QM2 -g dev_group +putamqsput MYQ QM1 8208 0 QM2

qm.ini:

Security:      ClusterQueueAccessControl=RQMName

disable firewall and selinux in CentOS 7

Linux init configuration for test MQ

1. disable selinux
vi /etc/selinux/config
SELINUX=disabled

=> reboot

2. disable firewall
systemctl stop firewalld.service (one time)
systemctl disable firewalld.service (all time)



https://www.opencli.com/linux/centos-7-disable-firewalld-selinux

How to reformat MQ error message

The content of the MQ error log is as following:

12/08/2018 08:21:42 AM - Process(16535.4) User(root) Program(amqzmur0)
                    Host(love) Installation(Installation1)
                    VRMF(8.0.0.9) QMgr(QM2)
                 
AMQ6287: WebSphere MQ V8.0.0.9 (p800-009-180321.1).

EXPLANATION:
WebSphere MQ system information:
Host Info         :- Linux 2.6.32-696.13.2.el6.x86_64 (MQ Linux (x86-64
platform) 64-bit)
Installation      :- /opt/mqm (Installation1)
Version           :- 8.0.0.9 (p800-009-180321.1)
ACTION:
None.
-------------------------------------------------------------------------------
12/08/2018 08:21:41 AM - Process(30069.1) User(root) Program(runmqchl)
                    Host(love) Installation(Installation1)
                    VRMF(8.0.0.9) QMgr(QM2)
                 
AMQ9213: A communications error for TCP/IP occurred.

EXPLANATION:
An unexpected error occurred in communications.
ACTION:
The return code from the TCP/IP (connect) call was 113 (X'71'). Record these
values and tell the systems administrator.
----- amqccita.c : 1278 -------------------------------------------------------
12/08/2018 08:21:41 AM - Process(30069.1) User(root) Program(runmqchl)
                    Host(love) Installation(Installation1)
                    VRMF(8.0.0.9) QMgr(QM2)
                 
AMQ9999: Channel 'QM2.V9QM2' to host '192.168.136.123(1415)' ended abnormally.

EXPLANATION:
The channel program running under process ID 30069 for channel 'QM2.V9QM2'
ended abnormally. The host name is '192.168.136.123(1415)'; in some cases the
host name cannot be determined and so is shown as '????'.
ACTION:
Look at previous error messages for the channel program in the error logs to
determine the cause of the failure. Note that this message can be excluded
AMQERR01.LOG


However I would like to reformat the error log as following:

12/08/2018 08:21:42 AM AMQ6287: WebSphere MQ V8.0.0.9 (p800-009-180321.1).
12/08/2018 08:21:41 AM AMQ9213: A communications error for TCP/IP occurred.
12/08/2018 08:21:41 AM AMQ9999: Channel 'QM2.V9QM2' to host '192.168.136.123(1415)' ended abnormally.

Only grep is not enough to handle, we must ask help from 'sed"

grep -o -E ".*[0-9]{2}:[0-9]{2}:[0-9]{2}\ [A,P]{,1}[M]{,1}[:space:]{,1}|AMQ[0-9]{4}:.*" AMQERR01.LOG|sed '$!N;s/\n/\ /'

grep:

-o: only print the match string
*** AIX 上的opensoure grep 要用[[:space:]]

sed:

N means read the next line (可用來合併二行)
$!N means read the next line unless it is the last line (最後一行不做)

sed   N和$!N 的理解使用

https://blog.51cto.com/goome/1749171

How to do Cold Restart of Queue Manager ?

How to do Cold Restart of Queue Manager ? (or) How to replace the Corrupted Queue Manager logs ?
on June 09, 2014

The following steps are required to cold start MQ on Linux:
 
Replacing Corrupted logs of a QMGR:


1. Delete all current queue manager logs:                                                                                             

mqm@mqm:~> cd /                                                                                                         
mqm@mqm:~> cd /var/mqm/log/OLDQMGR                                                                 
mqm@mqm:~> rm -r *                                                                                                     
                 
2. Create a DUMMY queue manager: 

(Note:  LOG PROPERTIES MUST MATCH OLDQMGR!!!)

If the corrupted QMGR logs looks like below:

   LogPrimaryFiles=55           -lp
   LogSecondaryFiles=2         -ls
   LogFilePages=16384          -lf
   LogType=LINEAR             -ll

Command to duplicate it:

mqm@mqm:~> crtmqm –lp 55 –ls 2 –lf 16384 -ll DUMMY

This might take little time.                                                           

Note: DON'T START the dummy qmgr once it is done.
                                                                                                                                   
3. Move file (amqhlctl.lfh) and directory (active) under:

/var/mqm/log/DUMMY into /var/mqm/log/OLDQMGR                                                                                                                                                                                                                 
mqm@mqm:~> mv /var/mqm/log/DUMMY/*
       
/var/mqm/log/OLDQMGR                                                 
                                                                                                                                   
4. Restart your QMGR:

Note: make sure all qmgr related processes are down:

ps –ef | grep  <qmgrname >

If you see some process still running Kill it with process id just like below:

kill –9 pid                                                                                                     

mqm@mqm:~> strmqm OLDQMGR

                                                                                                                                   
5. Delete the dummy QMGR:
                                                                                                                                   
       mqm@mqm:~> dltmqm DUMMY

Since the logs been replaced, We lost all information to commit or backout messages but all persistent messages are still in the queues (you don't lose persistent messages).


ref:

https://webspheremqadministrator.blogspot.com/2014/06/how-to-do-cold-restart-of-queue-manager.html

Find out which process is using a port in Linux

1. netstat
# netstat -tuplna|grep port_number
[root@love ~]# netstat -tuplan|grep 1477
tcp        0      0 :::1477                     :::*                        LISTEN      12129/runmqlsr
tcp        0      0 ::ffff:127.0.0.1:1477       ::ffff:127.0.0.1:50240      ESTABLISHED 12710/amqrmppa
tcp        0      0 ::ffff:127.0.0.1:50240      ::ffff:127.0.0.1:1477       ESTABLISHED 23447/java

從上面結果可知:
(1)pid 12129 (runmqlsr)    這個process 在LISTEN 1477這個port
(2)pid 12710 (amqrmppa) 這個process用127.0.0.1的1477 port連往 127.0.0.1的50240 port
(3)pid 23447 (java)           這個process 用127.0.0.1的50240 port連往 127.0.0.1的1477 port


2. fuser
#fuser port_number/tcp -u -v
[root@love ~]# fuser 1477/tcp -u -v
                     USER        PID   ACCESS    COMMAND
1477/tcp:      mqm       12129   F....            (mqm)runmqlsr
                     mqm       12710   F....            (mqm)amqrmppa

3. lsof
#lsof -i :port_number
[root@love ~]# lsof -i :1477
COMMAND  PID  USER FD TYPE DEVICE SIZE/OFF NODE NAME
runmqlsr        12129  mqm   5u  IPv6      699704    0t0       TCP *:ms-sna-server (LISTEN)
amqrmppa     12710  mqm   6u  IPv6     2028669   0t0       TCP localhost:ms-sna-server->localhost:50240 (ESTABLISHED)
java               23447   root  118u  IPv6    2028668   0t0       TCP localhost:50240->localhost:ms-sna-server (ESTABLISHED)

Ref:
Linux Find Out Which Process Is Listening Upon a Port

https://www.cyberciti.biz/faq/what-process-has-open-linux-port/

How to change the MQ qmgr error log file permission to allow user not in mqm group could access it

If you would like to allow user in non mqm user group to access the qmgr error log, you may try to modify the file and directory permission for the non mqm user group. However you will find after qmgr updating the content of the qmgr error log or qmgr restart, the qmgr sets all the files and folder permission back to the default setting. The non mqm user can’t access the error log again. To solve this issue, you need to use the following parameter in the qm.ini file.

Filesystem:ValidateAuth=No

This setting will cause the queue manager to leave the permissions on the error log files unaltered.

IT09572: ValidateAuth=No does not maintain file permissions on queue manager error logs

http://www-01.ibm.com/support/docview.wss?uid=swg1IT09572

passing an argument to mq process script

How to pass an argument to mq process script (or run it background in unix)

Example:

If we would like define a process which invokes the "luke.sh" script

and would like also passes the argument "lightsaber" to luke.

=== process definition ===

DEFINE PROCESS(P1) +
       DESCR ('MQ test process script') +
       APPLTYPE(UNIX) +
       APPLICID('/tmp/luke.sh') +
       USERDATA(' ') +
       ENVRDATA('lightsaber')
=== process definition ===

You must put the argument in the 'ENVRDATA' but not 'USERDATA'.

*** tip:

You can also put "&" in the ENVRDATA for the UNIX script running in the background.

DEFINE PROCESS

https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_7.5.0/com.ibm.mq.ref.adm.doc/q085670_.htm

****On UNIX systems, ENVRDATA can be set to the ampersand character (&) to make the 

    started application run in the background.

OpenSSL commands to check and verify your SSL certificate, key and CSR

https://support.asperasoft.com/hc/en-us/articles/216128468-OpenSSL-commands-to-check-and-verify-your-SSL-certificate-key-and-CSR

It can be useful to check a certificate and key before applying them to your server. The following commands help verify the certificate, key, and CSR (Certificate Signing Request).

(1)Check a certificate
Check a certificate and return information about it (signing authority, expiration date, etc.):

#openssl x509 -in server.crt -text -noout

(2)Check a key
Check the SSL key and verify the consistency:
#openssl rsa -in server.key -check

(3)Check a CSR
Verify the CSR and print CSR data filled in when generating the CSR:
#openssl req -text -noout -verify -in server.csr

(4)Verify a certificate and key matches
These two commands print out md5 checksums of the certificate and key; the checksums can be compared to verify that the certificate and key match.
#openssl x509 -noout -modulus -in server.crt| openssl md5
#openssl rsa -noout -modulus -in server.key| openssl md5

For the WAS or MQ, you can also use the keytool which under the jre/bin folder

#keytool -printcertreq -file your_req_file
#keytool -printcert -file your_cert_file

For Windows Platform, you can use certutil command (built-in) to review the file.
certutil -dump <file>


*** the MQ gskit command (runmqckm) can not do this job.

Removing a qmgr from a cluster

Procedure

Perform the following tasks at the TORONTO queue manager:

1. Modify the full repository queue manager REPOS and
REPOSNL attributes
If your queue manager is a full repository queue manager, before you can remove
it from a cluster, perform the additional step of altering the queue manager
definition to set the REPOS and REPOSNL attributes to blank. This sends a
notification to other queue managers advising them that they must stop sending
cluster information to this queue manager.

2. Check that the REPOS and REPOSNL changes have been
propagated
Check that the changes you made in the previous step have been propagated
around the cluster by issuing the following command on a remaining full
repository:

DIS  CLUSQMGR(TORONTO)  QMTYPE

and check that it shows that the queue manager is no longer a full repository. The
output should match the following:
AMQ8441:  Display  Cluster  Queue  Manager  details.
CLUSQMGR(TORONTO)
CLUSTER(INVENTORY)
CHANNEL(TO.TORONTO)
QMTYPE(NORMAL)

3. Suspend queue manager TORONTO
Issue the SUSPEND QMGR command to suspend availability of the queue
manager to the INVENTORY cluster:
SUSPEND  QMGR  CLUSTER(INVENTORY)
When you issue this command, other queue managers are advised that they
should refrain from sending messages to TORONTO.


4. Check that queue manager TORONTO has been suspended
Check that TORONTO has been suspended before moving on to the next step by
issuing the following command on a full repository:
DIS  CLUSQMGR(TORONTO)  SUSPEND
and check that it shows that the queue manager is suspended. The output should
match the following:
Removing a queue manager
114    Queue Manager ClustersAMQ8441:  Display  Cluster  Queue  Manager  details.
CLUSQMGR(TORONTO)
CLUSTER(INVENTORY)
CHANNEL(TO.TORONTO)
SUSPEND(YES)

5. Remove the CLUSRCVR channel definition
Remove the CLUSRCVR definition from the cluster:
ALTER  CHANNEL(TO.TORONTO)  CHLTYPE(CLUSRCVR)  CLUSTER(’  ’)
This command causes the full repository queue managers to remove all
information about that channel from their full repositories, so that queue managers
will no longer try to send messages to it. You can verify that this command has
been successfully propagated by issuing the following command on the full
repository:
DIS  CLUSQMGR(TORONTO)
You should receive a message like that below:
AMQ8147:  WebSphere  MQ  object  TORONTO  not  found

6. Stop the CLUSRCVR channel at TORONTO
Note:  Before performing this step, ensure that any bound messages have arrived
on TORONTO, otherwise these messages will become stuck on the sending
queue manager’s cluster transmit queue.
Issue the STOP CHANNEL command to stop the cluster-receiver channel:
STOP  CHANNEL(TO.TORONTO)
Once the channel is stopped, no more messages can be sent to TORONTO.
Later, to tidy up, you will probably want to delete the channel:
DELETE  CHANNEL(TO.TORONTO)
Note:  At this point the TORONTO queue manager is no longer a valid destination
in the cluster, but there may be messages bound to TORONTO (messages
put using BIND_ON_OPEN) still being sent from other queue managers in
the cluster.

7. Delete the CLUSSDR channel definition
Note:  Do not attempt this step before completing all previous steps in this task.
The CLUSSDR channel definition points to the full repository at queue manager
NEWYORK. Stop this channel as follows:
STOP  CHANNEL(TO.NEWYORK)
and then delete it:
DELETE  CHANNEL(TO.NEWYORK)

8. Issue the REFRESH CLUSTER command
Issue the REFRESH CLUSTER command to remove any auto-defined cluster
channels:
REFRESH  CLUSTER(INVENTORY)  REPOS(YES)

The queue manager TORONTO is no longer part of the cluster. However, it can
still function as an independent queue manager.


Ref:
Queue Manager Clusters

In IBM WebSphere MQ, can you disable TLSv1.0 and TLSv1.1 SSL ciphers / protocols?

https://developer.ibm.com/answers/questions/213076/in-ibm-websphere-mq-can-you-disable-tlsv10-and-tls.htm

In IBM WebSphere MQ, can you disable TLSv1.0 and TLSv1.1 SSL ciphers / protocols?

Question by MCregge  (3351) | Sep 10, 2015 at 06:54 AMMQSSLTLSCIPHERSTLSV1.1TLSV1.0

In IBM WebSphere MQ, can you disable TLSv1.0 and TLSv1.1 SSL ciphers / protocols?

Like ·    1 ·    Comment   Reward user

3 answers

 · Add your answer

• Sort: 

Accepted answer

Answer by MCregge (3351) | Sep 10, 2015 at 06:55 AM

As you probably know, the latest updates to MQ are deprecating (disabling) the use of SSLv3 ciphers (and some "weak" TLS ciphers) due to known security vulnerabilities. Several customers have asked about disabling TLSv1.0 and TLSv1.1 ciphers also.

---

*There is a new APAR which allows disabling TLSv1.0 ciphers at the listener level in the latest maintenance releases of MQ v8 and v9. This is enabled via a qm.ini setting, see:

 SSL:
    AllowTLSV1=NO  

http://www.ibm.com/support/docview.wss?uid=swg1IT23235

---

Before that APAR, TLSv1 could not be disabled at the listener level, but you could still configure MQ to only allow channel communications on certain ciphers.

The simplest way to disable TLSv1.0 & TLSv1.1 protocols would be to set a TLSv1.2 cipherspec in the channel definition. The queue manager will only allow that cipherspec to be used which was configured on the channel; thus if you configure your channels with TLSv1.2 ciphers, that would mean that TLSv1.0 & TLSv1.1 protocols being disabled.

There is another way to disable TLSv1.0 protocol which is by enabling Suite B mode. The GSKit docs state that Suite B will disable all protocols except TLSv1.2. Information on Suite B implementation is here:

https://www.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.sec.doc/q010200_.htm?lang=en

The configuration of Suite B mode is given in the following link:

https://www.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.sec.doc/q010210_.htm

To have a look at the list of cipherspecs and the corresponding protocols used by them, follow the below link:

http://www.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.sec.doc/q014260_copy.htm

Update: MQ/SSL connections can not disabled at MQ listener level, the options noted above cause the MQ channel to fail to start unless using an adequate cipher, but they do not disable the MQ listener process from initially receiving the TLSv1.0 session.

I hope this helps. Please add comments or info.

---

Related info:

Deprecation: SSLv3 protocol ( MQ v7.0.1.13, v7.1.0.7, v7.5.0.5, v8.0.0.2 )
http://www-01.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.pro.doc/q123420_.htm?lang=en

Deprecation: Weak Ciphers deprecated ( MQ v7.0.1.13, v7.1.0.7, v7.5.0.6, v8.0,0.3 )
http://www.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.pro.doc/q123425_.htm?lang=en

Like ·    0   Comment   Reward user   Share

Answer by CarlosBarros (1) | Oct 15, 2015 at 11:06 AM

We have some problems regarding the suggestions.

Set a TLSv1.2 cipherspec in the channel definition doesn't mean the TLS 1.0 and TLS 1.1 will be disable. We did the test and they are enable.

Set SUITEB on queue manager will force the ciphers TLS 1.2 with elliptic curve. Unfortunately, ciphers with elliptic curve are vulnerable too. http://www-01.ibm.com/support/docview.wss?uid=swg21688949

Do we have any other option to disable the TLS 1.0 and TLS 1.1?

Like ·    0   Comment   Reward user   Share

Answer by MCregge (3351) | Aug 01, 2016 at 10:55 AM

Before APAR IT23235 (noted above), by default MQ would accept the TLS 1.0 connection and then disconnect it if it requests a channel that requires TLS 1.2.
There was no way to disable TLS 1.0/1.1 completely short off the SUITEB setting noted above..

If there is a need to fully disable TLS 1.0/1.1 the recommendation is to create an Enhancement requests at the following website:

http://www.ibm.com/developerworks/rfe/?BRAND_ID=181

Select 'IBM MQ', then can search or submit new requests.

Like ·    0   Comment   Reward user   Share