Month: May 2020

Why cant I logoff from mqconsole?

If you are using mqweb using certificates to identify yourself, if you logoff, or close the tab, then open a new tab, you will get a session using the same certificate as before.

This little problem has been a tough one to investigate, and turns out to be lack of function in Chromium browser.

The scenario is you connect to mqweb using a digital certificate. You want to logoff and logon again with a different certificate, for example you do most of your work with a read only userid, and want to logon with a more powerful id to make a change.  You click logoff, and your screen flashes and logs you on again with the same userid as before.

At first glance this may look like a security hole, but if someone has access to your web browser, then the can click on the mqweb site, and just pick a certificate – so it is no different.

Under the covers,  the TLS handshake can pass up the previous session ID.   If the server  recognises this, then it is a short handshake instead of a full hand shake, so helping performance.

To reset the certificate if you are using Firefox

To clear your SSL session state in Firefox choose History -> Clear Recent History… and then select “Active Logins” and click “OK”. Then the next time you connect to your SSL server Firefox will prompt for which certificate to use, you may need to reset the URL.

You should check Firefox preferences, certificates, “Ask you every time” is selected, rather than “Select one automatically”.

Chrome does not support this reset of the certificate.

There has been discussion over the last 9 years along the lines of, seeing as Internet Explorer, and Firefox have there, should we do it to met the end user demand?

If you set up an additional browser instance, you get the same problem. With Chrome you have to close down all instances of the browser and restart chrome to be able to select a different certificate.

It looks like there is code which has a cache of url, and certificate to use.   If you open up another tab using the same IP address you will reuse the same certificate.

If you localhost instead of 127.0.0.1 – it will prompt for certificate, and then cache it, so you can have one tab open with one certificate, and another tab, with a different URL and another certificate.

GUIs ain’t what they used to be

I’ve recently had to use some “improved” applications (one of which was internet banking) and it made me realize how different GUIs are these days compared to when I were a lad, and you only had a choice of text colours green or bright green.  (I remember a banking customer being shown the pre-release 3279 displays which could display 8 colours.  The customer asked “why do we need so many colours”, and someone said “you can show overdrawn balances in red” – the banker was convinced; and put in a big order).

You need to know your audience for example

  1. People who only use the app once a week, for example internet banking.   You want the user to do things easily and without problems. They may just want to look at the top few entries in their bank statement
  2. People who use the interface 100 times a day – for example, programmers and administrators.  These people want to do their job – and one key press is better than multiple key-presses.  They need to process large  numbers of items(hundreds) and take actions.

I feel that modern interfaces try to use one interface for both sets of users.

As a professional programmer I wanted any interface to be efficient.  For example

  • small movements – press just one key if possible
  • have important fields together.   For example for a list of left justified items, have the action field/icon in front of the list instead of at  the right hand side, being the wrong end of the line.  They eye should only have small movements.
  • display “more” – with one key press
  • use screen space efficiently

I thought the ISPF interface on z/OS was very good.

  • I could efficiently move around it, for example, when looking at job output, I could type =L;3;4;(enter) to get to the place in the GUI hierarchy to list the files.
  • You press F7 andF8 to scroll within the file
  • You have a local command area in front of each item in a list and you can use E to edit, B for Browse, D for delete etc.
  • You can have thousands of entries in the list, and can you the “find” command to locate entries of interest.
  • I can could organise fields in the display, so I can display the start of job/file/queue name, and %cpu/depth/depth and so the important information was in the left 20 %of the screen – and then stack up 4 screens from different systems all showing this information.

Compare this with “the modern GUI” in a web browser

  • Often you have a big picture or icon at the top of the screen – wasting valuable space.   The first thing you have to do is scroll past it. To get to the top you press “home” and “page down” – two key strokes
  • Lines are widely spaced – for example one row of output per centimeter of screen space, showing 10 lines per window, a third the density compared to the mainframe
  • “Actions” icons are at the right hand end of the lines – it is harder to match up the line of interest with the action icon – coloured backgrounds help with this.  Sometimes the “Action icon” is off the side of the screen – so is invisible.  It would help to have an action icon at each end to make it easier.   (I remember a “new” tool in IBM that we had to use, which had the “save” button off the side of the screen.  It was only visible if the window was very wide.   I lost a lot of data as I foolishly assumed the lack of a visible “save” button meant the tool saved automatically! – and pressing the “help” button lost what you had typed.)   The minimum you want displayed is the item, and the action.  Having the action icon only at the right means you will lose it if you make the window narrower.
  • Can we have “right click” for data rows?
  • I tend to work with a “messy desk” with several narrow windows displayed, many on automatic refresh.   This allows me to quickly see if things have changed.   If I am forced to have wide windows, then I need an even wider display which is less efficient
  • You have to click on “Next” and “Back” to navigate.  Some times “Up” is at the top of the screen, and “Down” is at the bottom of the screen so you have to move your mouse a large distance to be able to scroll.  Having up and down buttons adjacent,  is much more efficient as  it means you need a small movement to be able to scroll.
    • Some times the “next” or “back” button move as you move through the pages.  This means you have to move the mouse, and so slows you down!
  • It displays a small number of items at a time  (up to 50) to display more, you have have to scroll – for example I have 500 user queues on one of my queue managers – that would be 10 “next page” actions to get to the end.  Personally I would allow up to 1000 items on the page.

I remember watching some Chinese programmers who could drive their systems properly by chaining all of the commands together and they could type faster than the eye could follow.

Ive seen other people who program their 3270 emulator so Alt+Ctrl+6 logged on to another system, issued commands, copied data to a clip board, jumped to another session and pasted the data in a file.  This was a joy to watch.

Ive seen other people who use the cursor to scroll up and down a web page to get to the bottom, to find the “next” key, and it takes them 10 seconds a page.  I did not show my frustrations but suggested they use the “home” and “end” keys – for which they were very grateful.

On my laptop I use  Ctrl+up instead of the home key and Ctrl+down instead of the end key, as my hands to not need to move so far, which means it is more accurate.   I doubt if modern web GUI designers think about this sort of design.

facepalm: Why my mqconsole was refreshing every 60 seconds

I had just upgraded MQ to v915 and was trying out the new mqconsole via the web stuff.  It was really annoying because every 60 seconds the web page would refresh, and I would have to start again.

I checked my mqwebuser.xml file for “60” seconds, but there were no hits.

Gwydion suggested I check the ltpaExpiration value.   This specifies how long a logon token is valid for; after it has expired you have to logon. again .  There were several problems here:

  • I had <variable name=”ltpaExpiration” value=”30″/> .   This says your session expires after 30 minutes.  Because I was using certificates to logon, I automatically get relogged on after this interval expires, this was 30 minutes not 1 minute so not my problem.
  • I used grep ltpa mqwebuser.xml and found I had several  <variable name=”ltpaExpiration” value=…./> statements. The last one had a value of 01 – one minute.   This was the statement causing my problems.

What did I learn from this?

  • Use the command  dspmqweb properties -a  to display all of the parameters.   If they are not as you expect, check the mqwebuser.xml file.
  • The setmqweb command deletes all the entries except for the last one, and updates the last entry with the specified value.   This solved my duplicate entry problem.
  • I specified setmqweb properties -k ltpaExpiration -v 015 to set it to 15 minutes.
  • You can put a comment  <!– unit in minutes –> before(near) the statement.
  • I also added unit=minutes into the statement <variable name=”ltpaExpiration” unit=”minutes” value=”016″/>.  setmqweb, and startup ignore this.

I tend not to use the setmqweb command as I pretend to be an enterprise where every change has to have a change record and where configurations are created centrally and deployed to the machines.

What is the connection between MQ, a thatched cottage, a museum, an aeroplane and a factory?

Do you give up on the question – so do I!

I upgraded to 915 and used the “improved” mqconsole web interface.  This has several problems. Under “MQ Basics, what is messaging?” you get some pictures.  For example, we seem to have random meteors going to random places,

It is hard to understand, as it uses a white background and off-white colours for connections.   I took the source of this, and by a bit of python magic changed the html and produced

This is clearer, but I am non the wiser.  We have  icons for Home,  Shopping Trolley, Thatched cottage, High rise building with garage, Factory, Aeroplane, and Museum.  The aeroplane sends stuff to the blue box( queue manager?) but messages are not processed.

My blog posts from the old IBM community

The old IBM community site is being replaced by a new IBM community web site, and old blogs are not being copied across.

I’ve managed to copy the posts I wrote when I worked for IBM and copied them to this web site. It has been a trip down memory lane reading the posts, and the topic I covered.

NETTIME does not just mean net time

I saw a post which mentioned NETTIME and where people assume it is the network time.   It is more subtle than that.

If NETTIME is small then dont worry.   If NETTIME is large it can mean

  • Slow network times
  • Problems processing messages at the remote end

Consider a well behaved channel where there are 2 messages on the transmission queue

Sender end Receiver end
  • MQGET first message from the queue
  • TCP Send message in  buffer 1
  • MQGET second message from the queue
  • TCP Send message in buffer 2
  • MQGET – no message found
  • Do end of batch processing
    • TCP Send “End of batch” in buffer 3
    • Start timer
    • Wait
    • buffer arrives, wake up application
    • Stop timer. Interval is “Sender wait time”
  • Extract “receiver processing time” from reply buffer
  • Calculate NETTIME = “sender wait time” – “receiver processing time”
  • buffer 1 arrives, wake up Receiver channel application
  • buffer 2 arrives
  • TCP receive buffer 1 from network
  • MQPUT message 1 to the queue
  • buffer 3 arrives
  • TCP receive buffer 2 from network
  • MQPUT message 2  to the queue
  • TCP receive buffer 3 from the network – get  “end of batch” flag
    • Start timer
    • Issue commit
    • Stop timer
    • Send “OK + time interval back to Sender

In this case the NETTIME is the total time less the time at the receiver end.  So NETTIME is the network time.

In round numbers

  • it takes 2 millisecond from sending the data to it being received
  • get + send takes 0 ms ( the duration of these calls is measured in microseconds)
  • receive (when there is data) + MQPUT and put works, takes 0 ms
  • commit takes 10 ms
  • it takes 1 ms between sending the response and it arriving.
  • “10 ms” is sent in the response message

This is a simplified picture with details omitted.

The sender channel sees 13 ms  between the last send and getting the response.  (13 ms – 10 m)s is 3 ms – the time spent in the network.

 

Now introduce a queue full situation at the receiver end

Sender end Receiver end
  • MQGET first message from the queue
  • TCP Send message in buffer 1
  • MQGET second message from the queue
  • TCP Send message in buffer 2
  • MQGET – no message found
  • Do end of batch processing
    • TCP Send “End of batch” in buffer 3
    • Start timer
    • Wait
    • buffer arrives, wake up application
    • Stop timer. Interval is “Sender wait time”
  • Extract “receiver processing time” from reply buffer
  • Calculate NETTIME = “sender wait time” – “receiver processing time”
  • buffer 1 arrives, wake up Receiver channel application
  • buffer 2 arrives
  • TCP receive buffer 1 from network
  • MQPUT message 1 to the queue – it gets queue full, it pauses
  • buffer 3 arrives.  All of the data is in the buffers in TCP at this end.
  • after 500 ms the MQPUT succeeds.
  • TCP receive buffer 2 from network
  • MQPUT message 2 to the queue
  • TCP receive buffer 3 from the network – get “end of batch” flag
    • Start timer
    • Issue commit
    • Stop timer
    • Send “OK + time interval back to Sender

In round numbers

  • it takes 2 millisecond from sending the data to it being received
  • get + send takes 0 ms ( it is in microseconds)
  • receive (when there is data) takes 0 ms
  • the pause and retry took 500 ms
  • the second receive and MQPUT takes 0 ms
  • commit takes 10 ms
  • it takes 1 ms between sending the response and it arriving.
  • “10 ms” is sent ( as before) in the response message (the time between the channel code seeing the “end of batch” flag and the end of its processing
  • Buffer 3 with the “end of batch” flag was sitting in the TCP buffers for 500 ms

The sender channel sees 513 ms  between the last send and getting the response.  513 ms – 10 ms is 503  ms – and reports this as ” the time spent in the network” when in fact the network time was 3 ms, and 500 ms was spent wait to put the message.

Regardless of the root cause of the problem, a large nettime should be investigated:

  • do a TCP ping to do a quick check of the network
  • check the error logs at the receiver end
  • check events etc to see if the queues are filling up at the receiver end