Are you getting ready do a little spring cleaning? Don’t forget to add your CA OPS/MVS global variable data base to the list!
Spring is usually the traditional time of year to clean-up the dirt and clutter that accumulates over the previous year. Within CA OPS/MVS, nothing gets more cluttered than the global variable checkpoint facility, also known as the SYSCHK1 DIV data set. This system specific linear VSAM file of course stores any OPS/REXX variable that begins with the stem of GLOBAL*, as well as all Relational Data Framework (RDF) tables.
More often than not, the testing of new applications, along with applications that misuse GLOBAL* stemmed variables, leave this file in a cluttered mess. This problem usually triggers the unnecessary effort of increasing the size of the file, and also affects the overall performance of the global variable checkpoint facility.
Follow the below steps to begin the clean-up of your SYSCHK1 file today, and also how to utilize the file more effectively in the future.
Clean-up of OPS/REXX GLOBAL variables
-
From option 4.8 of OPSVIEW, type the name of a valid global variable prefix name (GLOBAL, or GLOBALx where x = 0-9 or A-Z) within the ‘Global Prefix:’ field and hit enter.
-
Variable information for each existing subnode will be listed. As you move your screen display to the right (default PF11), you’ll see fields that list when the subnode was last accessed, and the name of the application that updated the subnode.
-
Use this update information to determine if a subnode or specific variable can be deleted via the ‘D’ option of this panel.
-
Optionally specify a date in the form of yyyy/mm/dd within the ‘Access Date <’ field. This will narrow the display of subnodes whose last access date is less than the specified date. For example, specifying 2006/03/01 for the GLOBAL prefix name, would only display those subnodes that have not been updated since March 1, 2006.
Note: A user defined OPS/REXX program can be created that utilizes the OPSVALUE() to determine the existence of global variable prefix names, and this update information. Creating such a program, may be beneficial to installations that have many OPS/MVS images when performing this clean-up task. Refer to the Command and Function Reference manual for details on the action codes that can be used within the OPSVALUE() to obtain this information programmatically.
Clean-up of RDF tables
-
From option 2.6 of OPSVIEW, get into ‘Browse’ mode of the table called ‘TABLE’. This table will list information regarding all your existing RDF tables.
-
From the command line type and enter ‘KEY 18’. This will lock in the NAME column to assist in viewing. Move to the right (default PF11) and locate the LAST_UPDATE column.
-
Use this information to determine if a table can be deleted. (Tables that begin with ATMSM* are internal to the System State Manager Schedule Manager Component. Use option 4.11 to delete these tables if needed)
Note: A user defined OPS/REXX program can be created that utilizes the Address SQL host environment to select this LAST_UPDATE column from this table. Creating such a program, may be beneficial to installations that have many OPS/MVS images when performing this clean-up task. Refer to the Command and Function Reference manual for details on using the Address SQL host environment to programmatically manipulate RDF tables.
Coding practices to utilize the SYSCHK1 more effectively
-
GLOBAL* stemmed variables should only be used to store data that must be saved across cycles of OPS/MVS and the data that is being saved is not obtainable via some other programmatic method. Meaning, you should not be saving and storing data such as job or device status as this information can be obtained dynamically via OPS/REXX functions.
-
If your are using the OPS/MVS shared variable data base (OPAMSVDB file allocated and writing/reading variables via the OPSHFI() within rules/programs), then do not use a variable stem name of GLOBAL* for your shared variables. Using this variable name will cause the variable to be unnecessarily saved to the SYSCHK1 and this of course is not needed since the OPAMSVDB is being utilized to store the variable. The GLVTEMPx stem name should be used for variables that are being stored on the OPAMSVDB shared variable data base.
-
If data is volatile, then look at other OPS/REXX variable types such as GLVTEMPx, GLVJOBID, static, or simple variables. Doing so will not only clean-up the SYSCHK1, but also eliminate unnecessary I/O to the SYSCHK1.
-
If data is truly non-volatile and warrants the use of a GLOBAL stemmed variable, always utilize the OPSVALUE() to manipulate these variables, especially when checking for the existence of a variable. Refer to the Command and Function Reference manual for information regarding the usage of the OPSVALUE().