Z/OS parallel sysplex

Its designed for Application Availability of 99.999%

DB2 for Z/OS VS other clustered DBMS

Processing Unicode data in COBOL applications

COBOL supports UTF-16 data. COBOL has no support for UTF-8 data.

About this task

DB2® for z/OS®, however, supports both UTF-8 and UTF-16 data.

Procedure

To process Unicode data in COBOL applications for DB2 for z/OS, perform the following recommended actions:

• Use one of the national data types for Unicode data. For example, use the COBOL PIC N(n) USAGE NATIONAL data type for Unicode character data. These data types are UTF-16 and enable COBOL to support Unicode data.
  Although COBOL does not have a native UTF-8 data type, you can still use a COBOL application to retrieve UTF-8 data from DB2. DB2 converts the output to the format that is required by the application. For example, if you query the DB2 catalog, DB2 converts the data for the COBOL application from UTF-8 to either UTF-16 (for PIC N USAGE NATIONAL variables) or EBCDIC (for PIC X variables). However, you should not store unconverted UTF-8 data in a COBOL variable. For example, if you have UTF-8 data in a PIC X variable, COBOL thinks that the data is EBCDIC and the data could get corrupted. Even something as simple as moving this UTF-8 value from one variable to another variable could corrupt the data, because COBOL pads the variable with X'40' for EBCDIC instead of X'20' for UTF-8.
• Store your data in DB2 in UTF-16. This format often requires more space than UTF-8. However, you gain CPU savings in processing because DB2 and COBOL are both using UTF-16 data, and no conversions are needed.
• Use the DB2 coprocessor to prepare your application.
• Specify the appropriate CCSID for your COBOL application source and data according to the instructions in Specifying a CCSID for your application.
  Recommendation: Use the ENCODING bind option to specify the CCSID of the data. This option typically yields the best performance. However, depending on the situation, you might consider the other options for Specifying a CCSID for your application.
• Do not specify ENCODING UNICODE as a bind option if your program uses PIC X variables and specifies the COBOL compiler option NOSQLCCSID. If you do specify ENCODING UNICODE in this situation, DB2 interprets these character variables as UTF-8, but COBOL does not support UTF-8. Thus, DB2 might misinterpret the data.

http://www-01.ibm.com/support/knowledgecenter/api/content/SSEPEK_11.0.0/com.ibm.db2z11.doc.char/src/tpc/db2z_processunidatacobol.html

64 Bit Address Space

With the release of zSeries mainframes in 2000, IBM extended the addressability

of the architecture to 64 bits. 

With 64-bit addressing, the potential size of a z/OS address

space expands to a size so vast that we need new terms to describe it.

Each address space,called a 64-bit address space, is 16 exabytes (EB) in size; an exabyte is slightly more than one billion gigabytes. 

The new address space has logically 264 addresses. It is 8 billion times the size of the former 2 GB address space. The number is 16 with 18 zeros after it:

16,000,000,000,000,000,000 bytes, or 16 EB (see the slide).

We say that the potential size is 16 exabytes because z/OS, by default, continues to create

address spaces with a size of 2 GB. The address space exceeds this limit only if a

program running in it allocates virtual storage above the 2 GB address. If so, the z/OS

operating system increases the storage available to the user from 2 GB to 16 EB.

The 16 MB address became the dividing point between the two previous architectures (the 24-bit addressability introduced with MVS/370 and the 31-bit addressing introduced in the operating system MVS Extended Architecture or MVS/XA), and is commonly called the line.  The area that separates the virtual storage area below the 2 GB address from the user private area is called the bar.

Z/OS components

The parts on the bottom of the diagram are the z/OS operating system components, and the parts in the top gray box are related to the application work that runs ON z/OS.  Note the key types of application workloads listed there:

•Transaction managers – It includes CICS, IMS TM, AND WebSphere App Server in this category.  z/OS is a key platform for high volume, high value transaction management

•Database – DB2 is the key database these days, but IMS DB and several 3rd party DBMSs like IDMS and ADABAS also fall into the database management category

•Batch – batch is one of the key differentiators on z/OS.  Contrary to popular belief, batch is NOT dead.  It remains a very important application model and will continue to do so as long as IT systems exist.  z/OS is well-suited for running batch because of the OS support via job scheduling, the Job Entry Subsystem, and the ability for System z to process very large volumes of data simultaneously.

•End user access – Users of z/OS applications can be what we think of as “green screen” users of the old 3270 technology.  But nowadays, it is rare for customers to build new systems using 3270.  Most new z/OS applications use web interfaces or SOA services interfaces, just as non z systems do.

And all of these application and database middleware and systems are architected to interlock with System z security software.

IBM Z/OS Environment - Highlevel View

Why USS Supports only EBCDIC 1047?

So why is C designed for EBCDIC 1047? Because z/OS Unix Systems Services (USS) is also designed for it.

When IBM created USS for z/OS, it makes sense that it had to work in EBCDIC. The POSIX standard for UNIX doesn't require the use of ASCII, and z/OS is an EBCDIC operating system. IBM really didn't have a choice.

The problem is that UNIX, and its core programming language C, rely on characters that don't exist in some EBCDIC codepages.

EBCDIC 1047 is designed to include all the characters USS needs - effectively all the characters from Extended ASCII: ISO8859-1.

So EBCDIC 1047 is the default EBCDIC codepage used in USS.

 All parameter and help files are usually supplied in EBCDIC 1047, the C compiler expects code in EBCDIC 1047, and all UNIX file contents default to EBCDIC 1047.