SHowing NetView TVBs
I do lots of NetView Comand Processor development and frequently use the SHow MEM, SHow TVB and the SH MVT functions of the NetResults/z SHOW facility.
Our NetView domains are large and we have a lot of TVBs. It's nice to be able to do a SHow TVB=taskid, cause it gets you to the TVB you want, quickly.
However, at times I like to "probe" through "all" the TVBs, and chasing down the TVBNEXT pointer is time consuming. Any suggestions ?
The SHow TVB option was enhanced, quite a while ago, to enable you to do just what you're asking - "chain" through the TVB pointers.
How do you chain through the TVB's ?
Easy. Just start with whichever TVB you prefer, then press PF9 to turn "Chaining" ON. When chaining is ON, a "C" is displayed in the upper right hand portion of the screen heading. PF7 and PF8 also change in function, so that they now traverse, to the previous or next TVB control block, instead scrolling through the TVB itself.
You can quickly get to the top or the bottom of the TVB chain by entering an "M" on the command line, and then pressing PF7 (top) or PK8 (bottom).
When you get to the TVB you want, just press PF9, again, to "toggle" Chaining OFF. When chaining is OFF the little "C" in the upper right hand portion of the screen heading goes away; and PF7/PF8 revert back to "intra" TVB scrolling.
SHowing Message Queues
Every now and then we get an AUTOTASK that gets "stuck". Eventually, we blow it away, then reestablish it. But it bugs me not knowing "why" it happened. I noticed in your doc that the SHOW facility of NetResults/z has a "SHow MSGQ" function. I tried it, but didn't totally understand what I was looking at. Could you elaborate ?
Sure. The SHow MSGQ function of NetResults/390 displays the status and contents of a NetView Task's Message Queues.
Before getting into the details, however, we should point out a few things about NetView Task message queues;
First of all,
There are essentially two "types" of message queues, Public and Private.
Within each "type", there are also "priority" levels; High, Low and Normal.
Furthermore, each and every "queue" type and "priority" level, can contain many "different" message types. This is "not" easy stuff.
The SHow MSGQ function of NetResults/z, by default, shows the status of the message queues, belonging to the Task issuing the Show MSGQ command.
For example; "SHOW MSGQ" issued by task NETOP2 shows the Message queue status belonging to NETOP2. That is, it produces the "same" results as "SHOW MSGQ=NETOP2" would.
You can also show the Message queues belonging to a specific task;
If you need to look at many tasks, you can show the Message queues for "all" Tasks or specific "types" of Tasks; like AUTOTASKs, DSTs, NNTs, HCTs, OSTs, etc.
The initial SHOW MSGQ screen looks cryptic, but succinct; containing:
Taskid, Task Type, #Pubq (which is an aggregate count of all messages on the hi/lo/normal "Public" message queues), #Pvtq (which is an aggregate count of all messages on the hi/lo/normal "Private" message queues).
The amount of storage presently being used to contain the messages on the queue and the timestamp of the "oldest" message on the queue, is also displayed. These are important items.
Also, if you wish to peruse the "content" of queued messages; just place your cursor on the line containing the Taskid, in which you're interested, then press PF4 to Zoom to a Hex/Graphic display of the messages on that task's queue(s).
The display starts with the most recently (newest) queued message and chains "forward" to the oldest queued message; you guessed it - the queues are in LIFO order. They're not processed that way, of course, but they're chained that way.
If you want to get to the "last" (oldest) message on the queue, enter an "M" on the Command line and press PF8. To get back to the "first" (newest) message on the queue, enter an "M" on the Command line and press PF7.
If your AUTOTASK seems "stuck", the timestamp of the "oldest" message might be a way to corroborate that.
For example, if it's 11:30 and the oldest timestamp in the message queue display is 11:25, that implies (although not conclusively) that the last time a message was retrieved from your AUTOTASK's message queue, was somewhere "on" or "before" 11:25.
From that inference, you can deduce that your AUTOTASK has been processing the last message retrieved (de-queued), for at least 5 minutes.
We know what your next question is. What message is it processing ?
Good question, but unfortunately, the answer to that question can either be straightforward or quite involved. However, if you're a "down to the metal" type of person, you might consider this to be fun.
To determine the message currently being processed;
You either have to look at the memory pointed to by the "TVBAIIFR" field in the task's TVB. You can use the SHOW MEM function of the NetResults/z SHOW facility.
Or, usually very tediously, you have to chase through the task's "storage" control blocks. That's because the current message is no longer on the "message" queue and it's not an AIIFR.
The non-AIIFR message's storage is still owned by the task, however, and is therefore available for display.
Chasing down the storage containing the current message, however, can be tricky; but if you call OUI tech support, we'll walk you through it, using the SHOW MEM function, in just a few minutes.
Be aware, however, that in either case (AIIFR and Non-AIIFR), that to "know" the content of the current message, may or may not help you to resolve/circumvent the "stuck" condition.
If the problem "is" data-related, however, at least you'll be able to identify and route "rogue" message types to an AUTOTASK that specifically handle's problematic message types.