Re: Software costs - CPU Replacement

[Timothy Sipples]

Carlos Bodra wrote:
>We are studying to replace old IBM z890 Capacity Setting 230 (170 Mips –
26
>MSU´s) by an IBM z10 BC Capacity Setting J02 (182 Mips – 23 MSU´s).
>We understand that since MSU´s are lower in z10BC (23 x 26 MSU´s), we
should
>pay less for software contracts with IBM, CA and SoftwareAG.
>This situation is correct for IBM and CA, but not for SoftwareAG since
they
>charge by MIPS not MSU´s.
>Questions about:
>1 – Anyone had any experience with this?

Yes. There are some customers and a very few vendors with software license
agreements that are based on full capacity, however defined.

>2 – IBM and CA accepts capping to charge software, SoftwareAG not, is this
a
>normal business practice?

A software vendor and their customer can agree to pretty much any charging
metric, as long as it's legal. For example, if you manufacture ice cream,
you and the vendor can agree to pay for software based on the number of
liters of ice cream that you manufacture each month. Whatever contract you
have, and can agree to, is what you have.

There are some sensible industry norms, of course.

>3 – Any ideas how to circumvent this situation? z890 is out of IBM service
>and we need to replace it. 2nd hand machine available closer to z890
>capacity is z10BC, even due z/OS-e will run there with few ptfs applied to
>support new hardware (z10BC).

"Talk to your friendly IBM representative." And probably also to Brian
Westerman at Syzygy. I haven't seen your contract (and don't want to!), but
here are some ideas, in no particular order:

(a) If you have a full capacity license for the "software of concern" AND
your peak usage of that software can be substantially below 170 "MIPS,"
then consider setting up a basic Parallel Sysplex with two machines. For
example, let's suppose you only need 75 MIPS of that particular software
(at peak), and otherwise you need 130 MIPS for everything else. OK, then
you could get an IBM z13s A01 capacity model and couple it to an IBM z13s
A02 capacity model. You would run the "software of concern" on the A01
(softcapped at 75 MIPS, pay for 80 MIPS for that particular software), and
you would run all your other software on the A02 machine (and softcap it at
130 MIPS). Other "penalty box" variations are possible, of course. Note
that the machines can be physically separated a substantial amount and
probably take care of your DR needs, in "flip flop" fashion, especially if
you use Coupling Thin Interrupts and Asynchronous CF Duplexing.

(b) Buy an IBM z13s capacity model B02 (165 MIPS, 21 MSUs). The z13s B02 is
the "Price is Right" system: the closest you will get to 170 MIPS without
going over, assuming you want to maintain a 2-way configuration and
assuming you do not want to license more of that "software of concern."

(c) Buy a used IBM z10BC capacity model N01 (168 MIPS, 21 MSUs), a 1-way
machine. I do not recommend this option, for a variety of reasons.

(d) Check to see if a z/OS hosting company makes sense, at least for this
"software of concern" workload. Syzygy, IBM, and others can advise you on
such options.

(e) Migrate from the "software of concern" to a machine like the one in
Option (b) but with different software with better licensing terms. And,
preferably, use the same machine to run other cool stuff, too -- new stuff
and stuff you may already be running on other servers. There's an excellent
IBM redbook with some advice.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sipp...@sg.ibm.com

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

Re: Security, Other Risks When Unsupported (Was: z14 and z/OS 2.3 Blog Post)

[Edward Gould]

> On Aug 2, 2017, at 3:40 AM, Elardus Engelbrecht 
>  wrote:
> 
> Radoslaw Skorupka wrote:
> 
>> BTW: I would take care to inform my manager less officially (and keep the 
>> notification in my archive). From personal experience I'm aware how 
>> pointless is this ;-)
> 
> Or wait for next audit or weird abend / hacking attempt, then tell manglers, 
> supervisors and auditors.
> 
> Wait first for fireworks/drama, then wait for your retirement or dismissal 
> letter... ;-)


I did something similar but with of all thing the COBOL compiler. 
I used to go out drinking on Friday afternoons with application programmers, 
during our long lunch's we would talk a lot about issues that concerned us. I 
looked at it as tell the application people WHY they could not access this or 
do that. We were way out of date on just about everything. 
I would routinely tell my boss during meetings the issue that we were running 
into. One of the concerns I told him that at the time the programmers were 
restricted as to size of array’s in COBOL (sorry I am blanking out as to the 
proper name). COBOL programmers were essentially using VSAM files to contain 
the data, and the number of accesses to these files was causing us to be late, 
just close to late) so the opening of the market could have been delayed, and 
that was a major no-no. I regularly ran reports to show this. He said he 
followed it up and informed his management. Of course, nothing happened.
The following Christmas party I got brave and went over to the CEO and got into 
a conversation about the issue. He said he was interested and to call his 
secretary to set up a working session. I knew the secretary (long story 
deleted), and I called up the following week to ask about setting up a working 
session. She told me that he blocked off the entire afternoon on Weds. That was 
1.5 days away. So I had to whip up a few reports to show him the problems and a 
possibility on how to eliminate the bottlenecks and this was to simply upgrade 
our version of COBOL to the level that it would allow larger tables, he felt he 
understood the issue. Now, understand that the CEO was 3 or 4 levels above my 
VP. Next thing I know the VP sticks his head in my cubicle and asks me to show 
him the reports I had shown the CEO. I was in the middle of a small crisis and 
said yes, in a few minutes. After the mini crisis was dealt with I gathered the 
reports and went into his office. Next thing I knew my boss was there and his 
boss was there. I explained what was happening and why it was causing this 
delay in production. There weren’t any questions asked other than how much was 
the improved compiler. I said I guess around $250 a month, but IBM would have 
to confirm the number. 
The VP said that is all we don’t have to upgrade our machine? I said well you 
would have to sometime in the next year but this should stave off an upgrade by 
six months as we were getting close to needing one anyway due to other issues, 
much too complex to tell here. The VP looked at me well let's confirm the 
numbers and if it's around your estimate lets go ahead and buy it. I said one 
caveat, and I saw everyone look at me, and I said this issue would need to be 
implemented by program redesign. I said the programming area would have to be 
involved. I thought I heard someone get out a gun but it was something like a 
sigh. I got the COBOL upgrade, and we pushed the end of the day back about an 
hour. A few months later we were told we were going to get a major hardware 
upgrade and software as well.
Ed
  
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Security, Other Risks When Unsupported

[Timothy Sipples]

Elardus Engelbrecht wrote:
>Wait first for fireworks/drama, then wait for your retirement or
>dismissal letter... ;-)

Kees Vernooij wrote:
>Saying: if you knew this, why didn't you tell us?

Yes, I agree. You really don't want the "Why didn't you tell us?" question
after something bad happens. (Unless you want full responsibility?) It's
perfectly reasonable to inform your manager, in writing, when you spot an
anomaly that could impact the business (or government agency if you work in
the public sector). "My boss already knows" isn't quite enough here, in my
view. I'd put it in writing, and again when there's a material change to
report.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sipp...@sg.ibm.com

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

Re: ​IBM's world record: 330TB uncompressed data on a palm-sized tape cartridge

[Paul Gilmartin]

On Wed, 2 Aug 2017 18:08:24 -0500, Edward Gould wrote:

>http://www.zdnet.com/article/ibms-world-record-330tb-uncompressed-data-on-a-palm-sized-tape-cartridge/?loc=newsletter_featured_related_listing=TRE-03-10aaa6b=27692896283679241297724022269468
>
Cloud archiving services such as Amazon's Glacier and Google's Nearline and
Coldline storage have displaced tape for some long-term archival needs, ...

Of course!  It's all in vapor; no physical medium involved?

What's projected GA?

-- gil

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

​IBM's world record: 330TB uncompressed data on a palm-sized tape cartridge

[Edward Gould]

http://www.zdnet.com/article/ibms-world-record-330tb-uncompressed-data-on-a-palm-sized-tape-cartridge/?loc=newsletter_featured_related_listing=TRE-03-10aaa6b=27692896283679241297724022269468
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Question about VSMLIST and LSQA

[Don Poitras]

The convention for the past 15 years or so has been first two letters of
first name and first four letters of last name. So you'd probably be
sts...@sas.com. For collisions, I think it goes to three and three, so
possibly ste...@sas.com. You could always try to bribe somebody to be 
sas...@sas.com though. Reminds me of the Heinlein book where there was
a character known as "Rudbeck of Rudbeck at Rudbeck". :)


In article  
you wrote:
> I asked the question based on the Auth. Ass. Services Guide... later on, I
> looked at the Diagnosis Ref., which says that the 230s are allocated in the
> 250s.  Ah well, it was only idle curiosity anyway.

> If I got a job with SAS, would my email be s...@sas.com?  Or sas...@sas.com?
> UGH.  Better stay where I'm @.

> On Wed, Aug 2, 2017 at 12:49 PM, Don Poitras  wrote:

> > In article  > cwyaumn6z...@mail.gmail.com> you wrote:
> > > In sorting through the Rubik's Cube that is the subpool selection charts,
> > > it appears to me that 233-235 are defined exactly the same as 253-255
> > > respectively.  Is there some difference I'm missing?
> > > sas
> >
> > If there was a difference, that would be a problem. Since the note for
> > all three subpools says they are actually allocated in the corresponding
> > subpool. I would guess that there was some historic difference, but not
> > any more.

-- 
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

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

Re: Question about VSMLIST and LSQA

[Steve Smith]

I asked the question based on the Auth. Ass. Services Guide... later on, I
looked at the Diagnosis Ref., which says that the 230s are allocated in the
250s.  Ah well, it was only idle curiosity anyway.

If I got a job with SAS, would my email be s...@sas.com?  Or sas...@sas.com?
UGH.  Better stay where I'm @.

On Wed, Aug 2, 2017 at 12:49 PM, Don Poitras  wrote:

> In article  cwyaumn6z...@mail.gmail.com> you wrote:
> > In sorting through the Rubik's Cube that is the subpool selection charts,
> > it appears to me that 233-235 are defined exactly the same as 253-255
> > respectively.  Is there some difference I'm missing?
> > sas
>
> If there was a difference, that would be a problem. Since the note for
> all three subpools says they are actually allocated in the corresponding
> subpool. I would guess that there was some historic difference, but not
> any more.
>
>
> --
> Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
> sas...@sas.com   (919) 531-5637Cary, NC 27513
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
sas

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

Windows NFS (was: z14 and z/OS 2.3 Blog Post)

[Paul Gilmartin]

On Sat, 29 Jul 2017 10:03:43 +0800, Timothy Sipples wrote:
>
>Microsoft includes NFS ("Services for NFS") in Windows 7 Enterprise and
>Ultimate. (I don't think Windows 8.x had an Ultimate flavor, so in the
>Windows 8.x stream Microsoft's NFS is only in Windows 8 Enterprise.) All
>that really changed in Windows 10 is that Microsoft included NFS in their
>lower Windows 10 license tiers.
> 
What security mechanism(s) do(es) it provide:
o UID/GID?
  (What do UID and GID mean to Windows?)
o MVSLOGIN?
o Kerberos?
o Other (specify)?

Does it support:
o Classic data sets?
  (ISPF-style member serialization (this seems to be a z/OS server function)?
o HFS/zFS files?

-- gil

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

Re: Question about VSMLIST and LSQA

[Don Poitras]

In article  
you wrote:
> In sorting through the Rubik's Cube that is the subpool selection charts,
> it appears to me that 233-235 are defined exactly the same as 253-255
> respectively.  Is there some difference I'm missing?
> sas

If there was a difference, that would be a problem. Since the note for
all three subpools says they are actually allocated in the corresponding
subpool. I would guess that there was some historic difference, but not
any more.


-- 
Don Poitras - SAS Development  -  SAS Institute Inc. - SAS Campus Drive
sas...@sas.com   (919) 531-5637Cary, NC 27513

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

Re: [EXTERNAL] Re: Friday Fun: hcd charts to htm via b2h issue

[Dyck, Lionel B. (TRA)]

Try using 'noindex' instead of 'no index'.  You could also use index=no


--
Lionel B. Dyck 


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Dana Mitchell
Sent: Wednesday, August 02, 2017 10:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: Friday Fun: hcd charts to htm via b2h issue

Lionel,

Excellent work with B2H,  I've been experimenting with it also.  I like it,  
the price is right!
One question,  when I produce the HCD report with  'No Index'  I receive the 
following error:

B2H: Abend in line 7208 of B2H, RC=30
B2H: CondxC : SYNTAX 
B2H: CondxD :
B2H: ErrText: Name or string > 250 characters
B2H: Source :   return word(Abbrev.daid daid,1)  
|B2H107 Info:Highest RC=30   

Anyone else seen this, or is this perhaps something specific to our HCD report? 
  I'm in the process of debugging b2h to see what part of the HCD report is 
causing this.

Thanks
Dana

 
On Mon, 31 Jul 2017 06:30:01 -0500, Dyck, Lionel B. (TRA)  
wrote:

>Made the following changes e SYM file to resolve the unknown symbols:
>
>:SYM. bx0022 bx0220  V='*'
>:SYM. bx0202 bx2020 bx2200   V='|' --|||
>:SYM. bx2002 V='|' --|||
>
>I also changed the code thus as the code appeared to assume PROFILE NOPREFIX 
>and kept failing until I did this.
>
>then pipcmd 'var dsnarg | SYSDSN | buffer | var dsnarg'
>/* LBD: add quotes around dsnarg 07-28-2017 */
>else dsnarg = SYSDSN("'"dsnarg"'") /* Changed */ 
>
>The command I run for my report is
>
>'%b2h IODF.CF.REPORT ( toc=no noindex title="AITC CF IODF Chart"'
>
>And then I use XMITIP to email the html file to myself and it works nicely.
>
>---
>---
>Lionel B. Dyck
>Mainframe Systems Programmer - TRA
>

--
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: Question about VSMLIST and LSQA

[Steve Smith]

In sorting through the Rubik's Cube that is the subpool selection charts,
it appears to me that 233-235 are defined exactly the same as 253-255
respectively.  Is there some difference I'm missing?

sas

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

Re: Sort

[Scott Barry]

On Tue, 1 Aug 2017 16:17:51 -0500, gsg  wrote:

>Let me reword this.  Does anyone have any experience with CA-Sort?  How do you 
>like working with the product?  Easy to use?

CA Sort software is no longer marketed / supported, as of July 2010.

https://www.ca.com/us/services-support/ca-support/ca-support-online/product-content/status/announcement-documents/2010/ca-sort-for-zos--end-of-life-announcement.html


Scott Barry
SBBWorks, Inc.

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

Re: Software costs - CPU Replacement

[Lizette Koehler]

You should review this weblink (access the PDF) on support for the hardware

https://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/TD105503


you want to make sure the next hardware you are going to will be available for a
long time.


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Carlos Bodra - Pessoal
> Sent: Wednesday, August 02, 2017 6:07 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Software costs - CPU Replacement
> 
> We are studying to replace old IBM z890 Capacity Setting 230 (170 Mips – 26
> MSU´s) by an IBM z10 BC Capacity Setting J02 (182 Mips – 23 MSU´s).
> 
> 
> 
> We understand that since MSU´s are lower in z10BC (23 x 26 MSU´s), we should
> pay less for software contracts with IBM, CA and SoftwareAG.
> 
> 
> 
> This situation is correct for IBM and CA, but not for SoftwareAG since they
> charge by MIPS not MSU´s.
> 
> 
> 
> Questions about:
> 
> 
> 
> 1 – Anyone had any experience with this?
> 
> 
> 
> 2 – IBM and CA accepts capping to charge software, SoftwareAG not, is this a
> normal business practice?
> 
> 
> 
> 3 – Any ideas how to circumvent this situation? z890 is out of IBM service
> and we need to replace it. 2nd hand machine available closer to z890 capacity
> is z10BC, even due z/OS-e will run there with few ptfs applied to support new
> hardware (z10BC).
> 
> 
> 
> Thanks
> 
> 
> 
> Carlos Bodra
> 
> IBM System Certified System z
> 
> São Paulo - Brazil

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

Re: JCL to get a report of large datasets

[David Staudacher]

Although DCOLLECT is restricted where I work, so I've never been able to 
actually use it, I believe it's the simplest and easiest option for this task, 
if available. 
See DFSMS Data Collection Facility: 
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2i2a1/11.0

For my own homegrown solution for this requirement, I use the UCBSCAN service 
to allocate each online volser (one at a time), then run through the DSCBs in 
each VTOC and write out the information I want, including the calculated size 
of each individual extent. Then, sorting the output by DSNAME and summing the 
extent sizes, I can obtain a precise value for the number of tracks used by 
each Dataset. Then, sorting by total size in descending order, I can identify 
the largest datasets on the entire system.  For convenience, I also write the 
output to a .csv format file where it can then be easily manipulated for 
further analyis. 

A detailed discussion of the development of this solution can be found here: 
http://www.linkedin.com/groups/1462937/1462937-220206787
... along with some other goodies, such as how to use EXCP.

I can share the code for it if you like, but be forewarned it's written in 
Assembler, so the code is likely to be gibberish unless you have good 
understanding of the language.  Nonetheless, if you don't mind Assemble the 
code with the standard IBM ASMA90 Assembler, and Bind (Link) it into a load 
library, it *will* run and *will* work.

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

Re: Friday Fun: hcd charts to htm via b2h issue

[Dana Mitchell]

Lionel,

Excellent work with B2H,  I've been experimenting with it also.  I like it,  
the price is right!
One question,  when I produce the HCD report with  'No Index'  I receive the 
following error:

B2H: Abend in line 7208 of B2H, RC=30
B2H: CondxC : SYNTAX 
B2H: CondxD :
B2H: ErrText: Name or string > 250 characters
B2H: Source :   return word(Abbrev.daid daid,1)  
|B2H107 Info:Highest RC=30   

Anyone else seen this, or is this perhaps something specific to our HCD report? 
  I'm in the process of debugging b2h to see what part of the HCD report is 
causing this.

Thanks
Dana

 
On Mon, 31 Jul 2017 06:30:01 -0500, Dyck, Lionel B. (TRA)  
wrote:

>Made the following changes e SYM file to resolve the unknown symbols:
>
>:SYM. bx0022 bx0220  V='*'
>:SYM. bx0202 bx2020 bx2200   V='|' --|||
>:SYM. bx2002 V='|' --|||
>
>I also changed the code thus as the code appeared to assume PROFILE NOPREFIX 
>and kept failing until I did this.
>
>then pipcmd 'var dsnarg | SYSDSN | buffer | var dsnarg'
>/* LBD: add quotes around dsnarg 07-28-2017 */
>else dsnarg = SYSDSN("'"dsnarg"'") /* Changed */ 
>
>The command I run for my report is
>
>'%b2h IODF.CF.REPORT ( toc=no noindex title="AITC CF IODF Chart"'
>
>And then I use XMITIP to email the html file to myself and it works nicely.
>
>--
>Lionel B. Dyck 
>Mainframe Systems Programmer - TRA
>

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

Re: EXTERNAL: Re: Any IBM announcements on Cobol v4.2 EOS [Public Information]

[Usher, Darrold]

Thanks Lisette!

Classification: Public Information


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Wednesday, August 02, 2017 10:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: Re: Any IBM announcements on Cobol v4.2 EOS

Note:  If there is no EOS/EOM/EOL for that version of the product, then IBM has 
not determined a date.  So you are probably good for a long time yet.

I do not think they would do anything less than 1 year out when determining not 
to support a product - which is the first step to its life ending.

For example.  Cobol 4.1

  Enterprise COBOL for z/OS Version  4.1.x
  PID  5655-S71

  License type  ICA

  Lifecycle dates, announcement letters and other information

  GA14-Dec-2007, 207-339 
  EOM   28-Aug-2009, 209-244 
  EOS   30-Apr-2014, 913-010 

Lifecycle policy Standard 

Last updated: 13-Jun-2013.


There was 18 months from GA to EOM,  And 7 years from GA to EOS

This seems to me to mean it will take a while for the product, once a date is 
announced, to actually go through the process.

Then there are the customers of IBM, once the date is announced, that will 
complain, and IBM may move it out again.


I would not be too concerned that there is no date at this point.  If your 
conversion takes longer than 2 years, you may have some issue.

If it is that much of an issue, you could open an SR to IBM and get the answer, 
if they have one.  I am not sure the list will have internal information from 
IBM.   And IBM probably cannot discuss this issue on an open list. ;-D


Lizette




> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Lizette Koehler
> Sent: Wednesday, August 02, 2017 7:49 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Any IBM announcements on Cobol v4.2 EOS
> 
> Going to 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ibm.com=DwIFaQ=4VfW4Y7UDKzr0jHM1Tk29w=qHPaw2L0yLxvGwbmiYgAA36weh33S1tOPU9koM7O4GQ=XGUWtQuAWOtVv47dbrgRf3EPwhGs4remCL-x5toBVuE=VrEkUyLcxYbnYelnzaKO8H_AInJ-IYXBg0qotTCes-M=
> I used the search box with the words
> 
> COBOL ROADMAPor  COBOL LIFECYCLE
> 
> This brought me to this Webpage
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www-2D=DwIFaQ
> =4VfW4Y7UDKzr0jHM1Tk29w=qHPaw2L0yLxvGwbmiYgAA36weh33S1tOPU9koM7O4GQ&
> m=XGUWtQuAWOtVv47dbrgRf3EPwhGs4remCL-x5toBVuE=rSpl2jWJGw_aboCaQgdaz1
> B5PQyIZhpO8MujRJwznpM=
> 01.ibm.com/software/support/lifecycleapp/PLCDetail.wss?from=spf
> =B98438
> 5H82239E03
> 
> Lizette
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Usher, Darrold
> > Sent: Wednesday, August 02, 2017 5:06 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Any IBM announcements on Cobol v4.2 EOS
> >
> > Any IBM announcements on End of Support for Enterprise Cobol for z/OS v4.2?
> > We have Cobol v6.1 installed and our application teams are testing, 
> > but it would be nice to know how the 4.2 EOS date.
> >

--
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: Any IBM announcements on Cobol v4.2 EOS

[Lizette Koehler]

Note:  If there is no EOS/EOM/EOL for that version of the product, then IBM has 
not determined a date.  So you are probably good for a long time yet.

I do not think they would do anything less than 1 year out when determining not 
to support a product - which is the first step to its life ending.

For example.  Cobol 4.1

  Enterprise COBOL for z/OS Version  4.1.x
  PID  5655-S71

  License type  ICA

  Lifecycle dates, announcement letters and other information

  GA14-Dec-2007, 207-339 
  EOM   28-Aug-2009, 209-244 
  EOS   30-Apr-2014, 913-010 

Lifecycle policy Standard 

Last updated: 13-Jun-2013.


There was 18 months from GA to EOM,  And 7 years from GA to EOS

This seems to me to mean it will take a while for the product, once a date is 
announced, to actually go through the process.

Then there are the customers of IBM, once the date is announced, that will 
complain, and IBM may move it out again.


I would not be too concerned that there is no date at this point.  If your 
conversion takes longer than 2 years, you may have some issue.

If it is that much of an issue, you could open an SR to IBM and get the answer, 
if they have one.  I am not sure the list will have internal information from 
IBM.   And IBM probably cannot discuss this issue on an open list. ;-D


Lizette




> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lizette Koehler
> Sent: Wednesday, August 02, 2017 7:49 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Any IBM announcements on Cobol v4.2 EOS
> 
> Going to www.ibm.com   I used the search box with the words
> 
> COBOL ROADMAPor  COBOL LIFECYCLE
> 
> This brought me to this Webpage
> 
> https://www-
> 01.ibm.com/software/support/lifecycleapp/PLCDetail.wss?from=spf=B98438
> 5H82239E03
> 
> Lizette
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Usher, Darrold
> > Sent: Wednesday, August 02, 2017 5:06 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Any IBM announcements on Cobol v4.2 EOS
> >
> > Any IBM announcements on End of Support for Enterprise Cobol for z/OS v4.2?
> > We have Cobol v6.1 installed and our application teams are testing,
> > but it would be nice to know how the 4.2 EOS date.
> >

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

Re: EXTERNAL: Re: Any IBM announcements on Cobol v4.2 EOS [Public Information]

[Usher, Darrold]

Thanks Lizette. I saw the official docs, but I was hopeful to gain additional 
insight from perhaps Tom Ross to help with our planning.

https://www-01.ibm.com/software/support/lifecycleapp/PLCDetail.wss?q45=H814828B44612R28


Classification: Public Information


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Wednesday, August 02, 2017 9:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: EXTERNAL: Re: Any IBM announcements on Cobol v4.2 EOS

Going to 
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ibm.com=DwIFaQ=4VfW4Y7UDKzr0jHM1Tk29w=qHPaw2L0yLxvGwbmiYgAA36weh33S1tOPU9koM7O4GQ=UCqGwXDMhJNlTISAN_BVbuKFrJH9mGX0DFRRUVDVYr8=IvhjMi36AraIwwm_7LBMdwGen8FLWZXLSJWnAMzMQFs=
I used the search box with the words

COBOL ROADMAPor  COBOL LIFECYCLE

This brought me to this Webpage

https://urldefense.proofpoint.com/v2/url?u=https-3A__www-2D01.ibm.com_software_support_lifecycleapp_PLCDetail.wss-3Ffrom-3Dspf-26synkey-3DB984385H82239E03=DwIFaQ=4VfW4Y7UDKzr0jHM1Tk29w=qHPaw2L0yLxvGwbmiYgAA36weh33S1tOPU9koM7O4GQ=UCqGwXDMhJNlTISAN_BVbuKFrJH9mGX0DFRRUVDVYr8=5MbSSmOYJ_HMEd9WDvaawtLE2bRGCh2Z6IslJr-VL1w=
 

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Usher, Darrold
> Sent: Wednesday, August 02, 2017 5:06 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Any IBM announcements on Cobol v4.2 EOS
> 
> Any IBM announcements on End of Support for Enterprise Cobol for z/OS v4.2?
> We have Cobol v6.1 installed and our application teams are testing, 
> but it would be nice to know how the 4.2 EOS date.
> 

--
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: Any IBM announcements on Cobol v4.2 EOS

[Lizette Koehler]

Going to www.ibm.com   I used the search box with the words

COBOL ROADMAPor  COBOL LIFECYCLE

This brought me to this Webpage

https://www-01.ibm.com/software/support/lifecycleapp/PLCDetail.wss?from=spf=B984385H82239E03

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Usher, Darrold
> Sent: Wednesday, August 02, 2017 5:06 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Any IBM announcements on Cobol v4.2 EOS
> 
> Any IBM announcements on End of Support for Enterprise Cobol for z/OS v4.2?
> We have Cobol v6.1 installed and our application teams are testing, but it
> would be nice to know how the 4.2 EOS date.
> 

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

Re: XL C++ and the missing trunc()

[Charles Mills]

Not sure that it matters but the doc specifies 

#include 

Are you possibly getting the wrong math.h?

You could also try

#define _TR1_C99
#include 

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Baguley, Nicholas: Absa
Sent: Wednesday, August 2, 2017 6:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: XL C++ and the missing trunc()

Hi List

I am trying to compile some code

16761 | #define _ISOC99_SOURCE
16762 | #include "math.h"
16763 | ..dNewValue = trunc(dValue*dDigits) / dDigits;

Getting error:


¬
"/u/abnb529/cpf/source/XMM021D.C", line 16763.29: CCN5274 (S) The name
lookup for "trunc" did not find a declaration.
16764 |


Running 15650ZOS V2.2 z/OS XL C++

Version Macros. . . . . . . . : __COMPILER_VER__=0x4202
  : __LIBREL__=0x4202
  : __TARGET_LIB__=0x4202

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

Re: XL C++ and the missing trunc()

[John McKown]

On Wed, Aug 2, 2017 at 8:01 AM, Baguley, Nicholas: Absa <
nicholas.bagu...@absa.co.za> wrote:

> Hi List
>
> I am trying to compile some code
>
> 16761 | #define _ISOC99_SOURCE
> 16762 | #include "math.h"
> 16763 | ..dNewValue = trunc(dValue*dDigits) / dDigits;
>
> Getting error:
>
>
> ¬
> "/u/abnb529/cpf/source/XMM021D.C", line 16763.29: CCN5274 (S) The name
> lookup for "trunc" did not find a declaration.
> 16764 |
>
>
> Running 15650ZOS V2.2 z/OS XL C++
>
> Version Macros. . . . . . . . : __COMPILER_VER__=0x4202
>   : __LIBREL__=0x4202
>   : __TARGET_LIB__=0x4202
>
> Could anyone shed some light?
> TIA
>
> Nick Baguley
>

​Looking at page:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxbd00/trun.htm

The code seems to be:


*C++ TR1 C99*

#define _TR1_C99
#include 

float trunc(float x);

long double trunc(long double x);​


-- 
Veni, Vidi, VISA: I came, I saw, I did a little shopping.

Maranatha! <><
John McKown

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

unsubscribe

[Vince Coen]

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

Software costs - CPU Replacement

[Carlos Bodra - Pessoal]

We are studying to replace old IBM z890 Capacity Setting 230 (170 Mips – 26
MSU´s) by an IBM z10 BC Capacity Setting J02 (182 Mips – 23 MSU´s).

 

We understand that since MSU´s are lower in z10BC (23 x 26 MSU´s), we should
pay less for software contracts with IBM, CA and SoftwareAG.

 

This situation is correct for IBM and CA, but not for SoftwareAG since they
charge by MIPS not MSU´s. 

 

Questions about:

 

1 – Anyone had any experience with this?

 

2 – IBM and CA accepts capping to charge software, SoftwareAG not, is this a
normal business practice?

 

3 – Any ideas how to circumvent this situation? z890 is out of IBM service
and we need to replace it. 2nd hand machine available closer to z890
capacity is z10BC, even due z/OS-e will run there with few ptfs applied to
support new hardware (z10BC). 

 

Thanks

 

Carlos Bodra

IBM System Certified System z

São Paulo - Brazil

 


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

Re: JCL to get a report of large datasets

[Ron Thomas]

Thanks  everyone  for the valuable information .

Regards
Ron T

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

Re: Security, Other Risks When Unsupported (Was: z14 and z/OS 2.3 Blog Post)

[Mark Jacobs - Listserv]

Been there too. Got the t-shirt and everything myself several times over 
a 38 year career.


Mark Jacobs


John McKown 
August 2, 2017 at 8:42 AM

​Hum, around here when I "poke my nose in where it doesn't belong", it
tends to get whacked. My immediate manager is well aware of what is going
on. I am sure that he has let his manager know. It has most likely been
"risk assessed and accepted"​.

​-​
-
Veni, Vidi, VISA: I came, I saw, I did a little shopping.

Maranatha! <><
John McKown

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


Please be alert for any emails that may ask you for login information 
or directs you to login via a link. If you believe this message is a 
phish or aren't sure whether this message is trustworthy, please send 
the original message as an attachment to 'phish...@timeinc.com'.


Timothy Sipples 
August 2, 2017 at 3:52 AM

It is your job, too. You just write (yes write) something like:

- - - -

August 2, 2017

Dear (My Manager):

I would like to make you aware that we are no longer receiving
security-related and other patches for the following software products and
release levels that are in productive use, as of the dates indicated:

z/OS Version 1.12 2014-09-30
CICS Transaction Server Version 3.2 2015-12-31
DB2 for z/OS Version 9.1 2014-06-27

Without security patches, and without an ongoing preventive maintenance
program to apply them, there is a growing risk of breaches. We are also
running software products that will receive security updates only for the
next 12 months or less. I can provide those details upon request.

If you have any questions, please let me know. Thanks.

(My Signature)

- - - -

That's it. You've provided the factual information, in writing (which 
could
be electronic), and your manager decides what to do or not to do. If 
you've

already done that, great. If there's a material update to provide, to keep
management reasonably well informed, please do.

Just apply a "reasonable care" standard and tell your manager, that's all.
If you're a secretary at an electric company, walking along the park one
sunny afternoon, and you see a couple people trying to steal a utility
pole, "not my job" doesn't wash. You call the police, and you tell your
boss. Likewise, if somebody has left the door open to the utility pole
depot, you ring up your company's security desk and tell them. Whether 
they

do anything or not is indeed *their* job, but you can observe and notify,
too.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sipp...@sg.ibm.com

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


Please be alert for any emails that may ask you for login information 
or directs you to login via a link. If you believe this message is a 
phish or aren't sure whether this message is trustworthy, please send 
the original message as an attachment to 'phish...@timeinc.com'.




--

Mark Jacobs
Time Customer Service
Global Technology Services

The standard you walk past is the standard you accept.
Lt. Gen. David Morrison


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

XL C++ and the missing trunc()

[Baguley, Nicholas: Absa]

Hi List

I am trying to compile some code

16761 | #define _ISOC99_SOURCE
16762 | #include "math.h"
16763 | ..dNewValue = trunc(dValue*dDigits) / dDigits;

Getting error:


¬
"/u/abnb529/cpf/source/XMM021D.C", line 16763.29: CCN5274 (S) The name lookup 
for "trunc" did not find a declaration.
16764 |


Running 15650ZOS V2.2 z/OS XL C++

Version Macros. . . . . . . . : __COMPILER_VER__=0x4202
  : __LIBREL__=0x4202
  : __TARGET_LIB__=0x4202

Could anyone shed some light?
TIA

Nick Baguley


:LANGLVL(ANONSTRUCT,ANONUNION,ANSIFOR,ANSISINIT,AUTOTYPEDEDUCTION,CHECKPLACEMENTNEW,C1XNORETURN,
 
COMPLEXINIT,C99VLA,C99__FUNC__,C99LONGLONG,C99PREPROCESSOR,NOCOMPATRVALUEBINDING,CONSTEXPR,NODBCS,
DECLTYPE,DEFAULTANDDELETE,DELEGATINGCTORS,NODEPENDENTBASELOOKUP,NODOLLARINNAMES,EMPTYSTRUCT,
 
EXPLICITCONVERSIONOPERATORS,EXTENDEDFRIEND,NOEXTENDEDINTEGERSAFE,EXTERNTEMPLATE,ILLPTOM,
 
IMPLICITINT,INLINENAMESPACE,LIBEXT,NOLONGLONG,NONEWEXCP,OFFSETNONPOD,NOOLDDIGRAPH,NOOLDFRIEND,
 
NOOLDMATH,NOOLDSTR,OLDTEMPACC,NOOLDTMPLALIGN,OLDTMPLSPEC,NOREDEFMAC,RIGHTANGLEBRACKET,
 
REFERENCECOLLAPSING,RVALUEREFERENCES,SCOPEDENUM,STATIC_ASSERT,NOTEMPSASLOCALS,NOTEXTAFTERENDIF,
 
GNU_LABELVALUE,GNU_COMPUTEDGOTO,TRAILENUM,TYPEDEFCLASS,NOUCS,UNIFORMINIT,VARARGMACROS,
 
VARIADICTEMPLATES,NULLPTR,GNU_INCLUDE_NEXT,ZEROEXTARRAY,NOC99COMPLEX,NOC99COMPLEXHEADER,
 NOGNU_COMPLEX,GNU_SUFFIXIJ)



Important Notice:
Absa is an Authorised Financial Services Provider and Registered Credit 
Provider, 
registration number: NCRCP7. This e-mail and any files transmitted with it may 
contain information that is confidential, privileged or otherwise protected 
from 
disclosure. If you are not an intended recipient of this e-mail, do not 
duplicate 
or redistribute it by any means. Please delete it and any attachments and 
notify 
the sender that you have received it in error. Unless specifically indicated, 
this 
e-mail is not an offer to buy or sell or a solicitation to buy or sell any 
securities, 
investment products or other financial product or service, an official 
confirmation of 
any transaction, or an official statement of Absa. Any views or opinions 
presented 
are solely those of the author and do not necessarily represent those of Absa. 
This e-mail is subject to terms available at the following link: 
http://www.absa.co.za/disclaimer. 
The Disclaimer forms part of the content of this email. If you are unable to 
access 
the Disclaimer, send a blank e-mail to disclai...@absa.co.za and we will send 
you a 
copy of the Disclaimer. By messaging with Absa you consent to the foregoing. 
By emailing Absa you consent to the terms herein. This email may relate to or 
be sent 
from other members of the Absa Group.

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

Re: Security, Other Risks When Unsupported (Was: z14 and z/OS 2.3 Blog Post)

[John McKown]

On Wed, Aug 2, 2017 at 2:52 AM, Timothy Sipples  wrote:

> John McKown wrote:
> >Yes. And hopefully the ones whose job this is are doing that.
> >I'm a z/OS sysprog
>
> It is your job, too. You just write (yes write) something like:
>

​Hum, around here when I "poke my nose in where it doesn't belong", it
tends to get whacked. My immediate manager is well aware of what is going
on. I am sure that he has let his manager know. It has most likely been
"risk assessed and accepted"​.

​-​
-
Veni, Vidi, VISA: I came, I saw, I did a little shopping.

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: Question about VSMLIST and LSQA

[Peter Relson]

>>A key reason for the last is so that someone can use LSQA for an SRB 
that 
>>is not associated with a TCB, for which you might not want private 
storage 
>>obtained by the SRB to be freed just because some task terminates.

>Seems like a weak reason. Are there other ways SRBs are protected from 
poor
>subpool choices?

It is far from a weak reason. It is an extremely strong reason.
If this is a "poor subpool choice" then what would be a good subpool 
choice? 

Any task-related subpool will have its storage freed when that task 
terminates. An SRB *can* (but need not) be tied to a particular task. When 
it is, it can rely on a task-owned subpool associated with that task (or a 
parent of that task). When it is not, it ought not to rely on such.

The SRB, in that case, needs to use a subpool that has no task 
association. That is either LSQA or common. If anything, I'd say that 
common would be a "poor subpool choice" if addressability from multiple 
address spaces is not needed.

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

Any IBM announcements on Cobol v4.2 EOS

[Usher, Darrold]

Any IBM announcements on End of Support for Enterprise Cobol for z/OS v4.2? We 
have Cobol v6.1 installed and our application teams are testing, but it would 
be nice to know how the 4.2 EOS date.

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

Re: Tools, tips, ideas to produce visuals of your z/OS network topology

[Timothy Sipples]

In IBM's big bag of tricks I'd take a look at Tivoli Application Dependency
Discovery Manager ("TADDM"):

https://www.ibm.com/developerworks/servicemanagement/bsm/taddm/

and perhaps add a dash of Tivoli NetView for z/OS, a tool that (among other
things) has specific SNA-related expertise.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sipp...@sg.ibm.com

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

Re: Security, Other Risks When Unsupported (Was: z14 and z/OS 2.3 Blog Post)

[Elardus Engelbrecht]

Vernooij, Kees (ITOPT1) - KLM wrote:

>> >BTW: I would take care to inform my manager less officially (and keep  the 
>> >notification in my archive). From personal experience I'm aware how 
>> >pointless is this ;-) 

>> Or wait for next audit or weird abend / hacking attempt, then tell manglers, 
>> supervisors and auditors. 

>> Wait first for fireworks/drama, then wait for your retirement or dismissal 
>> letter... ;-) 
 
>Saying: if you knew this, why didn't you tell us? 

Yup. Good question. If someone ask me your question, I'll be in serious 
trouble...

In fact I have seen all variants of this:

- Tell top brass directly by mouth, e-mail, formal letter.
- Tell via supervisor/auditor using above methods.
- Delegate the trouble to someone else. (really!)
- Don't tell anyone.
- Resign. Retire. Move to other dept.
...etc...

It really helps that we (from top brass to lowest ranks) have a regurlar review 
of all software used and their levels and PTFS/APARS/patches/license fees/etc.

IBM 'n+2' version support helps us a lot.

But what about software which are already marked as 'sunset' software, but you 
are still hanging on them...?

Groete / Greetings
Elardus Engelbrecht

'sunset' - dead vendor or vendor not bothering to update/support it.

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

Re: Security, Other Risks When Unsupported (Was: z14 and z/OS 2.3 Blog Post)

[Vernooij, Kees (ITOPT1) - KLM]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Elardus Engelbrecht
> Sent: 02 August, 2017 10:40
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Security, Other Risks When Unsupported (Was: z14 and z/OS
> 2.3 Blog Post)
> 
> Radoslaw Skorupka wrote:
> 
> >BTW: I would take care to inform my manager less officially (and keep
> the notification in my archive). From personal experience I'm aware how
> pointless is this ;-)
> 
> Or wait for next audit or weird abend / hacking attempt, then tell
> manglers, supervisors and auditors.
> 
> Wait first for fireworks/drama, then wait for your retirement or
> dismissal letter... ;-)

Saying: if you knew this, why didn't you tell us?

Kees.

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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

Re: Security, Other Risks When Unsupported (Was: z14 and z/OS 2.3 Blog Post)

[Elardus Engelbrecht]

Radoslaw Skorupka wrote:

>BTW: I would take care to inform my manager less officially (and keep the 
>notification in my archive). From personal experience I'm aware how pointless 
>is this ;-)

Or wait for next audit or weird abend / hacking attempt, then tell manglers, 
supervisors and auditors.

Wait first for fireworks/drama, then wait for your retirement or dismissal 
letter... ;-)

Groete / Greetings
Elardus Engelbrecht

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

Re: Security, Other Risks When Unsupported (Was: z14 and z/OS 2.3 Blog Post)

[R.S.]

W dniu 2017-08-02 o 09:52, Timothy Sipples pisze:

John McKown wrote:

Yes. And hopefully the ones whose job this is are doing that.
I'm a z/OS sysprog

It is your job, too. You just write (yes write) something like:

- - - -

August 2, 2017

Dear (My Manager):

I would like to make you aware that we are no longer receiving
security-related and other patches for the following software products and
release levels that are in productive use, as of the dates indicated:

z/OS Version 1.12  2014-09-30
CICS Transaction Server  Version 3.2   2015-12-31
DB2 for z/OS Version 9.1   2014-06-27

Without security patches, and without an ongoing preventive maintenance
program to apply them, there is a growing risk of breaches. We are also
running software products that will receive security updates only for the
next 12 months or less. I can provide those details upon request.

If you have any questions, please let me know. Thanks.

(My Signature)

- - - -

That's it. You've provided the factual information, in writing (which could
be electronic), and your manager decides what to do or not to do. If you've
already done that, great. If there's a material update to provide, to keep
management reasonably well informed, please do.

Just apply a "reasonable care" standard and tell your manager, that's all.
If you're a secretary at an electric company, walking along the park one
sunny afternoon, and you see a couple people trying to steal a utility
pole, "not my job" doesn't wash. You call the police, and you tell your
boss. Likewise, if somebody has left the door open to the utility pole
depot, you ring up your company's security desk and tell them. Whether they
do anything or not is indeed *their* job, but you can observe and notify,
too.


Possible reaction:
(no paper, just shout): GET OUT, YOU'RE FIRED.

BTW: I would take care to inform my manager less officially (and keep 
the notification in my archive). From personal experience I'm aware how 
pointless is this ;-)



--
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.plsą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.2016 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.
   


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

Security, Other Risks When Unsupported (Was: z14 and z/OS 2.3 Blog Post)

[Timothy Sipples]

John McKown wrote:
>Yes. And hopefully the ones whose job this is are doing that.
>I'm a z/OS sysprog

It is your job, too. You just write (yes write) something like:

- - - -

August 2, 2017

Dear (My Manager):

I would like to make you aware that we are no longer receiving
security-related and other patches for the following software products and
release levels that are in productive use, as of the dates indicated:

z/OS Version 1.12  2014-09-30
CICS Transaction Server  Version 3.2   2015-12-31
DB2 for z/OS Version 9.1   2014-06-27

Without security patches, and without an ongoing preventive maintenance
program to apply them, there is a growing risk of breaches. We are also
running software products that will receive security updates only for the
next 12 months or less. I can provide those details upon request.

If you have any questions, please let me know. Thanks.

(My Signature)

- - - -

That's it. You've provided the factual information, in writing (which could
be electronic), and your manager decides what to do or not to do. If you've
already done that, great. If there's a material update to provide, to keep
management reasonably well informed, please do.

Just apply a "reasonable care" standard and tell your manager, that's all.
If you're a secretary at an electric company, walking along the park one
sunny afternoon, and you see a couple people trying to steal a utility
pole, "not my job" doesn't wash. You call the police, and you tell your
boss. Likewise, if somebody has left the door open to the utility pole
depot, you ring up your company's security desk and tell them. Whether they
do anything or not is indeed *their* job, but you can observe and notify,
too.


Timothy Sipples
IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA
E-Mail: sipp...@sg.ibm.com

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

Re: events in the New York area

[Vernooij, Kees (ITOPT1) - KLM]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of R.S.
> Sent: 02 August, 2017 9:02
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: events in the New York area
> 
> > âãé áï àáé wrote:
> >> Hi,
> >>
> >> Does anyone know of any mainframe related events in the New York are
> >> between now and August 9th?
> 
> Some IPLs are scheduled for that period.
> 
> --
> Radoslaw Skorupka
> Lodz, Poland
> 

I thought exactly the same, but then again, it was not Friday yet.
Kees.


For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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

Re: events in the New York area

[R.S.]

âãé áï àáé wrote:

Hi,

Does anyone know of any mainframe related events in the New York are 
between now and August 9th?


Some IPLs are scheduled for that period.

--
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.plsą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.2016 r. kapitał 
zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.955.696 złotych.
   


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

Re: Tools, tips, ideas to produce visuals of your z/OS network topology

[Brian Westerman]

I use Visio to map all of the networks I use, (our internal one(s) and the 
client networks as well).  I start with a basic map of Everything I can find 
and then keep overlaying things on top of that.  Eventually you get something 
that looks very convoluted, but since it's in layers you can pull any of them 
when you need it.

It doesn't take very long if you do it in steps like I do, and the layers also 
make changes a lot simpler.

There are some other products that are more drawing oriented, and they make the 
process even easier, but I've been using Visio too long to change now.

When I get to a specific area (like a NetAPP node or even a DASD controller), I 
then break out all of the devices.  I have some software I wrote that keeps 
things like DASD and TAPE statistics and names up to date on a daily or weekly 
basis, but I only use that for client sites where something like that actually 
matters.  Internally we do way too much development to try to keep close tabs 
on things.  We probably create (and delete) 10 to 15 LPARs a week, some for 
testing and some for clients, on our internal system, things are very short 
lived.  The network changes all the time to fit new projects, but without some 
solid basis for what is there, you can't really even take full advantage of 
what you have available.

Brian

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