Red Alert - IMS V12, V13 or V14 - potential for IMS to write incorrect log data

Yesterday, IBM issued a Red Alert on IMS. Here's the info. I'm just taking over the text from the Red Alert.

Title:

IMS V12, V13 or V14 - potential for IMS to write incorrect log data and/or over-write 64-bit (key 7) common storage which might belong to another address space.

Users Affected:

Users of IMS that are on V12 or later,

• who are using log buffers in above-the-bar storage (BUFSTOR=64), or
• have callers who supply an above-the-bar log record to the IMS Logger, such as:
      IMS 64-bit Fast Path buffer manager
      Installation-written or vendor-written software

Description:

The IMOVE macro (used by the IMS Logger) uses 32-bit instructions to advance the addresses of the source and target destinations. If the address being advanced is a 64-bit address which crosses a 4GB boundary, then the updated address is incorrect since only the low-half of the address is updated.

The two areas of IMS that are exposed to this are the IMS Logger and the 64-bit Fast Path buffer manager.

The IMS Logger is exposed to the problem if the storage allocated for the log buffers crosses a 4GB boundary. If this is the case, a log record will contain inaccurate data and an attempt will be made to inadvertently write to another location in memory. If this location is key 7, the data will be overwritten; if it is not, IMS will ABEND0C4.

The 64-bit Fast Path buffer manager is exposed to the problem if its BPND5 area crosses a 4GB boundary. To encounter the problem, not only would the area have to cross a 4GB boundary, but log record data must exist in the location where the boundary is crossed.

Recommended Actions:

(1) Determine exposure from IMS Logger or 64-bit Fast Path buffer manager
The IMS Support Center is shipping a diagnostic utility as a ++USERMOD which will determine the exposure of a given IMS system. This can help a customer gauge the urgency for which they should take action, if any. The utility runs as a stand-alone batch job and determines:

1. If the log buffers are above the bar, and if the storage allocated for the log buffers crosses a 4GB boundary.
2. If the 64-bit Fast Path buffer manager is enabled, and if the storage area which might contain a log record crosses a 4GB boundary

To download the utility, obtain it from:
Site: testcase.software.ibm.com
Directory: fromibm/im
File name: IM97624A.trs

The file contains ++USERMODs for IMS versions 12, 13, and 14. Instructions for running the utility are in a ++HOLD card along with its return codes.

If a customer cannot (or does not wish to) run the utility, instructions for determining the exposure via a series of /DIAGNOSE commands are in the ++HOLD card.

(2) Determine exposure from other programs which invoke the ILOG macro:
Installation-written or vendor-written programs can detect if they pass log records which reside above the bar by searching for the flag PRMLL64 which is set by the invoker of ILOG in the ILOG parameter list.

(3) Apply PTF if exposure is identified
If an exposure is identified, the exposed IMS should be:

1. Brought down cleanly (for example, with the /CHE FREEZE or /CHE DUMPQ commands)


2. Cold start IMS with the PTF applied for the appropriate version. The PTFs can be downloaded from ShopZ and are:
V12: UI42725 (APRA PI71688)
V13: UI42726 (APAR PI71701)
V14: UI42685 (APAR PI71702)
A cold start is necessary to prevent the reading of potentially inaccurate log data.


3. After all previously exposed IMS systems in a data sharing group are successfully started with the PTF applied, if there is the possibility of needing to run a database recovery before regularly scheduled image copies will be taken, it is recommended that image copies be taken of all appropriate databases. This eliminates the possibility of reading potentially corrupt log data during a recovery.

If you haven't signed up to the Red Alerts by now, you really should do it. Just go over here.

Realdolmen z Systems e-zine 25

The 25th issue of our RealDolmen z Systems Newsletter was sent out today. You can download it over here. Just like the last times, there's just an English version. No more Dutch or French versions. Since it's been a bit quiet over here on the blog lately, there's lots of new content in this issue. I think I'll post some of it over here as well.

The content ? There is one major topic : software pricing. Usually we are hosting the GSE z/OS Working Group at our HQ, but on November 15, we were hosting the GSE Young professionals Working Group. And for that occasion, I thought I'd write 'A brief history of IBM Software prcing'. It's an introduction to the evolutions we saw in mainframe software pricing over the last 25 years.

We also focus on some announcements, as usual there are some hints and tips and of course the usual table of EOS dates of the operating systems is also present again.

One last note : if you're used to receiving our newsletter and you didn't this time, just send me a mail and I'll take care of it. Apparently we changed mailing systems and I just want to check everything went allright.

Enjoy the reading !

Realdolmen

Once in a while, I'm going off topic, but there's always a reason why. So today I would like to tell you a bit about our company :

Realdolmen is one of the biggest independent ICT experts in Belgium. With around 1,250 highly trained employees, we provide services to over 1,000 customers in Benelux. 
We strive to make ICT more personal, to make the most of your employees’ and your organisation’s potential in every collaboration we’re a part of. We do all this with the motto: ‘To get there, together’.

But I especially want to elaborate a bit on our rebranding. You might already have seen we have a new logo  

But there's more than this. It was inevitable: after helping numerous companies with their digital transformation in 2016, we also underwent a radical change ourselves. Our structure, our approach, our story: it all needed updating to better meet our customers’ needs.Here's a video explaining our strategy and why we went through this rebranding exercise.




For this occasion, we also have a special edition of our simplICiTy magazine that you can download over here. A few of the topics discussed include:

• The story behind the new logo and baseline
• Why we – even though we’re still a technology business – are putting people at the centre of our approach
• How we’ve updated our services to support our customers as much as possible at an operational, tactical and strategic level
• The Internet of Things (IoT), artificial intelligence (AI), smart machines, the hybrid cloud, big data: what trends and hypes do you as an organisation need to take into account?
• What role can ICT play in your organisation’s digital transformation process?

Well, let me know what you think of it !

Red Alert - Potential for loss of access to data on a volume due to erroneous 'End of File' written to the VTOC or VTOCIX on z/OS V2R2 DFSMS

Here's the information for the second Red Alert. It was first published on November 2 (link) with an update on November 4 (link). I'm giving you the info from the updated version

Abstract:

Potential for loss of access to data on a volume due to erroneous 'End of File' written to the VTOC on z/OS V2R2 DFSMS (HDZ2220)

Users Affected:

Systems running z/OS V2R2 with DFSMS Secondary Space Reduction (SSR) function enabled (default)

Description:

For systems with DFSMS Device Manager Secondary Space Reduction enabled, the VTOC may be updated incorrectly if an AbendE37 occurs when no storage space is available while trying to extend to secondary extents on a new volume.

Recommended Actions:

Disable z/OS SSR function of Device Manager until fix for APAR OA51499 is available (instructions below).
Please note: If recent PTF UA82730 is applied then you must remove this PE PTF or apply ++APAR for OA51474 prior to disabling SSR. Please see APAR OA51499 Local Fix for additional details.
Disabling z/OS SSR:

• Issue z/OS Command F DEVMAN,DISABLE(SSR) for current IPL

                          -or-  

• Update DEVSUPxx parmlib member to include DISABLE(SSR) and issue z/OS command SET DEVSUP=(xx,yy) or SET DEVSUP=xx to all systems to persist across IPL's.

If you haven't signed up to the Red Alerts by now, you really should do it. Just go over here.

Red Alert - z/OS V2R2 - Potential for z/OS V2R2 JES2 (HJE77A0) members unable to WARM start

Last week there were two important recommendations for z/OS V2R2 users. Here's the info on the first one. I'm just taking over the text from the Red Alert.

Abstract #1:

Potential for z/OS V2R2 JES2 (HJE77A0) members unable to WARM start.

Users Affected:

Systems running z/OS V2R2 that have the JES2 Checkpoint residing on DASD -and- running in DUAL mode (CKPTDEF MODE=DUAL)

Description:

For systems that meet the above criteria, JES2 uses a change log to contain a summary of updates since the previous checkpoint cycle. JES2 may encounter I/O errors ($HASP291) and/or abends (S18A) when attempting to read in a large valid checkpoint change log. A checkpoint I/O reconfiguration will be triggered in this case, however potential overlays of JES2 private storage from the original error may result in unpredictable errors after exiting the reconfiguration.
Any z/OS V2R2 JES2 member in the multi-access spool (MAS) will not be able to read the checkpoint containing a large valid change log without encountering abends. z/OS V2R1 JES2 members in the MAS will be able to read the checkpoint appropriately, but the z/OS V2R2 members will not be able to WARM start. If the entire MAS is comprised of z/OS V2R2 members, then no member will be able to process the checkpoint and this may result in a required COLD start.
Please see APAR OA51558 for additional details.

Recommended Actions:

For users that meet the above criteria, checkpoint should be switched to DUPLEX mode (CKPTDEF MODE=DUPLEX) to avoid the situation.

If you haven't signed up to the Red Alerts by now, you really should do it. Just go over here.