Re: (External):Re: Unicode services Red alert

[Haselbach, Markus]

Yes we had first 12th of dec.   in our appl test Sysplexthen jumped to 30rd 
dec and had the problem; we tried Ipling with many dates until someone had the 
idea that the tod clock  has near there a special value... 

Brgds
Markus Haselbach


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of J O Skip Robinson
Sent: Friday, October 16, 2015 5:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: (External):Re: Unicode services Red alert

I wish we could take credit for discovering the problem. I've learned that many 
sites do time-warp testing on a regular basis. Remember the Y2K Flash Mob scene 
when we all did that incessantly? I seriously doubt that this problem was 
discovered by IPLing at Dec. 15. There was undoubtedly some further future date 
being explored. Whoa! Unicode is broken. Eventually it was narrowed down by the 
original customer (wishful thinking) or more likely by IBM to the actual fail 
point. 

Our PMR was opened by a diligent colleague who wanted more specific details. 
And I appreciate that IBM complied and supplied more details, especially the 
SAMPLIB pointer, which allowed us to test without the painful need to change 
the system time at IPL. 

OK, I warned about a RACF war story. A DB2 sysprog was trying to debug what 
looked like a RACF problem in DB2. She found a flag documented in DB2 as 'RACF 
available'. She could see that it was zero, so she zapped it to one. This was 
not a DB2 control block but the actual MVS CVT flag. The entire system stopped 
working. Every RACF access of any kind resulted in a WTOR requesting permission 
to allow access. Somehow we got the flag zeroed out before total system 
collapse. Luckily it was the development system, and luckily we didn't have to 
IPL. But that's how I remember the meaning of the RACF flag. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Thursday, October 15, 2015 8:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: (External):Re: Unicode services Red alert

On 2015-10-15, at 21:06, J O Skip Robinson wrote:

> I'm piecing together various clues. It appears to me that:
> 
> 1. The UCCB is a defined control block, mapped in several (!) MACLIB members 
> such as CUNBAIDF.
>  
A more modular design might map it in one macro and call it from all the 
others.  Jurisdiction probably precludes.

> 2. Various flags are defined beginning at UCCB+10.
> 3. Somehow during IPL the system clock has been overlaying UCCB+10 by 
> (presumably) Unicode set up processing.
> 4. No one noticed all this time because the flag nibble in the timestamp has 
> always, coincidentally, indicated 'Unicode available'.
> 5. As of the magic moment on December 15, the clock rolls over and reverses 
> the benign bit. Without the fix, Unicode appears to be unavailable more or 
> less forever. Until the bit once again changes back?
> 
> I suspect that checks for the timestamp are far rarer than checks for Unicode 
> availability. So the fix is to store the clock somewhere else at IPL 
> (UCCB+20) and ensure that the critical flags are zero. Our PMR indicates what 
> I suspected: a zero value means OK, a one value means not OK. This is 
> analogous to the RACF flag in the CVT. Zero means that RACF is functional 
> while one means that it is not. I have a hilarious war story about how I know 
> that. 
>  
And I wonder how the problem was discovered.  Does someone routinely test with 
the system clock advanced a few weeks; long enough for an APAR to turn around?  
May I infer from "Our PMR" that you're the reporting site?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: (External):Re: Unicode services Red alert

[Peter Relson]

Ah, my "no subject" post was rejected by the tooling. 

>I assume the repair is to test the correct bit, ignoring the 
>correct store of the system clock. 

The assumption is incorrect.

>Are all defective macros (even non-GUPI) repaired?

There are no macros involved. The fix is complete.

>Presumably they decided to move the timestamp field rather than whatever
>field the tested bit is in. Probably there are lots of places that test 
the
>(incorrect) bit, and just one that stores the TOD clock value there, so
>less code needed to change. 

This is indeed what was done. The main problem with any other approach is 
that the "lots of places" are not limited to IBM load modules. They can be 

packaged with any application (IBM-owned, ISV-owned, customer-owned). 
That is the nature of callable services stubs (which is where the 
erroneous code is). Thus the fix makes things so that those stubs will 
always report "available" because as of z/OS 1.10 it *is* available (and 
if someone has reason to change those stubs, future versions of the stubs 
might not have the test at all).

The error was not only testing the wrong byte. The error was also in 
checking for "off" instead of "on". Thus the test succeeded whenever the 
bit was off. As of Dec 15, the bit will be on and things break. Up until 
the clock gets to X'E' (when things would start working again) and 
then back off again when it gets to x'F'.

Thus Tony's correct that this is a little incomplete:
>...[fails] when the create time of the UCCB time is 
>D000 000 or greater


It wasn't a question of "didn't go very far with testing" but with not 
bothering to discuss something that is likely of no practical relevance 
(and 
perhaps being a bit careless in the details -- no one really needed the 
detail about the clock value either). No one really needed to know 
that it will be broken between 2015 and 2024, then work again until then 
2033, then be broken again until 2042 (or whatever the dates are).  It was 

plenty to know when things break.  As with many things, the less said the 
better. Adding unnecessary details sometimes serves little purpose other 
than to introduce opportunity for having error in those details.

Peter Relson
z/OS Core Technology Design

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: (External):Re: Unicode services Red alert

[Paul Gilmartin]

On Sun, 18 Oct 2015 18:58:27 -0400, Peter Relson wrote:
>
>>Presumably they decided to move the timestamp field rather than whatever
>>field the tested bit is in. Probably there are lots of places that test the
>>(incorrect) bit, and just one that stores the TOD clock value there, so
>>less code needed to change.
>
>This is indeed what was done. The main problem with any other approach is
>that the "lots of places" are not limited to IBM load modules. They can be
>packaged with any application (IBM-owned, ISV-owned, customer-owned).
>That is the nature of callable services stubs (which is where the
>erroneous code is). Thus the fix makes things so that those stubs will
>always report "available" because as of z/OS 1.10 it *is* available (and
>if someone has reason to change those stubs, future versions of the stubs
>might not have the test at all).
> 
This makes sense if the test was intended to report product capability,
not any user selectable option.

In the long run, it's advisable to clean up things sucn as those stubs
to avoid a secular growth of cruft.  And likewise to remove needless
fields in those macros.

>The error was not only testing the wrong byte. The error was also in
>checking for "off" instead of "on". Thus the test succeeded whenever the
>bit was off ...
> 
That might be the consequence of an empirical repair: a programmer may
have coded:

TM
BO

... and got undesered behavior, so decided to change to:

TM
BZ

I think you're saying the bit tested is unconditionally set to 0; never changed,
and the stubs are now just an inefficient implementation of TRUE.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

External):Re: Unicode services Red alert

[Peter Relson]

Apologies. My previous reply had no "subject" but was about the Red alert. 


One of those things that I noticed, naturally, too late, right after 
"send".

Peter Relson
z/OS Core Technology Design

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Unicode services Red alert

[Tony Harminc]

On 15 October 2015 at 21:06, Paul Gilmartin wrote:
>> http://www-01.ibm.com/support/docview.wss?uid=isg1OA48941
>>
> I'm curious: how (not when) does this problem occur?  Is it some
> OCO doing a TM on the wrong address?  I suppose I should infer
> something from:
>
> Problem summary
> 
> Correct the code involved to move the timestamp field to
> allow the Unicode services active indicator to remain valid.

The Red Alert itself makes it reasonably clear.
http://www14.software.ibm.com/support/customercare/sas/f/redAlerts/20150930.html

"A recent problem was discovered in Unicode Services where the check for
the availability of the Conversion Information service, introduced in z/OS
1.10, is checking the wrong bit in the Unicode UCCB to determine if the
function is available. Unfortunately, the wrong bit happens to be within a
timestamp reflecting the time at which the UCCB was created at IPL time.
That bit in the timestamp will change when the system is IPLed on or after
December 15, 2015, causing the availability check to fail and resulting in
an error return code back to every caller of the service."

Presumably they decided to move the timestamp field rather than whatever
field the tested bit is in. Probably there are lots of places that test the
(incorrect) bit, and just one that stores the TOD clock value there, so
less code needed to change. Though the fix does seem to hit multiple
modules...

Perhaps the description in the APAR is misleading. It says "...[fails] when
the create time of the UCCB time is D000 000 or greater. An
identical request does not fail when the time is CFFF "  Maybe
they didn't go very far with testing "or greater".

A typical flag-bit definition (ON means the service IS available) would fit
the description in the Red Alert if the flag is bit 4. This bit has been on
since June of 2011, so the code (written later than that, I believe) may
have been testing it and finding all to be well since then. Following this
reasoning, the bit would "right itself" in May of 2020. Bit 5 or even 6
might be possible if the code was implemented after the turn-on date for
one of those bits, since once on, none of them goes off until the Dec 2015
rollover. Or of course the sense of the bit in question could be backwards
(if ON then the service is NOT available), which allows for yet more
possibilities. Well I guess this borders on reverse engineering. It's
Friday...

C800 = 2011-06-30 15:40:08.883200  bit 4 goes on
CC00 = 2013-09-22 02:32:33.060864  bit 5 goes on
CD00 = 2014-04-13 17:15:39.105280
CE00 = 2014-11-03 07:58:45.149696  bit 6 goes on
CF00 = 2015-05-25 22:41:51.194112
D000 = 2015-12-15 13:24:57.238528  bits 4-7 go off
D800 = 2020-05-31 11:09:45.593856  bit 4 goes back on
F92CF59044F0 = 2038-11-28 11:05:00.00  Freedom 85 for me
 = 2042-09-17 23:53:47.370495  End of world as we know it

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: (External):Re: Unicode services Red alert

[Charles Mills]

One small correction. The bit/error/whatever is not for "Unicode Services 
Available" but for "CUNLINFO available." 

CUNLINFO is not "essential" (unless particular program logic treats it as so). 
CUNLINFO lets a program detect translation parameter mismatches ahead of doing 
any actual translation. The product I am responsible for survives a return code 
saying that CUNLINFO is not available by putting out a message at parameter 
validation time that if the specified translation is wrong, you won't know it 
until the program attempts an actual translation.

CUNLINFO was an addition to Unicode Services around V1R10. My code was written 
when V1R9 was still common; that's why I coded it that way. Validate parameters 
if possible; else just inevitably blow up at translation time.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of J O Skip Robinson
Sent: Thursday, October 15, 2015 8:06 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: (External):Re: Unicode services Red alert

I'm piecing together various clues. It appears to me that:

1. The UCCB is a defined control block, mapped in several (!) MACLIB members 
such as CUNBAIDF. 
2. Various flags are defined beginning at UCCB+10.
3. Somehow during IPL the system clock has been overlaying UCCB+10 by 
(presumably) Unicode set up processing.
4. No one noticed all this time because the flag nibble in the timestamp has 
always, coincidentally, indicated 'Unicode available'.
5. As of the magic moment on December 15, the clock rolls over and reverses the 
benign bit. Without the fix, Unicode appears to be unavailable more or less 
forever. Until the bit once again changes back?

I suspect that checks for the timestamp are far rarer than checks for Unicode 
availability. So the fix is to store the clock somewhere else at IPL (UCCB+20) 
and ensure that the critical flags are zero. Our PMR indicates what I 
suspected: a zero value means OK, a one value means not OK. This is analogous 
to the RACF flag in the CVT. Zero means that RACF is functional while one means 
that it is not. I have a hilarious war story about how I know that. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Unicode services Red alert

[Chris Hoelscher]

I have been curious since this alert was published - if for some reason the 
Unicode conversion service was NOT available, but the incorrect byte was being 
interrogated, would the Unicode conversion service ALWAYS shown as being 
available thru Dec 14 2015 ???


Chris hoelscher

The information transmitted is intended only for the person or entity to which 
it is addressed
and may contain CONFIDENTIAL material.  If you receive this 
material/information in error,
please contact the sender and delete or destroy the material/information.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: (External):Re: Unicode services Red alert

[Peter Relson]

from Gil:
>I'm curious: how (not when) does this problem occur?  Is it some
>OCO doing a TM on the wrong address? 

yes.

It should have been testing a flag byte but, because of the error, was 
testing a byte that was not a flag byte but was the target of a STCK.

from Skip: 
>1. The UCCB is a defined control block, mapped in several (!) 
>MACLIB members such as CUNBAIDF. 
The UCCB is not an interface and should not have been placed into any 
MACLIB member. This was part of the origin of the erroneous code. You may 
notice that while the mapping is there, there is no interface provided to 
locate the area. So while there is a mapping that is visible, it does not 
effectively constitute an interface.

>2. Various flags are defined beginning at UCCB+10.
Nope. What is defined at UCCB+10 is a timestamp. See the answer to Gil's 
question.

>3. Somehow during IPL the system clock has been overlaying 
>UCCB+10 by (presumably) Unicode set up processing.
Nope. See #2.

>4. No one noticed all this time because the flag nibble in 
>the timestamp has always, coincidentally, indicated 'Unicode available'.
Yup. And no one (apparently) tested "prior to z/OS 1.10 is this function 
available".
By the way, it's not actually "Unicode available". It's "Unicode 
conversion services available".

>5. As of the magic moment on December 15, the clock rolls over and 
>reverses the benign bit. Without the fix, Unicode appears 
>to be unavailable more or less forever. Until the bit once again 
>changes back?
Not all of unicode, but these services. And "yes" (more specifically, 
until you re-IPL after the bit changes back -- in 18 or so years). 

Peter Relson
z/OS Core Technology Design

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: (External):Re: Unicode services Red alert

[John McKown]

On Fri, Oct 16, 2015 at 8:04 AM, Richard Pinion 
wrote:

> What happens if one does not use Unicode services and does not apply the
> PTF?
>

​I was wondering that too. We haven't applied maintenance to z/OS 1.12 for
about 18 months because "it is going away"​. Well, it is going away, likely
mid-2016. Our only job now is "do the daily work needed, fix any overt
problems, don't break anything".

-- 

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

Maranatha! <><
John McKown

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: (External):Re: Unicode services Red alert

[Richard Pinion]

What happens if one does not use Unicode services and does not apply the PTF?



--- rel...@us.ibm.com wrote:

From: Peter Relson <rel...@us.ibm.com>
To:   IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: (External):Re: Unicode services Red alert
Date: Fri, 16 Oct 2015 08:39:15 -0400

from Gil:
>I'm curious: how (not when) does this problem occur?  Is it some
>OCO doing a TM on the wrong address? 

yes.

It should have been testing a flag byte but, because of the error, was 
testing a byte that was not a flag byte but was the target of a STCK.

from Skip: 
>1. The UCCB is a defined control block, mapped in several (!) 
>MACLIB members such as CUNBAIDF. 
The UCCB is not an interface and should not have been placed into any 
MACLIB member. This was part of the origin of the erroneous code. You may 
notice that while the mapping is there, there is no interface provided to 
locate the area. So while there is a mapping that is visible, it does not 
effectively constitute an interface.

>2. Various flags are defined beginning at UCCB+10.
Nope. What is defined at UCCB+10 is a timestamp. See the answer to Gil's 
question.

>3. Somehow during IPL the system clock has been overlaying 
>UCCB+10 by (presumably) Unicode set up processing.
Nope. See #2.

>4. No one noticed all this time because the flag nibble in 
>the timestamp has always, coincidentally, indicated 'Unicode available'.
Yup. And no one (apparently) tested "prior to z/OS 1.10 is this function 
available".
By the way, it's not actually "Unicode available". It's "Unicode 
conversion services available".

>5. As of the magic moment on December 15, the clock rolls over and 
>reverses the benign bit. Without the fix, Unicode appears 
>to be unavailable more or less forever. Until the bit once again 
>changes back?
Not all of unicode, but these services. And "yes" (more specifically, 
until you re-IPL after the bit changes back -- in 18 or so years). 

Peter Relson
z/OS Core Technology Design

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN




_
Netscape.  Just the Net You Need.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: (External):Re: Unicode services Red alert

[J O Skip Robinson]

The PTF does not update any macro, but as Peter says, it's not a programming 
interface anyway. 

One more point. The NUCLEUS element CUNMIIPL has the alias IEAVNPUN. If you 
choose to put the fix elements in place 'manually' ahead of the next IPL, don't 
forget the alias. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, October 16, 2015 7:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: (External):Re: Unicode services Red alert

On Fri, 16 Oct 2015 06:04:35 -0700, Richard Pinion wrote:

>What happens if one does not use Unicode services and does not apply the PTF?
> 
Can you do that?

Can you audit all your in-house code to assure that nothing uses Unicode 
services?
What about indirectly?

Can you electively disable Unicode services and observe what fails?  (Can you 
zap the evil bit on?  Or zap the CC mask in the test so it always takes the 
"disabled" path?  Yah, I know: OCO.)

I assume the repair is to test the correct bit, ignoring the correct store of 
the system clock.  Are all defective macros (even non-GUPI) repaired?

-- gil


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: (External):Re: Unicode services Red alert

[Doug Henry]

>On Fri, Oct 16, 2015 at 8:04 AM, Richard Pinion 
>wrote:
>
>> What happens if one does not use Unicode services and does not apply the
>> PTF? 

We found out that we are using Unicode services by running a slip trap that 
level 2 gave us. They gave us 2 slip traps - one for running instruction fetch 
slip to GTF and the other to take an svcdump. You can just choose one of them.
 
Following are two SLIPs, one to determine users of CUNLINFO, one to determine 
users of CUN4LINF.  You CANNOT run both SLIPs at the same time, you first need 
an AMBLIST or link edit map of LPA module CUNMUNI on the affected system.  

For users of CUNLINFO, first find the starting offset of CSECT CUNMINFO within 
CUNMUNI.  This will be the "" 
value in the SLIP below.For users of CUN4LINF, first find the starting offset 
of CSECT CUN4MINF within CUNMUNI.  This will be the ""   value in the SLIP 
below.

SL SET,IF,L=(CUNMUNI,),A=TRACE,TRDATA=(STD,REGS),END(with GTF running 
for the trace)
  
SL 
SET,IF,L=(CUNMUNI,),A=SVCD,SDATA=(CSA,SQA,LPA,ALLNUC,RGN,TRT,SUM,PSA),END 

The caller of the service (and its AMODE) will be in GPR14 at the time the SLIP 
matches.  

Doug   

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: (External):Re: Unicode services Red alert

[J O Skip Robinson]

OK, what Peter said. I get a C- for the explanation part, but I think the 
method part is sound. We're now running R13 on sandbox with the fix in place. 
V2R1 to follow soon. 

A note on circumvention options. If you are truly out of harm's way for this 
problem, I don't suppose you have to do anything. I personally would not want 
to bet the farm on that judgment, but Seymour has repeatedly bequeathed you the 
dog. The timestamp is stored at UCCB+10 only at IPL, so the current value will 
remain indefinitely until the next IPL. Regardless of your IPL schedule, keep 
in mind that any system failure--software or hardware--could cause an 
unscheduled IPL on or after Dec 15. Best to have the fix in place by then. OTOH 
you don't have to actually IPL in advance if you have the three fix elements in 
place in NUC, LINK, and LPA. If your system crashes, re-IPL will implement the 
fix and you will be OK. As long as you got it right.

Another note. Our R13 system is fairly current but not pristinely so. All three 
fix elements were at base level, so the PTF installed without any requisites. 
The NUC element CUNMIIPL is a 77K standalone module--not part of IEANUC01--so 
it should be easy to drop into SYS1.NUCLEUS if you wish to defer IPL.

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Relson
Sent: Friday, October 16, 2015 5:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: (External):Re: Unicode services Red alert

from Gil:
>I'm curious: how (not when) does this problem occur?  Is it some OCO 
>doing a TM on the wrong address?

yes.

It should have been testing a flag byte but, because of the error, was testing 
a byte that was not a flag byte but was the target of a STCK.

from Skip: 
>1. The UCCB is a defined control block, mapped in several (!) MACLIB 
>members such as CUNBAIDF.
The UCCB is not an interface and should not have been placed into any MACLIB 
member. This was part of the origin of the erroneous code. You may notice that 
while the mapping is there, there is no interface provided to locate the area. 
So while there is a mapping that is visible, it does not effectively constitute 
an interface.

>2. Various flags are defined beginning at UCCB+10.
Nope. What is defined at UCCB+10 is a timestamp. See the answer to Gil's 
question.

>3. Somehow during IPL the system clock has been overlaying
>UCCB+10 by (presumably) Unicode set up processing.
Nope. See #2.

>4. No one noticed all this time because the flag nibble in the 
>timestamp has always, coincidentally, indicated 'Unicode available'.
Yup. And no one (apparently) tested "prior to z/OS 1.10 is this function 
available".
By the way, it's not actually "Unicode available". It's "Unicode conversion 
services available".

>5. As of the magic moment on December 15, the clock rolls over and 
>reverses the benign bit. Without the fix, Unicode appears to be 
>unavailable more or less forever. Until the bit once again changes 
>back?
Not all of unicode, but these services. And "yes" (more specifically, until you 
re-IPL after the bit changes back -- in 18 or so years). 

Peter Relson
z/OS Core Technology Design

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: (External):Re: Unicode services Red alert

[Paul Gilmartin]

On Fri, 16 Oct 2015 06:04:35 -0700, Richard Pinion wrote:

>What happens if one does not use Unicode services and does not apply the PTF?
> 
Can you do that?

Can you audit all your in-house code to assure that nothing uses Unicode 
services?
What about indirectly?

Can you electively disable Unicode services and observe what fails?  (Can you
zap the evil bit on?  Or zap the CC mask in the test so it always takes the
"disabled" path?  Yah, I know: OCO.)

I assume the repair is to test the correct bit, ignoring the correct store of 
the
system clock.  Are all defective macros (even non-GUPI) repaired?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Unicode services Red alert

[Mike Shorkend]

The PTFs are out there

see http://www-01.ibm.com/support/docview.wss?uid=isg1OA48941

for version specific fixes

On 8 October 2015 at 18:27, גדי בן אבי <gad...@malam.com> wrote:

> I was told, by our IBM person, that the official PTF we be made available
> on October 16th.
> Gadi
>
> 
> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] On Behalf
> Of Jake Anderson [justmainfra...@gmail.com]
> Sent: 08 October 2015 17:46
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Unicode services Red alert
>
> So far we have the APAR, Any idea when we will be getting the GA PTF for
> this ?
>
> On Thu, Oct 8, 2015 at 8:08 PM, Peter Relson <rel...@us.ibm.com> wrote:
>
> > >What bugs me is that z/OS 1.13 systems are not exposed
> > >to this defect yet IBM created an aparfix for 1.13.
> >
> > Any application, whether customer-owned, ISV-owned, or IBM-owned could be
> > using this service (which has been in z/OS since z/OS 1.10).  IBM has no
> > idea what might fit into those first two categories. Thus I would think
> it
> > would be in everyone's best interest to get this PTF and apply it, if for
> > no other reason than to avoid having to figure out if you truly care.
> >
> > The IBM use in LE apparently is new with z/OS 2.1.
> >
> > Peter Relson
> > z/OS Core Technology Design
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> לשימת לבך, בהתאם לנהלי חברת מלם מערכות בע"מ ו/או כל חברת בת ו/או חברה
> קשורה שלה (להלן : "החברה") וזכויות החתימה בהן, כל הצעה, התחייבות או מצג
> מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את
> לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך
> סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום
> טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי.
>
> Please note that in accordance with Malam and/or its subsidiaries
> (hereinafter : "Malam") regulations and signatory rights, no offer,
> agreement, concession or representation is binding on the Malam, unless
> accompanied by a duly signed separate document (or a scanned version
> thereof), affixed with the Malam seal.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
Mike Shorkend
m...@shorkend.com
www.shorkend.com
Tel: +972524208743
Fax: +97239772196

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Unicode services Red alert

[Jake Anderson]

Post applying this Fixes, Are there any kind of Verification's needs to be
done ?

On Thu, Oct 15, 2015 at 6:44 PM, Mike Shorkend <mike.shork...@gmail.com>
wrote:

> The PTFs are out there
>
> see http://www-01.ibm.com/support/docview.wss?uid=isg1OA48941
>
> for version specific fixes
>
> On 8 October 2015 at 18:27, גדי בן אבי <gad...@malam.com> wrote:
>
> > I was told, by our IBM person, that the official PTF we be made available
> > on October 16th.
> > Gadi
> >
> > 
> > From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] On Behalf
> > Of Jake Anderson [justmainfra...@gmail.com]
> > Sent: 08 October 2015 17:46
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Unicode services Red alert
> >
> > So far we have the APAR, Any idea when we will be getting the GA PTF for
> > this ?
> >
> > On Thu, Oct 8, 2015 at 8:08 PM, Peter Relson <rel...@us.ibm.com> wrote:
> >
> > > >What bugs me is that z/OS 1.13 systems are not exposed
> > > >to this defect yet IBM created an aparfix for 1.13.
> > >
> > > Any application, whether customer-owned, ISV-owned, or IBM-owned could
> be
> > > using this service (which has been in z/OS since z/OS 1.10).  IBM has
> no
> > > idea what might fit into those first two categories. Thus I would think
> > it
> > > would be in everyone's best interest to get this PTF and apply it, if
> for
> > > no other reason than to avoid having to figure out if you truly care.
> > >
> > > The IBM use in LE apparently is new with z/OS 2.1.
> > >
> > > Peter Relson
> > > z/OS Core Technology Design
> > >
> > > --
> > > For IBM-MAIN subscribe / signoff / archive access instructions,
> > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> > >
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
> > לשימת לבך, בהתאם לנהלי חברת מלם מערכות בע"מ ו/או כל חברת בת ו/או חברה
> > קשורה שלה (להלן : "החברה") וזכויות החתימה בהן, כל הצעה, התחייבות או מצג
> > מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא
> את
> > לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות
> מסמך
> > סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום
> > טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי.
> >
> > Please note that in accordance with Malam and/or its subsidiaries
> > (hereinafter : "Malam") regulations and signatory rights, no offer,
> > agreement, concession or representation is binding on the Malam, unless
> > accompanied by a duly signed separate document (or a scanned version
> > thereof), affixed with the Malam seal.
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
>
>
> --
> Mike Shorkend
> m...@shorkend.com
> www.shorkend.com
> Tel: +972524208743
> Fax: +97239772196
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: (External):Re: Unicode services Red alert

[Jousma, David]

Skip,

Thanks for sharing this.   I used this to check my systems that have the PTF on 
them, against those that have not yet been IPLed.  I didn’t press IBM for this 
in the ETR I had opened on this, but should have.   

_
Dave Jousma
Assistant Vice President, Mainframe Engineering
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of J O Skip Robinson
Sent: Thursday, October 15, 2015 7:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: (External):Re: Unicode services Red alert

We have installed the R13 PTF and tested with assistance from IBM. To see your 
vulnerability, use IPCS ACTIVE or Omegamon MLST or Mainview (???) to display 
data currently in the UCCB control block at +10:

10?+220?+3C?+10

Before the PTF, you will see something like CFA83DBE 87F18D69 , which is a copy 
of the system clock at the last IPL. The problem is that on December 15, this 
data turns to D000  . With this clock value, the flag being checked 
for Unicode availability returns 'not available' via RC 8. After the PTF is 
IPLed (required!), the field is all zeroes, which is OK. The fix moves the time 
stamp to UCCB+20 and zeroes out UCCB+10. 

In order to verify functionally, SYS1.SAMPLIB contains member CUNSISMA, which 
calls Unicode. RC 0 indicates Unicode is available, RC 8 indicates it is not 
available. If you run CUNSISMA today, you'll get RC 0. But if you use your 
favorite memory altering tool--we used Omegamon MZAP--to set UCCB+10 to 
D000 , the program will get RC 8. After the fix is IPLed, UCCB+10 
is all zeroes, and CUNSISMA gets RC 0. 

We could go further and IPL the system to December 16, but that's a lot of 
trouble just to see if IBM is telling the truth. ;-)

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com



This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: (External):Re: Unicode services Red alert

[J O Skip Robinson]

We have installed the R13 PTF and tested with assistance from IBM. To see your 
vulnerability, use IPCS ACTIVE or Omegamon MLST or Mainview (???) to display 
data currently in the UCCB control block at +10:

10?+220?+3C?+10

Before the PTF, you will see something like CFA83DBE 87F18D69 , which is a copy 
of the system clock at the last IPL. The problem is that on December 15, this 
data turns to D000  . With this clock value, the flag being checked 
for Unicode availability returns 'not available' via RC 8. After the PTF is 
IPLed (required!), the field is all zeroes, which is OK. The fix moves the time 
stamp to UCCB+20 and zeroes out UCCB+10. 

In order to verify functionally, SYS1.SAMPLIB contains member CUNSISMA, which 
calls Unicode. RC 0 indicates Unicode is available, RC 8 indicates it is not 
available. If you run CUNSISMA today, you'll get RC 0. But if you use your 
favorite memory altering tool--we used Omegamon MZAP--to set UCCB+10 to 
D000 , the program will get RC 8. After the fix is IPLed, UCCB+10 
is all zeroes, and CUNSISMA gets RC 0. 

We could go further and IPL the system to December 16, but that's a lot of 
trouble just to see if IBM is telling the truth. ;-)

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dno
Sent: Thursday, October 15, 2015 10:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Unicode services Red alert

Great! Thanks Al. I did not see the fix in the link.

Sent from my iPhone

> On Oct 15, 2015, at 1:40 PM, Nims,Alva John (Al) <ajn...@ufl.edu> wrote:
> 
> PTF UA79203 for z/OS 1.13 is available today, I just received it and when I 
> did an APPLY CHECK, it was the only one applied.
> 
> Al Nims
> Systems Admin/Programmer 3
> EI
> University of Florida
> (352) 273-1298
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Dno
> Sent: Thursday, October 15, 2015 1:37 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Unicode services Red alert
> 
> I applied the APAR fix to be safe, but I see that IBM did not publish a PTF 
> for 1.13??? Any reason why?
> 
> Sent from my iPhone
> 
>> On Oct 15, 2015, at 9:14 AM, Mike Shorkend <mike.shork...@gmail.com> wrote:
>> 
>> The PTFs are out there
>> 
>> see http://www-01.ibm.com/support/docview.wss?uid=isg1OA48941
>> 
>> for version specific fixes
>> 
>>> On 8 October 2015 at 18:27, גדי בן אבי <gad...@malam.com> wrote:
>>> 
>>> I was told, by our IBM person, that the official PTF we be made 
>>> available on October 16th.
>>> Gadi
>>> 
>>> 
>>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] On 
>>> Behalf Of Jake Anderson [justmainfra...@gmail.com]
>>> Sent: 08 October 2015 17:46
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: Unicode services Red alert
>>> 
>>> So far we have the APAR, Any idea when we will be getting the GA PTF 
>>> for this ?
>>> 
>>> On Thu, Oct 8, 2015 at 8:08 PM, Peter Relson <rel...@us.ibm.com> wrote:
>>> 
>>>>> What bugs me is that z/OS 1.13 systems are not exposed to this 
>>>>> defect yet IBM created an aparfix for 1.13.
>>>> 
>>>> Any application, whether customer-owned, ISV-owned, or IBM-owned 
>>>> could be using this service (which has been in z/OS since z/OS 
>>>> 1.10).  IBM has no idea what might fit into those first two 
>>>> categories. Thus I would think
>>> it
>>>> would be in everyone's best interest to get this PTF and apply it, 
>>>> if for no other reason than to avoid having to figure out if you truly 
>>>> care.
>>>> 
>>>> The IBM use in LE apparently is new with z/OS 2.1.
>>>> 
>>>> Peter Relson
>>>> z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: (External):Re: Unicode services Red alert

[J O Skip Robinson]

I wish we could take credit for discovering the problem. I've learned that many 
sites do time-warp testing on a regular basis. Remember the Y2K Flash Mob scene 
when we all did that incessantly? I seriously doubt that this problem was 
discovered by IPLing at Dec. 15. There was undoubtedly some further future date 
being explored. Whoa! Unicode is broken. Eventually it was narrowed down by the 
original customer (wishful thinking) or more likely by IBM to the actual fail 
point. 

Our PMR was opened by a diligent colleague who wanted more specific details. 
And I appreciate that IBM complied and supplied more details, especially the 
SAMPLIB pointer, which allowed us to test without the painful need to change 
the system time at IPL. 

OK, I warned about a RACF war story. A DB2 sysprog was trying to debug what 
looked like a RACF problem in DB2. She found a flag documented in DB2 as 'RACF 
available'. She could see that it was zero, so she zapped it to one. This was 
not a DB2 control block but the actual MVS CVT flag. The entire system stopped 
working. Every RACF access of any kind resulted in a WTOR requesting permission 
to allow access. Somehow we got the flag zeroed out before total system 
collapse. Luckily it was the development system, and luckily we didn't have to 
IPL. But that's how I remember the meaning of the RACF flag. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Thursday, October 15, 2015 8:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: (External):Re: Unicode services Red alert

On 2015-10-15, at 21:06, J O Skip Robinson wrote:

> I'm piecing together various clues. It appears to me that:
> 
> 1. The UCCB is a defined control block, mapped in several (!) MACLIB members 
> such as CUNBAIDF.
>  
A more modular design might map it in one macro and call it from all the 
others.  Jurisdiction probably precludes.

> 2. Various flags are defined beginning at UCCB+10.
> 3. Somehow during IPL the system clock has been overlaying UCCB+10 by 
> (presumably) Unicode set up processing.
> 4. No one noticed all this time because the flag nibble in the timestamp has 
> always, coincidentally, indicated 'Unicode available'.
> 5. As of the magic moment on December 15, the clock rolls over and reverses 
> the benign bit. Without the fix, Unicode appears to be unavailable more or 
> less forever. Until the bit once again changes back?
> 
> I suspect that checks for the timestamp are far rarer than checks for Unicode 
> availability. So the fix is to store the clock somewhere else at IPL 
> (UCCB+20) and ensure that the critical flags are zero. Our PMR indicates what 
> I suspected: a zero value means OK, a one value means not OK. This is 
> analogous to the RACF flag in the CVT. Zero means that RACF is functional 
> while one means that it is not. I have a hilarious war story about how I know 
> that. 
>  
And I wonder how the problem was discovered.  Does someone routinely test with 
the system clock advanced a few weeks; long enough for an APAR to turn around?  
May I infer from "Our PMR" that you're the reporting site?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Unicode services Red alert

[Paul Gilmartin]

On 2015-10-15 17:37, J O Skip Robinson wrote:
> I think I received the following link internally rather than from IBM-MAIN. 
> It's a good discussion of the issue. 
> 
> http://www-01.ibm.com/support/docview.wss?uid=isg1OA48941
>  
I'm curious: how (not when) does this problem occur?  Is it some
OCO doing a TM on the wrong address?  I suppose I should infer
something from:


Problem summary

Correct the code involved to move the timestamp field to
allow the Unicode services active indicator to remain valid.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Unicode services Red alert

[J O Skip Robinson]

I think I received the following link internally rather than from IBM-MAIN. 
It's a good discussion of the issue. 

http://www-01.ibm.com/support/docview.wss?uid=isg1OA48941

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of J O Skip Robinson
Sent: Thursday, October 15, 2015 4:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: (External):Re: Unicode services Red alert

We have installed the R13 PTF and tested with assistance from IBM. To see your 
vulnerability, use IPCS ACTIVE or Omegamon MLST or Mainview (???) to display 
data currently in the UCCB control block at +10:

10?+220?+3C?+10

Before the PTF, you will see something like CFA83DBE 87F18D69 , which is a copy 
of the system clock at the last IPL. The problem is that on December 15, this 
data turns to D000  . With this clock value, the flag being checked 
for Unicode availability returns 'not available' via RC 8. After the PTF is 
IPLed (required!), the field is all zeroes, which is OK. The fix moves the time 
stamp to UCCB+20 and zeroes out UCCB+10. 

In order to verify functionally, SYS1.SAMPLIB contains member CUNSISMA, which 
calls Unicode. RC 0 indicates Unicode is available, RC 8 indicates it is not 
available. If you run CUNSISMA today, you'll get RC 0. But if you use your 
favorite memory altering tool--we used Omegamon MZAP--to set UCCB+10 to 
D000 , the program will get RC 8. After the fix is IPLed, UCCB+10 
is all zeroes, and CUNSISMA gets RC 0. 

We could go further and IPL the system to December 16, but that's a lot of 
trouble just to see if IBM is telling the truth. ;-)

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dno
Sent: Thursday, October 15, 2015 10:50 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Unicode services Red alert

Great! Thanks Al. I did not see the fix in the link.

Sent from my iPhone

> On Oct 15, 2015, at 1:40 PM, Nims,Alva John (Al) <ajn...@ufl.edu> wrote:
> 
> PTF UA79203 for z/OS 1.13 is available today, I just received it and when I 
> did an APPLY CHECK, it was the only one applied.
> 
> Al Nims
> Systems Admin/Programmer 3
> EI
> University of Florida
> (352) 273-1298
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Dno
> Sent: Thursday, October 15, 2015 1:37 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Unicode services Red alert
> 
> I applied the APAR fix to be safe, but I see that IBM did not publish a PTF 
> for 1.13??? Any reason why?
> 
> Sent from my iPhone
> 
>> On Oct 15, 2015, at 9:14 AM, Mike Shorkend <mike.shork...@gmail.com> wrote:
>> 
>> The PTFs are out there
>> 
>> see http://www-01.ibm.com/support/docview.wss?uid=isg1OA48941
>> 
>> for version specific fixes
>> 
>>> On 8 October 2015 at 18:27, גדי בן אבי <gad...@malam.com> wrote:
>>> 
>>> I was told, by our IBM person, that the official PTF we be made 
>>> available on October 16th.
>>> Gadi
>>> 
>>> 
>>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] On 
>>> Behalf Of Jake Anderson [justmainfra...@gmail.com]
>>> Sent: 08 October 2015 17:46
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: Unicode services Red alert
>>> 
>>> So far we have the APAR, Any idea when we will be getting the GA PTF 
>>> for this ?
>>> 
>>> On Thu, Oct 8, 2015 at 8:08 PM, Peter Relson <rel...@us.ibm.com> wrote:
>>> 
>>>>> What bugs me is that z/OS 1.13 systems are not exposed to this 
>>>>> defect yet IBM created an aparfix for 1.13.
>>>> 
>>>> Any application, whether customer-owned, ISV-owned, or IBM-owned 
>>>> could be using this service (which has been in z/OS since z/OS 
>>>> 1.10).  IBM has no idea what might fit into those first two 
>>>> categories. Thus I would think
>>> it
>>>> would be in everyone's best interest to get this PTF and apply it, 
>>>> if for no other reason than to avoid having to figure out if you truly 
>>>> care.
>>>> 
>>>> The IBM use in LE apparently is new with z/OS 2.1.
>>>> 
>>>> Peter Relson
>>>> z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: (External):Re: Unicode services Red alert

[Paul Gilmartin]

On 2015-10-15, at 21:06, J O Skip Robinson wrote:

> I'm piecing together various clues. It appears to me that:
> 
> 1. The UCCB is a defined control block, mapped in several (!) MACLIB members 
> such as CUNBAIDF.
>  
A more modular design might map it in one macro and call it from all
the others.  Jurisdiction probably precludes.

> 2. Various flags are defined beginning at UCCB+10.
> 3. Somehow during IPL the system clock has been overlaying UCCB+10 by 
> (presumably) Unicode set up processing.
> 4. No one noticed all this time because the flag nibble in the timestamp has 
> always, coincidentally, indicated 'Unicode available'.
> 5. As of the magic moment on December 15, the clock rolls over and reverses 
> the benign bit. Without the fix, Unicode appears to be unavailable more or 
> less forever. Until the bit once again changes back?
> 
> I suspect that checks for the timestamp are far rarer than checks for Unicode 
> availability. So the fix is to store the clock somewhere else at IPL 
> (UCCB+20) and ensure that the critical flags are zero. Our PMR indicates what 
> I suspected: a zero value means OK, a one value means not OK. This is 
> analogous to the RACF flag in the CVT. Zero means that RACF is functional 
> while one means that it is not. I have a hilarious war story about how I know 
> that. 
>  
And I wonder how the problem was discovered.  Does someone routinely test
with the system clock advanced a few weeks; long enough for an APAR to
turn around?  May I infer from "Our PMR" that you're the reporting site?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: (External):Re: Unicode services Red alert

[J O Skip Robinson]

I'm piecing together various clues. It appears to me that:

1. The UCCB is a defined control block, mapped in several (!) MACLIB members 
such as CUNBAIDF. 
2. Various flags are defined beginning at UCCB+10.
3. Somehow during IPL the system clock has been overlaying UCCB+10 by 
(presumably) Unicode set up processing.
4. No one noticed all this time because the flag nibble in the timestamp has 
always, coincidentally, indicated 'Unicode available'.
5. As of the magic moment on December 15, the clock rolls over and reverses the 
benign bit. Without the fix, Unicode appears to be unavailable more or less 
forever. Until the bit once again changes back?

I suspect that checks for the timestamp are far rarer than checks for Unicode 
availability. So the fix is to store the clock somewhere else at IPL (UCCB+20) 
and ensure that the critical flags are zero. Our PMR indicates what I 
suspected: a zero value means OK, a one value means not OK. This is analogous 
to the RACF flag in the CVT. Zero means that RACF is functional while one means 
that it is not. I have a hilarious war story about how I know that. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Thursday, October 15, 2015 6:07 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Unicode services Red alert

On 2015-10-15 17:37, J O Skip Robinson wrote:
> I think I received the following link internally rather than from IBM-MAIN. 
> It's a good discussion of the issue. 
> 
> http://www-01.ibm.com/support/docview.wss?uid=isg1OA48941
>  
I'm curious: how (not when) does this problem occur?  Is it some OCO doing a TM 
on the wrong address?  I suppose I should infer something from:


Problem summary

Correct the code involved to move the timestamp field to
allow the Unicode services active indicator to remain valid.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Unicode services Red alert

[Dno]

Great! Thanks Al. I did not see the fix in the link.

Sent from my iPhone

> On Oct 15, 2015, at 1:40 PM, Nims,Alva John (Al) <ajn...@ufl.edu> wrote:
> 
> PTF UA79203 for z/OS 1.13 is available today, I just received it and when I 
> did an APPLY CHECK, it was the only one applied.
> 
> Al Nims
> Systems Admin/Programmer 3
> EI
> University of Florida
> (352) 273-1298
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Dno
> Sent: Thursday, October 15, 2015 1:37 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Unicode services Red alert
> 
> I applied the APAR fix to be safe, but I see that IBM did not publish a PTF 
> for 1.13??? Any reason why?
> 
> Sent from my iPhone
> 
>> On Oct 15, 2015, at 9:14 AM, Mike Shorkend <mike.shork...@gmail.com> wrote:
>> 
>> The PTFs are out there
>> 
>> see http://www-01.ibm.com/support/docview.wss?uid=isg1OA48941
>> 
>> for version specific fixes
>> 
>>> On 8 October 2015 at 18:27, גדי בן אבי <gad...@malam.com> wrote:
>>> 
>>> I was told, by our IBM person, that the official PTF we be made 
>>> available on October 16th.
>>> Gadi
>>> 
>>> 
>>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] On 
>>> Behalf Of Jake Anderson [justmainfra...@gmail.com]
>>> Sent: 08 October 2015 17:46
>>> To: IBM-MAIN@LISTSERV.UA.EDU
>>> Subject: Re: Unicode services Red alert
>>> 
>>> So far we have the APAR, Any idea when we will be getting the GA PTF 
>>> for this ?
>>> 
>>> On Thu, Oct 8, 2015 at 8:08 PM, Peter Relson <rel...@us.ibm.com> wrote:
>>> 
>>>>> What bugs me is that z/OS 1.13 systems are not exposed to this 
>>>>> defect yet IBM created an aparfix for 1.13.
>>>> 
>>>> Any application, whether customer-owned, ISV-owned, or IBM-owned 
>>>> could be using this service (which has been in z/OS since z/OS 
>>>> 1.10).  IBM has no idea what might fit into those first two 
>>>> categories. Thus I would think
>>> it
>>>> would be in everyone's best interest to get this PTF and apply it, 
>>>> if for no other reason than to avoid having to figure out if you truly 
>>>> care.
>>>> 
>>>> The IBM use in LE apparently is new with z/OS 2.1.
>>>> 
>>>> Peter Relson
>>>> z/OS Core Technology Design
>>>> 
>>>> 
>>>> -- For IBM-MAIN subscribe / signoff / archive access instructions, 
>>>> send email to lists...@listserv.ua.edu with the message: INFO 
>>>> IBM-MAIN
>>> 
>>> -
>>> - For IBM-MAIN subscribe / signoff / archive access instructions, 
>>> send email to lists...@listserv.ua.edu with the message: INFO 
>>> IBM-MAIN
>>> 
>>> לשימת לבך, בהתאם לנהלי חברת מלם מערכות בע"מ ו/או כל חברת בת ו/או חברה 
>>> קשורה שלה (להלן : "החברה") וזכויות החתימה בהן, כל הצעה, התחייבות או 
>>> מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, 
>>> הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך 
>>> כאמור (לרבות מסמך
>>> סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא 
>>> משום טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי.
>>> 
>>> Please note that in accordance with Malam and/or its subsidiaries 
>>> (hereinafter : "Malam") regulations and signatory rights, no offer, 
>>> agreement, concession or representation is binding on the Malam, 
>>> unless accompanied by a duly signed separate document (or a scanned 
>>> version thereof), affixed with the Malam seal.
>>> 
>>> -
>>> - For IBM-MAIN subscribe / signoff / archive access instructions, 
>>> send email to lists...@listserv.ua.edu with the message: INFO 
>>> IBM-MAIN
>> 
>> 
>> 
>> --
>> Mike Shorkend
>> m...@shorkend.com
>> www.shorkend.com
>> Tel: +972524208743
>> Fax: +97239772196
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions, send 
>> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Unicode services Red alert

[Porowski, Ken]

OA48941 PTF UA79203 is for 1.13



CIT | Ken Porowski | VP Mainframe Engineering | Information Technology | +1 973 
740 5459 (tel) | ken.porow...@cit.com




This email message and any accompanying materials may contain proprietary, 
privileged and confidential information of CIT Group Inc. or its subsidiaries 
or affiliates (collectively, “CIT”), and are intended solely for the 
recipient(s) named above.  If you are not the intended recipient of this 
communication, any use, disclosure, printing, copying or distribution, or 
reliance on the contents, of this communication is strictly prohibited.  CIT 
disclaims any liability for the review, retransmission, dissemination or other 
use of, or the taking of any action in reliance upon, this communication by 
persons other than the intended recipient(s).  If you have received this 
communication in error, please reply to the sender advising of the error in 
transmission, and immediately delete and destroy the communication and any 
accompanying materials.  To the extent permitted by applicable law, CIT and 
others may inspect, review, monitor, analyze, copy, record and retain any 
communications sent from or received at this email address.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dno
Sent: Thursday, October 15, 2015 1:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] Unicode services Red alert

I applied the APAR fix to be safe, but I see that IBM did not publish a PTF for 
1.13??? Any reason why?

Sent from my iPhone

> On Oct 15, 2015, at 9:14 AM, Mike Shorkend <mike.shork...@gmail.com> wrote:
>
> The PTFs are out there
>
> see http://www-01.ibm.com/support/docview.wss?uid=isg1OA48941
>
> for version specific fixes
>
>> On 8 October 2015 at 18:27, גדי בן אבי <gad...@malam.com> wrote:
>>
>> I was told, by our IBM person, that the official PTF we be made
>> available on October 16th.
>> Gadi
>>
>> 
>> From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] On
>> Behalf Of Jake Anderson [justmainfra...@gmail.com]
>> Sent: 08 October 2015 17:46
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Unicode services Red alert
>>
>> So far we have the APAR, Any idea when we will be getting the GA PTF
>> for this ?
>>
>> On Thu, Oct 8, 2015 at 8:08 PM, Peter Relson <rel...@us.ibm.com> wrote:
>>
>>>> What bugs me is that z/OS 1.13 systems are not exposed to this
>>>> defect yet IBM created an aparfix for 1.13.
>>>
>>> Any application, whether customer-owned, ISV-owned, or IBM-owned
>>> could be using this service (which has been in z/OS since z/OS
>>> 1.10).  IBM has no idea what might fit into those first two
>>> categories. Thus I would think
>> it
>>> would be in everyone's best interest to get this PTF and apply it,
>>> if for no other reason than to avoid having to figure out if you truly care.
>>>
>>> The IBM use in LE apparently is new with z/OS 2.1.
>>>
>>> Peter Relson
>>> z/OS Core Technology Design
>>>
>>> 
>>> -- For IBM-MAIN subscribe / signoff / archive access instructions,
>>> send email to lists...@listserv.ua.edu with the message: INFO
>>> IBM-MAIN
>>
>> -
>> - For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO
>> IBM-MAIN
>>
>> לשימת לבך, בהתאם לנהלי חברת מלם מערכות בע"מ ו/או כל חברת בת ו/או חברה
>> קשורה שלה (להלן : "החברה") וזכויות החתימה בהן, כל הצעה, התחייבות או
>> מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה,
>> הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך
>> כאמור (לרבות מסמך
>> סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא
>> משום טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי.
>>
>> Please note that in accordance with Malam and/or its subsidiaries
>> (hereinafter : "Malam") regulations and signatory rights, no offer,
>> agreement, concession or representation is binding on the Malam,
>> unless accompanied by a duly signed separate document (or a scanned
>> version thereof), affixed with the Malam seal.
>>
>> -
>> - For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO
>> IBM-MAIN
>
>
&

Re: Unicode services Red alert

[Peter Relson]

>What bugs me is that z/OS 1.13 systems are not exposed 
>to this defect yet IBM created an aparfix for 1.13.

Any application, whether customer-owned, ISV-owned, or IBM-owned could be 
using this service (which has been in z/OS since z/OS 1.10).  IBM has no 
idea what might fit into those first two categories. Thus I would think it 
would be in everyone's best interest to get this PTF and apply it, if for 
no other reason than to avoid having to figure out if you truly care.

The IBM use in LE apparently is new with z/OS 2.1.

Peter Relson
z/OS Core Technology Design

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Unicode services Red alert

[Jake Anderson]

So far we have the APAR, Any idea when we will be getting the GA PTF for
this ?

On Thu, Oct 8, 2015 at 8:08 PM, Peter Relson  wrote:

> >What bugs me is that z/OS 1.13 systems are not exposed
> >to this defect yet IBM created an aparfix for 1.13.
>
> Any application, whether customer-owned, ISV-owned, or IBM-owned could be
> using this service (which has been in z/OS since z/OS 1.10).  IBM has no
> idea what might fit into those first two categories. Thus I would think it
> would be in everyone's best interest to get this PTF and apply it, if for
> no other reason than to avoid having to figure out if you truly care.
>
> The IBM use in LE apparently is new with z/OS 2.1.
>
> Peter Relson
> z/OS Core Technology Design
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Unicode services Red alert

[גדי בן אבי]

I was told, by our IBM person, that the official PTF we be made available on 
October 16th.
Gadi


From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of 
Jake Anderson [justmainfra...@gmail.com]
Sent: 08 October 2015 17:46
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unicode services Red alert

So far we have the APAR, Any idea when we will be getting the GA PTF for
this ?

On Thu, Oct 8, 2015 at 8:08 PM, Peter Relson <rel...@us.ibm.com> wrote:

> >What bugs me is that z/OS 1.13 systems are not exposed
> >to this defect yet IBM created an aparfix for 1.13.
>
> Any application, whether customer-owned, ISV-owned, or IBM-owned could be
> using this service (which has been in z/OS since z/OS 1.10).  IBM has no
> idea what might fit into those first two categories. Thus I would think it
> would be in everyone's best interest to get this PTF and apply it, if for
> no other reason than to avoid having to figure out if you truly care.
>
> The IBM use in LE apparently is new with z/OS 2.1.
>
> Peter Relson
> z/OS Core Technology Design
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

לשימת לבך, בהתאם לנהלי חברת מלם מערכות בע"מ ו/או כל חברת בת ו/או חברה קשורה שלה 
(להלן : "החברה") וזכויות החתימה בהן, כל הצעה, התחייבות או מצג מטעם החברה, 
מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או 
שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף 
להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין 
להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי.

Please note that in accordance with Malam and/or its subsidiaries (hereinafter 
: "Malam") regulations and signatory rights, no offer, agreement, concession or 
representation is binding on the Malam, unless accompanied by a duly signed 
separate document (or a scanned version thereof), affixed with the Malam seal.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Unicode services Red alert

[Bill Godfrey]

On Thu, 1 Oct 2015 11:41:38 -0700, Charles Mills wrote:

>The error I am hoping for is #define CUN_RS_NO_SERV_AVAILABLE  11  /*
>Service not available   */ but it looks like there is no clue here that
>that is it.
>

The "RSNB" in the APAR description means the reason code is 11.

Bill

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Unicode services Red alert

[Charles Mills]

Many thanks. Perfect. I am travelling and did not realize there was significant 
information in the APAR beyond what John Eels posted. (We're good! We'll only 
generate a warning and fall back to pre-V1R10 mode.)

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bill Godfrey
Sent: Thursday, October 01, 2015 11:59 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unicode services Red alert

On Thu, 1 Oct 2015 11:41:38 -0700, Charles Mills wrote:

>The error I am hoping for is #define CUN_RS_NO_SERV_AVAILABLE  11  /*
>Service not available   */ but it looks like there is no clue here that
>that is it.
>

The "RSNB" in the APAR description means the reason code is 11.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Unicode services Red alert

[Dana Mitchell]

We are on z/OS 1.13, I'm still a little unclear of our exposure here.  The apar 
states:
...
In the reported problem, iconv() calls the Unicode Services,
conversion information service, CUNLINFO or CUN4LINF, during a
character conversion and receives RC8 RSNB when the create time
of the UCCB time is D000 000 or greater. 
...
1. Any application or system code that calls iconv() -
 The iconv() service only makes use of the Unicode
 Information Services at z/OS 2.1 and higher releases.
 iconv() is not exposed to this defect on z/OS 1.13 and
 lower.

If I'm understanding this correctly:  
1. The bug makes iconv() fail because CUNLINFO or CUN4LINF fails with RC8.
2. iconv() only calls CUNLINF or CUN4LINF only at z/OS 2.1 and higher.

so at 1.13 the only failure would be any code that calls CUNLINFO or CUN4LINF 
directly?   other than what was stated above, no other IBM components call 
these?

I plan on getting this applied but we probably would not be able to get 
production online lpars IPLed before this date, just want to understand and be 
able to explain the risks.

thanks
Dana

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Unicode services Red alert

[Leonardo Vaz]

What bugs me is that z/OS 1.13 systems are not exposed to this defect yet IBM 
created an aparfix for 1.13.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dana Mitchell
Sent: Friday, October 02, 2015 12:56 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unicode services Red alert

We are on z/OS 1.13, I'm still a little unclear of our exposure here.  The apar 
states:
...
In the reported problem, iconv() calls the Unicode Services, conversion 
information service, CUNLINFO or CUN4LINF, during a character conversion and 
receives RC8 RSNB when the create time of the UCCB time is D000 000 or 
greater. 
...
1. Any application or system code that calls iconv() -
 The iconv() service only makes use of the Unicode
 Information Services at z/OS 2.1 and higher releases.
 iconv() is not exposed to this defect on z/OS 1.13 and
 lower.

If I'm understanding this correctly:  
1. The bug makes iconv() fail because CUNLINFO or CUN4LINF fails with RC8.
2. iconv() only calls CUNLINF or CUN4LINF only at z/OS 2.1 and higher.

so at 1.13 the only failure would be any code that calls CUNLINFO or CUN4LINF 
directly?   other than what was stated above, no other IBM components call 
these?

I plan on getting this applied but we probably would not be able to get 
production online lpars IPLed before this date, just want to understand and be 
able to explain the risks.

thanks
Dana

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Unicode services Red alert

[Charles Mills]

No problem until you do IPL so you are good either way. 


CharlesSent from a mobile; please excuse the brevity

 Original message 
From: Dana Mitchell <mitchd...@gmail.com> 
Date: 10/02/2015  9:56 AM  (GMT-08:00) 
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: Unicode services Red alert 

We are on z/OS 1.13, I'm still a little unclear of our exposure here.  The apar 
states:
...
In the reported problem, iconv() calls the Unicode Services,
conversion information service, CUNLINFO or CUN4LINF, during a
character conversion and receives RC8 RSNB when the create time
of the UCCB time is D000 000 or greater. 
...
1. Any application or system code that calls iconv() -
 The iconv() service only makes use of the Unicode
 Information Services at z/OS 2.1 and higher releases.
 iconv() is not exposed to this defect on z/OS 1.13 and
 lower.

If I'm understanding this correctly:  
1. The bug makes iconv() fail because CUNLINFO or CUN4LINF fails with RC8.
2. iconv() only calls CUNLINF or CUN4LINF only at z/OS 2.1 and higher.

so at 1.13 the only failure would be any code that calls CUNLINFO or CUN4LINF 
directly?   other than what was stated above, no other IBM components call 
these?

I plan on getting this applied but we probably would not be able to get 
production online lpars IPLed before this date, just want to understand and be 
able to explain the risks.

thanks
Dana

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Unicode services Red alert

[Mike Schwab]

IBM created PTFs for z/OS 1.10 and up.  I believe z/OS 1.10, 1.11, and
maybe 1.12 is out of support

On Fri, Oct 2, 2015 at 1:33 PM, Leonardo Vaz <leonardo@cn.ca> wrote:
> What bugs me is that z/OS 1.13 systems are not exposed to this defect yet IBM 
> created an aparfix for 1.13.
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Dana Mitchell
> Sent: Friday, October 02, 2015 12:56 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Unicode services Red alert
>
> We are on z/OS 1.13, I'm still a little unclear of our exposure here.  The 
> apar states:
> ...
> In the reported problem, iconv() calls the Unicode Services, conversion 
> information service, CUNLINFO or CUN4LINF, during a character conversion and 
> receives RC8 RSNB when the create time of the UCCB time is D000 000 
> or greater.
> ...
> 1. Any application or system code that calls iconv() -
>  The iconv() service only makes use of the Unicode
>  Information Services at z/OS 2.1 and higher releases.
>  iconv() is not exposed to this defect on z/OS 1.13 and
>  lower.
>
> If I'm understanding this correctly:
> 1. The bug makes iconv() fail because CUNLINFO or CUN4LINF fails with RC8.
> 2. iconv() only calls CUNLINF or CUN4LINF only at z/OS 2.1 and higher.
>
> so at 1.13 the only failure would be any code that calls CUNLINFO or CUN4LINF 
> directly?   other than what was stated above, no other IBM components call 
> these?
>
> I plan on getting this applied but we probably would not be able to get 
> production online lpars IPLed before this date, just want to understand and 
> be able to explain the risks.
>
> thanks
> Dana
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
> lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Unicode services Red alert

[Haselbach, Markus]

I got following in OMVS:

Bnn:/u/bnn:>iconv -f IBM-819 -t IBM-1047   text >  result   

iconv: Conversion from codeset "IBM-819" to "IBM-1047": EDC5121I Invalid 
argument.  

Regards
Markus 



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Leonardo Vaz
Sent: Thursday, October 01, 2015 7:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unicode services Red alert

I am trying the following command after IPLing with a 2016 date and it works 
fine:
iconv -f UTF-8 -t IBM-1047 < my_ascii_file

Could anyone reproduce the error described in the red alert?

Thanks and Regards,
Leo

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Haselbach, Markus
Sent: Thursday, October 01, 2015 9:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unicode services Red alert

You have to install ++Apar oa48941   which belongs to Unicode Services and 
updates one LMOD in each Lpalib, Linklib and Nucleus.  


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Thursday, October 01, 2015 1:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Unicode services Red alert

Anyone have any additional details on this?  Red Alert webpage in ResourceLink 
appears to be non-functional at the moment.

z/OS family - all hardware, OS, and related software: Red Alerts




*


z/OS Unicode Services Conversion Information Service fails after 
12-15-20<http://www14.software.ibm.com/webapp/set2/sas/f/redAlerts?myns=z000=OCHW188=OCHW18N=OCHW19Y=OCHW20L=OCHW22D=OCHW23D=OCHW25D=OCHW30D=OCSWG90=OCSWG80=OCSWGA0=OCSWGB0=E_sp=z000-_-OCHW188-OCHW18N-OCHW19Y-OCHW20L-OCHW22D-OCHW23D-OCHW25D-OCHW30D-OCSWG90-OCSWG80-OCSWGA0-OCSWGB0-_-E>




Unicode Services conversion information service on all current z/OS releases 
will return incorrect return code on systems IPLed on or after December 15, 
2015 affecting many system services and applications. Action is required to 
prevent failures

To read the complete text of this Red Alert as well as previous Red Alerts 
please use the above link.





_
Dave Jousma
Assistant Vice President, Mainframe Engineering david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 616.653.2717

This e-mail transmission contains information that is confidential and may be 
privileged.
It is intended only for the addressee(s) named above. If you receive this 
e-mail in error, please do not read, copy or disseminate it in any manner.  If 
you are not the intended recipient, any disclosure, copying, distribution or 
use of the contents of this information is prohibited. Please reply to the 
message immediately by informing the sender that the message was misdirected. 
After replying, please erase it from your computer system. Your assistance in 
correcting this error is appreciated.




--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Unicode services Red alert

[Haselbach, Markus]

You have to install ++Apar oa48941   which belongs to Unicode Services and 
updates one LMOD in each Lpalib, Linklib and Nucleus.  


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Thursday, October 01, 2015 1:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Unicode services Red alert

Anyone have any additional details on this?  Red Alert webpage in ResourceLink 
appears to be non-functional at the moment.

z/OS family - all hardware, OS, and related software: Red Alerts




*


z/OS Unicode Services Conversion Information Service fails after 
12-15-20<http://www14.software.ibm.com/webapp/set2/sas/f/redAlerts?myns=z000=OCHW188=OCHW18N=OCHW19Y=OCHW20L=OCHW22D=OCHW23D=OCHW25D=OCHW30D=OCSWG90=OCSWG80=OCSWGA0=OCSWGB0=E_sp=z000-_-OCHW188-OCHW18N-OCHW19Y-OCHW20L-OCHW22D-OCHW23D-OCHW25D-OCHW30D-OCSWG90-OCSWG80-OCSWGA0-OCSWGB0-_-E>




Unicode Services conversion information service on all current z/OS releases
will return incorrect return code on systems IPLed on or after December 15, 2015
affecting many system services and applications. Action is required to prevent
failures

To read the complete text of this Red Alert as well as previous Red Alerts 
please use the above link.





_
Dave Jousma
Assistant Vice President, Mainframe Engineering
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

This e-mail transmission contains information that is confidential and may be 
privileged.
It is intended only for the addressee(s) named above. If you receive this 
e-mail in error,
please do not read, copy or disseminate it in any manner.  If you are not the 
intended 
recipient, any disclosure, copying, distribution or use of the contents of this 
information
is prohibited. Please reply to the message immediately by informing the sender 
that the 
message was misdirected. After replying, please erase it from your computer 
system. Your 
assistance in correcting this error is appreciated.




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Unicode services Red alert

[Jousma, David]

Nevermind, I should have checked my ibm-main inbox first.  I see John already 
responded.

_
Dave Jousma
Assistant Vice President, Mainframe Engineering
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Thursday, October 01, 2015 7:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Unicode services Red alert

Anyone have any additional details on this?  Red Alert webpage in ResourceLink 
appears to be non-functional at the moment.

z/OS family - all hardware, OS, and related software: Red Alerts




*


z/OS Unicode Services Conversion Information Service fails after 
12-15-20<http://www14.software.ibm.com/webapp/set2/sas/f/redAlerts?myns=z000=OCHW188=OCHW18N=OCHW19Y=OCHW20L=OCHW22D=OCHW23D=OCHW25D=OCHW30D=OCSWG90=OCSWG80=OCSWGA0=OCSWGB0=E_sp=z000-_-OCHW188-OCHW18N-OCHW19Y-OCHW20L-OCHW22D-OCHW23D-OCHW25D-OCHW30D-OCSWG90-OCSWG80-OCSWGA0-OCSWGB0-_-E>




Unicode Services conversion information service on all current z/OS releases 
will return incorrect return code on systems IPLed on or after December 15, 
2015 affecting many system services and applications. Action is required to 
prevent failures

To read the complete text of this Red Alert as well as previous Red Alerts 
please use the above link.





_
Dave Jousma
Assistant Vice President, Mainframe Engineering david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 616.653.2717

This e-mail transmission contains information that is confidential and may be 
privileged.
It is intended only for the addressee(s) named above. If you receive this 
e-mail in error, please do not read, copy or disseminate it in any manner.  If 
you are not the intended recipient, any disclosure, copying, distribution or 
use of the contents of this information is prohibited. Please reply to the 
message immediately by informing the sender that the message was misdirected. 
After replying, please erase it from your computer system. Your assistance in 
correcting this error is appreciated.




--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Unicode services Red alert

[Jousma, David]

Anyone have any additional details on this?  Red Alert webpage in ResourceLink 
appears to be non-functional at the moment.

z/OS family - all hardware, OS, and related software: Red Alerts




*


z/OS Unicode Services Conversion Information Service fails after 
12-15-20




Unicode Services conversion information service on all current z/OS releases
will return incorrect return code on systems IPLed on or after December 15, 2015
affecting many system services and applications. Action is required to prevent
failures

To read the complete text of this Red Alert as well as previous Red Alerts 
please use the above link.





_
Dave Jousma
Assistant Vice President, Mainframe Engineering
david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H
p 616.653.8429
f 616.653.2717

This e-mail transmission contains information that is confidential and may be 
privileged.
It is intended only for the addressee(s) named above. If you receive this 
e-mail in error,
please do not read, copy or disseminate it in any manner.  If you are not the 
intended 
recipient, any disclosure, copying, distribution or use of the contents of this 
information
is prohibited. Please reply to the message immediately by informing the sender 
that the 
message was misdirected. After replying, please erase it from your computer 
system. Your 
assistance in correcting this error is appreciated.




--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Unicode services Red alert

[Charles Mills]

Thanks. Unfortunately those errors are a couple of layers away from Unicode
Services and don't help me.

Is someone more familiar with Apache documentation than I able to translate
what 0xC22C001E is trying to tell us?

https://apr.apache.org/docs/apr/2.0/group__apr__errno.html 

The error I am hoping for is #define CUN_RS_NO_SERV_AVAILABLE  11  /*
Service not available   */ but it looks like there is no clue here that
that is it.

Yes, I was not saying iconv *would* work, just that I would not be surprised
if it did.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Leonardo Vaz
Sent: Thursday, October 01, 2015 11:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unicode services Red alert

I was actually able to reproduce it, I had only changed local time and not
the UTC time.

IHS powered by apache doesn't start with the following error, for example:
(121)EDC5121I Invalid argument. (errno2=0xC22C001E): apr_xlate_open() failed

Doing iconv -f UTF-8 -t IBM-1047 < my_ascii_file actually doesn't
externalize an error, just says invalid argument:
iconv: Conversion from codeset "UTF-8" to "IBM-1047": EDC5121I Invalid
argument.

I'm not sure any iconv actually succeeds.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Unicode services Red alert

[Leonardo Vaz]

I was actually able to reproduce it, I had only changed local time and not the 
UTC time.

IHS powered by apache doesn't start with the following error, for example:
(121)EDC5121I Invalid argument. (errno2=0xC22C001E): apr_xlate_open() failed

Doing iconv -f UTF-8 -t IBM-1047 < my_ascii_file actually doesn't externalize 
an error, just says invalid argument:
iconv: Conversion from codeset "UTF-8" to "IBM-1047": EDC5121I Invalid argument.

I'm not sure any iconv actually succeeds.

Regards,
Leo


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Charles Mills
Sent: Thursday, October 01, 2015 1:55 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unicode services Red alert

I would appreciate that also. I would like to see the specific reason code.

My reading is that the error occurs on a call to CUNLINFO, which is optional in 
that it did not exist before V1R10 and you can use Unicode services very 
effectively without CUNLINFO. That may be why iconv succeeds, at least in some 
circumstances. CUNLINFO does not do translation, it tells you about your 
intended translation. You can call CUNLINFO (writing from memory here) and 
determine that translation from CCSID n to CCSID m is or is not 
supported, that CCSID n is single-byte EBCDIC or is MBCS ASCII, and so 
forth. Peripheral to actual translation.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Leonardo Vaz
Sent: Thursday, October 01, 2015 10:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unicode services Red alert

I am trying the following command after IPLing with a 2016 date and it works
fine:
iconv -f UTF-8 -t IBM-1047 < my_ascii_file

Could anyone reproduce the error described in the red alert?

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Unicode services Red alert

[Leonardo Vaz]

I am trying the following command after IPLing with a 2016 date and it works 
fine:
iconv -f UTF-8 -t IBM-1047 < my_ascii_file

Could anyone reproduce the error described in the red alert?

Thanks and Regards,
Leo

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Haselbach, Markus
Sent: Thursday, October 01, 2015 9:20 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unicode services Red alert

You have to install ++Apar oa48941   which belongs to Unicode Services and 
updates one LMOD in each Lpalib, Linklib and Nucleus.  


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jousma, David
Sent: Thursday, October 01, 2015 1:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Unicode services Red alert

Anyone have any additional details on this?  Red Alert webpage in ResourceLink 
appears to be non-functional at the moment.

z/OS family - all hardware, OS, and related software: Red Alerts




*


z/OS Unicode Services Conversion Information Service fails after 
12-15-20<http://www14.software.ibm.com/webapp/set2/sas/f/redAlerts?myns=z000=OCHW188=OCHW18N=OCHW19Y=OCHW20L=OCHW22D=OCHW23D=OCHW25D=OCHW30D=OCSWG90=OCSWG80=OCSWGA0=OCSWGB0=E_sp=z000-_-OCHW188-OCHW18N-OCHW19Y-OCHW20L-OCHW22D-OCHW23D-OCHW25D-OCHW30D-OCSWG90-OCSWG80-OCSWGA0-OCSWGB0-_-E>




Unicode Services conversion information service on all current z/OS releases 
will return incorrect return code on systems IPLed on or after December 15, 
2015 affecting many system services and applications. Action is required to 
prevent failures

To read the complete text of this Red Alert as well as previous Red Alerts 
please use the above link.





_
Dave Jousma
Assistant Vice President, Mainframe Engineering david.jou...@53.com
1830 East Paris, Grand Rapids, MI  49546 MD RSCB2H p 616.653.8429 f 616.653.2717

This e-mail transmission contains information that is confidential and may be 
privileged.
It is intended only for the addressee(s) named above. If you receive this 
e-mail in error, please do not read, copy or disseminate it in any manner.  If 
you are not the intended recipient, any disclosure, copying, distribution or 
use of the contents of this information is prohibited. Please reply to the 
message immediately by informing the sender that the message was misdirected. 
After replying, please erase it from your computer system. Your assistance in 
correcting this error is appreciated.




--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Unicode services Red alert

[Charles Mills]

I would appreciate that also. I would like to see the specific reason code.

My reading is that the error occurs on a call to CUNLINFO, which is optional
in that it did not exist before V1R10 and you can use Unicode services very
effectively without CUNLINFO. That may be why iconv succeeds, at least in
some circumstances. CUNLINFO does not do translation, it tells you about
your intended translation. You can call CUNLINFO (writing from memory here)
and determine that translation from CCSID n to CCSID m is or is not
supported, that CCSID n is single-byte EBCDIC or is MBCS ASCII, and so
forth. Peripheral to actual translation.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Leonardo Vaz
Sent: Thursday, October 01, 2015 10:48 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Unicode services Red alert

I am trying the following command after IPLing with a 2016 date and it works
fine:
iconv -f UTF-8 -t IBM-1047 < my_ascii_file

Could anyone reproduce the error described in the red alert?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN