Following up on the post from David Bond (18 October 2010): > DB2 V8 was released during this time. The minimum hardware support was > advertised to be simply z/Architecture, but that wasn't true. DB2 V8 > required an upgraded z900 and it would not run at all on FLEX-ES. But there > was no way to know that from the documentation. This was a real problem for > ISVs using FLEX-ES.
IBM issued the flash/alert which can be seen at: http://www-01.ibm.com/support/docview.wss?uid=swg21171847 This flash references APAR PQ88207. The "Local Fix" portion of the APAR description states: "Run on hardware the includes the Long Displacement Facility or has the simulation/emulation software." (The quote is literal from the IBM APAR description -- the first occurrence of the word "the" is an IBM typo that should be the word "that".) I was not aware of Long Displacement Facility "simulation/emulation software" which was distributed as a base part of z/OS. Was this simulation capability available in z/VM? > Unlike other changes before and since, the attempt to use this new feature > on a machine that didn't support it did not result in a program check or > some other obvious sign. The long displacement byte was simply ignored in > the original z/Architecture so the wrong location was accessed with typical > unpredictable results. When I first read about the Long Displacement Facility in Principles of Operation I was surprised that IBM did such a truly stupid thing with respect to assigning meaning to bits documented as "unassigned" in previously existing general (unprivileged) instructions. I suppose the real flaw was in the weak implementation in prior machines with respect to enforcing that unassigned bits in instructions were zero. IBM does have legitimate wiggle room here with respect to what is documented in Principles of Operation (but I still think what they did was stupid). The first edition of the z/Architecture Principles of Operation (SA22-7832-00) contains the following text: 1.4.2.2 Problem-State Compatibility A high degree of compatibility exists at the problem-state level in going forward from ESA/390 to z/Architecture. Because the majority of a user's applications are written for the problem state, this problem-state compatibility is useful in many installations. A problem-state program written for ESA/390 operates with z/Architecture, provided that the program: 1. Complies with the limitations described in "Compatibility among z/Architecture Systems" in topic 1.4.1. 2. Is not dependent on control-program facilities which are unavailable on the system. Programming Note: This publication assigns meanings to various operation codes, to bit positions in instructions, channel-command words, registers, and table entries, and to fixed locations in the low 512 bytes and bytes 4096-8191 of storage. Unless specifically noted, the remaining operation codes, bit positions, and low-storage locations are reserved for future assignment to new facilities and other extensions of the architecture. To ensure that existing programs operate if and when such new facilities are installed, programs should not depend on an indication of an exception as a result of invalid values that are currently defined as being checked. If a value must be placed in unassigned positions that are not checked, the program should enter zeros. When the machine provides a code or field, the program should take into account that new codes and bits may be assigned in the future. The program should not use unassigned low-storage locations for keeping information since these locations may be assigned in the future in such a way that the machine causes the contents of the locations to be changed. The Enterprise Systems Architecture/390 Principles of Operation (SA22-7201-08) contains the following text: 1.3.1 Compatibility among ESA/390 Systems Although systems operating as defined by ESA/390 may differ in implementation and physical capabilities, logically they are upward and downward compatible. Compatibility provides for simplicity in education, availability of system backup, and ease in system growth. Specifically, any program written for ESA/390 gives identical results on any ESA/390 implementation, provided that the program: 1. Is not time-dependent. 2. Does not depend on system facilities (such as storage capacity, I/O equipment, or optional facilities) being present when the facilities are not included in the configuration. 3. Does not depend on system facilities being absent when the facilities are included in the configuration. For example, the program must not depend on interruptions caused by the use of operation codes or command codes that are not installed in some models. Also, it must not use or depend on fields associated with uninstalled facilities. For example, data should not be placed in an area used by another model for fixed-logout information. Similarly, the program must not use or depend on unassigned fields in machine formats (control registers, instruction formats, etc.) that are not explicitly made available for program use. 4. Does not depend on results or functions that are defined to be unpredictable or model-dependent or are identified as undefined. This includes the requirement that the program should not depend on the assignment of device numbers and CPU addresses. 5. Does not depend on results or functions that are defined in the functional-characteristics publication for a particular model to be deviations from the architecture. 6. Takes into account any changes made to the architecture that are identified as affecting compatibility. Bob Raicer
