by Jim Damon
In MVS, System Queue Area (SQA) is an area of virtual storage reserved for tables and queues related to the entire system. It contains fixed pages and is assigned protection key zero.
The Extended System Queue Area (ESQA) is an extension of SQA, which is allocated above the 16-MB line.
This article discusses usage of these MVS storage areas to maximize Model 204 performance.
Model 204 allocates approximately 200 bytes of ESQA storage in the form of two input/output supervisor blocks (IOSB and SRB), when each I/O operation is initiated, which includes all database, CCATEMP, and CCASERVR I/O. To reduce the number of GETMAINs issued by Model 204 and to improve performance, these blocks are not released following I/O completion, but are allocated to the address space until the job step completes. This practice allows subsequent I/Os to be initiated more quickly and without issuing additional GETMAINs.
The Execute Channel Program (EXCP) component of MVS performs database I/O. EXCP, the I/O driver in this case, limits these address spaces to no more than 500 concurrent EXCPs. However, if 500 concurrent EXCPs are exceeded, the address space is terminated with a C22 ABEND.
For this reason, CCA recommends setting XMEMOPT=2 in multiuser Onlines to avoid C22 ABENDs and for better performance. This setting enables the high-performance I/O component in Model 204 known as IOS Branch Entry. Model 204 itself becomes an I/O driver, replacing EXCP and eliminating the 500-concurrent-I/O restriction. C22 ABENDs are avoided and throughput is increased.
Because IOSBs allow greater than 500 I/Os per second, in high I/O-rate situations Model 204 uses more SQA storage than the EXCP limit of 10,000 bytes.
The following Model 204 commands cause Model 204 to issue multiple concurrent page I/Os for a single user. The resulting ESQA demands are described.
The CREATE command formats each page of each table in a Model 204 file with the character string "INITIAL JOBNAME" in the first 16 bytes of the page. Pages are written using one I/O for each track in the file being created. This causes a write of 7 pages for a 3380 volume, 8 for a 3390 volume. Model 204 then waits for the I/O to complete. During the create process, no more than about 200 bytes of ESQA are required. However, because each dataset in the file is formatted in parallel as part of this process, the ESQA requirement for each dataset is about 200 bytes.
Before issuing a wait, the INITIALIZE command formats each page in Table A and Table C, and also Table B for hashed files, with hex zeroes, by issuing 64 write I/Os (each a 6184-byte block/page). Approximately 13K of ESQA is allocated and remains allocated until the job step completes.
High MAXBUF and NUMBUF values combined with SEQOPT=0 usually do not affect ESQA usage. These buffers are allocated above the line from the private area; ESQA space is acquired only when an EXCP into one of the buffers is started.
In a single-user run like BATCH204 (except for look-ahead read, CREATE, and INITIALIZE), only one EXCP is issued at a time in uniprocessor mode, or up to 30 at a time in MP mode; the number of EXCPs is limited. Therefore, the amount of ESQA acquired is generally quite small. A large buffer pool for CREATE, INITIALIZE, and FILE LOAD is not necessary, and MAXBUF=100 should be sufficient.
However, in large multiuser Onlines, large buffer pools are quite common. Depending on user activity, it is possible for the Model 204 Online to have more than 500 concurrent-database I/Os pending. CCA recommends XMEMOPT=2 in these kinds of systems. These Onlines usually use more ESQA than BATCH204 jobs, because more concurrent I/Os are in progress.
Excessive ESQA usage might also occur as a result of channel and device contention: I/Os do not complete as fast as they otherwise would and pending I/Os hold space in ESQA over longer time periods. Even in these environments, however, ESQA usage usually does not exceed 10-15K bytes.
Because SEQOPT=1 causes a read of the next Table B page identified by the found set (regardless of data references), a FOR loop that fails to reference at least one field in each record runs at CPU speed and could generate up to NUMBUF I/O requests in a matter of several seconds. This loop, which consumes resources only to verify that the entire range of pages in Table B are free of I/O read errors, could result in a significant increase in ESQA requirements for the job.
Using MVS monitoring tools such as RMF or OMEGAMON, you can monitor actual SQA and ESQA usage on a per-address-space basis to determine whether common storage shortages are likely to develop. Model 204 should be a minor consumer of that storage.
The following RMF Common Storage report shows several Model 204 address spaces and their storage utilization, in bytes, under the AMOUNT USED columns. These amounts are quite small and consistent with Model 204’s usage of CSA and SQA, with the exception of the highlighted job. That job had look-ahead read enabled, NUMBUF=3000, and was running a FOR loop against a FIND ALL RECORDS found set, which contained NO field references.
by Tym Stegner
By this time, most any company you can name is deeply involved in Year 2000 problem evaluation or remediation. Fortunately, System 1032 users running on the OpenVMS operating system generally experience few Y2K problems.
Most remediation in the System 1032 world requires changing form fields or report formats to allow a 4-digit date. Because we have used System 1032 Date data types, we are safe from the dreaded "data expansion" problem.
However, in a couple of instances, some additional work must be done to address Y2K issues.
When a 2-digit year has been stored as an integer that is also part of an identification code, it cannot be expanded into either a Date data type or a 4-digit year.Two solutions can be employed for this situation.
The first solution, using a substitution array, is easier. Define a 100-element integer or date array (or both, depending on what you need) having the array index declared as 0:99. Store this array right in the dataset, and create an OPEN trigger procedure to populate the array with the year values based upon the value of $CENTURY_BOUNDARY, as shown in the following example:
Dataset WHATEVER Variable XDATE Array (0:99) of Integer format i4 Procedure Fill_Xdate Trigger Open Enabled Secure var ixx integer for ixx from 0 to 99 do if ixx+1900 lt $CENTURY_BOUNDARY then let xdate(ixx)=ixx+2000 else let xdate(ixx)=ixx+1900 end_if end_for End_Procedure Atr... Atr... End_Dataset
Now, anywhere that you would have used the 2- digit year, use the array instead, with the attribute as the array index.
Voila! Instant 4-digit year, using the same $CENTURY_BOUNDARY setting as the rest of your dates!
The second solution is to process your 2-digit date string directly into a date variable using $DATE and $TEXT:
Let Var_ATR = $DATE("1/1/"&$TEXT(atr,iz3[2:3]));
This also obeys $CENTURY_BOUNDARY. Just use the variable any place that you would have used the attribute.
Note that the first solution works for any record in the dataset, while the second must be recalculated for each new record used.
Another Y2K issue arises when accessing 2-digit years using RDs.
Historically, you could use the RD date formats 2 (mmm-dd-yyyy), 3 (mm/dd/yyyy), and 4 (mmddyyyy) to produce 2- or 4-digit years by specifying the appropriate length of the field. However, for Y2K compliance, these formats changed in V9.70; they no longer produce a 2-digit year (see the V9.70 Release Notes). This change prevents applications from destroying data by losing the century information.
Any attempt to output dates in a 2-digit format using these formats gives the following error:
%S1032-E-CBFOVFL, character buffer overflow
If you must output a 2-digit date, you can still use the predefined 2-digit format 5 (yymmdd).
by Jim Marnell
On October 20, 1998, Computer Corporation of America made some changes that affect how you access and transport documentation to our FTP server.
The new FTP site name is:
ftp.cca-int.com
Any other server name or address that you have been using is no longer available.
Anonymous logon to the server is no longer allowed, and a user name and password are required.
Once you have successfully logged on to the new server, you can use two directories:
Upload instructions appear in the first line of the greeting you receive after you have logged in. Following these instructions are the terms and conditions you agree to when you choose to use this site. The outgoing directory has been set up as a location for CCA to use for transmitting information.
Upload instructions for using this new FTP site are also in the readme file in the Access Secure Maintenance Information area on CCA’s Web site. If you have any questions or problems, call Customer Support at 1-800-755-4222.
To deposit a file for CCA:
by Mark LaRocca
At IMPACT’98, CCA introduced our customers to WebGate. At the time, we did our best to answer your questions and address the issues that you felt were most important, such as security, performance, ease of use, and so on. Now, after developing several customer prototypes and hitting the dusty trail and seen first hand the types of applications you want to bring to the Web, it seems fair to revisit some of those questions and to address some new ones based on our experience. But first, the basic question...
WebGate helps you conduct real business with Internet/intranet applications.
WebGate is based on a strategic, multi-tier architecture that scales easily as your number of users, Web-based applications, and databases grow over time. It is open at every level, and supports the use of best-in-class Web design and programming tools, Web servers, and ODBC-compliant databases.
Most importantly, WebGate makes Model 204 data accessible to Web-based applications.
Our tests were conducted on a 250-mhz Pentium PC running NT 4.0 and IIS 3.0. Interfacing with a single Model 204 region, throughput reached 1.2+ million transactions per 24-hour period. Of course, the Model 204 region easily handled the requests. To increase the throughput, simply adding more WebGate Web servers.
The transactions included significant updating requests using both SQL and remote command line (RCL) User Language requests.
Novice Web programmers especially like the WebGate Developer, because they can generate simple applications in minutes. The template-based WebGate Developer can be used, for example, to generate an SQL drill down query consisting of three Web pages. You are prompted, step by step, for columns to display and use for inquiry. Also, RCL templates can quickly produce Model 204 reports. Just enter the procedures and input required to see a Model 204 report in a browser text box with automatic scrolling. Of course, complex applications require more robust coding capabilities,
WebGate’s HTML-like coding language is simple and powerful. Also, with a little experience, programmers can use server side JavaScript or VBScript with WebGate extensions for even more intricate applications.
Yes.
One of our customer prototypes makes use of this capability, and it is quite simple, once the up-front design work is finished.
The application uses RCL to pass requests to Model 204. These requests log the user on to the APSY, feed the APSY screen input from the Web application user, and format data for presentation to the user.
The code uses WebGate’s programming language and server side VBScript capabilities.
Presentation at the browser uses HTML and VBScript to format screens and populate MS Word and Excel documents at the user’s PC with Model 204 data.
And, this spectacular presentation can be achieved with minimal changes to the Model 204 APSY and related procedures.
Security remains the most important concern when implementing a Web application.
Because of WebGate’s flexible three-tier architecture, security can be implemented at several levels and makes use of industry-standard software:
Conference Season Cometh
US’99
System 1032 users are reminded that the new user conference exclusively for System 1032, US’99 will be held in the Boston area March 28-30. Not only is US’99 a FREE CONFERENCE, but CCA will pay the hotel accommodation for speakers. So get those abstracts in now! (E-mail Nancy_Diettrich@cca- int.com). Please let us know soon if you will be coming so that we can arrange conference and accommodation facilities for this exciting new user forum.
Contact CCA Webmaster Copyright 2008
