Fniger trouble when using AMS on z/OS
Feb 26 2016
I was working with someone installing AMS ( MQ Message encryption) on z/OS and we hit a few set up problems. I thought it worth documenting the problems we had and what to do to fix them.
This are written for a search engine to find rather than for an interesting read.
AMS is started using program CSQ0DSRV
- Abend 0c4 in pki_svc_init 0C4. Check you have updated SYS1.PARMLIB with MQM.V800.SCSQPROC(CSQ4SCHD) See here
- If you get return code 03353009 from GSKIT. This means the keyring is not set up for the AMS address space started task userid. See here for GSKIT codes
- If you forgot to define the AMS specific queues – AMS will not start, and the queue manager will shut down. You need to either change ZPARMs CSQ6SYSP SPLCAP=NO or put MQM.V800.SCSQPROC(CSQ4INSM) into CSQINP2 dataset,and restart the queue manager.
- If you get a message like
ICH420I PROGRAM CSQ0DSRV FROM LIBRARY MQM.V800.SCSQAUTH CAUSED THE
ENVIRONMENT TO BECOME UNCONTROLLED.
BPXP014I ENVIRONMENT MUST BE CONTROLLED FOR SERVER (BPX.SERVER)
CSQ0629E …. CSQ0DLCL Unable to create security environment for
user’….’, reason 0000008B
See here Reissue the RALTER PROGRAM * ADDMEM(‘thlqual.SCSQAUTH’//NOPADCHK) and restart the queue manager
Understanding log stats
Feb 23 2016
Understanding log statistics
I recently presented on MQ performance, and covered lots of deep details. While some people enjoyed this depth, it was clear that for some people this information was too deep, and I was asked – what do I need to look at?
So the simple picture : think of a bus…
You run a bus from A to B and want to know if you need to have a second bus on the route
The bus driver has the following rules.
- Take as many people as will fit on the bus, or until the queue of people is empty
- The bus can take up to 100 people.
- If there is no one waiting – wait for someone/some people to arrive
It takes an 10 minutes to go from A to B and back again… and the more people you have it takes longer to load and unload all of the people
What are good measures to see if you need to have a second bus ?
Guess at the maximum rate of people the bus can take in an hour?
Good measure 1: How often does the bus have nothing to do? – Is it always driving or is it often waiting for customers
Good measure2 : How many people are there on the bus at any one time? If it is 1 person, then you have plenty of capacity. If it is 100 people then you are at the maximum
Maximum capacity is each trip has 100 people. It must do 6 a trips an hour or less – so under 600 people per hour
How can you increase the throughput?
- Use a faster bus
- Have more than one door so people can get on and off faster
- Have more than one bus
In MQ terms
- Use a faster bus – have faster IO
- Have more than one door so people can get on and off faster – Stripe data set
- Have more than one bus – 2 queue managers
What does this mean with my queue manager
The key measure is the average number of pages per I/O. The absolute maximum is 128 pages per IO but 100 pages per IO is at the top end.
I hope this is clearer.
How to get my messages back from the data log
Feb 13 2016
For MQ on z/OS you have been able to use the EXTRACT capability of CSQ1LOGP to process the log data sets and get the messages back out – useful if you want to know who put or got a message.
See here for more information
I was asked to show how to extract data from the logs to make it usable. Below I have used the ICETOOL capability of the IBM DFSORT program to extract and display the data from the logs.
This only works for persistent message as non persistent messages are not logged.
The output is
TIME URID USERID APPTYPE JOBNAME QMGR LEN QUEUE VERB MSG_KEY SEG DATA
———— —————- ——– ——– ——– —- ———– —————- —— —————- ———– —-
18:25:28.800 024EA8FA48040000 PAICE BATCH PAICEH1 MQPA +32296 CP0001 MQPUT 000000010019F932 +1 MD
18:25:28.800 024EA8FA48040000 PAICE BATCH PAICEH1 MQPA +32385 CP0001 MQPUT 000000010019F932 +2 xxxx
18:25:28.800 024EA8FA48040000 PAICE BATCH PAICEH1 MQPA +32385 CP0001 MQPUT 000000010019F932 +3 xxxx
18:25:28.800 024EA8FA48040000 PAICE BATCH PAICEH1 MQPA +32385 CP0001 MQPUT 000000010019F932 +4 xxxx
18:25:28.800 024EA8FA48040000 PAICE BATCH PAICEH1 MQPA +32385 CP0001 MQPUT 000000010019F932 +5 xxxx
Long messages are segmented. The above data shows there are 5 segments for the message. The message content is all xxxx’s. The first 4 bytes of the data are displayed under the DATA column. The first segment has the MD, the remaining segments have xxxx from the message body.
Len is the length of the user data.
Each message has a message key. After the message been got there will be a message with VERB = MQGET and the same key.
The JCL below extracts the records for MQPUT requests. This covers MQPUT and MQPUT1
The column number used by ICETOOL is from the start of the record. DFSORT processes the record as an undefined format record, and so the 4 bytes of information about the size of the record(Record Descriptor Word) are available. This means you have to add 4 bytes to the offsets of the data within the record to get the offset for ICETOOL
//TOOLRUN EXEC PGM=ICETOOL,REGION=0M
//TOOLMSG DD SYSOUT=*
//DFSMSG DD SYSOUT=*
//TOOLIN DD *
SORT FROM(IN) TO(TEMP1) USING(CTL1)
* This reads from the //IN DD statement and outputs it to //TEMP1 DD statements
* The commands for DFSORT are in the //CTL1CNTL DD statement
DISPLAY FROM(TEMP1) LIST(OUT1) PLUS –
* This reads the output from Sort on //TEMP1 and displays it on //OUT1 DD statement
* Plus makes the column widths smaller.
* one blank between columns
* so you get lots of data before the columns are displayed
* so you have with output ( this is the maximum length)
HEADER(‘TIME’) ON(14,12,CH) –
* This display a column called TIME and formats it as a CHaracter string
HEADER(‘URID’) ON(41,8,HEX) –
* This displays the Unit of Recovery ID in hex
HEADER(‘USERID’) ON(59,8,CH) –
* This displays the userid that put the message
HEADER(‘APPTYPE’) ON(83,8,CH) –
* This displays the type of application such as BATCH
HEADER(‘JOBNAME’) ON(91,8,CH) –
* This displays the name of the job that put the message
HEADER(‘QMGR’) ON(106,4,CH) –
* This is the queue manager name
HEADER(‘LEN’) ON(102,4,BI) –
*This is the lenth of the data
HEADER(‘QUEUE’) ON(110,16,CH) –
* Which queue was used.
HEADER(‘VERB’) ON(178,6,CH) –
* This is the MQ Activity, MQPUT, MQGET COMMIT, ABORT, EXPIRE etc
*HEADER(‘SL’) ON(200,1,HEX) –
* This can be used to display if it was LOCAL(01) or Shared(02)
HEADER(‘MSG_KEY’) ON(170,8,HEX) –
* This is the message key for local queues
HEADER(‘SEG ‘) ON(201,4,BI) –
* This is the segment number
* The first 4 bytes of the message
* You can display the data in CH and then use ISPF editor command HEX ON to view the data
* which are not printable
//CTL1CNTL DD *
* SELECT THE RECORDS WHICH WERE PUT
//IN DD DISP=SHR,DSN=PAICE.EXTRACT.MQPB
//TEMP1 DD DISP=(NEW,DELETE),DSN=&TEMP1,SPACE=(CYL,(10,10))
//OUT1 DD SYSOUT=*
To process the file for MQGET, you have to copy the JCL and remove the SEG and DATA fields as the records for MQGET do not have these fields and so the records are shorter. DFSORT stops if it detects a record which it is too small. Then change the ‘MQPUT’ to ‘MQGET’
These blog posts are from when I worked at IBM and are copyright © IBM 2016.