Indexes VS subscripts

Using indexes to address a table is more efficient than using subscripts since the index already
contains the displacement from the start of the table and does not have to be calculated at run time.
Subscripts, on the other hand, contain an occurrence number that must be converted to a
displacement value at run time before it can be used.

When using subscripts to address a table, use a binary (COMP) signed data item with eight or fewer
digits (for example, using PICTURE S9(8) COMP for the data item). This will allow fullword
arithmetic to be used during the calculations. Additionally, in some cases, using four or fewer digits
for the data item may also offer some added reduction in CPU time since halfword arithmetic can be
used.

Performance considerations for indexes vs subscripts (PIC S9(8)):

● using binary data items (COMP) to address a table is 56% slower than using indexes
● using decimal data items (COMP-3) to address a table is 426% slower than using indexes
● using DISPLAY data items to address a table is 680% slower than using indexes

History of Z Series with Z Architecture - I

It got announced in October 2000

 Evolution of ESA-390

    -  24-bit, 31-bit, and 64-bit addressing Supported concurrently

    -  z900 – up to 16 Processors

    -  z800 - up to 4 Processores 

       • Linux-only model in January 2002

       • General purpose model in February 2002

          - Integrated Facility for Linux on z900/z890

 Family of operating systems

    – OS/390     z/OS

    – VSE/ESA  z/VSE

    – VM/ESA   z/VM

    – TPF          z/TPF

    – Linux for S/390  Linux for zSeries

 May 2003

    – z990 – up to 32 processors – configurable as CPs, IFLs, SAPs
    – Up to 256GB memory

 October 2003

     – The Mainframe Charter

 April 2004

     – z890 – up to 4 configurable processors
    – zSeries Application Assist Processor

 October 2004

     – Crypto Express 2

 January 2005
     – FICON Express 2

System z9 EC
(Announced July 26 2005)

- Strengthening the role of the mainframe as the data hub of the enterprise
- New versatile capacity settings designed to optimize capacity and cost
- Continued Improvement in IBM FICON performance and throughput

- On demand innovative technologies to help meet ever-changing business demands

- IBM Z9 IIP(Integration Information Processor) is designed to improve resource      optimization and lower the cost of eligible work.

System z9 BC

(Announced April 27 2006)

- Z9 Technology , for entry level to midsize capacity needs , with a wide choice of capacity settings and highly granular growth options, an increase of 2.6 times more capacity settings than zSeries z890.

- A broad set of speciality engines to facilitate integration of many types of workloads and fully leverage the power of the mainframe.

- Helps protect clients investments in mainframe technologies with upgradeability from Z890 and Z800 servers

- Key system z9 features of advanced security , resiliency, virtualization and connectivity technologies delivered in a midrange package   

System/390 with Enterprise Systems Architecture

System/390 with Enterprise Systems Architecture

Announced September 1990


 Evolution of ESA/370

 1994 – S/390 Parallel Transaction Server

       – Family of CMOS processors

 1998 – System/390 Generation 5 server – more than 1,000 MIPS

 1999 -  System/390 Generation 6 Server - Copper Chip Technology

 Common set of peripheral devices

     – RAMAC, Enterprise Storage Subsystem disk

     – 3590 Magstar tape

 Family of operating systems

      – MVS/ESA  OS/390

      – VSE/ESA

      – VM/ESA

      – AIX/ESA

      – Linux for S/390 (December 1999)

DB2 TIPS : VARCHAR

For each VARCHAR in a copybook you need a datastructure with a length-field and a string:

  EXEC SQL DECLARE GB5F.FINIDOC TABLE
  ( PKEY                           TIMESTAMP NOT NULL,
    APDU                           VARCHAR(11000) NOT NULL
  ) END-EXEC.
                

******************************************************************
* COBOL DECLARATION FOR TABLE GB5F.FINIDOC      *
******************************************************************
          01  DCLFINIDOC.
            10 PKEY                 PIC X(26).
            10 APDU.
               49 APDU-LEN          PIC S9(4) USAGE COMP.
               49 APDU-TEXT         PIC X(11000).
       
Long Varchars
The length-field will be defined as PIC S9(4) COMP. If the length of the VARCHAR is greater than 9999, it seems that this length-field will be too short. But DB2 uses the full binary length (2 bytes), so the length of the VARCHAR can be up to 32.767. Normally COBOL recognises only values until 9999. Bigger values will be truncated (data truncation). Data truncation can be switched off by using the compiler option TRUNC(BIN). The default for this option is (STD). When using STD, the result of a MOVE will be truncated after the number of digits according to the picture-clause. The option TRUNC(BIN) must be specified with a PROCESS-statement in the program source before the IDENTIFICATION DIVISION and before the first line of comment.

Example:

        PROCESS TRUNC(BIN)
        *****************************************************************
        *      PROGRAMMA-NAAM : MU01000
                  

DB2 TIPS : LIKE predicate in DB2

The LIKE predicate offers a great deal of flexibility and power to your SQL statements. Using LIKE you can quickly retrieve data based on patterns and wildcards. However, some uses of LIKE can be confusing to implement appropriately—especially when LIKE is used with host variables. Let's assume that you need to create an application that retrieves employees by last name, but the supplied value for the last name can be either the entire name or just the first few bytes of that name. In that case, the following query can suffice: SELECT EMPNO, FIRSTNME, LASTNAME FROM   DSN8810.EMP WHERE  LASTNAME LIKE :host_variable; In order for this to work, when you enter the value for host_variable, the host_variable always append percent signs (%) to the end of the value. The percent sign specifies that DB2 should accept as a match any number of characters (including 0). This must be done programmatically. So, if the value entered is SM, the host_variable should contain SM%%%%%%%% and if the value entered is SMITH, the host_variable should contain SMITH%%%%%. Append as many percent signs as required to fill up the entire length of the host variable. Failure to do this will result in DB2 searching for blank spaces. Think about it—if you assign SMITH% to a 10-byte host variable, that host variable will think it should search for SMITH%, that is SMITH at the beginning, four blanks at the end, and anything in the middle. So, for SMITH%%%%%, SMITH will be returned, and so SMITHLY (or any name beginning with SMITH). There is no way to magically determine if what was entered is a complete name or just a portion thereof. If this is not acceptable, then a single query will not likely to be feasible. Instead, you would have to ask the user to enter whether a full name or just a portion is being entered.