Around the world in 64-bit

The migration from OS/390 V2.10 to z/OS V1.4 is similar to other release-to-release migrations, with one exception: the move to the new 64-bit z/Architecture. When you make that switch and your operating system is running in z/Architecture mode, will your current business applications execute correctly? Will there be any problems with systems management tools and middleware when running under z/Architecture? The answers to these questions should give you added comfort in making the decision to move forward to z/OS, because the z/Architecture was designed to protect your current portfolio of 31-bit and even 24-bit applications!

Before we explain the impact of 64-bit to your applications, let's clarify some terms.

• ESA/390 architecture is what the S/390 servers are based on. These include 9672, MP2000 and MP3000 server. ESA/390 is a 31-bit mode architecture. OS/390 and even z/OS can run in this architecture level mode when you specify ARCHLVL 1 in LOADxx.
  
  
• z/Architecture is the base for the zSeries servers (z800 and z900). It includes 64-bit support and other new technology advancements. OS/390 V2R10 and all z/OS releases can take advantage of this architecture by specifying ARCHLVL 2 in LOADxx.

Business applications

Business applications are written to execute business logic. They do not run in an authorized state and have been completely shielded from the changes in the architecture. The subset of the architecture that is used by business applications is identical in ESA/390 and z/Architecture. Since no programming interfaces were changed, applications perceive these architectures as compatible. This means that both 24-bit and 31-bit applications will operate correctly when running in z/Architecture mode. It is that simple. For continued application development and maintenance, as far as the transition to z/Architecture is concerned, you can continue to use the same levels of assembler, compilers and language environment.

Home-grown tools

If you have home-grown tools which execute in an authorized state, they will need to be reviewed. If the program does not deal with real storage addresses, then there is no impact when running in z/Architecture mode. You may proceed to the next section. The best clue that a tool deals with real storage addresses is that it issues the Load Real Address (LRA) instruction.

Now, if you are sitting with a program that is manipulating real storage addresses, a closer examination of the program is required, but there is still a good chance that this program will be compatible! The operating system by default will move data into real storage frames below 2GB as part of the page fixing operation. Therefore, even programs in this category will probably operate compatibly. If the program that creates the virtual storage that is page fixed does not use a new z/Architecture option to request that the page fix uses real storage above 2GB, there is no incompatibility.

One difference with z/Architecture — although it's not really an incompatibility — is that issuing an LRA instruction against virtual storage which is not page fixed will often lead to a program check (which becomes a 0D3 ABEND). Most cases of issuing LRA against pageable storage are errors and it is good that they are caught under z/Architecture. For the other case, where LRA is being used simply to determine if a page is currently back in real storage, the TPROT instruction can be used to answer the same question without causing an error.

IBM software (middleware and tools)

While there should be few business applications that are impacted by the introduction of 64-bit z/Architecture, this is not necessarily true for systems management tools and middleware. Some of these products may depend on real storage addresses (like a performance tool that examines memory activity), or they may actually issue their own I/O instructions.

The good news is these products have received extensive testing and have been in production in many customer environments since the introduction of z/Architecture in December 2000. As early as August 2000, hundreds of products from multiple software vendors were tested on z/Architecture servers. Now, over two years later, you can reap the benefits of this early testing and the efforts of our early support customers covering four releases of z/OS. Simply request the latest maintenance from your software vendors for your tools and products.

As with any release-to-release migration, check with your independent software vendor to ensure all of your products are supported on the new releases of z/OS. Some products may require maintenance or a new release in order to run on new releases of z/OS.

For IBM tools and middleware, you can obtain the latest maintenance for new releases of z/OS by requesting the PSP buckets for your specific server type. For information on other z/OS migration topics, see the Migration to z/OS: Come on in the water's fine article on page 5 of the February 2003 Hot Topics Newsletter.