OSPF - Open Shortest Path First

An important aspect in the huge operation is the performance and availability the underlying platform z/OS.

Many applications require a high availability . In the z/OS infrastructure environment, also really important to have fault tolerance like HP nonstop.

For that, Z/OS has the feature called ‘Open Shortest Path First (OSPF)’ network. This is a dynamic routing technique, instead of the static routing that has been used in mainframe environment. This implementation makes the z/OS platform fully tolerant to network failures through automatic failover and recovery.

The failover process

Failover means that when one machine fails, another machine takes over and resumes service. 

To address this issue, and to make further improvements in the z/OS configuration , all z/OS environments can get migrated into the OSPF network.

Open Shortest Path First

As written above, OSPF stands for ‘Open Shortest Path First’. It is a technique where the z/OS network traffic will be routed though the most efficient path. 

- With OSPF we are able to stay fully available on the network in case of a (network) disaster. 

- The failover will be performed automatically and no manual intervention is required. 

With OSPF, z/OS now has its own logical network. This means that there will be no interference with other network changes or failovers outside of z/OS.

Dev-Ops in Mainframe

DevOps is short for ‘development operations’ and this buzz word is increasingly used to describe the delivery of software and infrastructure changes.

DevOps is about the rapid ‘code, build, test, package, release, configure and monitor’ of software deployments - is also called agile infrastructure. Successful DevOps implementation revolves around developing a DevOps culture requiring effective communications between all those involved in the delivery pipeline.

 Here are five developments we need to know about to compete.

1. Large enterprises will get fully on-board

In most large enterprises, DevOps isn’t new. Small teams are using DevOps principles to work on discrete projects, and after a few years of experimenting, they’re starting to rack up successes. But in general, DevOps hasn’t been adopted widely throughout the enterprise. As a result, software releases in the enterprise are still too slow, too buggy and too costly.

Now that multiple teams are proving the value of adopting DevOps practices, C-level executives are taking notice and beginning to wonder whether DevOps might be an answer to some of their organisation’s top business challenges. They’re starting to engage with IT and asking how they can employ DevOps principles at scale throughout the enterprise to bring more speed and quality to business applications.

Interest at the C-level is a positive development because DevOps can’t succeed in large enterprises without executive support. DevOps requires a fair amount of experimentation and a tolerance for failure—the kind of experimentation and failure that might not be acceptable to the organisation’s leaders unless they feel confident that the eventual outcome will be worth it.

As enterprises begin to modernise legacy applications in 2016 and beyond, DevOps will play a central role. Within five years, DevOps will be the norm when it comes to software development.

2. Standards will emerge

DevOps currently has no defined standards, so what passes for DevOps in one organisation might not look much like DevOps in another. That means DevOps entails a certain amount of risk—and large enterprises are notoriously risk averse. Even if your small teams are documenting wins, scaling out DevOps successes to the broader organization can be a process of trial and error, which most enterprises don’t tend to engage in willingly.

As different teams experiment with DevOps and share their successes, there will be opportunities to standardise best practices gleaned from the lessons learned. Standardisation will help mitigate the risk of scaling DevOps practices and could involve everything from testing processes to determining the best deployment tools, even how to use internal coaching across teams.

Eventually, as best practices rise to the top, they will likely become adopted and pervasive across industries.

3. Security will increasingly become integrated with DevOps

Whether they learned the hard way or by watching other organisations get burnt, enterprises know that a security problem caught by users is far more damaging than a security problem they catch internally before it’s released into production.

As the pace of software delivery increases, it poses a challenge for security teams because their primary focus is on releasing and maintaining safe and secure applications. Doing things faster doesn’t necessarily give them the time to thoroughly vet applications before they get into end users’ hands. The challenge lies in finding the right combination of processes that allows thorough security assessments and keeps software releases flowing at a rapid pace. Bringing security and DevOps teams together offers a solution.

Recent high-profile security breaches have made it clear that security cannot be an afterthought. Security best practices and testing must be built into the development process from the beginning—and that means making it a part of the DevOps team.

That said, the full integration of security and DevOps has not become mainstream yet. In 2016 and beyond, security team members will become increasingly integrated into DevOps practices. This will occur with security experts coaching DevOps on how to effectively and efficiently embed application security within software development, deployment, and production cycles.

4. Key technology adoptions that enable DevOps will take off

Because DevOps is still in the beginning stages of adoption, there are few defined tool chains for DevOps and no accepted single standards. However, as organisations learn and share success from their DevOps practices, this will start to change in 2016 and beyond, with a few key technology concepts helping IT maximise speed and quality throughout the software development lifecycle.

Increasing automation

Automated testing, infrastructure and application deployments speed up cycles and reduce errors. By automating routine and repetitive tasks, you decrease cycle times in the software delivery lifecycle also ensure repeatability. As enterprises look to adopt DevOps, the first few wins from a technology tool chain perspective will occur through the adoption of automation that will accelerate tasks, eliminate manual handoffs, and cut down error prone processes.

Decreasing latency

As organisations move to increase the pace of application delivery, they must look at each stage of the lifecycle and identity and remove the biggest hurdles that impede a rapid, high quality delivery cadence of software releases to customers. You can make huge progress by identifying the biggest bottlenecks in the ‘conveyer belt’ delivery pipeline. It’s not particularly useful to remove smaller bottlenecks first because the major bottlenecks can still cause technical ‘debt’ to build up earlier in the pipeline or reduce key resources further down in the pipeline.

Increasing visibility

For high quality applications to be delivered at a rapid pace from inception to the hands of end users, it is important to continuously assess and monitor them at every stage of the lifecycle. You must monitor and measure key metrics against business demands including application user experience, health and availability of the application and infrastructure, and threat and risk monitoring, sharing results across the team through continuous feedback loops. If they don’t meet the business needs, you must then improve and iterate, making constant forward progress.

5. Job roles will evolve

Most IT organisations’ adoption of DevOps will force everyone to adopt new skills—not just from a technical perspective, but also from a cultural one. As developers become more familiar with infrastructure, and operations staff gets more familiar with code, it’s inevitable that jobs will begin to morph and evolve.

In 2016 and beyond, those changes will go beyond development and operations to impact business analysts, planning teams, and even C-level executives. For example, traditional system administrator roles will become less relevant as automation takes over many tasks, while ‘full-stack’ engineers, who are familiar with the entire application technology stack, will start to become more critical.

Roles will evolve as teams become more horizontally embedded around products and services, and multiple roles become part of the extended DevOps delivery chain.

Conclusions for DevOps in 2016

In the digital revolution where software will determine business leadership in the marketplace, it’s critical that enterprises understand the power of DevOps to help deliver higher quality software faster.

DevOps is no longer a fringe movement or even simply an idea for so-called ‘unicorns.’ It’s the way enterprise IT must operate to compete and stay relevant in the marketplace. Armed with these predictions for DevOps, you can be ready for the changes to come—and take steps to be among the innovators, not those left behind

IBM DB2 Analytics Accelartor(IDAA) Components

BPXBATCH utility - How to run C/C++ Programs thru JCL in Z/OS Batch.

BPXBATCH utility

This information provides a quick reference for the IBM-supplied BPXBATCH program. BPXBATCH makes it easy for you to run shell scripts andz/OS® XL C/C++ executable files that reside in z/OS UNIX files through the z/OS batch environment. If you do most of your work from TSO/E, use BPXBATCH to avoid going into the shell to run your scripts and applications.

In addition to using BPXBATCH, if you want to perform a local spawn without being concerned about environment set-up (that is, without having to set specific environment variables, which could be overwritten if they are also set in your profile) you can use BPXBATSL. BPXBATSL, which provide you with an alternate entry point into BPXBATCH, and force a program to run using a local spawn instead of fork or exec as BPXBATCH does. This ultimately allows a program to run faster.

BPXBATSL is also useful when you want to perform a local spawn of your program, but also need subsequent child processes to be forked or executed. Formerly, with BPXBATCH, this could not be done since BPXBATCH and the requested program shared the same environment variables.BPXBATSL is provided as an alternative to BPXBATCH. It will force the running of the target program into the same address space as the job itself is initiated in, so that all resources for the job can be used by the target program; for example, DD allocations. In all other respects, it is identical to BPXBATCH.

For information on c89 commands, see c89 — Compiler invocation using host environment variables.

BPXBATCH usage

The BPXBATCH program allows you to submit z/OS batch jobs that run shell commands, scripts, or z/OS XL C/C++ executable files in z/OS UNIX files from a shell session. You can invoke BPXBATCH from a JCL job, from TSO/E (as a command, through a CALL command, from a REXX EXEC).

JCL: Use one of the following:

• EXEC PGM=BPXBATCH,PARM='SH program-name'
• EXEC PGM=BPXBATCH,PARM='PGM program-name'

TSO/E: Use one of the following:

• BPXBATCH SH program-name
• BPXBATCH PGM program-name

BPXBATCH allows you to allocate the z/OS standard files stdin, stdout, and stderr as z/OS UNIX files for passing input, for shell command processing, and writing output and error messages. If you do allocate standard files, they must be z/OS UNIX files. If you do not allocate them, stdin,stdout, and stderr default to /dev/null. You allocate the standard files by using the options of the data definition keyword PATH.

Note: The BPXBATCH utility also uses the STDENV file to allow you to pass environment variables to the program that is being invoked. This can be useful when not using the shell, such as when using the PGM parameter.

Example: For JCL jobs, specify PATH keyword options on DD statements; for example:

//jobname JOB …
 
//stepname EXEC PGM=BPXBATCH,PARM='PGM program-name parm1 parm2'
 
//STDIN   DD  PATH='/stdin-file-pathname',PATHOPTS=(ORDONLY)
//STDOUT  DD  PATH='/stdout-file-pathname',PATHOPTS=(OWRONLY,OCREAT,OTRUNC),
//            PATHMODE=SIRWXU
//STDERR  DD  PATH='/stderr-file-pathname',PATHOPTS=(OWRONLY,OCREAT,OTRUNC),
//            PATHMODE=SIRWXU
⋮

You can also allocate the standard files dynamically through use of SVC 99.

For TSO/E, you specify PATH keyword options on the ALLOCATE command. For example:

ALLOCATE FILE(STDIN) PATH('/stdin-file-pathname') PATHOPTS(ORDONLY)
ALLOCATE FILE(STDOUT) PATH('/stdout-file-pathname')
         PATHOPTS(OWRONLY,OCREAT,OTRUNC) PATHMODE(SIRWXU)
ALLOCATE FILE(STDERR) PATH('/stderr-file-pathname')
         PATHOPTS(OWRONLY,OCREAT,OTRUNC) PATHMODE(SIRWXU)
 
BPXBATCH SH program-name

You must always allocate stdin as read. You must always allocate stdout and stderr as write.

Parameter

BPXBATCH accepts one parameter string as input. At least one blank character must separate the parts of the parameter string. When BPXBATCH is run from a batch job, the total length of the parameter string must not exceed 100 characters. When BPXBATCH is run from TSO, the parameter string can be up to 500 characters. If neither SH nor PGM is specified as part of the parameter string, BPXBATCH assumes that it must start the shell to run the shell script allocated by stdin.

SH | PGM

Specifies whether BPXBATCH is to run a shell script or command or a z/OS XL C/C++ executable file that is located in a z/OS UNIX file.

SH

Instructs BPXBATCH to start the shell, and to run shell commands or scripts that are provided from stdin or the specified program-name.

Note: If you specify SH with no program-name information, BPXBATCH attempts to run anything read in from stdin.

PGM

Instructs BPXBATCH to run the specified program-name as a called program.

If you specify PGM, you must also specify program-name. BPXBATCH creates a process for the program to run in and then calls the program. The HOME and LOGNAME environment variables are set automatically when the program is run, only if they do not exist in the file that is referenced by STDENV. You can use STDENV to set these environment variables, and others.

program-name

Specifies the shell command or the z/OS UNIX path name for the shell script or z/OS XL C/C++ executable file to be run. In addition, program-name can contain option information.

BPXBATCH interprets the program name as case-sensitive.

Note: When PGM and program-name are specified and the specified program name does not begin with a slash character (⁄), BPXBATCH prefixes your initial working directory information to the program path name.

Usage notes

You should be aware of the following:

1. BPXBATCH is an alias for the program BPXMBATC, which resides in the SYS1.LINKLIB data set.
2. BPXBATCH must be invoked from a user address space running with a program status word (PSW) key of 8.
3. BPXBATCH does not perform any character translation on the supplied parameter information. You should supply parameter information, including z/OS UNIX path names, using only the POSIX portable character set.
4. A program that is run by BPXBATCH cannot use allocations for any files other than stdin, stdout, or stderr.
5. BPXBATCH does not close file descriptors except for 0, 1, and 2. Other file descriptors that are open and not defined as "marked to be closed"remain open when you call BPXBATCH. BPXBATCH runs the specified script or executable file.
6. BPXBATCH uses write-to-operator (WTO) routing code 11 to write error messages to either the JCL job log or your TSO/E terminal. Your TSO/E user profile must specify WTPMSG so that BPXBATCH can display messages to the terminal.

Files

The following list describes the files:

• SYS1.LINKLIB(BPXMBATC) is the BPXBATCH program location.
• The stdin default is /dev/null.
• The stdout default is /dev/null.
• The stdenv default is /dev/null.
• The stderr default is the value of stdout. If all defaults are accepted, stderr is /dev/null.

Overview of Z/OS Crypto

Cryptographic software : ICSF

The Integrated Cryptographic Service Facility or ICSF is the system component that provides
the interface to the hardware. As new functions are implemented in hardware, new versions
of ICSF are made available to exploit those functions. ICSF is available as a component of
z/OS. The most current versions are available at:

http://www.ibm.com/servers/eserver/zseries/zos/downloads/

A number of crypto instructions are now available in the CP and can be coded directly in an
application. However most of the crypto functions can only be accessed by using the ICSF
Application Programming Interfaces (APIs). The API passes the cryptographic request to
ICSF, which determines what hardware is available and which device can best service the
request. The ICSF Application Programmer’s Guide provides a table that describes the
hardware that is required to support the APIs.

How Mainframe(System z) addresses ATM, EFT, and POS processing Requirements?

ATM and POS transactions, which are business critical transactions that require a platform
(hardware and software) that provides robust levels of reliability, availability, and scalability.

The IBM System z server and z/OS operating system provides an ideal environment to host
payment systems. In the following sections, we list the processing requirements that can be
met when running on a System z platform.

1. Availability

2. Parallel Sysplex Clustering

3. Manageability

4. Security

5. Scalability

6. Dynamic Workload balancing

7. IBM Integrated Cryptographic service Facility

8. Integration with External Authorization Systems.

1. Availablity:

System z provides 24-hour a day, 7-days per week availability, which includes scheduled
maintenance. Continuous availability goes beyond just hardware fault tolerance; it is
achieved by a combination of hardware, application code, and good system management
practices.

On a server basis, System z systems are equipped with features that provide for very high
availability:
Redundant I/O interconnect
Concurrent Capacity Backup Downgrade (CBU Undo)
Concurrent memory upgrade
Enhanced driver maintenance
Capacity backup upgrade
On/Off capacity

2. Parallel Sysplex clustering

When configured properly, a Parallel Sysplex® cluster has no single point-of-failure and can
provide customers with near continuous application availability over planned and unplanned
outages. Events that otherwise seriously impact application availability (such as failures in
hardware elements or critical operating system components) have no, or reduced, impact in a
Parallel Sysplex environment.

With a Parallel Sysplex cluster, it is possible to construct a parallel processing environment
with no single point-of-failure. Because all systems in the Parallel Sysplex can have
concurrent access to all critical applications and data, the loss of a system due to either
hardware or software failure does not necessitate loss of application availability. Peer
instances of a failing subsystem executing on remaining healthy system nodes can take over
recovery responsibility for resources that are held by the failing instance.

Alternatively, the failing subsystem can be automatically restarted on still-healthy systems
using automatic restart capabilities to perform recovery for work in progress at the time of the
failure. While the failing subsystem instance is unavailable, new work requests can be
redirected to other data-sharing instances of the subsystem on other cluster nodes to provide
continuous application availability across the failure and subsequent recovery, which
provides the ability to mask planned and unplanned outages from the end user.

A Parallel Sysplex cluster consists of up to 32 z/OS images coupled to one or more Coupling
Facilities (CFs or ICFs) using high-speed specialized links for communication. The Coupling
Facilities, at the heart of a Parallel Sysplex cluster, enable high speed, read/write data
sharing and resource sharing among all of the z/OS images in a cluster. All images are also
connected to a common time source to ensure that all events are properly sequenced in time.

The flexibility of System z, z/OS, and Parallel Sysplex allows customers to create many high
availability system designs, from multiple LPARs in a Parallel Sysplex on multiple System z
servers, to dual LPARs in a Parallel Sysplex on a single System z server.

3. Manageability

A wide array of tools, which include the IBM Tivoli® product and other operational facilities,
contribute to continuous availability. IBM Autonomic Computing facilities and tools provide for
completely fault tolerant, manageable systems that can be upgraded and maintained without
downtime.

Autonomic computing technologies that provide Self-Optimizing, Self-Configuring, and
Self-Healing characteristics go beyond simple hardware fault tolerance. Additionally, the
System z hardware environment provides:

Fault Detection
Automatic switching to backups where available
(Chipkill memory, ECC cache, CP, Service Processor, system bus, Multipath I/O, and soon)
Plug and Play and Hot swap I/O
Capacity Upgrade on Demand

4. Security

On March 14, 2003, IBM eServer™ zSeries 900 was the first server to be awarded EAL5
security certification. The System z architecture is designed to prevent the flow of information
among logical partitions on a system, thus helping to ensure that confidential or sensitive data
remains within the boundaries of a single partition.

On February 15, 2005, IBM and Novell® announced that SUSE® Linux Enterprise Server 9
successfully completed a Common Criteria (CC) evaluation to achieve a new level of security
certification (CAPP/EAL4+). IBM and Novell also achieved United States (US) Department of
Defense (DoD) Common Operating Environment (COE) compliance, which is a Defense
Information Systems Agency requirement for military computing products.

On March 2, 2006, z/OS V1.7 with the RACF® optional feature achieved EAL4+ for
Controlled Access Protection Profile (CAPP) and Labeled Security Protection Profile (LSPP).
This prestigious certification assures customers that z/OS V1.7 goes through an extensive
and rigorous testing process and conforms to standards that the International Standards
Organization sanctions.

These certification efforts highlight the IBM ongoing commitment to providing robust levels of
security to assist customers in protecting their business critical data.

5. Scalability

The Capacity Upgrade on Demand (CUoD) capability allows you to non-disruptively add one
or more Central Processors (CPs), Internal Coupling Facilities (ICFs), System z Application
Assist Processor (zAAP), and Integrated Facility for Linux (IFLs) to increase server resources
when they are needed, without incurring downtime. Capacity Upgrade on Demand can
quickly add processors up to the maximum number of available inactive engines. Also,
additional books (up to a maximum of four in total) can be installed concurrently, providing
additional processing units and memory capacity to a z9® or z10® server.

In addition, the new Enhanced Book Availability function also enables a memory upgrade to
an installed z9 or z10 book in a multi-book server. This feature provide customers with the
capacity for much needed dynamic growth in an unpredictable ATM/EFT world.
The CUoD functions include:

Non-disruptive CP, ICF, IFL, and zAAP upgrades
Dynamic upgrade of all I/O cards in the I/O Cage
Dynamic upgrade of memory

The Parallel Sysplex environment can scale near linearly from two to 32 systems. This
environment can be a mix of any servers that support the Parallel Sysplex environment.

6. Dynamic workload balancing

To end users and business applications, the entire Parallel Sysplex cluster can be seen as a
single logical resource. Just as work can be dynamically distributed across the individual
processors within a single SMP server, so too can work be directed to any node in a Parallel
Sysplex cluster that has the available capacity, which avoids the need to partition data or
applications among individual nodes in the cluster or to replicate databases across multiple
servers.

7. IBM Integrated Cryptographic Service Facility

In addition to the external security modules (HSMs) that are available on other platforms,
BASE24-eps on System z can take full advantage of the IBM Crypto Express 2 card using the
Integrated Cryptographic Service Facility (ICSF) for very high speed and highly available
cryptographic services, such as Personal Identification Number (PIN) translation and
verification and Message Authentication Code (MAC) generation and validation.

8. Integration with external authorization systems

On all platforms, BASE24-eps can use data communications to send requests and receive
responses from external transaction authorization systems. On System z only, other means
of communicating with external authorization systems are available, such as:

IBM WebSphere MQ CICS Gateway for communicating synchronously or asynchronously
with local CICS-based authorization systems. (Synchronous communications is
recommended only for suitably reliable and low-latency systems.)

The IBM External CICS Interface (EXCI) for communicating synchronously with suitably
reliable and low-latency local CICS authorization systems with the lowest possible CPU
cost.

The IBM IMSConnect for communicating with local IMS-based authorization systems.