System 1032
User Symposium ’99 Highlights
By Ann Hulsing and David Stone
"The most solidly useful conference in years."
As System 1032 users departed from US’99, one reviewer commented, "CCA values its customers and it shows!" From the first slide to the last e-mail address exchange, US’99 participants were fully engaged.
System 1032 V9.7-1
"CCA has regained its reputation and shown a definite commitment to System 1032."
In addition to major work on enhancing the quality of the code, two major new features are introduced with which you can:
Compaq OpenVMS
The rumors surrounding OpenVMS continue, and everyone wanted to know, "Is OpenVMS going away?" The answer appears to be, "Not any time soon."
Instead of announcing the demise of OpenVMS, Compaq has released an aggressive 5-year schedule of improvements and enhancements. Compaq recently released OpenVMS 7.2, which introduced performance enhancements and Java support. Both System 1032 and OpenVMS appear to be viable for quite a while. Furthermore, the pressure to port System 1032 to the NT platform decreases, as OpenVMS introduces better interoperability with Windows NT.
System 1032 ODBC Driver V2.10-2
The next release of ODBC Driver is fast approaching customer beta. In addition to numerous performance and quality enhancements, V2.10-2 supports both Input and InputOutput parameter types for stored procedures as well as result sets.
Demonstrations of both client-server and Web- based applications show easy access to System 1032 data from PC applications, high throughput using the World Wide Web, and ways to capitalize on your investment by reusing existing PL1032 procedures as ODBC stored procedures.
Update Trigger procedures
"I’ve got good stuff to go home with."
Tym Stegner and Jody Regan, System 1032 senior software engineers, presented a slide show for Update Trigger procedures that includes a tidy application to register for a golf tournament. The application illustrates:
Database design and efficiency
With an eye on what the ODBC Driver can do for you, Nancy Diettrich, CCA Customer Support, walked through many tips and ideas for improving applications and avoiding pitfalls, paying particular attention to:
WEBGEN tool
"WebGen looks great! I’m looking forward to using it."
A hot topic among users looking at ODBC and PC applications is how to recreate all the forms that you created in PL1032. For users contemplating this daunting task, Tym Stegner created WebGen, an unsupported tool for converting to a Web interface. WebGen takes a System 1032 form or dataset
and converts it into an HTML page, including JavaScript code that validates your fields. You can manually edit the HTML, if desired, and use it as the beginning of a Web-based application.
CCA provides the WebGen tool to users of the System 1032 ODBC Driver.
Model 204
The Line – Above and Below
Part II
by Jim Damon
Model 204 allocates virtual storage for control blocks, tables, input/output buffers, and other structures from both above and below the 16-megabyte line. Standard operating-system services make these allocations: GETMAIN under MVS-OS/390, CMSSTOR under VM, and GETVIS under VSE.
Total storage allocated
Model 204 makes the following types of storage allocations:
The sum of these three types of storage constitutes the total storage required by a Model 204 job (ONLINE, BATCH204, IFAM1, or IFAM4). You can view the amount of static and dynamic storage using a VIEW STORINIT, STORCUR, STORMAX command.
Viewing static storage used
In Figure 1, the STORINIT parameter indicates that this Online allocated approximately 327-megabytes of virtual storage during initialization, as directed through parameters in CCAIN, primarily LENQTBL, LRETBL, MAXBUF, NJBUFF, NSERVS, NUSERS, and SERVSIZE, as well as several others.
Figure 1. Storage allocated during initialization
However, the STORINIT parameter does not reflect the storage required for:
Determining dynamic allocation
Dynamic allocation is tracked by two parameters:
After certain operations complete, dynamic storage is released. Therefore, STORCUR is always less than or equal to STORMAX, because as a high- water mark, STORMAX never decreases.
You can determine and verify the location— above or below the line—and the total amount of program, static, and dynamic storage, under MVS- OS/390, by examining the end-of-step message, IEF374I (see Figure 2).
Figure 2. IEF374I end-of-step message
Where:
Storage allocation for the load module
You can determine the amount of storage required for a load module or executing program by examining:
address of last csect – address of first csect + VT75 length (16000 bytes) = X’2A5FC0’ – X’6EF0’ + X’3E80’ = X’2A2F50’ = 2,764,624 bytes
The csect addresses listed in this map indicate that each resides below the 16-megabyte line, because each address is less than X’00FFFFFF’. In this example the operating system loads the ONLINE program into storage below or above-the-line depending on the RMODE parameter specified during linkedit. For most Model 204 load modules, RMODE=24 must be specified; the program must reside in storage at an address less than or equal to the maximum value of a 24-bit address, that is, less than or equal to X’00FFFFFF’.
Figure 3. Module link map by address
Static and dynamic storage allocation
When a CCASNAP listing is generated, a storage map for that Model 204 address space, virtual machine, or partition is also generated. The map lists all system control blocks and tables, including the address and length of each, allocated at the time of the snap. The map includes both static and dynamically allocated storage. The map excludes all servers except for the server of the user who caused the snap.
In Figure 4, an excerpt from the Allocated Storage Map shows the server of the user causing this snap. Each server begins with the LASTERR control block and ends with QTBL.
Figure 4. Allocated Storage Map excerpt
Further down in the listing, the contents of many of the individual control blocks are dumped in their entirety, depending on SNAPCTL options.
Most of the control blocks itemized in the Allocated Storage Map by Address are static and allocated during initialization as directed by parameters in CCAIN. The largest of these control blocks is almost always BUFFERS, shown in Figure 5.
Figure 5. BUFFERS control block
Here, the BUFFERS control block is allocated above-the-line (the address is X’070FF1C0’) and has a length of X’01D7CD50’, or 30,920,0016 bytes. Subtracting 16 bytes for the header preceding each control block and dividing by 6184 (PAGESZ) gives 5000, which is the value of MAXBUF/NUMBUF in this run.
If you make extensive use of the Resident Request feature, you also see numerous control blocks labeled RESREQST, reflecting dynamic storage allocated to support this feature.
This brief review of storage allocation can be useful for understanding virtual storage management under Model 204, because it provides a basic outline of the fundamental architecture of the database. Anyone involved in capacity planning and performance monitoring and tuning should be familiar with this architecture, because that knowledge can be crucial in planning for future growth and for maximizing system efficiency.
Correction to February 1999 Part I article
In the second paragraph of the February 1999 Part I article, mention is made of the DMSFREE service of the VM operating system. For DMSFREE, please substitute CMSSTOR. DMSFREE has been obsolete and unsupported in VM now for several years.
End of series
Education Schedule
April – May 1999
Model 204 Training
500 Old Connecticut Path, Framingham, MA 01701 webmaster@cca-int.com Copyright 2005
