North Ridge Software
Logon | Search | Go to
About UsProductsSolutionsResourcesSupport
Home : Resources : Newsletters
Newsletters
Network Center
Network Director
Service/Software
Industry Talk
White Papers

Support: North Ridge Reports

How big should the Network Director's LOGSIZE be?

Originally published: Winter 1999

We hear this question quite often and the answer really depends on how much information you'd like to be able to see from within Network Administration. If you rely on the Network Administration facility to manage a logical VTAM network, a bigger LOGSIZE will allow you to collect more information, increasing your ability to diagnose problems. On the other hand, if the Network Director runs mostly unattended, then a smaller LOGSIZE will minimize paging activity and related operating system actions.

In the following discussion we'll take a look at how the Network Director uses the Log Buffer; it may help you to understand the storage buffer and, in turn, remove any qualms about allocating a large LOGSIZE (over 1 Megabyte).

Finding the Log Buffer

To follow along with the examples in our discussion, locate the virtual storage queue associated with the LOGSIZE parameter by looking at offset +13C (Version 4.2.3) in the PDA.

If you are unfamiliar with this procedure, you can locate the virtual storage queue by doing the following steps:

  1. Access the internal Network Director Network Administration APPLICATION and enter "DUMP PDA" on the command line; a hexadecimal dump of virtual storage will appear containing the key Network Director control block (the Primary Director Area).
  2. Enter "+13C" and press Enter; the DUMP display will update to an offset of X'13C'. The first fullword in storage points at the beginning of the Log Buffer Elements (LBEs).
  3. Enter "DUMP address" (where "address" is the value stored at +13C) and press Enter; you should now be viewing The Network Director buffer that is allocated as a result of initialization activities (its size is set by the GLOBALS LOGSIZE= value):

The first 4 LBE fullwords identify basic information about the virtual storage buffer, as follows:

EyeCatcher
is the literal "LBE"
LBEEND
is the Virtual Storage address of the end of the Buffer
LBEOLD
is the address of the oldest entry in the Buffer
LBENEW
is the address of the most recent entry in the Buffer

How it works

During execution, The Network Directors uses these virtual storage addresses to insert additional messages into the storage buffer. To add a new message, The Network Director simply locates the newest entry (LBENEW), inserts the message for the required length, and, if necessary, updates LBEOLD.

As a result, The Network Director references only the LBE header (the first 4 fullwords in the buffer) and the actual page that will contain the message text. This results in a sequential operation that processes only the virtual pages within the Address Space or Virtual Machine that are necessary for tracking the information.

The payoff: Paging activity is minimized because the Network Director is NOT constantly cruising through storage to locate the "next spot" in the buffer. Furthermore, the processing overhead remains the same whether the LOGSIZE is 5K or 5000K.

Individual Entries

The Network Administrator's LOG display function also provides for maximum information availability with minimal storage. To understand how it does this, we need to explore how it manages individual LOG Buffer Entries (LBE). Take a look at the LBE that starts at the virtual address of 617C3 (buffer offset +FDC3):

1143008DB2213C7021E3F0F1F0F0F14040

This individual LBE is mapped via The Network Director's LBE DSECT (TNDLBE in the distribution libraries). It breaks down as follows:

11
is the binary length of this LBE entry (pointer to the next one)
43
is the binary length backwards to the prior LBE entry
008D
is the Network Director message number. This is TND0141 (interpreted in English as "Contact with the Terminal has been lost (VARY OFF, etc.)")
B2213C70
is the date and time of day the message was issued (in STCK format). This indicates the event (message 141) happened on 4/20/1999 at 14:20:25.
21
is the "flag byte" that establishes the presence or absence of other LBE elements. In this case, the X'20' bit indicates that this entry does NOT contain the Userid. The X'01' bit identifies the message as a Network Director Class G message.
E3F0F1F0F0F14040
represents the LUname of the device associated with the message. In this case, X'E3F0F1F0F0F14040' is the same as the LUname of C'T01001'

As you may note, the LBE only used 17 bytes of storage to indicate when and what kind of activity occurred, and to what device. Using this technique, The Network Director can store large quantities of information for your review with the Administrator's facility.

Go For It!

We encourage you to consider increasing the LOGSIZE of your queue beyond the 16K default (unless your Director runs unassisted). We think you'll find the additional information to be quite useful. We know we do!


----------
Copyright © 2018 by North Ridge Software, Inc./WebMaster@North-Ridge.com
   RidgeStar, Internet Services