Computer Corporation of America
|
 Feedback
Search CCA:
   
USA CCA
CCA Products
CCA Customer Support
CCA Resources
CCA - Company
CCAPRINT: A Newsletter for Model 204® and System 1032® Users
February 10, 1999

 
  • Model 204: The Line - Above and Below
  • System 1032: Logical Redirection for S1032/ODBC - Part I
  • Education Course Schedule
  • System 1032: Beat the Clock - Register for US'99
    •  
     
    Model 204
    The Line - Above and Below
    by Jim Damon
     
    With the advent of IBM's extended architecture (XA) some years back, CCA began enhancing Model 204 to exploit this powerful approach to addressing virtual storage. By the release of Version 2.2.0, virtually all control blocks and tables required by Model 204 were allocated above the 16-megabyte line. Even now, however, this "line" remains mysterious and confusing to many users. This article attempts to clarify the concept.
     
    Model 204 allocates memory from central storage for many different control blocks and tables using an operating-system service commonly known as GETMAIN in MVS, CMSSTOR in VM, and GETVIS in VSE. The majority of these control blocks and tables are allocated during Model 204 initialization. They constitute what is generally referred to as the region or address space in MVS, the virtual machine in VM, or the partition in VSE.
     
    The amount of storage acquired is determined exclusively by CCAIN parameters and DCB attributes for sequential datasets such as CCAJRNL, CCARF, and others. Most notable among the CCAIN parameters (there are others) are LENQTBL, LRETBL, MAXBUF, NSERVS, and SERVSIZE.
     
    Before XA
     
    Prior to the introduction of XA, a program could address only memory locations (using a 3-byte or 24-bit address) in the range:
     
    X'00000000' to X'00FFFFFF'
     
     
    Or in decimal: 0 to 16,777,215
     
    The X'FFFFFF' location, therefore, represented the maximum amount of virtual storage that a program could use or reference; this limit came to be know as the 16-megabyte line. Because it was assumed that no program would ever be any larger or ever need to address more than 16M of memory, this limit was deemed sufficient -- and perhaps was, for a few years.
     
    In XA and beyond
     
    In an XA environment (including ESA and OS/390), the operating system supports 31-bit addresses (4-bytes less 1-bit). So a program can now use or reference up to:
     
    X'7FFFFFFF' = 2,147,483,647 = 231-1 = 2 gigabytes of memory
     
    Under XA, any address less than the old maximum of X'00FFFFFF' is referred to as an address below-the-line. Any address greater than X'00FFFFFF' is referred to as an address above-the-line. The CCASNAP excerpt in Figure 1 (generated with the *SNAP command) illustrates this concept.
     
    For example, the control block named CNSTPG, allocated at address X'002C37F0' for a length of X'1810', is allocated below-the-line, because the address is less than X'00FFFFFF'.
     
    The next control block, TBLDALCA, is the first control block allocated above-the-line. It is allocated at address X'06900008' and, because this address is greater than X'00FFFFFF' (the high-order byte is greater than 00), it is an address above-the-16M-line.
     
     
    31-bit addressing prevails
     
    With Version 2.2.0, all Model 204 routines were modified to run in 31-bit addressing mode (AMODE=31), which means that, when an XA environment is detected, virtually all control blocks and tables are allocated above-the-16M-line. The minor exceptions consist of a few control blocks, which, for reasons largely related to 24-bit BSAM (IBM's Basic Sequential Access Method), must still be allocated below-the-line. However, if a 31-bit version of BSAM is detected during initialization, buffers used for BSAM I/O are also allocated above-the-line.
     
    The most significant use of below-the-line storage, however, consists of the Model 204 nucleus, which must reside (RMODE=24) below-the-line. This is illustrated by the excerpt in Figure 2, which shows the load module (ONLINE in this case) link map. Each of these addresses is less than X'00FFFFFF' and, therefore, represents an address below-the-16M-line. Although the Model 204 nucleus (load module) must reside below-the-16M-line for the time being, its consumption of 2.5-3M of virtual storage is highly unlikely to result in problems caused by virtual storage constraints in the Model 204 address space.
     
    Breathing room above the line
     
    Version 2.2.0 relieved severe virtual-storage constraints for many users by allowing them to fully exploit available memory and dramatically reduce end-user response times. This happened primarily because database buffers (MAXBUF), previously constrained to below-the-line addresses, could now be allocated above-the-line, where the limit on available virtual storage is 2 gigabytes, not 16 megabytes. As a result, MAXBUF can be increased, in many cases, by an order of magnitude from, say 1000 to 10,000, assuming that the resulting virtual storage is backed by sufficient real storage to avoid excessive system paging. So more database pages (Tables A, B, C, and D) can remain in memory for longer periods of time, with a concomitant reduction in disk I/O (DKRD) and a dramatic reduction in end-user response times. This benefit is true not only in the Online environment, but
    also in BATCH204, IFAM1, and IFAM4.
     
    Constraints on acquiring storage
     
    The amount of storage acquired by Model 204 can be limited, but not determined by:
     
     
    The ability to limit, but not determine, storage acquired is an important point. For example, setting REGION=128M on the EXEC card in MVS (DEFINE STOR in VM) does not mean that Model 204 actually uses that amount of storage. It means that the job is limited to a maximum of 128M of virtual storage; the actual amount used is determined by CCAIN parameter settings and DCB attributes, and might be significantly less than 128M.
     
    Determining virtual storage allocation--to come
     
    In a future article, I will discuss various information sources that you can use to determine the amount of virtual storage actually allocated by a Model 204 job (both above- and below-the-line) and the implications that allocation has for performance.
     
    Those information sources include:
     
     
     
    System 1032
     
    Logical Redirection for S1032/ODBC - Part I
     
    by Tym Stegner
     
    When you run an ODBC session, two temporary file areas are declared in ODBC.INI:
     
     
    At some sites, you might want to redirect one or both of these logical names to a scratch device.
     
    For the ODBC environment, to define any logical names you must either place the definitions in the system logical name table, or define them within the LOGIN.COM command file for the ODBC administrator account, because your own LOGIN.COM is not executed by S1032/ODBC.
     
    Switching to user directories
     
    SYS$LOGIN and SYS$SCRATCH default to user-specific directories such as:
     
    $ show log sys$login,sys$scratch
    "SYS$LOGIN" = "DISK$PUBLIC1:[MYDIR]"
    (LNM$JOB_80E0F980)
     
    "SYS$SCRATCH" = "DISK$PUBLIC1:[MYDIR]"
    (LNM$JOB_80E0F980)
     
    However, to ensure that there are valid, writable directories for each of these logical names, the server redefines both logical names during the so-called "persona" switch from the ODBC administrator account to the user's environment.
     
    Consequently, redefinition of SYS$LOGIN and/or SYS$SCRATCH within the ODBC administrator LOGIN.COM does not normally help you, because, at the time of the execution of LOGIN.COM, no information is available about who is actually logging in; therefore, no way exists to correctly define supervisor-mode logical names unless to a non-user-specific directory.
     
    To redirect either logical name to a generic directory, define the logical names in SUPERVISOR mode. Those values supersede S1032/ODBC's redefinition of the logical names.
     
    Current workaround
     
    CCA plans a future release of ODBC that will provide the ability to declare user-specific temporary areas. In the meantime, you can turn to the ever-present S1032 tools for a workaround.
     
    By the time that System 1032 is started within the ODBC environment, the "persona" shift has already been done. Therefore, you can use commands within the System 1032 initialization file to redefine SYS$SCRATCH and/or SYS$LOGIN. S1032/ODBC uses the logical names, rather than the definition of the logical names.
     
    You can redefine the logical names within either the systemwide initialization file or an initialization file local to the ODBC administrator's account. Use the SET_LOGICAL tools procedure in conjunction with system variables such as $USER.
     
    In Part II
     
    Next month, in Part II of this article, I will describe how to detect ODBC context.
     
     
    Education Course Schedule
    February - April 1999
     
    Model 204
    Model 204 V4R1 Update Class 2/12 McLean
    Programmer's User Language 2/22-26 McLean
    Implementing Online Applications 3/8-11 McLean
    Application Subsystem Facility 3/11 McLean
    File Design and Management 3/22-24 McLean
    Introduction to User Language 3/24-26 Framingham
    Recovering and Enqueuing 4/5-6 McLean
    Security 4/7 McLean
    Problem Determination & Resolution 4/8-9 McLean
    Programmer's User Language 4/19-23 McLean
    System 1032
    System 1032 DBMS Fundamentals 3/15-16 Framingham
    Essential PL1032 3/17-19 Framingham
     
     
     
    System 1032
     
    Beat the Clock - Register for US'99
     
    by Nancy Diettrich
     
    We're coming down to the wire for your registrations. Information packets are distributed as we receive your official fax-back registration forms. Any of you folks who indicated that you definitely are or may be attending this conference should have received a letter and fax-back forms. If you have not, please contact me so that I can ship one to you. It's not too late for those of you who are still thinking about coming. CCA needs to start nailing down the details, so please get that info back to me ASAP.
     
    One of the fax-back forms asks some questions regarding your site and its software and needs. That form is as important as the registration, because it tells us what you need to keep System 1032 as useful as possible at your site. Here is an example from one of our customers: "We are very interested in techniques to allow us to pass System 1032 data to a Web page, return the data, then update the System 1032 database, the point being, administrative applications using System 1032 and the Web."
     
    This interest will be addressed in detail by David Stone at this year's conference.
     
    Want to learn more? Well, join us for US'99, March 28-30, 1999. Remember, registration is free!
     
     
    Nancy Diettrich
     
    508-270-6666 x713
    Nancy_Diettrich@cca-int.com
     
     

     
    Copyright © 2003 Computer Corporation of America.
    All right reserved. Published in the United States of America.

    500 Old Connecticut Path, Framingham, MA 01701
    webmaster@cca-int.com
     Copyright 2005