What is SQL and why you need SQL? | Type of SQL | Introduction to SQL | Structured Query Language (SQL) Example - Quick Guide.

SQL - Structured Query Language. 

COBOL+DB2 application program uses SQL statements. These SQL statements are used to select, insert, update, and delete data from the DB2 tables. These SQL statements must be embedded into the host language programs such as COBOL, JAVA, or REXX.

Welcome to today's session on "Structure Query Language (SQL)". In this session, discover what is SQL statements and why you need them in your COBOL+DB2 application programs. Learn why you need DB2 pre-compilation for COBOL+DB2 programs. So, without wasting any time let's get started with today's SQL tutorial. 

 Agenda. 

• What is Data and why it is important?
• What is SQL and why you need it?
• Features of SQL ( ie. Structure Query Language).
• What is the difference between SQL and Host language? 
• What are the different types of SQL statements?
• SQL statements examples. 

What is Data and why it is important?

Data is a collection of facts, that computers can understand and process. So, when you book your flight or pay utility bills, or share photographs on the social media platform. 

Your action generates tons of data. Different storage mediums such as databases, file systems, etc. store generated data for processing. Large-scale enterprise applications generally use the database to store this valuable information. 

Proper storage and analysis of data not only improve the process but also boost profit. 

Now, the question is how to store and access data from the database. The answer is SQL or structured query language. 

An Overview of SQL.

The term SQL stands for "Structured Query Language". it's popularly known as "SQL" or "SEQUEL" or “ESS-CUE-EL”. SQL is a powerful data manipulation tool that is supported by all the leading RDBMS products such as DB2, MS SQL Server, Oracle, MYSQL, etc.

"SQL is the language that communicates with the database." 

The programmer uses SQL statements to specifies what data to be fetched or updated, but does not specifies how to perform the operation. DBMS parse and analyze the SQL statement to find the optimal path to retrieve data from the tables. 

Features of SQL.

SQL is not just a query language but it's the complete package in itself. The structured query language (SQL) provides all most all features of a high-level programming language such as JAVA, COBOL, REXX, C++, etc. In fact, users can easily manipulate data without writing a huge chunk of code. Following are a few salient features of SQL. 

• SQL is simple and easy to use. 
• SQL is flexible and portable. 
• SQL statements are used to retrieve data instead of lengthy code. 
• SQL is a free-form structure. 

What is the difference between SQL and Host language?

A high-level programming language such as COBOL, JAVA, REXX, etc. is designed to processing one record-at-a-time. However, SQL is designed to process a set of records at-a-time. In set-level processing, all operations applied on the set and the output is a set of records. But, sometimes the result set can be an empty or single row. 

Host languages such as COBOL, JAVA, REXX, etc. can not handle many records in a single request. Thus, in the COBOL-DB2 or JAVA-DB2 application, you need a DB2 cursor and host variables to process many records.

SQL vs Host language.

Let's talk about the different types of SQL statements. 

What are the different types of SQL statements?

There are no specific criteria for categorizing SQL statements. SQL statements are generally categorized into two categories.

    - SQL Functionality.

    - SQL Execution.

The two categorized further sub-divided into many categories. Let's look at each of them one by one. 

Based on the Functionality the SQL statements are of three types: 

1. Data Control Language (DCL): Control the user access to data. SQL statements such as Grant/Revok are used to grant or revoke user access to the data. 
2. Data Manipulation Language (DML): Maniulupate data stored in the database tables. SQL statements such as Select, Insert, Update, and Delete is used to perform various data manipulation operations. 
3. Data Definition Language (DDL): Create data objects such as tables, views, etc. SQL statements such as Create table, Drop table is used to create database objects.

Type of SQL Statements.

Based on the Execution the SQL statements are of two types:

1. Static SQL or Embedded SQL statements: These SQL statements are hardcoded into application programs such as COBOL+DB2.  
2. Dynamic SQL statements: These SQL statements are prepared by the application program during the run-time.    

SQL statements examples.

Following are some SQL statement examples. 

 

 

What is SQL and why you need SQL?

This SQL tutorial is linked to a YouTube video for better understanding. Please do visit and consider subscribing to my channel. 

Conclusion. 

In this SQL tutorial, you'll why is SQL and why you need it. You also learn the basics of SQL, type of SQL statements based on functionality and execution. Followed by SQL examples for better understanding. 

►Subscribe to Topictrick & Don't forget to press THE BELL ICON to never miss any updates. Also, Please visit below mention the link below to stay connected with Topictrick and the Mainframe forum on - 

► Youtube

► Follow us on Twitter  

► Facebook 

► Linkedin

► Reddit

► Mainframe Blog

► Medium Blog

Thank you for your support. 

Mainframe Forum™

Enable GingerCannot connect to Ginger Check your internet connection
or reload the browserDisable in this text fieldRephraseRephrase current sentenceEdit in Ginger×

Db2 History: System R, SQL, MVS, z/OS, and Db2 UDB



Db2 grew from SQL research into mainframe production data.

A COBOL program that runs EXEC SQL today is using ideas IBM researchers worked on before DB2 had a product name. The history matters because many current Db2 for z/OS habits still come from that path: static SQL, precompile, DBRMs, packages, plans, catalog metadata, and cost-based access paths.

This article keeps the timeline practical. It is not a museum tour. It explains how Db2 moved from relational research to the mainframe database system used by batch jobs, CICS transactions, IMS programs, and reporting workloads.

Db2 history at a glance

Period	Milestone	Why mainframe developers still care
1970s	IBM relational database research, including System R and SQL work	The SQL model used by COBOL programs, SPUFI, QMF, and application tools traces back to this work.
1981	SQL/DS for VM and VSE	IBM had a commercial relational database before DB2 for MVS became the mainframe name most developers know.
1983	DB2 for MVS Version 1 announced	This is the mainframe line that later became Db2 for z/OS.
1990s	DB2 expanded across distributed platforms and used the DB2 Universal Database name	Teams began seeing DB2 across mainframe and non-mainframe systems, with different platform behavior under a shared product family.
2000s onward	Db2 for z/OS evolved with 64-bit z/OS, data sharing, XML, security, and newer SQL features	The mainframe version kept its own operational model: subsystems, buffer pools, packages, plans, utilities, and workload controls.

Relational database research came first

Before DB2, IBM research work on the relational model changed how application data could be described. Instead of making every program navigate physical record chains, the relational approach let developers ask for rows and columns through SQL.

That sounds ordinary now, but it was a major change for mainframe teams used to hierarchical and network-style access. A program could ask for customer rows that match account status, branch number, and date criteria without coding every physical navigation step.

System R helped prove SQL could work

System R was an IBM research project that tested relational database ideas and SQL. It influenced later commercial systems because it showed that SQL did not have to be only a research language; it could be compiled, planned, and run with usable performance.

The cost-based access path idea is especially important for Db2 developers. When a COBOL program uses static SQL, Db2 can evaluate access paths during bind. That is why catalog statistics, indexes, and bind output matter so much for production performance.

SQL/DS came before DB2 for MVS

IBM's SQL/DS product ran on VM and VSE environments before DB2 for MVS became the better-known mainframe relational database. SQL/DS matters in the history because it shows that IBM relational database work was not a single product jump from research directly to DB2 for z/OS.

Many older sites had mixed platform histories. A team might have VM/VSE SQL/DS background, MVS DB2 workloads, and later distributed DB2 systems that shared SQL concepts but differed in operations, utilities, and tuning.

DB2 for MVS arrived in 1983

DB2 for MVS Version 1 gave the MVS mainframe a relational database product built for enterprise workloads. The name DB2 marked a move from older data access styles toward SQL-based relational processing on the mainframe.

For application programmers, this created the work pattern that still appears in many shops: write embedded SQL in COBOL or PL/I, precompile the source, bind the DBRM, run the program under a plan, and tune access paths when the batch window starts to hurt.

DB2 UDB widened the product family

In the 1990s, IBM used the DB2 Universal Database name across mainframe and distributed products. The phrase "Universal" reflected support for more data types and platforms, including AIX, Windows, OS/2, HP-UX, Solaris, and parallel processing environments.

This is where some confusion starts for learners. DB2 on distributed platforms and Db2 for z/OS share SQL heritage, but the day-to-day administration is not identical. A mainframe developer still has to know about subsystems, buffer pools, table spaces, plans, packages, utilities, and z/OS job control.

Db2 for z/OS kept the mainframe operating model

Modern Db2 for z/OS runs as a major subsystem on z/OS. It works with address spaces, workload controls, buffer pools, logging, utilities, security rules, and data sharing groups. CICS, IMS, batch, and distributed requesters can all reach Db2, but each path has its own operational checks.

The product name is now styled as Db2, but older posts, JCL comments, bind decks, and manuals often say DB2. In practice, mainframe teams still use both spellings in conversation. For current writing, Db2 is the cleaner style; for old job names and historic product names, DB2 may still be accurate.

Why the history helps in daily DB2 work

• Relational design explains why tables, keys, predicates, and joins are central to application logic.
• System R explains why the optimizer and access path selection became part of Db2's identity.
• DB2 for MVS explains why static SQL, DBRMs, packages, and plans remain visible in mainframe build pipelines.
• DB2 UDB explains why the same product family can behave differently across z/OS and distributed platforms.
• Db2 for z/OS explains why database work is tied to JCL, security, utilities, and subsystem operations.

Related DB2 topics

After the history, the practical next steps are Db2 Origins of SQL, Db2 Early Vendor Implementations, Db2 Objects, Db2 Binding an Application, and Db2 Optimizer.

For current product positioning, see IBM's Db2 for z/OS product page.

FAQ

Is DB2 the same as Db2?

They refer to the same IBM database family in most mainframe conversations. DB2 is the older styling, while Db2 is IBM's current styling. Historic product names and old JCL comments may still use DB2.

Did Db2 start on z/OS?

No. The relational database work started before z/OS existed. DB2 for MVS was announced in 1983, and the mainframe line later became Db2 for z/OS.

Why does Db2 history matter to COBOL developers?

It explains why embedded SQL programs still use precompile, DBRMs, packages, plans, and bind-time access path choices. Those are not random build steps; they come from Db2's static SQL design.

When you read old DB2 material, map the history back to the job in front of you: subsystem, table space, package, plan, SQLCODE, and access path.