Register for the IBM Master the Mainframe contest today! https://ibm.biz/masterthemainframe
IBM z Systems Development Blog
Register for the IBM Master the Mainframe contest today! https://ibm.biz/masterthemainframe
ChrisLarsson 27000763JH 12,487 Views
XML is an incredibly useful data format for enterprise level applications. A diverse and robust set of tools and a time proven infrastructure have been developed across many platforms to facilitate application development. But a common concern about XML is that it tends to be compute intensive. z/OS includes a very efficient XML parser component called z/OS XML System Services, which addresses many of the computing issues involved with XML parsing. Even so, we are constantly looking for new ways to improve performance.
With the new z13 mainframe, we looked for ways to use the new hardware features to improve XML parsing. One of the great new features is the single instruction, multiple data (SIMD) architecture. The new processor architecture includes 32 registers, each of which are a full 16 bytes wide. To operate on these registers, there is a full featured set of vector instructions which can operate on multiple operands at one time. Indeed, they can perform up to 16 simultaneous arithmetic, logical, or floating point operations. But the instructions which are the most interesting for XML parsing are the vector string instructions.
Why are vector string instructions so interesting? Well, in order to be compliant with the industry standard XML specifications, each character in an XML document must be checked to make sure it complies with the parsing rules. These rules are different depending on which structures are being examined at any one time. For example, element names have different parsing rules than attribute values. This means that the parsing code becomes more complex, and therefore more processor intensive. Fortunately, we can use the new Vector String Range Compare (VSTRC) instruction! This incredible instruction can perform multiple byte range tests simultaneously on up to 16 sequential bytes. The way this works is the code loads up two vector registers with the comparison specification, then loads up another vector register with the next set of 16 bytes of XML document data. The VSTRC instruction is then invoked, performs the range tests, and the results are placed into yet another vector register. A simple Condition Code check tells the program whether the string passes or not, and if so can move on to the next set of 16 bytes of XML data.
Due to the nature of the vector instructions, the greatest performance advantage is realized when operating on longer strings. These include various XML structures such as tag names, attribute names, character content and attribute values. Documents largely made up of strings which are 16 bytes or longer will show the best improvement. On the other hand, if the documents typically have short strings, then there will probably not be any improvement by using these new instructions.
To enable the XML System Services parser to use vector instructions, your application simply needs to specify the new feature flag, XEC_FEAT_ALLOW_VECTOR for assembler code or GXLHXEC_FEAT_ALLOW_VECTOR for C code on the parser initialization API call. The application doesn't even need to check for the presence of the SIMD architecture. The parser will check if the capability is present, and if not, it will use the non-SIMD support. This new feature is supported only for non-validating parsing applications. It is available in z/OS 2.2, and was rolled back to z/OS 2.1 in the beginning of this year.
System and data availability have always been two of the most important issues for customers. These have become increasingly important with today’s social, highly mobile and interactive environments. IBM has several comprehensive solutions, like GDPS and TPC for Replication (soon to be IBM Copy Services Manager), that offer both data protection and continuous system availability using z/OS HyperSwap technology.
In October 2014, IBM announced a new enhancement to the DS8870 storage system called Multiple Target Peer-to-Peer Remote Copy (MT-PPRC). With this new capability, you can now achieve a higher level of data protection and continuous system availability by maintaining two synchronous copies of the data that protect against a storage system failure or the event of a disaster.
In 2015, IBM extended the value of MT-PPRC by providing mainframe HyperSwap support with this new feature. HyperSwap can move applications and the operating system transparently to either of the two copies of the data without more than a short pause in their operation. HyperSwap operates on IBM's DS8000 Metro Mirror technology which allows replication of data from a primary device to its secondary device. Metro Mirror is a synchronous replication method ensuring that write I/O exists on both the primary and secondary before the I/O is considered complete. The synchronous nature of this replication helps ensure that when HyperSwap automatically swaps to the secondary device; that it is swapping to a fully consistent copy of that device.
The z/OS HyperSwap solution consists of TPC for Replication and the HyperSwap component of z/OS I/O Supervisor (IOS). TPC for Replication provides an end user interface for configuring and monitoring the replication environment, while z/OS HyperSwap monitors the configuration and I/O activities on the devices and performs recovery action (i.e. HyperSwap) when necessary. The HyperSwap component of z/OS I/O Supervisor can also be used with GDPS/PPRC HyperSwap Manager to provide a full end to end service offering for you.
To take advantage of this new HyperSwap protection environment with z/OS HyperSwap, you can create a TPC for Replication Multi-Target ‘Metro Mirror – Metro Mirror’ session. Then using the TPC for Replication GUI or CLI, you can select the desired pairs consisting of a primary and two secondary devices.
When the session is started, Metro Mirror relationships are created between the primary and both sets of secondary devices. Once the Metro Mirror relationships reach a Prepared state, the configuration of all Metro Mirror pairs being managed by the session are given to z/OS HyperSwap in the form of a configuration file. z/OS HyperSwap maintains the configuration file and reacts to failures on the primary devices by performing a HyperSwap to the secondary devices. Once the HyperSwap is completed, system and application programs resume with the secondary devices as the active devices. All of the HyperSwap activities are performed very quickly and transparently to the system and application programs. After the cause of the primary device failure are determined and corrected, you will then have the option to reestablish the HyperSwap protection with the former primary devices as secondary devices.
The TPC for Replication ‘Metro Mirror – Metro Mirror’ session allows for two different policies related to which site z/OS HyperSwap will swap to in the event of a primary site failure. The first option is to allow z/OS to automatically determine which site to swap to. With this option, the z/OS HyperSwap component will make the decision on which of the secondary devices to swap the application to. The second option is to allow a user to set a priority order for the sites. Some customers, while setting up a multi-target configuration for higher availability, still have a preference to which site they want to swap to. This option allows you to tell the z/OS HyperSwap component which site it should attempt to swap to first. However, if z/OS HyperSwap is unable to swap to that site, it will continue to swap to the alternate site.
Multi-target PPRC (MT-PPRC) was introduced to provide immediate availability of data. This support enhances continuous data protection by providing synchronous replication relationships between the primary storage device and additional secondary storage devices. Data written to the primary devices are replicated to multiple secondary devices simultaneously. After a HyperSwap from the initial primary to one of the secondary devices, the new primary devices will then be ready to become the new primary for the remaining secondary storage devices. This will allow establishment of HyperSwap protection using the new Metro Mirror relationships between the new primary storage device and the remaining secondary storage devices without waiting for the former primary storage device to be made available again. If and when the initial primary storage device is made ready again, it then can be added as a new secondary for the current primary storage device. MT-PPRC function with z/OS HyperSwap is available with DS8870 R7.4, TPC-R 5.2.5 and z/OS 1.13 and above with APAR OA46683. The current support allows up to two secondary devices for each primary device. That number may be increased in future supports.
z/OS V2R2 DFSMShsm provides a MOVE option to perform data migration from small to large disk volumes with three simple steps:
During MOVE processing, DFSMShsm selects each eligible data set on each volume and invokes DFSMSdss COPY with DELETE using standard SMS ACS allocation to perform the move. Since the newly defined large volumes have the most free space, they will be automatically selected as the target location of the moves.
For example, to move all open DB2 data sets from a small volume to a large volume, perform the following:
As DFSMShsm processes each DB2 data set, it will invoke DB2 to close the data set, invoke DFSMSdss to move the data set with FlashCopy at both the local and remote site, and then reinvoke DB2 to reopen the data set. (The data set will be skipped if it has active DB2 transactions). This process enables active DB2 databases to be moved to larger disk volumes with minimal application impact.
The MOVE option can also be specified at the data set and storage group level.