Re: Junk your IT. Now. Before it drags you under

2015-10-15 Thread John McKown 
On Wed, Oct 14, 2015 at 11:32 PM, Ed Gould  wrote:

>
> http://www.theregister.co.uk/2015/10/15/junk_your_it_now_before_it_drags_you_under/
>
> Legacy systems tie you to unproductive legacy thinking and lead to
> stagnation.
>
> Really?
>
>
​If "legacy" means "static and unchanging" (think ancient Egypt), then
_maybe_ there is a small amount of truth. Surrounded by a bunch of idiocy.
"Uptime has become a god". ​

​Well, in a sense, I hope so. What good is a computer (or anything else,
like a car), if it is unavailable? Perhaps he dreams of the times of early
OS/360. I understand that the uptime was measured in minutes.

Gee, I wonder if we should tell our accountant that their insistence on
using GAAP has caused them to be stagnant. And say it in a sneering way.​
Of course, as I recall, those who use "creative accounting" usually get
free room and board courtesy of law enforcement. Oh, and let's sneer at
those silly civil engineers who keep building things according to
engineering principles. What good is a structure with long "uptime"? [snide
grin].


-- 

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

RRSF Vtam vs TCPIP

2015-10-15 Thread White, Andy 
Maybe someone can help me here: I thought IBM made a SOD for RRSF that we 
should go to TCPIP vs APPC. We currently have 15+ systems using RRSF via APPC 
and we are on z/OS 2.1 on all of them. I know it's been said many times at 
SHARE its recommended you change to TCPIP so the links can be encrypted, you 
can use TTLS etc. I'm not a RACF person more of systems back ground but is 
there an official IBM SOD? If so can you point me to it would be appreciated.


Thanks


Andy


The information contained in this message may be CONFIDENTIAL and is for the 
intended addressee only. Any unauthorized use, dissemination of the 
information, or copying of this message is prohibited. If you are not the 
intended addressee, please notify the sender immediately and delete this 
message.

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

Re: COBOL V5 and IMS Concerns

2015-10-15 Thread John McKown 
On Wed, Oct 14, 2015 at 4:08 PM, Charles Mills  wrote:

> Didn't IBM bring one of those missing NUMPROC options back in COBOL 5.2 or
> am I confused?
>
> Charles
>

​This "problem" (hardware checks invalid data & terminates), to me, to
violate​ the "spirit and intent" (as my Colonel used to say) of COBOL. I do
understand the comfort of knowing that the hardware itself will not allow
you to "ADD +1 TO 'A' ". But that, to me, makes it harder on future
programmers. Instead of actually _testing_ something and giving an
understandable error message, you get a LE abend. Which must then be traced
back to the reason, an S0C7. Which must then be tracked back back to the
COBOL variable which has the bad data. And then figure out where _that_
came from. Thank God for products like AbendAid which can do most of the
drudgery. This is another reason why I like production quality RDMS
systems. If you define the column (attribute) as an integer, then it _will_
be an integer (or money or ???). You can't stick a character string into
it. (An exception to this is the SQLite data base. I love SQLite, but it
does not validate data types in any way. Dr. Hipp, the designer/programmer,
did this deliberately). Also, it makes it more problematic to upgrade, as
Lizette has found. And much harder to "port" to another architecture. Hum,
this last might be a "good" reason to not check (increases the cost and
danger of conversion, which makes it less desirable).

Case in point for the above, from the misty past. This was in the 1970s on
OS/VS1. The original programmer got to a "this cannot occur" situation.
Rather than DISPLAY  UPON SYSOUT and call ILBOABND (I think), he (I say
he because the women programmers tended to not do this silliness) caused a
deliberate S0C7. Unfortunately, he was now gone. And we had just done a DOS
to VS1 conversion, so the other programmers didn't know how to debug it. I
ended up (just out of college) doing it, looking at the listing, and
reporting on the idiocy. This wasted about 2 hours (newbie, remember). That
firmly set my opinion of not checking for valid data.

Of course, the above is my _opinion_ and others will disagree. Hopefully we
can disagree respectfully.


-- 

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: Invoke AMODE31-only Code from AMODE6

2015-10-15 Thread Binyamin Dissen 
On Wed, 14 Oct 2015 18:49:07 -0500 "Shmuel Metz (Seymour J.)"
 wrote:

:>In
:>,
:>on 10/14/2015
:>   at 08:22 AM, Peter Relson  said:

:>>For exactly the reasons I described.

:>You described reasons for an unrelated issue.

FSVO related

:>>if you truly need to change AMODEs,

:>And if you truly need to return to the original AMODE but don't know
:>it at assembly time?

If your API requires BASSM linkage (Is there any IBM documented service that
requires this?) then great. The OP was referring to a service that documents a
requirement of AMODE31 and that returns via BR. The suggesting of using BASSM
to switch amodes in this case is ludicrous.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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

Re: Junk your IT. Now. Before it drags you under

2015-10-15 Thread Lucas Rosalen 
While there are some nice sparklings, like vendors acting more like
psychologists, the overall text shows no knowledge about IT industry,
specially "Embracing change means abandoning the false sense of stability
IT has offered management as part of its bargain to increase productivity.
Productivity is not a function of stability. It’s about the wholesale
revision of business processes to meet or generate market needs.
Productivity demands that we junk everything comfortable, everything safe,
everything stable, set our faces to the wind, and explore the unknown."

Well, I would like my credit card to work every single time I use it, no
matter what time or where in the world I am.
Also, junking everything comfort and stable might be a interesting
experience - how many trainning hours an enterprise would spend for this?
While I generally want to change/simplify most of the things at every
customer I work, I don't agree with the proposed "total change" scenario.

Lucas
On Oct 15, 2015 07:50, "Jack J. Woehr"  wrote:

> Ed Gould wrote:
>
>>
>> http://www.theregister.co.uk/2015/10/15/junk_your_it_now_before_it_drags_you_under/
>>
>> Legacy systems tie you to unproductive legacy thinking and lead to
>> stagnation.
>>
> He's not talking about mainframes. He doesn't seem to know they exist. Nor
> does he know that the demise of Sun Microsystems,
> arguably the single most innovative hardware+software company of the
> 1980's and 1990's, was in no small part due to their betting the
> farm on the proposition that Java J2EE on SPARC was going to replace TPF
> on the 390.
>
> Beyond that, what he says is nonsense in general. It's not true about
> technology as a whole. There are pools and eddies and perfectly
> lovely backwaters always.
>
> --
> Jack J. Woehr # Science is more than a body of knowledge. It's a way of
> www.well.com/~jax # thinking, a way of skeptically interrogating the
> universe
> www.softwoehr.com # with a fine understanding of human fallibility. -
> Carl Sagan
>
> --
> 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: Junk your IT. Now. Before it drags you under

2015-10-15 Thread Tom Brennan 
Doesn't seem to be targeting mainframes.  Are other old platforms now 
getting lumped into the term "legacy"?


Ed Gould wrote:

http://www.theregister.co.uk/2015/10/15/junk_your_it_now_before_it_drags_you_under/

Legacy systems tie you to unproductive legacy thinking and lead to  
stagnation.


Really?


--
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: Junk your IT. Now. Before it drags you under

2015-10-15 Thread David L. Craig 
On 15Oct14:2332-0500, Ed Gould wrote:

> http://www.theregister.co.uk/2015/10/15/junk_your_it_now_before_it_drags_you_under/
> 
> Legacy systems tie you to unproductive legacy thinking and lead to
> stagnation.
> 
> Really?

You didn't read the comments--picture a piranha feeding frenzy.
Every once in a while El Reg publishes an opinion piece by
someone born yesterday who usually regrets sharing their
not-so-well-considered opinions so publicly as a result.
-- 

May the LORD God bless you exceedingly abundantly!

Dave_Craig__
"So the universe is not quite as you thought it was.
 You'd better rearrange your beliefs, then.
 Because you certainly can't rearrange the universe."
__--from_Nightfall_by_Asimov/Silverberg_

--
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

2015-10-15 Thread 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, גדי בן אבי  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  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: Invoke AMODE31-only Code from AMODE6

2015-10-15 Thread Shmuel Metz (Seymour J.) 
In , on 10/15/2015
   at 03:59 PM, Binyamin Dissen  said:

>The OP was referring to a service that documents a
>requirement of AMODE31 and that returns via BR.

>If your API requires BASSM linkage

Is there a special on red herrings? You seem to be offering a lot of
them.

Yes, from a program running in an unexpwected AMODE. Use of BASSM
would have made that a nonisuue.

>The suggesting of using BASSM
>to switch amodes in this case is ludicrous.

Only to one who doesn't understand the issue, which is *saving*,
setting and *restoring* the AMODE.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: RRSF Vtam vs TCPIP

2015-10-15 Thread Mike Wawiorko 
The APPC Application Suite is long gone if you're on any supported release of 
z/OS. That was AFTP etc. and provided IP-like functions over APPC.

However, that's not relevant to RRSF. APPC/MVS is still a supported part of 
z/OS and may be used for RRSF amongst other things.

Your choice for RRSF is:
•   APPC/MVS, perhaps with LU6.2 session security, that you may judge not 
to be sufficiently secure these days.
•   TCPIP with AT-TLS giving industry standard PKI encryption up to TLSv1.1 
or TLSv1.2 depending on your version of z/OS.

IBM are recommending migration from APPC/MVS to TCPIP with AT-TLS as that may 
be regarded as more secure.
This has been available since z/OS 1.13, if my memory serves me correctly, and 
has been the subject of Share presentations.

Mike Wawiorko
 Please consider the environment before printing this e-mail

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mike Schwab
Sent: 15 October 2015 16:02
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RRSF Vtam vs TCPIP

http://www-03.ibm.com/systems/z/os/zos/zos_sods.html
then search for APPC:

z/OS statement of direction
August 8, 2006

IBM plans to take the following actions effective with the general availability 
of z/OS V1.8:

The APPC Application Suite is a set of common applications originally designed 
to enhance the value of SNA networks for end users. Since more full-featured 
alternative applications exist in modern integrated SNA/IP networks, z/OS V1.8 
is planned to be the last release of z/OS Communications Server which will 
include the APPC Application Suite.
After z/OS V1.8 the APPC Application Suite will no longer be shipped with the 
product, and will not be supported. However, note that APPC itself remains an 
integral part of z/OS Communications Server's SNA functions, and there are no 
plans to remove APPC from z/OS. For more information, refer to z/OS 
Communications Server Web site.



On Thu, Oct 15, 2015 at 7:59 AM, White, Andy 
> wrote:
> Maybe someone can help me here: I thought IBM made a SOD for RRSF that we 
> should go to TCPIP vs APPC. We currently have 15+ systems using RRSF via APPC 
> and we are on z/OS 2.1 on all of them. I know it's been said many times at 
> SHARE its recommended you change to TCPIP so the links can be encrypted, you 
> can use TTLS etc. I'm not a RACF person more of systems back ground but is 
> there an official IBM SOD? If so can you point me to it would be appreciated.
>
>
> Thanks
>
>
> Andy
>
>
> The information contained in this message may be CONFIDENTIAL and is for the 
> intended addressee only. Any unauthorized use, dissemination of the 
> information, or copying of this message is prohibited. If you are not the 
> intended addressee, please notify the sender immediately and delete this 
> message.
>
> --
> 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


This e-mail and any attachments are confidential and intended solely for the 
addressee and may also be privileged or exempt from disclosure under applicable 
law. If you are not the addressee, or have received this e-mail in error, 
please notify the sender immediately, delete it from your system and do not 
copy, disclose or otherwise act upon any part of this e-mail or its attachments.

Internet communications are not guaranteed to be secure or virus-free. The 
Barclays Group does not accept responsibility for any loss arising from 
unauthorised access to, or interference with, any Internet communications by 
any third party, or from the transmission of any viruses. Replies to this 
e-mail may be monitored by the Barclays Group for operational or business 
reasons.

Any opinion or other information in this e-mail or its attachments that does 
not relate to the business of the Barclays Group is personal to the sender and 
is not given or endorsed by the Barclays Group.

Barclays Bank PLC. Registered in England and Wales (registered no. 1026167). 
Registered Office: 1 Churchill Place, London, E14 5HP, United Kingdom. 

Barclays Bank PLC is authorised by the Prudential Regulation Authority and 
regulated by the Financial Conduct Authority and the Prudential Regulation 
Authority (Financial Services Register No. 122702).

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

Re: Syncsort changes hands

2015-10-15 Thread Grinsell, Don 
On 14/10/2015 20:25, Timothy Sipples wrote:
> Fun fact: Syncsort's new owners also own Jacuzzi.
So we can look forward to the return of the bubble sort!

Badaboom...and it's not even Friday yet.  

--
 
Donald Grinsell
State of Montana
406-444-2983
dgrins...@mt.gov

Vogonism: (n) originally defined as being overly bureaucratic; sticking too 
much to the book and leaving no room for original interpretation; requiring 
every single person to perceive and understand things only in a single, usually 
literal, fashion.

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

Re: RRSF Vtam vs TCPIP

2015-10-15 Thread John Eells 

White, Andy wrote:

Maybe someone can help me here: I thought IBM made a SOD for RRSF that we 
should go to TCPIP vs APPC. We currently have 15+ systems using RRSF via APPC 
and we are on z/OS 2.1 on all of them. I know it's been said many times at 
SHARE its recommended you change to TCPIP so the links can be encrypted, you 
can use TTLS etc. I'm not a RACF person more of systems back ground but is 
there an official IBM SOD? If so can you point me to it would be appreciated.



There are no current plans to remove support for RRSF over APPC.  (Of 
course, technically, we could start planning for that tomorrow.  But in 
my opinion, we won't.)


--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
ee...@us.ibm.com

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

Re: RRSF Vtam vs TCPIP

2015-10-15 Thread Mike Schwab 
http://www-03.ibm.com/systems/z/os/zos/zos_sods.html
then search for APPC:

z/OS statement of direction
August 8, 2006

IBM plans to take the following actions effective with the general
availability of z/OS V1.8:

The APPC Application Suite is a set of common applications originally
designed to enhance the value of SNA networks for end users. Since
more full-featured alternative applications exist in modern integrated
SNA/IP networks, z/OS V1.8 is planned to be the last release of z/OS
Communications Server which will include the APPC Application Suite.
After z/OS V1.8 the APPC Application Suite will no longer be shipped
with the product, and will not be supported. However, note that APPC
itself remains an integral part of z/OS Communications Server's SNA
functions, and there are no plans to remove APPC from z/OS. For more
information, refer to z/OS Communications Server Web site.



On Thu, Oct 15, 2015 at 7:59 AM, White, Andy  wrote:
> Maybe someone can help me here: I thought IBM made a SOD for RRSF that we 
> should go to TCPIP vs APPC. We currently have 15+ systems using RRSF via APPC 
> and we are on z/OS 2.1 on all of them. I know it's been said many times at 
> SHARE its recommended you change to TCPIP so the links can be encrypted, you 
> can use TTLS etc. I'm not a RACF person more of systems back ground but is 
> there an official IBM SOD? If so can you point me to it would be appreciated.
>
>
> Thanks
>
>
> Andy
>
>
> The information contained in this message may be CONFIDENTIAL and is for the 
> intended addressee only. Any unauthorized use, dissemination of the 
> information, or copying of this message is prohibited. If you are not the 
> intended addressee, please notify the sender immediately and delete this 
> message.
>
> --
> 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: Big Blue’s big storage iron gets bigger: DS8880 array uncloaked

2015-10-15 Thread Staller, Allan 
Newest I can find in the IBM Offerings is DS8870.

HTH,


Any one has url for IBM announcement letter of DS8880? I can´t find it and 
didn´t remember to see annoucement in last letters.


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

Re: Big Blue’s big storage iron gets bigger: DS8880 array uncloaked

2015-10-15 Thread Brian France 

Here's a link with some info. It's not an announcement letter but

http://www-03.ibm.com/systems/storage/disk/ds8000/

On 10/15/2015 10:46 AM, Staller, Allan wrote:

Newest I can find in the IBM Offerings is DS8870.

HTH,


Any one has url for IBM announcement letter of DS8880? I can´t find it and 
didn´t remember to see annoucement in last letters.


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


--
Brian W. France
Systems Administrator (Mainframe)
Pennsylvania State University
Administrative Information Services - Infrastructure/SYSARC
Rm 25 Shields Bldg., University Park, Pa. 16802
814-863-4739
b...@psu.edu

"To make an apple pie from scratch, you must first invent the universe."

Carl Sagan

--
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

2015-10-15 Thread 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 
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, גדי בן אבי  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  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: Junk your IT. Now. Before it drags you under

2015-10-15 Thread R.S. 

W dniu 2015-10-15 o 15:05, John McKown pisze:

​If "legacy" means "static and unchanging" (think ancient Egypt), then
_maybe_ there is a small amount of truth. Surrounded by a bunch of idiocy.


For me that could mean punched cards ;-) , VSAM passwords (OK, no longer 
available), OS/390 in use, 3380 emulation, 3390-3 model, no SMS, 3480 or 
3490E for data exchange, etc.


BTW: I upgrade or change both hardware and OS on my PC *much* less 
frequently than on production mainframe.


--
Radoslaw Skorupka
Lodz, Poland






--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru 
Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2015 r. kapitał zakładowy mBanku S.A. (w całości 
wpłacony) wynosi 168.840.228 złotych.


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

Re: Big Blue’s big storage iron gets bigger: DS8880 array uncloaked

2015-10-15 Thread Carlos Bodra 
Any one has url for IBM announcement letter of DS8880? I can´t find it 
and didn´t remember to see annoucement in last letters.



CARLOS BODRA
IBM Certified zSystem
São Paulo - SP - BRAZIL

Em 15/10/2015 01:35, Ed Gould escreveu:

http://www.theregister.co.uk/2015/10/14/ibm_ds8880_array/

There are three models:

DS8884 entry-level system that saves on space and features easy-to-use 
operations and continuous availability for running critical workloads.
DS8886 mid-range array with double the DS88770 speed, six nines 
availability and multi-site replication.

DS high-end product with all-flash media and non-stop operations
The array can scale up from 3TB to just over 3PB2 and has a 
high-performance flash enclosure (HPFE) module, with 400GB “ultra-fast 
flash cards” for the highest data access speeds. We’re told storage 
pool striping and flash drives can virtually eliminate disk “hot spots.”




--
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: COBOL V5 and IMS Concerns

2015-10-15 Thread Jon Butler 
Perhaps ILBOABN0 (zero)?

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

Re: Junk your IT. Now. Before it drags you under

2015-10-15 Thread Ed Finnell 
http://acumen.lib.ua.edu/u0001_1831001_124/image/u0001_1831001_124?p
age=1=40=move
 
Few years back. Looked like this. Got this much horsepower in tooth  
brush...  
 
 
In a message dated 10/15/2015 9:29:29 A.M. Central Daylight Time,  
r.skoru...@bremultibank.com.pl writes:

BTW: I  upgrade or change both hardware and OS on my PC *much* less 
frequently  than on production mainframe.


--
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

2015-10-15 Thread 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

2015-10-15 Thread 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)  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  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, גדי בן אבי  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  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

2015-10-15 Thread 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

2015-10-15 Thread 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

2015-10-15 Thread 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)  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  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, גדי בן אבי  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  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

2015-10-15 Thread 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

2015-10-15 Thread 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

COBOL V5.x and CSP descendants was Re: New and improved IBM migration recommendations for COBOL V5

2015-10-15 Thread Clark Morris 
On 14 Oct 2015 15:35:36 -0700, in bit.listserv.ibm-main you wrote:

>Several things have come together to give us a better recommendation
>for customers who want to migrate to COBOL V5 but who also want to avoid
>discovering 'differences' when they deploy into production.

Have the descendants of CSP 4.2 stopped forcing F zones on positive
numbers?  The ones I looked up were still forcing the F zone rather
than leaving the C zone.  Until this is changed, any installation
stuck with one of these products has to either not migrate to 5.x or
put up with bad performance.

Clark Morris
>
>First, some background.  As usual, read the COBOL Migration Guide:
>http://www-01.ibm.com/support/knowledgecenter/SS6SG3_5.2.0/welcome.html
>
>Second, some of the most difficult problems when migrating to COBOL V5
>are not caused by changes in the COBOL language supported by the compiler,
>but instead are caused by 'invalid COBOL' that cannot be detected by
>inspecting source code.
>
>The top six most common of these are:
>o Invalid data in numeric USAGE DISPLAY data items
>o Parameter/argument size mismatch:
>o Modifying data outside the bounds of a table
>o Using tables when the ODO object value is not in the legal range
>o Modifying data following a table with INDEXED BY indexes
>o Overpopulated data items, with values that have more digits than are
>   defined in the data definitions
>
>In order to find these more easily, we should recommend that users:
>- Always compile with RULES(NOEVENPACK)
>- Use the "Scanning COBOL programs for compatibility" feature of
>RDz 9.5 to check parameters and arguments
>- Compile with SSRANGE, ZONECHECK and OPT(0) for initial code changes
>and unit test
>- Recompile with NOSSRANGE, NOZONECHECK and OPT(2) for quality
>assurance test and production
>
>Finally, in the topic of "Before you buy COBOL V5", we should recommend
>the following:
>- Install the latest maintenance on LE and other products for COBOL V5
>  (Use the COBOL V5 FIXCAT feature as documented here:
>   http://www-01.ibm.com/support/docview.wss?uid=swg21648871. )
>- Change build processes to add REPLACE IGZEBST in the BIND/LINK step
> to fix the "old VS COBOL II bootstrap" problem
>- Convert PDS load libraries to PDSE
>- Locate all OS/VS COBOL programs and either target them for early
> migration to V5 or migrate to V4 now
>
>Cheers,
>TomR  >> COBOL is the Language of the Future! <<
>
>--
>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: Having the mainframe on YouTube

2015-10-15 Thread Bigendian Smalls 
Thanks Jack!  - Chad
> On Oct 15, 2015, at 2:49 PM, Jack J. Woehr  wrote:
> 
> Mark Post wrote:
>> Related to this, Chad Rikansrud has written a blog post about APAR OA43999 
>> and just how much that APAR improves RACF's encryption.  
>> Seehttp://www.bigendiansmalls.com/racf-gets-serious-about-password-encryption
>>   if you're interested.  The improvement is actually pretty impressive.
>> 
> 
> Nice presentation, learned more from that about RACF than I ever learned 
> administering it back in the 1990's!
> 
> -- 
> Jack J. Woehr # Science is more than a body of knowledge. It's a way of
> www.well.com/~jax # thinking, a way of skeptically interrogating the universe
> www.softwoehr.com # with a fine understanding of human fallibility. - Carl 
> Sagan
> 
> --
> 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: Invoke AMODE31-only Code from AMODE6

2015-10-15 Thread Binyamin Dissen 
On Thu, 15 Oct 2015 10:19:34 -0500 "Shmuel Metz (Seymour J.)"
 wrote:

:>In , on 10/15/2015
:>   at 03:59 PM, Binyamin Dissen  said:

:>>The OP was referring to a service that documents a
:>>requirement of AMODE31 and that returns via BR.

:>>If your API requires BASSM linkage

:>Is there a special on red herrings? You seem to be offering a lot of
:>them.

Not at all.

:>Yes, from a program running in an unexpwected AMODE. Use of BASSM
:>would have made that a nonisuue.

:>>The suggesting of using BASSM
:>>to switch amodes in this case is ludicrous.

:>Only to one who doesn't understand the issue, which is *saving*,
:>setting and *restoring* the AMODE.

The OPs issue was that he was running amode64 and wished to invoke a service
that required amode31. Use of BASSM would simply complicate things and not
gain anything. SAM31 before the call and SAM64 after the call works perfectly.

I grant you the last word.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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

DB2 v10

2015-10-15 Thread Mark Rodger 
Hi,

we are coming a bit late to the DB2 v10 party, having stayed on DB2 v8 for a 
bit longer than most.  Various reasons for this mostly around a requirement to 
re-write a lot of application code to get it compliant for DB2 v10.

Moving to DB2 v10 compatibility mode and we expect a fairly stable system as 
v10 has been out for a while now.  I'm just looking for advice on any gotchas 
that we should look out for maybe because of tightening up of IBM code, or 
whatever.  Any system issues that people have experienced and how to avoid them.

Thanks
Mark.

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

Re: DB2 v10

2015-10-15 Thread Taylor, Scott 
> Various reasons for this mostly around a requirement to re-write a lot of 
> application code to get it compliant for DB2 v10

I'd be equally interested in knowing what you had to redesign for compliancy, 
if you have an opportunity to share.

Regards,
Scott

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Rodger
Sent: Thursday, October 15, 2015 12:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: DB2 v10

Hi,

we are coming a bit late to the DB2 v10 party, having stayed on DB2 v8 for a 
bit longer than most.  Various reasons for this mostly around a requirement to 
re-write a lot of application code to get it compliant for DB2 v10.

Moving to DB2 v10 compatibility mode and we expect a fairly stable system as 
v10 has been out for a while now.  I'm just looking for advice on any gotchas 
that we should look out for maybe because of tightening up of IBM code, or 
whatever.  Any system issues that people have experienced and how to avoid them.

Thanks
Mark.

--
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

RSU1509 PTFs showed up today

2015-10-15 Thread David Magee 
I usually have a RECEIVE RECOMMENDED run every couple of days for my z/OS 
GLOBAL zone. Today it pulled in 204 PTFs of which 202 were marked RSU1509. 

These PTFs had not previously shown up. 

The email from IBM with Subject: "New IBM z/OS RSU testing complete" came in 
back on Oct 7th. None of my RECEIVE processes since then had picked up any new 
RSU* assigned PTFs until today. I have never seen such a delay between getting 
the email and PTFs in the repository not getting updated.

Anyone else seen this?

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

Re: Having the mainframe on YouTube

2015-10-15 Thread Jack J. Woehr 

Mark Post wrote:

Related to this, Chad Rikansrud has written a blog post about APAR OA43999 and 
just how much that APAR improves RACF's encryption.  
Seehttp://www.bigendiansmalls.com/racf-gets-serious-about-password-encryption  
if you're interested.  The improvement is actually pretty impressive.



Nice presentation, learned more from that about RACF than I ever learned 
administering it back in the 1990's!

--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

--
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

2015-10-15 Thread 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)  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  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, גדי בן אבי  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  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: DB2 v10

2015-10-15 Thread Charles Mills 
Beating Liz Koehler to the punch, there is an excellent DB2 mailing list. Join 
at IDUG.org. 

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Rodger
Sent: Thursday, October 15, 2015 10:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: DB2 v10

Hi,

we are coming a bit late to the DB2 v10 party, having stayed on DB2 v8 for a 
bit longer than most.  Various reasons for this mostly around a requirement to 
re-write a lot of application code to get it compliant for DB2 v10.

Moving to DB2 v10 compatibility mode and we expect a fairly stable system as 
v10 has been out for a while now.  I'm just looking for advice on any gotchas 
that we should look out for maybe because of tightening up of IBM code, or 
whatever.  Any system issues that people have experienced and how to avoid them.

Thanks
Mark.

--
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

2015-10-15 Thread 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  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, גדי בן אבי  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  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: