z/OS

z/OS supports 64-bit addresses for both virtual[10] and real addresses. Within each address space, z/OS typically permits the placement of only data, not code, above the 2 GB "bar". z/OS enforces this distinction primarily for performance reasons. There are no architectural impediments to allowing more than 2 GB of application code per address space. IBM has started to allow Java code running on z/OS to execute above the 2 GB bar, again for performance reasons.

Starting with z/OS version 2 release 3, code may be placed and executed above the 2 GB "bar". However, very few z/OS services may be invoked from above the "bar".

Memory is obtained as "Large Memory Objects" in multiples of 1 MB (with the expectation that applications and middleware will manage memory allocation within these large pieces). There are three types of large memory objects:

• Unshared – where only the creating address space can access the memory.
• Shared – where the creating address space can give access to specific other address spaces.
• Common – where all address spaces can access the memory. (This type was introduced in z/OS Release 10.)

z/OS Encryption Readiness Technology (zERT) monitors, records, and reports details of z/OS cryptographic network protection. It is a feature of z/OS V2R3 (and later releases) Communications Server component.[11]

With zERT, the TCP/IP stack acts as a focal point in collecting and reporting the cryptographic security attributes of IPv4 and IPv6 application traffic that is protected using the TLS/SSL, SSH and IPSec cryptographic network security protocols. The collected connection level data is written to SMF in new SMF 119 subtype 11 records for analysis.[12]

In certain environments, the volume of SMF 119 subtype 11 records can be large. The zERT aggregation function provides an alternative SMF view of the collected security session data. This alternate view is written in the form of new SMF 119 subtype 12 records that summarize the use of security sessions by many application connections over time and which are written at the end of each SMF interval. This alternate view condenses the volume of SMF record data while still providing all the critical security information.

z/OS Management Facility (z/OSMF) is enhanced to provide a plug-in named IBM zERT Network Analyzer. IBM zERT Network Analyzer is a web-based graphical user interface that z/OS network security administrators can use to analyze and report on data reported in zERT Summary records. With the zERT Network Analyzer, a z/OS network security administrator (typically a systems programmer with responsibility over z/OS Communications Server) can import SMF zERT summary records into a Db2 for z/OS database and then build and run custom queries against that data.

The z/OS Generation Data Group (GDG) is a description of how many generations of a file are to be kept and at what age a generation will be deleted. Whenever a new generation is created, the system checks whether one or more obsolete generations are to be deleted.

The purpose of GDGs is to automate archival, using the command language JCL, the file name given is generic. When DSN appears, the GDG name appears along with the history number, where

(0) is the most recent version

(-1), (-2), ... are previous generations

(+1) a new generation (see DD)

Another use of GDGs is to be able to address all generations simultaneously within a JCL script without having to know the number of currently available generations. To do this, you have to omit the parentheses and the generation number in the JCL when specifying the dataset.

Creation of a standard GDG for five safety scopes, each at least 35 days old:

//STEP1 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
DEFINE GDG (NAME('DB2.FULLCOPY.DSNDB04.TSTEST') LIMIT(5) SCRATCH FOR(35))
/*

Delete a standard GDG:

//STEP3 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
DELETE DB2.FULLCOPY.DSNDB04.TSTEST GDG FORCE
/*

Operational data is data that z/OS system produces when it runs. This data indicates the health of the system and can be used to identify sources of performance and availability issues in the system. IBM Z Operational Log and Data Analytics and IBM Z Anomaly Analytics with Watson collect IT operational data from z/OS systems, analyze and provide insights about the operational data.

IBM Z Operational Log and Data Analytics collects IT operational data from z/OS systems, transforms it to a consumable format, and streams it to third-party enterprise analytics platforms like the Elastic Stack and Splunk, or to the included operational data analysis platform. The included insights can help to visualize and search operational data to help identify the cause of operational issues.[13]

IBM Z Anomaly Analytics with Watson collects IT operational data from z/OS systems, uses historical IBM Z metric and log data to build a model of normal operational behavior, then analyzes real-time operational data through comparison with the model of normal operations to detect anomalous behavior, and notifies IT operations of the anomalous behavior to identify incidents that might lead to business disruption.[14]

IBM Z Operational Log and Data Analytics collects and analyzes both structured and unstructured data, including the following types of operational data:[15]

• System Management Facilities (SMF) data
• Log data from the following sources:
  • Job log, the output which is written to a data definition (DD) by a running job
  • z/OS UNIX log file, including the UNIX System Services system log (syslogd)
  • Entry-sequenced Virtual Storage Access Method (VSAM) cluster
  • z/OS system log (SYSLOG)
  • IBM Tivoli NetView for z/OS messages
  • IBM WebSphere Application Server for z/OS High Performance Extensible Logging (HPEL) log
  • z/OS Resource Measurement Facility (RMF) Monitor III reports
• User application data, the operational data from users' own applications

IBM Z Anomaly Analytics with Watson collects data from multiple IBM Z systems and subsystems, including IBM Db2 for z/OS, IBM CICS Transaction Server for z/OS and IBM MQ for z/OS.[16] The following types of operational data are collected:

• System Management Facilities (SMF) data
• z/OS system log (SYSLOG)