Sidebar

Examining Business Rules in DB2

DB2
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

This article focuses on the constraint rules as, in most businesses, data often must adhere to a certain set of rules and restrictions.

 

Editor's note: This article is an excerpt from the book DB2 10.1/10.5 for Linux, UNIX, and Windows Database Administration (Exams 611 and 311): Certification Study Guide.

 

A business rule is a statement that defines or constrains some characteristics of the business. According to the Business Rules Group (www.businessrulesgroup.org) organization, a business rule can belong to one of the following:

  • Definitions of business terms (entity rules). An entity is a collection of information about things that are important to the business and worthy of capture. A business term has a specific meaning for a business in some designated context. This describes how people think about things and categorizes them based on behavior and dependency.
  • Facts that relate terms to each other (relationship and cardinality rules). These express relationships between terms and define behaviors in specific situations.
  • Constraints. Every organization constrains behavior in one way or another to prevent an action from taking place.
  • Derivations. These define how organizations can transform knowledge in one form into another to derive facts or inferences.

This section focuses on the constraint rules as, in most businesses, data often must adhere to a certain set of rules and restrictions. For example, companies typically have a specific format and numbering sequence they use when generating purchase orders. Constraints allow you to place the logic needed to enforce such business rules directly in the database, rather than in applications that work with the database. Essentially, constraints are rules that govern how data values can be added to a table, as well as how those values can be modified once they have been added.

 

The following types of constraints are:

  • NOT NULL
  • DEFAULT
  • CHECK
  • UNIQUE
  • Referential integrity
  • Informational

 

Constraints are usually defined during table creation; however, constraints can also be added to existing tables by using the ALTER TABLE SQL statement.

 

Not Null Constraints

With DB2, you use NULL values (not to be confused with empty strings) to represent missing or unknown data or states. And by default, every column in a table will accept a NULL value. This allows you to add records to a table when not all the values that pertain to the record are known. However, at times, this behavior might be unacceptable (for example, a tax identification number might be required for every employee who works for a company). When such a situation arises, using the NOT NULL constraint can ensure that a particular column in a base table is never assigned a NULL value; once you have defined the NOT NULL constraint for a column, any operation that attempts to place a NULL value in that column will fail. Figure 4.1 illustrates how to use the NOT NULL constraint to avoid inserting a NULL value.

 

101415MohanFigure4.1 

Figure 4.1: How the NOT NULL constraint prevents NULL values

 

Because NOT NULL constraints are associated with a specific column in a base table, they are usually defined during the table creation process or during the table alter process. The DB2 commands and the results for the above scenario are as follows:

 

CREATE TABLE employee

     (      EMPID    CHAR(3),

            NAME      VARCHAR(25),

            TAX_ID     INTEGER NOT NULL)

DB20000I The SQL command completed successfully.

 

INSERT INTO employee VALUES

     (001,'JAGGER, MICK', 591075),

     (002,'RICHARDS, KEITH', 234667),

     (003,'WOOD, RONNIE', 257423),

     (004,'WATTS, CHARLIE', 194894),

     (005,'WYMAN, BILL', 691647);

DB20000I The SQL command completed successfully.

 

INSERT INTO employee VALUES (006,'JONES, BRIAN', NULL)

DB21034E The command was processed as an SQL statement because it was not a valid Command Line Processor command. During SQL processing it returned: SQL0407N Assignment of a NULL value to a NOT NULL column "TBSPACEID=2, TABLEID=258, COLNO=2" is not allowed. SQLSTATE=23502

 

If you are wondering what the TBSPACEID=2, TABLEID=258, and COLNO=2 are, they are all the metadata information about the table and the column in the system catalog table. You can query the system catalog tables or views by using a command something like:

 

SELECT

     VARCHAR (A.TABNAME, 10) TABNAME,

     VARCHAR (A.COLNAME, 10) COLNAME,

     A.COLNO, A.NULLS, B.TABLEID, B.TBSPACEID,

     VARCHAR (B.TBSPACE, 12) TBSPACE

   FROM SYSCAT.COLUMNS A, SYSCAT.TABLES B

   WHERE A.TABNAME=B.TABNAME AND A.COLNO=2 AND A.TABNAME='EMPLOYEE';

 

TABNAME   COLNAME   COLNO NULLS TABLEID TBSPACEID TBSPACE

---------- ---------- ------ ----- ------- --------- ------------

EMPLOYEE   TAX_ID         2 N         258         2 USERSPACE1

 

Default Constraints

Just as there are times when it is objectionable to accept a NULL value, there may be times when it is desirable to have the system provide a specific value for you (for example, you might want to automatically assign the current date to a particular column whenever a new record is added to a table). In these situations, you can use the DEFAULT constraint to ensure that a particular column in a base table is assigned a predefined value (unless that value is overridden) each time a record is added to the table. The predefined value provided can be NULL (if the NOT NULL constraint has not been defined for the column), a user-supplied value compatible with the column’s data type, or a value furnished by the DB2 database manager. Table 4.1 shows the default values that the DB2 database manager can provide for the various DB2 data types.

 

Table 4.1: DB2 default values

Column Data Type

Default Value Provided

Small integer

(SMALLINT)

0

Integer

(INTEGER or INT)

0

Decimal

(DECIMAL, DEC, NUMERIC, or NUM)

0

Single-precision floating-point

(REAL or FLOAT)

0

Double-precision floating-point

(DOUBLE, DOUBLE PRECISION, or FLOAT)

0

Fixed-length character string

(CHARACTER or CHAR)

A string of blank characters

Varying-length character string

(CHARACTER VARYING, CHAR VARYING, or VARCHAR)

A zero-length string

Long varying-length character string

(LONG VARCHAR)

A zero-length string

Fixed-length double-byte character string

(GRAPHIC)

A string of blank characters

Varying-length double-byte character string

(VARGRAPHIC)

A zero-length string

Long varying-length double-byte character string

(LONG VARGRAPHIC)

A zero-length string

Date

(DATE)

The system date at the time the record is added to the table (when a date column is added to an existing table, existing rows are assigned the date January 01, 0001)

Time

(TIME)

The system time at the time the record is added to the table (when a time column is added to an existing table, existing rows are assigned the time 00:00:00)

Timestamp

(TIMESTAMP)

The system date and time (including microseconds) at the time the record is added to the table (when a timestamp column is added to an existing table, existing rows are assigned a timestamp that corresponds to January 01, 0001 – 00:00:00.000000)

Binary large object

(BLOB)

A zero-length string

Character large object

(CLOB)

A zero-length string

Double-byte character large object

(DBCLOB)

A zero-length string

XML document

(XML)

Not applicable

Any distinct user-defined data type

The default value provided for the built-in data type that the distinct user-defined data type is based on (typecast to the distinct user-defined data type)

Adapted from Table 13 on page 140 of the DB2 SQL Reference, Volume 2 manual

 

Figure 4.2 illustrates how to use the DEFAULT constraint to insert a default value when no data is supplied for the default column.

 

101415MohanFigure4.2

Figure 4.2: How to use the DEFAULT constraint to provide default data values

 

Like NOT NULL constraints, the DEFAULT constraints are associated with a specific column in a base table and are usually defined during the table creation process or changed during the table alter process. The DB2 commands and the results for the above scenario are something like the following:

 

CREATE TABLE employee

     (    EMPID      CHAR(3),

          NAME        VARCHAR(25),

          TAX_ID     INTEGER WITH DEFAULT 999999)

DB20000I The SQL command completed successfully.

 

INSERT INTO employee VALUES

     (001,'JAGGER, MICK', 591075),

     (002,'RICHARDS, KEITH', 234667),

     (003,'WOOD, RONNIE', 257423),

     (004,'WATTS, CHARLIE', 194894),

     (005,'WYMAN, BILL', 691647);

DB20000I The SQL command completed successfully.

 

INSERT INTO employee (EMPID, NAME) VALUES (006,'JONES, BRIAN')

DB20000I The SQL command completed successfully.

 

SELECT * FROM employee

 

EMPID NAME                     TAX_ID

----- ------------------------- -----------

1     JAGGER, MICK                   591075

2     RICHARDS, KEITH               234667

3     WOOD, RONNIE                  257423

4     WATTS, CHARLIE                 194894

5     WYMAN, BILL                   691647

6     JONES, BRIAN                   999999

 

Check Constraints

Sometimes, it is desirable to control which values will be accepted for a particular item and which values will not (for example, a company might decide that all nonexempt employees must be paid, at a minimum, the federal minimum wage). When this is the case, you can directly incorporate the logic needed to determine whether a value is acceptable into the data-entry program used to collect the data.

 

A better way to achieve the same objective is by defining a CHECK constraint for the column in the base table that is to receive the data value. You can use a CHECK constraint (also known as a table check constraint) to ensure that a particular column in a base table is never assigned an unacceptable value—once you have defined a CHECK constraint for a column, any operation that attempts to place a value in that column that does not meet specific criteria will fail.

 

CHECK constraints consist of one or more predicates (which are connected by the keywords AND or OR) collectively known as the check condition. This check condition is compared with the data values you provide, and the result of this comparison is returned as the value TRUE, FALSE, or Unknown. If the CHECK constraint returns the value TRUE, the value is acceptable, so it is added to the column. If, however, the CHECK constraint returns the value FALSE or Unknown, the operation attempting to place the value in the column fails, and all changes made by that operation are backed out. However, it is important to note that when the results of a particular operation are rolled back because of a CHECK constraint violation, the transaction that invoked that operation is not terminated, and other operations within that transaction are unaffected. Figure 4.3 illustrates how to use a simple CHECK constraint to control which data values are acceptable by a column.

 

101415MohanFigure4.3

Figure 4.3: How to use the CHECK constraint to control what data values are acceptable

 

Like NOT NULL constraints and DEFAULT constraints, CHECK constraints are associated with a specific column in a base table and are usually defined during the table creation process or during the table alter process. The DB2 commands and the results for the above said scenario look something like this:

 

CREATE TABLE employee

     (     EMPID      CHAR(3),

          NAME        VARCHAR(25),

          TAX_ID     INTEGER CHECK (TAX_ID > 1000))

DB20000I The SQL command completed successfully.

 

INSERT INTO employee VALUES

     (001,'JAGGER, MICK', 591075),

     (002,'RICHARDS, KEITH', 234667),

     (003,'WOOD, RONNIE', 257423),

     (004,'WATTS, CHARLIE', 194894),

     (005,'WYMAN, BILL', 691647);

DB20000I The SQL command completed successfully.

 

INSERT INTO employee (EMPID, NAME, TAX_ID) VALUES (006,'JONES, BRIAN', 90)

DB21034E The command was processed as an SQL statement because it was not a valid Command Line Processor command. During SQL processing it returned: SQL0545N The requested operation is not allowed because a row does not satisfy the check constraint "DATAMARTS.EMPLOYEE.SQL140717193343960". SQLSTATE=23513

 

You can query the SYSIBM.CHECK_CONSTRAINTS system catalog table to capture the CHECK constraint information, as follows:

 

SELECT

     VARCHAR(CONSTRAINT_CATALOG,10)   CONSTRAINT_CATALOG,

     VARCHAR(CONSTRAINT_NAME,30)       CONSTRAINT_NAME,

     VARCHAR(CHECK_CLAUSE,40)         CHECK_CLAUSE

   FROM SYSIBM.CHECK_CONSTRAINTS

   WHERE

   CONSTRAINT_NAME='SQL140717193343960';

 

CONSTRAINT_CATALOG CONSTRAINT_NAME               CHECK_CLAUSE

------------------ ------------------------------ --------------------

SAMPLE             SQL140717193343960             TAX_ID > 1000

 

Unique Constraints

By default, records added to a base table can have the same values assigned to any of the columns any number of times. As long as the records stored in the table do not contain information that is not be duplicated, this kind of behavior is acceptable. However, sometimes certain pieces of information that make up a record must be unique (for example, if an employee identification number is assigned to each individual that works for a particular company, each number must be unique—two employees must never have the same employee identification number).

 

In these situations, you can use the UNIQUE constraint to ensure that the values you assign to one or more columns when a record is added to a base table are always unique. Once you have defined a UNIQUE constraint for one or more columns, any operation that attempts to place duplicate values in those columns will fail. Figure 4.4 illustrates how to use the UNIQUE constraint.

 

101415MohanFigure4.4

Figure 4.4: How to use the UNIQUE constraint to control the duplication of data values

 

Unlike NOT NULL constraints, DEFAULT constraints, and CHECK constraints, which can be associated with only a single column in a base table, UNIQUE constraints can be associated with either an individual column or a group of columns. However, each column in a base table can participate in only one UNIQUE constraint, regardless of how you group the columns. Like the other constraints, UNIQUE constraints are usually defined during the table creation process or during the table alter process. The DB2 commands and the results for the above scenario look something like this:

 

CREATE TABLE employee

     (     EMPID      CHAR(3)     NOT NULL UNIQUE,

           NAME        VARCHAR(25),

           TAX_ID     INTEGER)

DB20000I The SQL command completed successfully.

 

INSERT INTO employee VALUES

     (001,'JAGGER, MICK', 591075),

     (002,'RICHARDS, KEITH', 234667),

     (003,'WOOD, RONNIE', 257423),

     (004,'WATTS, CHARLIE', 194894),

     (005,'WYMAN, BILL', 691647);

DB20000I The SQL command completed successfully.

 

INSERT INTO employee

     (EMPID, NAME, TAX_ID) VALUES (005,'JONES, BRIAN', 463642)

DB21034E The command was processed as an SQL statement because it was not a valid Command Line Processor command. During SQL processing it returned: SQL0803N One or more values in the INSERT statement, UPDATE statement, or foreign key update caused by a DELETE statement are not valid because the primary key, unique constraint or unique index identified by "1" constrains table "DATAMARTS.EMPLOYEE" from having duplicate values for the index key. SQLSTATE=23505

 

Regardless of when you define a UNIQUE constraint, when you create it, the DB2 database manager checks to determine whether an index for the columns that the UNIQUE constraint refers to already exists. If so, that index is marked as unique and system required (when an index is marked as system required, it cannot be dropped without dropping the constraint on the base table). If not, an appropriate index is created and marked as unique and system required. This index will then enforce uniqueness whenever new records are added to the columns for which the unique constraint was defined. As with other constraints, you can verify the unique rule by querying the system catalog views:

 

SELECT

     VARCHAR (INDSCHEMA, 8)        INDSCHEMA,

     VARCHAR (INDNAME, 20)         INDNAME,

     VARCHAR (TABNAME, 10)        TABNAME,

     UNIQUERULE,

     SYSTEM_REQUIRED

   FROM SYSCAT.INDEXES

   WHERE

   TABNAME='EMPLOYEE';

 

INDSCHEMA INDNAME             TABNAME   UNIQUERULE SYSTEM_REQUIRED

--------- -------------------- ---------- ---------- ---------------

SYSIBM   SQL140717202520710   EMPLOYEE   U                       1

Because no valid index was present on the EMPLOYEE table for the EMPID column, the DB2 database manager created the index SQL140717202520710 and marked it as system required. To provide a better naming convention, it is advisable to create an index and associate the UNIQUE constraint with the earlier created index, something like this:

CREATE TABLE employee

     (     EMPID      CHAR(3)     NOT NULL,

           NAME        VARCHAR(25),

           TAX_ID     INTEGER)

DB20000I The SQL command completed successfully.

 

INSERT INTO employee VALUES

     (001,'JAGGER, MICK', 591075),

     (002,'RICHARDS, KEITH', 234667),

     (003, 'WOOD, RONNIE', 257423),

     (004,'WATTS, CHARLIE', 194894),

     (005,'WYMAN, BILL', 691647);

DB20000I The SQL command completed successfully.

 

CREATE INDEX ix1_employee ON employee

           (EMPID ASC) ALLOW REVERSE SCANS

DB20000I The SQL command completed successfully.

 

ALTER TABLE employee ADD CONSTRAINT U1_EMPLOYEE UNIQUE (EMPID)

SQL0598W Existing index "DATAMARTS.IX1_EMPLOYEE" is used as the index for the primary key or a unique key. SQLSTATE=01550

 

The DB2 database manager is using the DATAMARTS.IX1_EMPLOYEE index to build the UNIQUE constraint on the table. You can also verify the unique rule in the system catalog view, as follows:

 

SELECT

    VARCHAR (INDSCHEMA, 8)   INDSCHEMA,

     VARCHAR (INDNAME, 20)     INDNAME,

     VARCHAR (TABNAME, 10)    TABNAME,

     UNIQUERULE,

     SYSTEM_REQUIRED

FROM SYSCAT.INDEXES

   WHERE TABNAME='EMPLOYEE';

 

INDSCHEMA INDNAME             TABNAME   UNIQUERULE SYSTEM_REQUIRED

--------- -------------------- ---------- ---------- ---------------

DATAMARTS IX1_EMPLOYEE         EMPLOYEE  U                       1

 

A primary key, which we will look at next, is a special form of a UNIQUE constraint. Each table can contain only one primary key, and every column that defines a primary key must be assigned the NOT NULL constraint. In addition to ensuring that every record added to a table has some unique characteristic, primary keys allow tables to participate in referential constraints.

 

A table can have any number of UNIQUE constraints; however, a table cannot have more than one UNIQUE constraint defined on the same set of columns. Because UNIQUE constraints are enforced by indexes, all the limitations that apply to indexes (for example, a maximum of 64 columns with a combined length of 8,192 bytes is allowable; no column can have a large object, long character string data type) also apply to UNIQUE constraints.

 

Although a unique, system-required index can enforce a UNIQUE constraint, there is a distinction between defining a UNIQUE constraint and creating a unique index. Both enforce uniqueness, but a unique index allows NULL values and generally cannot be used in a referential constraint. A UNIQUE constraint, however, does not allow NULL values and can be referenced in a foreign key specification. (The value NULL means a column’s value is undefined and distinct from any other value, including other NULL values.)

 

Learn more with the book DB2 10.1/10.5 for Linux, UNIX, and Windows Database Administration (Exams 611 and 311): Certification Study Guide.

 

Mohankumar Saraswatipura

Mohankumar (Mohan) Saraswatipura works as a database solutions architect at Kronsys, Inc., focusing on IBM DB2, Linux, UNIX, and Windows solutions. Prior to his current position, he worked as a database solutions architect at Reckitt Benckiser Group, plc (UK), focusing on IBM Smart Analytics System 5600, Siebel, SQL Server, and SAP HANA solutions. 

Mohan is an IBM Champion (2010–2015) and a DB2’s Got Talent 2013 winner. He has written dozens of technical papers for IBM developerWorks and IBM Data magazine. He is an IBM-Certified DB2 Advanced Database Administrator, DB2 Application Developer, and DB2 Problem Determination Master. Mohan holds a Master’s of Technology (M Tech) degree in computer science and an Executive MBA (IT).


MC Press books written by Mohankumar Saraswatipura available now on the MC Press Bookstore.

DB2 10.1/10.5 for Linux, UNIX, and Windows Database Administration (Exams 611 and 311) DB2 10.1/10.5 for Linux, UNIX, and Windows Database Administration (Exams 611 and 311)
Master DB2 database administration and prepare for IBM's Exams 611 and 311: Certified Database Administrator.
List Price $134.95

Now On Sale

BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

RESOURCE CENTER

  • WHITE PAPERS

  • WEBCAST

  • TRIAL SOFTWARE

  • White Paper: Node.js for Enterprise IBM i Modernization

    SB Profound WP 5539

    If your business is thinking about modernizing your legacy IBM i (also known as AS/400 or iSeries) applications, you will want to read this white paper first!

    Download this paper and learn how Node.js can ensure that you:
    - Modernize on-time and budget - no more lengthy, costly, disruptive app rewrites!
    - Retain your IBM i systems of record
    - Find and hire new development talent
    - Integrate new Node.js applications with your existing RPG, Java, .Net, and PHP apps
    - Extend your IBM i capabilties to include Watson API, Cloud, and Internet of Things


    Read Node.js for Enterprise IBM i Modernization Now!

     

  • Profound Logic Solution Guide

    SB Profound WP 5539More than ever, there is a demand for IT to deliver innovation.
    Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects.
    The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the companyare not aligned with the current IT environment.

    Get your copy of this important guide today!

     

  • 2022 IBM i Marketplace Survey Results

    Fortra2022 marks the eighth edition of the IBM i Marketplace Survey Results. Each year, Fortra captures data on how businesses use the IBM i platform and the IT and cybersecurity initiatives it supports.

    Over the years, this survey has become a true industry benchmark, revealing to readers the trends that are shaping and driving the market and providing insight into what the future may bring for this technology.

  • Brunswick bowls a perfect 300 with LANSA!

    FortraBrunswick is the leader in bowling products, services, and industry expertise for the development and renovation of new and existing bowling centers and mixed-use recreation facilities across the entertainment industry. However, the lifeblood of Brunswick’s capital equipment business was running on a 15-year-old software application written in Visual Basic 6 (VB6) with a SQL Server back-end. The application was at the end of its life and needed to be replaced.
    With the help of Visual LANSA, they found an easy-to-use, long-term platform that enabled their team to collaborate, innovate, and integrate with existing systems and databases within a single platform.
    Read the case study to learn how they achieved success and increased the speed of development by 30% with Visual LANSA.

     

  • Progressive Web Apps: Create a Universal Experience Across All Devices

    LANSAProgressive Web Apps allow you to reach anyone, anywhere, and on any device with a single unified codebase. This means that your applications—regardless of browser, device, or platform—instantly become more reliable and consistent. They are the present and future of application development, and more and more businesses are catching on.
    Download this whitepaper and learn:

    • How PWAs support fast application development and streamline DevOps
    • How to give your business a competitive edge using PWAs
    • What makes progressive web apps so versatile, both online and offline

     

     

  • The Power of Coding in a Low-Code Solution

    LANSAWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed.
    Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

    • Discover the benefits of Low-code's quick application creation
    • Understand the differences in model-based and language-based Low-Code platforms
    • Explore the strengths of LANSA's Low-Code Solution to Low-Code’s biggest drawbacks

     

     

  • Why Migrate When You Can Modernize?

    LANSABusiness users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
    In this white paper, you’ll learn how to think of these issues as opportunities rather than problems. We’ll explore motivations to migrate or modernize, their risks and considerations you should be aware of before embarking on a (migration or modernization) project.
    Lastly, we’ll discuss how modernizing IBM i applications with optimized business workflows, integration with other technologies and new mobile and web user interfaces will enable IT – and the business – to experience time-added value and much more.

     

  • UPDATED: Developer Kit: Making a Business Case for Modernization and Beyond

    Profound Logic Software, Inc.Having trouble getting management approval for modernization projects? The problem may be you're not speaking enough "business" to them.

    This Developer Kit provides you study-backed data and a ready-to-use business case template to help get your very next development project approved!

  • What to Do When Your AS/400 Talent Retires

    FortraIT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators is small.

    This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:

    • Why IBM i skills depletion is a top concern
    • How leading organizations are coping
    • Where automation will make the biggest impact

     

  • Node.js on IBM i Webinar Series Pt. 2: Setting Up Your Development Tools

    Profound Logic Software, Inc.Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. In Part 2, Brian May teaches you the different tooling options available for writing code, debugging, and using Git for version control. Attend this webinar to learn:

    • Different tools to develop Node.js applications on IBM i
    • Debugging Node.js
    • The basics of Git and tools to help those new to it
    • Using NodeRun.com as a pre-built development environment

     

     

  • Expert Tips for IBM i Security: Beyond the Basics

    SB PowerTech WC GenericIn this session, IBM i security expert Robin Tatam provides a quick recap of IBM i security basics and guides you through some advanced cybersecurity techniques that can help you take data protection to the next level. Robin will cover:

    • Reducing the risk posed by special authorities
    • Establishing object-level security
    • Overseeing user actions and data access

    Don't miss this chance to take your knowledge of IBM i security beyond the basics.

     

     

  • 5 IBM i Security Quick Wins

    SB PowerTech WC GenericIn today’s threat landscape, upper management is laser-focused on cybersecurity. You need to make progress in securing your systems—and make it fast.
    There’s no shortage of actions you could take, but what tactics will actually deliver the results you need? And how can you find a security strategy that fits your budget and time constraints?
    Join top IBM i security expert Robin Tatam as he outlines the five fastest and most impactful changes you can make to strengthen IBM i security this year.
    Your system didn’t become unsecure overnight and you won’t be able to turn it around overnight either. But quick wins are possible with IBM i security, and Robin Tatam will show you how to achieve them.

  • Security Bulletin: Malware Infection Discovered on IBM i Server!

    SB PowerTech WC GenericMalicious programs can bring entire businesses to their knees—and IBM i shops are not immune. It’s critical to grasp the true impact malware can have on IBM i and the network that connects to it. Attend this webinar to gain a thorough understanding of the relationships between:

    • Viruses, native objects, and the integrated file system (IFS)
    • Power Systems and Windows-based viruses and malware
    • PC-based anti-virus scanning versus native IBM i scanning

    There are a number of ways you can minimize your exposure to viruses. IBM i security expert Sandi Moore explains the facts, including how to ensure you're fully protected and compliant with regulations such as PCI.

     

     

  • Encryption on IBM i Simplified

    SB PowerTech WC GenericDB2 Field Procedures (FieldProcs) were introduced in IBM i 7.1 and have greatly simplified encryption, often without requiring any application changes. Now you can quickly encrypt sensitive data on the IBM i including PII, PCI, PHI data in your physical files and tables.
    Watch this webinar to learn how you can quickly implement encryption on the IBM i. During the webinar, security expert Robin Tatam will show you how to:

    • Use Field Procedures to automate encryption and decryption
    • Restrict and mask field level access by user or group
    • Meet compliance requirements with effective key management and audit trails

     

  • Lessons Learned from IBM i Cyber Attacks

    SB PowerTech WC GenericDespite the many options IBM has provided to protect your systems and data, many organizations still struggle to apply appropriate security controls.
    In this webinar, you'll get insight into how the criminals accessed these systems, the fallout from these attacks, and how the incidents could have been avoided by following security best practices.

    • Learn which security gaps cyber criminals love most
    • Find out how other IBM i organizations have fallen victim
    • Get the details on policies and processes you can implement to protect your organization, even when staff works from home

    You will learn the steps you can take to avoid the mistakes made in these examples, as well as other inadequate and misconfigured settings that put businesses at risk.

     

     

  • The Power of Coding in a Low-Code Solution

    SB PowerTech WC GenericWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed.
    Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

    • Discover the benefits of Low-code's quick application creation
    • Understand the differences in model-based and language-based Low-Code platforms
    • Explore the strengths of LANSA's Low-Code Solution to Low-Code’s biggest drawbacks

     

     

  • Node Webinar Series Pt. 1: The World of Node.js on IBM i

    SB Profound WC GenericHave you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application.
    Part 1 will teach you what Node.js is, why it's a great option for IBM i shops, and how to take advantage of the ecosystem surrounding Node.
    In addition to background information, our Director of Product Development Scott Klement will demonstrate applications that take advantage of the Node Package Manager (npm).
    Watch Now.

  • The Biggest Mistakes in IBM i Security

    SB Profound WC Generic The Biggest Mistakes in IBM i Security
    Here’s the harsh reality: cybersecurity pros have to get their jobs right every single day, while an attacker only has to succeed once to do incredible damage.
    Whether that’s thousands of exposed records, millions of dollars in fines and legal fees, or diminished share value, it’s easy to judge organizations that fall victim. IBM i enjoys an enviable reputation for security, but no system is impervious to mistakes.
    Join this webinar to learn about the biggest errors made when securing a Power Systems server.
    This knowledge is critical for ensuring integrity of your application data and preventing you from becoming the next Equifax. It’s also essential for complying with all formal regulations, including SOX, PCI, GDPR, and HIPAA
    Watch Now.

  • Comply in 5! Well, actually UNDER 5 minutes!!

    SB CYBRA PPL 5382

    TRY the one package that solves all your document design and printing challenges on all your platforms.

    Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product.

    Request your trial now!

  • Backup and Recovery on IBM i: Your Strategy for the Unexpected

    FortraRobot automates the routine tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
    - Simplified backup procedures
    - Easy data encryption
    - Save media management
    - Guided restoration
    - Seamless product integration
    Make sure your data survives when catastrophe hits. Try the Robot Backup and Recovery Solution FREE for 30 days.

  • Manage IBM i Messages by Exception with Robot

    SB HelpSystems SC 5413Managing messages on your IBM i can be more than a full-time job if you have to do it manually. How can you be sure you won’t miss important system events?
    Automate your message center with the Robot Message Management Solution. Key features include:
    - Automated message management
    - Tailored notifications and automatic escalation
    - System-wide control of your IBM i partitions
    - Two-way system notifications from your mobile device
    - Seamless product integration
    Try the Robot Message Management Solution FREE for 30 days.

  • Easiest Way to Save Money? Stop Printing IBM i Reports

    FortraRobot automates report bursting, distribution, bundling, and archiving, and offers secure, selective online report viewing.
    Manage your reports with the Robot Report Management Solution. Key features include:

    - Automated report distribution
    - View online without delay
    - Browser interface to make notes
    - Custom retention capabilities
    - Seamless product integration
    Rerun another report? Never again. Try the Robot Report Management Solution FREE for 30 days.

  • Hassle-Free IBM i Operations around the Clock

    SB HelpSystems SC 5413For over 30 years, Robot has been a leader in systems management for IBM i.
    Manage your job schedule with the Robot Job Scheduling Solution. Key features include:
    - Automated batch, interactive, and cross-platform scheduling
    - Event-driven dependency processing
    - Centralized monitoring and reporting
    - Audit log and ready-to-use reports
    - Seamless product integration
    Scale your software, not your staff. Try the Robot Job Scheduling Solution FREE for 30 days.