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).

SPUFI TIPS

SQL Debugging

Finding a bad character in SQL with SPUFI

You know when you have that forty lines of code you are testing in SPUFI and you get Illegal Symbol ',' and you can't find it. Well you can, those funny numbers after the message to give you a pointer.

Here is an example:


SELECT                                                                  
'A',                                                                    
'BBB' ,                                                                 
,'C'                                                                   
FROM                                                                    
SYSIBM.SYSDUMMY1                                                        
;                                                                       
---------+---------+---------+---------+---------+---------+---------+--
---------+---------+---------+---------+---------+---------+---------+--
---------+---------+---------+---------+---------+---------+---------+-
DSNT408I SQLCODE = -104, ERROR:  ILLEGAL SYMBOL ",". SOME SYMBOLS THAT MIGH
         LEGAL ARE: ( + - ? : CASE CAST USER <FLOAT> CURRENT <DECIMAL>  
         <INTEGER>                                                      
DSNT418I SQLSTATE   = 42601 SQLSTATE RETURN CODE                        
DSNT415I SQLERRP    = DSNHPARS SQL PROCEDURE DETECTING ERROR            
DSNT416I SQLERRD    = 0  0  0  -1  217  0 SQL DIAGNOSTIC INFORMATION    
DSNT416I SQLERRD    = X'00000000'  X'00000000'  X'00000000'  X'FFFFFFFF'
         X'000000D9'  X'00000000' SQL DIAGNOSTIC INFORMATION      

Look at the first SQLERRD line.  The fifth number shows the character position within you SQL with the error.  SPUFI is limited to 72 chars so pos 217 means line 4 position 1 (217/72=3, Rem = 1).

JCL Tips

Cleaning up sequence numbers in JCL

It is well known that JCL statements are from columns 1-72, but SYSIN cards are from 1-80.


Therefore, when we have Num On while editing a JCL and it has SYSIN cards in it, it is good to do UNNUM followed by NUM OFF.  It ensures that sequence number does not remain in cols 73-80 of SYSIN Card and results are predictable.

JCL - II

JCL Syntax

Now that you've run the JCL and seen that it works.

First, you'll notice that most lines start with two slashes. The two slashes mark a line as part of JCL. Lines that do not contain those slashes, such as the last two lines in this job, are usually embedded input files.

//TSOJOB  JOB CLASS=A,NOTIFY=&SYSUID,MSGCLASS=H

- This line is the job header. It defines a job called TSOJOB. 

- The CLASS parameter specifies the job's priority, the maximum amount of resources the job is allowed to consume, and so on. A is a good default in most installations, at least for the short jobs we'll use in this book.

- The NOTIFY parameter specifies that a user should be notified when the job ends. It could be the name of a user to notify, but here it is &SYSUID, which is a macro that expands to the user who submits the job.

- The MSGCLASS parameter specifies that the output of the job needs to be held. This makes it accessible afterward, as you will see in Section 1.3.5, "Viewing the Job Output."

//        EXEC PGM=IKJEFT01

This line starts an execution step—a step in the batch job that runs a program. It is possible for these steps to be named using an identifier immediately after the two slashes. However, this is a very simple job, so there is no need to identify this stage.

The program that this step executes is IKJEFT01, which is the TSO interpreter.

//SYSTSPRT DD SYSOUT=*

This line is a data definition. It defines the data stream called SYSTSPRT, which is the output of TSO. SYSOUT=* means that this data stream will go to the standard output of the job. In the next section, you will learn how to get to this output to read it.

//SYSTSIN  DD *

This line is another data definition. It defines SYSTSIN, which is the input to the TSO interpreter. The value * means that the text that follows is the data to be placed in SYSTSIN.

SEND 'Hello, World' U(ORIPOME)
/*

This is the input to the TSO interpreter. The first line is a command, the same "Hello, World" command we executed in Section 1.2.3, " 'Hello, World' from TSO." The second line, /*, is a delimiter that means the end of the file.

JCL

Entering commands from TSO is one way to accomplish tasks in z/OS, but many other ways exist. 

-   One of the most popular and powerful ways is to create files that contain lists of things to do. These lists are called          batch jobs and are written in z/OS Job Control Language (JCL).

-  It fulfills roughly the same role as shell scripting languages in UNIX.

Introduction to JCL

JCL is a language with its own unique vocabulary and syntax.

JCL to create batch jobs. A batch job is a request that z/OS will execute later.

 z/OS will choose when to execute the job and how much z/OS resources the job can have based upon the policies that the system administrator has set up. 

z/OS can manage multiple diverse workloads (jobs) based upon the service level that the installation wants. 

For example, online financial applications will be given higher priority and, therefore, more z/OS resources, and noncritical work will be given a lower priority and, therefore, fewer z/OS resources

In your batch job, you will tell z/OS this information:

• You'll give the name of your job, with a //JOB statement
• You'll specify the program you want to execute, with a //EXEC PGM=<program name>statement
• If your program uses or creates any data, you'll point to the data using a //DDstatement.

Example Job:

This job executes an IBM-provided z/OS program called IEFBR14. This is a dummy program that tells z/OS "I'm done and all is well." It requires no input and produces no output other than an indication to the operating system that it completed successfully.

//Arunams JOB CLASS=A, NOTIFY=&SYSUID,MSGGLASS=H

//                    EXEC PGM=IEFBR14

You can also run TSO as a batch job by using JCL to tell z/OS this information:

• The name of the job
• The program to run, which is the TSO interpreter IKJEFT01
• Where to get the input for IKJEFT01 and the commands that you want to execute
• Where to put the output from IKJEFT01, the output from TSO, and the commands that you execute

//TSOJOB  JOB CLASS=A,NOTIFY=&SYSUID,MSGCLASS=H
//        EXEC PGM=IKJEFT01
//SYSTSPRT DD SYSOUT=*
//SYSTSIN  DD *
SEND 'Hello, World' U(ORIPOME)
/*