By
Don Fowler - June 2004
The accelerated delivery of new releases of operating system, DB2, CICS, and other system components to exploit the UNICODE, Web, JAVA, and CORBA compliance shows that tighter and tighter integration of software products is occurring in order to achieve more object oriented open systems.
Many people want to focus on some of the underlying architecture of z-Series. Such as the 64-bit implementation. The underlying architecture just indicates if you are on a 8-cylinder or 4-cylinder engine. Performance and capacity related for sure, but not the real reasons for going there. The real reasons are the new functions provided that solve business problems and features that increase productivity of development and debugging tasks.
That is what the new PLI brings to the table. And you can get there with a rather trivial migration from older LE PLI compilers at an upgrade cost that would be considered a rounding error on the software budget.
Object code produced by the VisualAgeŽ PL/I for OS/390 Version 2 compiler is compatible with that produced by the V3 compiler (as long as the matching CMPAT option is used). Enterprise PLI V3 provides improved object code compatibility with the code generated by the PL/I for MVS and OS PL/I V2R3 compilers. In particular, this compiler supports the CMPAT(V2) and CMPAT(V1) options. Previously, only non-string scalars could be passed to or received from old code. Now, strings, arrays, and structures may also be passed to and received from old code.
The first enhancement of note is the inclusion of the Integrated CICS Translator. This is very similar to the integrated SQL coprocessor contained in DB2 V7 and Enterprise COBOL . With this feature (which is controlled via a compiler option), the EXEC CICS replacement statements are brought in at compile time via copybooks. This removes the need for the old pre-compile job step to pre-process the CICS statements. This also eliminates the old problem of the PLI source lines not matching up to the reported line number at debug time. Note that you must be at CICS TS 2.2 to utilize this feature since CICS is providing the copybooks. The compile step will handle EXEC CICS statements in the same way that it handles any use of the MACRO facility. Also, since debugging is against the source code fed to the compiler, you can now debug against the source you wrote (rather than what the CICS pre-compiler produced).
A similar enhancement for SQL has been added. With the integrated SQL preprocessor, it is not necessary to run a separate job step that pre-compiles EXEC SQL statements into PL/I code. Instead, the compile step will handle EXEC SQL statements in the same way that it handles any use of the MACRO facility. Also, since debugging is against the source code fed to the compiler, you can now debug against the source you wrote (rather than what the SQL pre-compiler produced).
Functions and features are needed by the business to utilize the vast number of heart of the business applications that fall under the term "legacy". Enterprises have invested billions of dollars over the last 30 years in 3270 and mainframe based business applications. Many have invested millions of dollars in making the applications Y2K compliant. Why throw all of that investment away now? Wouldn't it be better to be able to reuse and extend those business solutions into e-business and the whole open object-oriented systems world?
How does the new PLI fit into this grand scheme?
One of the major functions is the re-worked Object Oriented PLI support. Full JAVA class mapping of PLI so that the two are 'in-sync'. Truly compatible data types defined between PLI and JAVA. Legacy code can be wrappered to JAVA applications for extending the applications into and onto CORBA compliant environments. For those of you who have not kept up on the object systems world, CORBA is Common Object Request Block Architecture. CORBA implies that a program object will be able to run on any CORBA compliant computing platform. This doesn't mean that the program runs native to the operating environment. It means that the program can be placed in a container that provides the operating system APIs and it will run with no source changes required. To distribute CORBA applications, someone must place the program objects in the proper containers and perform certain other naming and directory actions. Just remember that the source code does not change. You write it once.
Another major enhancement is the introduction of UNICODE support. This allows PLI programs to deal with data strings from other entities (such as JAVA). For those of you who have not kept up on the object systems world, UNICODE can be considered another data representation like EBCDIC or ASCII. If you don't have UNICODE capability you really aren't playing in the interoperability arena. In a recent SHARE presentation it was stated best as:
"Unicode provides a unique
number for every character, no matter what the platform, no matter what the program, no
matter what the language. Without Unicode you get many different code pages, reusing the
same numbers for different characters."
PLI now plays in the multithread world because you need it to support JAVA virtual machines as part of the total interoperability solution. PLI co-existence with COBOL also relies on this multithread capability.
XML, a markup language, is considered the data interconnection layer for e-business. XML defines the semantics of the data not the presentation of the data. It is the industry direction for application integration and platform independent data interchange. XML will allow the sender and receiver to evolve independently of each other. This is considerably different than say EDI that forces specific data formats and transmissions.
The new PLI incorporates a XML parser function as part of the run-time library. This high-speed parser gives PL/I programs the ability to
parse XML documents (in EBCDIC, ASCII, or UTF-16 Unicode) directly within their PL/I
applications. The service and support currency issue should also be considered as
part of the PLI For Z/OS and OS/390 decision process. The XML support can be used to enhance your existing high
performance IMS transactions written in PL/I in a B2B environment by receiving and sending
XML documents. IMS supports the transmission of XML documents in the data portion of the
IMS message. The messages can be placed and retrieved from the IMS messages queue for all
message regions including MPP, IFP, and BMP.
Consider that in December 2004 this newer PLI will be the only one with support.
Migration to this new level from a previous LE-level PLI is trivial. The cost differential is a rounding error in the overall software budget. To get pricing or other information, contact your IBM Business Partner.
The 2004 timeframe is the perfect time to position yourself for both exploitation of new functions as well as long-term continued vendor support.
***** End Of Article ********
Use Your Browser BACK Button To Return To Previous Page