Job Entry Subsystem(JES)

Job Entry Subsystem, since it’s pretty important to the ability for z/OS to run batch workloads.  

Description

– Component of z/OS that provides the necessary functions to get jobs into, and out of, the system.

– JES2 and JES3 are available.

– Manages jobs before and after running the program; the base control program manages them during processing.

The Job Entry Subsystem does just what the name implies – manages the entry (and exit) 
of jobs into z/OS.  When a batch job (or other kinds of work, actually) needs to run on z/OS, 

JES is responsible 

    - For taking that work in, 

    - Preparing for the allocation of resources, and 

    - Then passing the job into z/OS to be dispatched and run.  

JES manages the output generated by the running programs – it SPOOLs the output to the 
JES SPOOL (pretty much like a print spool on your PC) and temporarily stores it until it can 
be printed or stored or deleted.

“JES2” and “JES3”.   IBM actually sells two different JESes.  

They perform the same basic system functions, but with somewhat different interfaces.  Both were developed in the early days of z/OS, out in the field.  Some customers prefer one, some the other.  JES2 is more widely deployed, although there is a smaller, yet enthusiastic JES3 user community also. 

JCL is the “language” of batch jobs.  A programmer or user creates a JCL file (or as some old-timers say, a “deck”) that describes how a program executes.  The JCL identifies the program, its input and output files, and parameters that influence how the program runs.  

Multiple programs can be strung together in a “job stream” where data is passed to and from the programs in the stream.  

JCL files consist of a series of records, or “cards” that begin with two forward slashes.  

So if you ever see a file that has a bunch of lines that start with //, you’ll know it’s a JCL file that controls the running of a batch job stream.  

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.

Code Pages : C & REXX are exceptional

How C and REXX Mess Things Up

Code pages only change characters that aren't needed when programming or administering the mainframe. Is it correct? NO. That works for traditional z/OS features, and programming languages such as COBOL and PL/1.

But there are a couple of exceptions, and you can safely bet that more will follow.

Take REXX for example.

A common thing to do in REXX is concatenate two strings. This is done using the two vertical bars ('||'). For example, our sample REXX to get z/OS information has the line:

Say 'z/OS version:' zos_ver || '.' || zos_rel

The bad news is that the vertical bar character '|' isn't one of those 'standard' EBCDIC characters. So a vertical bar in EBCDIC 0037 looks like an exclamation mark (!) in Sweden. The REXX interpreter doesn't care what this character looks like, as long as it has a code of 79. So if you're in Sweden and using EBCDIC 0278, the above line becomes:

Say 'z/OS version:' zos_ver !! '.' !! zos_rel

C is another problem child. It uses funky characters like the square brackets '[]', curly brackets '{}' and broken vertical bar '¦'. These move around (or disappear) depending on your code page. But with C there's another catch: it's designed to use EBCDIC 1047, not EBCDIC 0037. So if you're using arrays in C, the line:

char cvtstuff[140];

is fine if you're using IBM1047. For IBM0037, it becomes:

char cvtstuffÝ140´

If you're using EBCDIC 0050, another common EBCDIC code page, it becomes:

char cvtstuffÝ140"

DB2 TIPS

Select unknown values only

For performance reasons it is better to select as few columns as possible. The optimizer may choose techniques like Index-only access. Besides it makes the query easier to read and maintain. In the following query selects five columns of table FOTB100. The first two columns are also used in the where-clause with “=”-predicates. So the values of these columns are no surprise and therefore it is not necessary to select these columns. So leave them out of the column-list.  SELECT         REK_NR       , PE_TX_REF       , ST_TS       , ST       , PRI  INTO        :REK-NR          OF FINTXSTH      , :PE-TX-REF     OF FINTXSTH      , :ST-TS              OF FINTXSTH      , :ST                   OF FINTXSTH      , :PRI                  OF FINTXSTH FROM  FOTB100  WHERE  REK_NR     = :REK-NR    OF FINTXST    AND  PE_TX_REF  = :PE-TX-REF OF FINTXST

EBCDIC - Few details...

From a very early age, most of us are taught about ASCII, and how this is used by computers to convert single byte numbers to the characters we see on our screen. So an 'a' is really 97 as far as the computer is concerned. So imagine my surprise when I found out that mainframes don't use ASCII, but EBCDIC.



I remember my reaction: "You've got to be kidding! Didn't EBCDIC die out years ago?"

Nope. And it's not just z/OS that uses it.
       IBM i,
       Fujitsu BSD2000/OSD,
       Unisys MCP,
       z/VSE,
       z/VM and
       z/TPF all happily continue to use EBCDIC today.

To them an 'a' is really 129, not 97.

This all worked out fine for many years. In fact EBCDIC was the most popular encoding system in the world until the Personal Computer revolution brought ASCII to the limelight.

But EBCDIC falls down when we need to display languages other than English. Words like "på" (Swedish) and "brève" (French) need special characters not necessarily available in the standard EBCDIC table. 

What's worse, there's no way that all these special characters for all the languages in the world are going to fit into the 255 places that an eight bit number has. To get around this, IBM created code pages.

EBCDIC Code Pages

Today there's no such thing as a single EBCDIC code table. You can find a few websites that claim to convert from ASCII to EBCDIC. But the chances are that they're really converting from ASCII to EBCDIC code page 37, or EBCDIC 0037.

EBCDIC 0037 is the default code page used by the United States and other English speaking countries when working with MVS: the traditional side of z/OS. It has all the normal a-z, A-Z, 0-9 characters, and other symbols like +, () and *. It also includes a few of the foreign characters for when we've borrowed foreign words like "resumé".

However if you're in France, the chances are that you'll be using EBCDIC 0297. In EBCDIC 0297, the standard a-z, A-z and 0-9 characters are the the same as EBCDIC 0037. But to see French words, other characters are used for other numbers.

 For example,
       - 177 is a pound sign (£) in EBCDIC 0037, &
       - A cross-hash (#)           in EBCDIC 0297.

There are many different code pages for all the different regions. From Spain and Iceland to Thailand and Japan.

Compare with ASCII

This is not a lot different to ASCII, which has gone from the original 7-bit code ASCII to ISO8859 with its different sub-definitions.

For example
  - ISO8859-1 is the standard 'Extended ASCII' that we all love,
  - ISO8859-2 is better for Eastern Europe, and
  - ISO8859-4 for countries like Latvia, Lithuania, Estonia and Greenland.

IBM controls these EBCDIC code pages, and assigns an ID to them called the Coded Character Set Identifier (CCSID).
 - The CCSID for EBCDIC 0037 is, you guessed it, 37.
 - IBM also has set CCSIDs for other characters sets - CCSID 1208 is Unicode (UTF-8).