Re: FTP TLS options

[Tom Conley]

On 4/10/2017 7:04 PM, Frank Swarbrick wrote:

I'm guessing there's a bit more to it than that, yes?  Such as actually 
configuring Policy Agent?



Frank,

Sorry, thought you already configured PAGENT, but missed the PROFILE 
member, like I did the first time I tried it.  If you run z/OSMF, you 
can config pagent.conf fairly easily with Configuration Assistant.  If 
not, you can try the samples in (WTW):


/usr/lpp/tcpip/samples/pagent_TTLS.conf

Good luck,
Tom Conley

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

Re: FTP TLS options

[Gibney, Dave]

I am at z/OS 2.1 and have
EXTENSIONS AUTH_TLS
TLSRFCLEVEL RFC4217

And some level of TLS is working

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Rob Schramm
> Sent: Monday, April 10, 2017 6:18 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: FTP TLS options
> 
> Yes. But policy agent is not actually that hard...But on zOS GT 1.13 you need
> zOSMF as well.
> 
> Rob Schramm
> 
> On Mon, Apr 10, 2017, 7:05 PM Frank Swarbrick
> 
> wrote:
> 
> > I'm guessing there's a bit more to it than that, yes?  Such as
> > actually configuring Policy Agent?
> >
> > 
> > From: IBM Mainframe Discussion List  on
> > behalf of Tom Conley 
> > Sent: Monday, April 10, 2017 3:46 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: FTP TLS options
> >
> > On 4/10/2017 3:15 PM, Frank Swarbrick wrote:
> > > Hi Mike.
> > >
> > > I assume you mean:
> > > TLSMECHANISM  ATTLS
> > > where the default (which we use) is
> > > TLSMECHANISM  FTP
> > >
> > > Unfortunately we don't currently have AT-TLS set up.  When I try to
> > > use
> > it I get the following:
> > > AT-TLS not enabled on TCPCONFIG
> > >
> > > Does z/OS FTP not support TLS v1.2 when TLSMECHANISM=FTP?
> > >
> > >
> > > I am not a sysprog so I can't speak to the question about IBM's
> > > security
> > vulnerability warnings.
> > >
> > > Frank
> >
> > Thou needst TCPCONFIG TTLS in thy PROFILE member, varlet.
> >
> > Yours,
> > Thomas de Conley
> >
> > --
> > 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
> >
> --
> 
> Rob Schramm
> 
> --
> 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: z/OS with ASCII and Non-ASCII input

[Jack J. Woehr]

Paul Gilmartin wrote:

Like Existential Bug Reports?:
 https://xkcd.com/1822/


Yeah, I've had to explain things that way at work many times.

--
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: z/OS with ASCII and Non-ASCII input

[Paul Gilmartin]

n 2017-04-10, at 18:51, Jack J. Woehr wrote:

> Phil Smith wrote:
> 
>> Those are related but*different*: one is a set of "things", one is a way to 
>> represent them.
> 
> Computer metaphysics! :)
> 
Like Existential Bug Reports?:
https://xkcd.com/1822/
https://en.wikipedia.org/wiki/Use%E2%80%93mention_distinction

-- gil

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

Re: FTP TLS options

[Rob Schramm]

Yes. But policy agent is not actually that hard...But on zOS GT 1.13 you
need zOSMF as well.

Rob Schramm

On Mon, Apr 10, 2017, 7:05 PM Frank Swarbrick 
wrote:

> I'm guessing there's a bit more to it than that, yes?  Such as actually
> configuring Policy Agent?
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Tom Conley 
> Sent: Monday, April 10, 2017 3:46 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: FTP TLS options
>
> On 4/10/2017 3:15 PM, Frank Swarbrick wrote:
> > Hi Mike.
> >
> > I assume you mean:
> > TLSMECHANISM  ATTLS
> > where the default (which we use) is
> > TLSMECHANISM  FTP
> >
> > Unfortunately we don't currently have AT-TLS set up.  When I try to use
> it I get the following:
> > AT-TLS not enabled on TCPCONFIG
> >
> > Does z/OS FTP not support TLS v1.2 when TLSMECHANISM=FTP?
> >
> >
> > I am not a sysprog so I can't speak to the question about IBM's security
> vulnerability warnings.
> >
> > Frank
>
> Thou needst TCPCONFIG TTLS in thy PROFILE member, varlet.
>
> Yours,
> Thomas de Conley
>
> --
> 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
>
-- 

Rob Schramm

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

Re: Fw: z/OS with ASCII and Non-ASCII input

[Jack J. Woehr]

Phil Smith wrote:


Those are related but*different*: one is a set of "things", one is a way to 
represent them.


Computer metaphysics! :)

--
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: Fw: z/OS with ASCII and Non-ASCII input

[Phil Smith]

>I recently received a request to produce a UNICODE table to allow zOS to 
>accept Non-ASCII input. Currently, the system recives ASCII input. Apparently 
>there is a scenario in IBM developer works to product this UNICODE table.
>My question then, if I do this, will z/OS accept both ASCII and Non-ascii 
>input?
>Has anyone gone through this exercise?

As Tom Conley notes, not clear what this means.

ASCII is a (very small) subset of Unicode.
UTF-8, UTF-16, UTF-32 are encodings.
Those are related but *different*: one is a set of "things", one is a way to 
represent them.

So what do you actually mean? This sounds interesting, not putting you down, 
just...confused!

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

SUBSCRIBE

[Hights, Charles (AMS Network Software)]

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: FTP TLS options

[Frank Swarbrick]

I'm guessing there's a bit more to it than that, yes?  Such as actually 
configuring Policy Agent?


From: IBM Mainframe Discussion List  on behalf of Tom 
Conley 
Sent: Monday, April 10, 2017 3:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: FTP TLS options

On 4/10/2017 3:15 PM, Frank Swarbrick wrote:
> Hi Mike.
>
> I assume you mean:
> TLSMECHANISM  ATTLS
> where the default (which we use) is
> TLSMECHANISM  FTP
>
> Unfortunately we don't currently have AT-TLS set up.  When I try to use it I 
> get the following:
> AT-TLS not enabled on TCPCONFIG
>
> Does z/OS FTP not support TLS v1.2 when TLSMECHANISM=FTP?
>
>
> I am not a sysprog so I can't speak to the question about IBM's security 
> vulnerability warnings.
>
> Frank

Thou needst TCPCONFIG TTLS in thy PROFILE member, varlet.

Yours,
Thomas de Conley

--
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: z/OS 1.13 to z/OS 2.2 Comm Server woes

[Tom Conley]

On 4/10/2017 5:33 PM, Lund James E wrote:

Howdy,
It pains me to ask, but can someone point me in the direction of diagnosing a 
connection problem to the mainframe *after* upgrade to z/OS 2.2?

Here's what I know:

-  Reserved port in TCPIP for the customer's connection

-  RACF userid UID and group GID defined

-  Solid connectivity from other ports (TN3270, FTP, etc.)

-  Reviewed all change pieces related to TCPIP in the Migration manual

I did generate a packet trace, but am clueless about how to read it fully.

I am not a TCPIP guy, so be patient... and I've been in the manual all day... 
nuf said.

Your knowledge would be most appreciated.

James Lund
Texas A University



James,

If you were using SSL, or AT-TLS, make sure your keyring or keydb is 
available (in your TN3270 parms).  Do you have any error messages?


Regards,
Tom Conley

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

Re: z/OS 1.13 to z/OS 2.2 Comm Server woes

[Lund James E]

Lizette,
As I understand,  the customer is using a telnet call to a mainframe server, 
listening on a defined port

Symptoms are the task hangs and eventually gives a connection failure message. 

I don't see any sense information in the trace CTRACE COMP(SYSTCPDA) FULL

Connection is Unix to MF, no other changes made.

James

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Monday, April 10, 2017 4:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] z/OS 1.13 to z/OS 2.2 Comm Server woes

What specifically are you seeing.  What sypmptoms do you have?

There should be sense info or something similar.

is the connection MF-MF, MF-AIX, etc...   

Other than z/OS was there any hardware changes?  Firewall Changes?  other?

Lizette



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

Re: FTP TLS options

[Tom Conley]

On 4/10/2017 3:15 PM, Frank Swarbrick wrote:

Hi Mike.

I assume you mean:
TLSMECHANISM  ATTLS
where the default (which we use) is
TLSMECHANISM  FTP

Unfortunately we don't currently have AT-TLS set up.  When I try to use it I 
get the following:
AT-TLS not enabled on TCPCONFIG

Does z/OS FTP not support TLS v1.2 when TLSMECHANISM=FTP?


I am not a sysprog so I can't speak to the question about IBM's security 
vulnerability warnings.

Frank


Thou needst TCPCONFIG TTLS in thy PROFILE member, varlet.

Yours,
Thomas de Conley

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

Re: z/OS 1.13 to z/OS 2.2 Comm Server woes

[Lizette Koehler]

Also, if you have not done so, you may wish to join the TCPIP list and post 
there as well.

For IBMTCP-L subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO IBMTCP-L


Lizette


-Original Message-
>From: Lund James E 
>Sent: Apr 10, 2017 2:34 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: z/OS 1.13 to z/OS 2.2 Comm Server woes
>
>Howdy,
>It pains me to ask, but can someone point me in the direction of diagnosing a 
>connection problem to the mainframe *after* upgrade to z/OS 2.2?
>
>Here's what I know:
>
>-  Reserved port in TCPIP for the customer's connection
>
>-  RACF userid UID and group GID defined
>
>-  Solid connectivity from other ports (TN3270, FTP, etc.)
>
>-  Reviewed all change pieces related to TCPIP in the Migration manual
>
>I did generate a packet trace, but am clueless about how to read it fully.
>
>I am not a TCPIP guy, so be patient... and I've been in the manual all day... 
>nuf said.
>
>Your knowledge would be most appreciated.
>
>James Lund
>Texas A University
>

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

Re: z/OS 1.13 to z/OS 2.2 Comm Server woes

[Lizette Koehler]

What specifically are you seeing.  What sypmptoms do you have?

There should be sense info or something similar.

is the connection MF-MF, MF-AIX, etc...   

Other than z/OS was there any hardware changes?  Firewall Changes?  other?

Lizette


-Original Message-
>From: Lund James E 
>Sent: Apr 10, 2017 2:34 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: z/OS 1.13 to z/OS 2.2 Comm Server woes
>
>Howdy,
>It pains me to ask, but can someone point me in the direction of diagnosing a 
>connection problem to the mainframe *after* upgrade to z/OS 2.2?
>
>Here's what I know:
>
>-  Reserved port in TCPIP for the customer's connection
>
>-  RACF userid UID and group GID defined
>
>-  Solid connectivity from other ports (TN3270, FTP, etc.)
>
>-  Reviewed all change pieces related to TCPIP in the Migration manual
>
>I did generate a packet trace, but am clueless about how to read it fully.
>
>I am not a TCPIP guy, so be patient... and I've been in the manual all day... 
>nuf said.
>
>Your knowledge would be most appreciated.
>
>James Lund
>Texas A University
>

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

Re: RMDS for reporting on Mainframe

[Lucas Rosalen]

Just for correctness, if I recall correctly CA-View is the old SAR and just
do syslog/joblog archival/retrieval.
I'm quite sure my former customer used CA-Dispatch for report distribution.

Lucas

On Apr 10, 2017 16:37, "Lizette Koehler"  wrote:

There are products out there

Systemware XPTR (not sure of today's name)

CA View (Old Mobius product I think)

$AVERS

And more

It will depend on $$ to spend and what features you need.

Searching the internet should be able to start your review process.

Not only look at the features, but how the conversion from RMDS to new
product will be handled.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of SrinivasG
> Sent: Monday, April 10, 2017 2:28 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: RMDS for reporting on Mainframe
>
> Hi,
>
> Is anyone using RMDS on Mainframe?
> Since its being discontinued , I am interested in knowing what other
shops are
> doing.
> Please share your solutions as far as RMDS is concerned.
>
> Thanks in advance.
>
> Regards,
> Srinivas G
>

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

z/OS 1.13 to z/OS 2.2 Comm Server woes

[Lund James E]

Howdy,
It pains me to ask, but can someone point me in the direction of diagnosing a 
connection problem to the mainframe *after* upgrade to z/OS 2.2?

Here's what I know:

-  Reserved port in TCPIP for the customer's connection

-  RACF userid UID and group GID defined

-  Solid connectivity from other ports (TN3270, FTP, etc.)

-  Reviewed all change pieces related to TCPIP in the Migration manual

I did generate a packet trace, but am clueless about how to read it fully.

I am not a TCPIP guy, so be patient... and I've been in the manual all day... 
nuf said.

Your knowledge would be most appreciated.

James Lund
Texas A University




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

Re: GREAT presentation on the history of the mainframe

[Anne & Lynn Wheeler]

l...@garlic.com (Anne & Lynn Wheeler) writes:
> 3090 added vector processing as part of playing in the supercomputer
> market ... however that required that they also be able to support
> 100mbyte/sec (and/or 1gbit/sec) I/O. 3090 was barely able to get up to
> 4.5mbyte/sec transfers ... so what to do?

re:
http://www.garlic.com/~lynn/2017d.html#4 GREAT presentation on the history of 
the mainframe

as mentioned mainframe bus half-duplex had increasing throughput
problems, handling 3mbyte/sec disks and then 4.5mbyte/sec disks ... but
unable to handle the engineering 40mbyte/sec disk
arrays. I've also mentioned that ESCON didn't finally get announced
until it was already obsolete (1990 w/ES9000) ... at 17mbytes/sec, it
couldn't also handle the 40mbyte/sec disk arrays.

This also basically precluded a project that the father of 801/risc
roped me into ... doing a "wide" disk head that did 18 tracks in
parallel. This is somewhat analogous to the 60s 2301 drum, essentially
the same as the 2303 drum but read/wrote four tracks in parallel at a
time, four times the transfer rate with 1/4th the number of tracks that
were four times larger.

Original 3380 had 20track width spacing between every data track. This
was later reduced to 10track width spacings for double density 3380 with
twice the number of cylinders ... and the spacing was reduced again for
triple density 3380.

Tne 3380 "wide-head" disk would have 16 adjacent data tracks plus a 17th
servo track. The "wide-head" would span 18tracks, two servo tracks on
either side of the 16 data tracks. It would read/write at
16*3mbytes/sec=48mbytes/sec. The problem for the project was that none
of IBM mainframe I/O could handle that data rate.

some old email about the wide-head r/w 16 data tracks.
http://www.garlic.com/~lynn/2006s.html#email871122
http://www.garlic.com/~lynn/2006s.html#email871230

following year (1988), I get asked to help LLNL standardize some serial
stuff they are playing with ... which quickly evolves into fibre channel
standard (initially @1gbit/sec full-duplex, 2gbit/sec aggregate) ... but
mainframe heavy-duty protocol running over fibre channel standard isn't
available until much, much later
http://www.garlic.com/~lynn/submisc.html#ficon

past posts getting to play disk engineer in bldgs 14&15 in
the late 70s and much of the 80s
http://www.garlic.com/~lynn/subtopic.html#disk

past 16+2 disk head posts:
http://www.garlic.com/~lynn/2006s.html#30 Why magnetic drums was/are worse than 
disks ?
http://www.garlic.com/~lynn/2007m.html#23 Bulkiest removable storage media?
http://www.garlic.com/~lynn/2007o.html#64 Toshiba Boosts Hard Drive Density By 
50%
http://www.garlic.com/~lynn/2009e.html#41 "A foolish consistancy" or "3390 
cyl/track architecture"
http://www.garlic.com/~lynn/2009i.html#66 Was there ever a 10in floppy?
http://www.garlic.com/~lynn/2009k.html#75 Disksize history question
http://www.garlic.com/~lynn/2009p.html#12 Secret Service plans IT reboot
http://www.garlic.com/~lynn/2010m.html#52 Basic question about CPU instructions
http://www.garlic.com/~lynn/2011g.html#70 History of byte addressing
http://www.garlic.com/~lynn/2012e.html#39 A bit of IBM System 360 nostalgia
http://www.garlic.com/~lynn/2012e.html#103 Hard Disk Drive Construction
http://www.garlic.com/~lynn/2013e.html#3 The Big, Bad Bit Stuffers of IBM
http://www.garlic.com/~lynn/2013g.html#41 A History Of Mainframe Computing
http://www.garlic.com/~lynn/2013o.html#92 Cylinder buffer
http://www.garlic.com/~lynn/2014b.html#17 Quixotically on-topic post, still on 
topic
http://www.garlic.com/~lynn/2014l.html#78 Could this be the wrongest prediction 
of all time?
http://www.garlic.com/~lynn/2016f.html#2 IBM DASD RAS discussion

-- 
virtualization experience starting Jan1968, online at home since Mar1970

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

Re: CPU Timerons/Seconds vs Wall-clock Time

[Mark Post]

>>> On 4/10/2017 at 12:13 PM, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote: 
> Isn't Linux available on at least one "real machine"?  

Linux runs on just about every type of machine, "real" or not.


Mark Post

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

z/OS positions available

[Allan Staller]

z/OS SYSPROG Position available (2) 5-10 years experience
Full Time.

Location: Toronto, Ca
Secondary Location, Dallas, Tx

Skills desired z/OS, ISV, Storage, PM/CP

Salary 75-90K USD

IMS DBA positon available (1) 5-10 years experience
Full Time.

Location: Toronto, Ca
Secondary Location, Dallas, Tx

Skills desired IMS, HALDB, DBRC

Salary 75-90K USD


Please respond off-list.
Allan dot staller at hcl dot com


::DISCLAIMER::


The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information 
could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in 
transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on 
the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the 
author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, 
dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written 
consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please 
delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and 
other defects.



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

Re: FTP TLS options

[Frank Swarbrick]

Hi Mike.

I assume you mean:
TLSMECHANISM  ATTLS
where the default (which we use) is
TLSMECHANISM  FTP

Unfortunately we don't currently have AT-TLS set up.  When I try to use it I 
get the following:
AT-TLS not enabled on TCPCONFIG

Does z/OS FTP not support TLS v1.2 when TLSMECHANISM=FTP?


I am not a sysprog so I can't speak to the question about IBM's security 
vulnerability warnings.

Frank


From: IBM Mainframe Discussion List  on behalf of 
Mike Wawiorko <014ab5cdfb21-dmarc-requ...@listserv.ua.edu>
Sent: Monday, April 10, 2017 4:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: FTP TLS options

Frank,

You should change to AT-TLS

SECURE_MECHANISM  ATTLS

That will get TLSv1.2 support but just as important will allow you to use newer 
cipher suites.

Many of the older cipher suites supported by the FTP client (or server) 
internal SSL/TLS function have been the subject of security warnings over the 
last couple of years.

Do you subscribe to IBM's security vulnerability warnings?

Mike Wawiorko

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Frank Swarbrick
Sent: 07 April 2017 19:28
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: FTP TLS options

Does z/OS 2.2 support TLS v1.2 for FTP clients without the use of AT-TLS?  This 
new server we have is (currently) configured to support only TLS v1.2, and 
nothing earlier.  We're trying to get approval to "back down" to TLS v1.0, but 
I figured I'd ask this anyway.

Frank
nstructions, 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 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: AW: Re: Opinion: Using C "standard library" routines in COBOL.

[scott Ford]

Sure does,

Threading in C easier in some sense than Assembler attaches, I an in this
situation now.
Write and attach routine or write in C , actually convert to C.

Scott


On Mon, Apr 10, 2017 at 1:17 PM Jack J. Woehr  wrote:

> Peter Hunkeler wrote:
>
>
> > If, on the other hand, you call C/C++ runtime library routines, the
> final code is not located via LOAD, but via some table with entry point
> addresses
>
> Makes sense. So write a one-liner wrapper for the library routine and
> compile it into your own little library.
>
> --
> 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
>
-- 
Scott Ford
IDMWORKS
z/OS Development

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

Re: AW: Re: Opinion: Using C "standard library" routines in COBOL.

[Jack J. Woehr]

Peter Hunkeler wrote:



If, on the other hand, you call C/C++ runtime library routines, the final code 
is not located via LOAD, but via some table with entry point addresses


Makes sense. So write a one-liner wrapper for the library routine and compile 
it into your own little library.

--
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: Opinion: Using C "standard library" routines in COBOL.

[Paul Gilmartin]

On Mon, 10 Apr 2017 15:44:44 +0200, Peter Hunkeler wrote:

>Sorry for the late reply. I've been trying to find the documentation that 
>talks about calling C/C++ library functions from other HLL code, such as 
>Cobol. All I found was ...
>
Nearly a half-century ago, when I had no experience with OS/360 nor access to 
it,
a brash post-doc, fresh out of Yale, praised OS, on which all languages and even
initiators used the same calling conventions.

"Even ALGOL-60, SNOBOL4, and LISP?"

"Of course!  And our system had 2000K!"

Them was the good old days.

He also lauded CP67 for giving him the appearance of having his own private
computer.  But I bet that at some level it had different calling conventions.

-- gil

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

Re: CPU Timerons/Seconds vs Wall-clock Time

[Paul Gilmartin]

On 2017-04-09, at 10:57, Lindy Mayfield wrote:

> you got me on that one, gil. :)  trying to exploit the ambiguity of a Sunday. 
>  guilty.
> 
> i got a side gig to figure out some performance problems, and it ain't on 
> linux, but on a real machine.  and nothing is good on tv at the moment.
>  
Isn't Linux available on at least one "real machine"?  

-- gil

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

Re: RMDS for reporting on Mainframe

[John McKown]

On Mon, Apr 10, 2017 at 9:37 AM, Lizette Koehler 
wrote:

> There are products out there
>
> Systemware XPTR (not sure of today's name)
>
> CA View (Old Mobius product I think)
>
> $AVERS
>
> And more
>
> It will depend on $$ to spend and what features you need.
>

​One thing that is (now) of greater importance to me is "Where is the data
stored?". There there seems to be two choices in today's world: individual
sequential(?) data sets for each job or in a single "data store" ​data set
which contains a "directory" and comes with "management software" to do
things such as request a reprint or archive old output. I rather liked the
"one PS data set per job/report" philosophy because it was easy to read
reports via ISPF 3.4. Even better, IMO, would be "one UNIX file per
report". Why UNIX you ask? Because it is _easy_ to use something like
"grep" to find complicated search strings. Well, it is easy so long as you
know regular expressions; which I do. Also, depending on your company's
technical expertise, it would be "easy" to transfer the reports to a
distributed system and index it similar to a "web search" engine so that
your user could do a Google (or Bing) like search.

We actually use a product which is PC resident (Report 2 Web). The z/OS
system uses JQP from MacKinney Software to send reports to a "LAN printer",
which is actually a "service" on a Windows machine. This service looks at
the data in the report (which includes a job separator which we use to
communicate with the service) to classify it. It can then do a number of
things with the data (including creating a subset from an embedded "table"
which is stored in an Excel spreadsheet), but we manly just store it in a
reformatted file on a LAN disk. The "index" to this is kept in an Oracle
data base (but, IIRC, it could use any ODBC compliant data base). Users are
defined to the software for access to specific reports. The users access
the reports to which they are authorized via their browser (thus to "2 Web"
part of the name). The file format on disk is undocumented, but fairly
simple to figure out.


>
> Searching the internet should be able to start your review process.
>
> Not only look at the features, but how the conversion from RMDS to new
> product will be handled.
>

​We converted from Mobius Infopack. We had help from a consulting firm
which basically wrote some programs to parse the output from an Infopack
report on available reports, and create "print" jobs which sent the "print"
out to the "LAN printer". Basically, it was a programmed operator to
request a reprint of every report in Infopack.​ Mobius was not well pleased
about the "automation", as I recall.



>
> Lizette
>


-- 
"Irrigation of the land with seawater desalinated by fusion power is
ancient. It's called 'rain'." -- Michael McClary, in alt.fusion

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: RLS for catalogs

[Mark Zelden]

On Sat, 8 Apr 2017 00:56:15 +, Jesse 1 Robinson  
wrote:

>I love getting affirmation after all these years, but I'm still a bit queasy. 
>All I did was
> change from GRS ring to star. No RNL changes. Is the 'QNAME=SYSZVVDS  
> RNAME=volser'
> conversion still explained? 
>
> Note that, despite years of IBM recommendations, we do not convert RESERVE to 
> ENQ
> because we have a handful of MIA data sets shared across sysplexes, across 
> data centers.
> I have always been afraid to throw those guys to the wolves.  
 
Oh, I missed that point.  I assumed once you went to GRS STAR you started 
converting
SYSVTOC and SYSVVDS.   So much for that theory.   I'm back to my first one 
then...
different code path that is more efficient.  

Regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://search390.techtarget.com/ateExperts/
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Fw: z/OS with ASCII and Non-ASCII input

[Tom Conley]

On 4/10/2017 10:47 AM, william janulin wrote:

  I am sending this question again as I do not recall receiving a response.

I recently received a request to produce a UNICODE table to allow zOS to accept 
Non-ASCII input. Currently, the system recives ASCII input. Apparently there is 
a scenario in IBM developer works to product this UNICODE table.
My question then, if I do this, will z/OS accept both ASCII and Non-ascii input?
Has anyone gone through this exercise?
Thank you in advance, Bill J.


 On Thursday, March 30, 2017 3:52 PM, william janulin  
wrote:


 To list;
  I recently received a request to produce a UNICODE table to allow zOS to 
accept Non-ASCII input. Currently, the system recives ASCII input. Apparently 
there is a scenario in IBM developer works to product this UNICODE table.
My question then, if I do this, will z/OS accept both ASCII and Non-ascii input?
Has anyone gone through this exercise?
Thank you in advance, Bill J.



Bill,

Not sure what you mean by "accept".  If you have UNICODE data in a file, 
ISPF EDIT and BROWSE should be able to display it properly.  You need to 
enter UTF-8 on the EDIT primary panel, or tag the file with CCSID 1208. 
Do a Google search on display Unicode data in ISPF and look at the ISPF 
Hidden Treasures presentation.


Regards,
Tom Conley

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

AW: Re: Opinion: Using C "standard library" routines in COBOL.

[Peter Hunkeler]

>What's the difference between calling C/C++ runtime library functions and your 
>own library functions? There's no difference in the C/C++ languages per se.




Well, for the topic at hand, there is, I think.


If you code your own C/C++, the compiler generates the code, and it includes 
the C/C++ signature CSECT CEESG003 is included in the resulting load module. 
This way LE knows that this is C/C++ code and makes sure the C/C++ LE 
Environment is initialized before your code gets control.


If, on the other hand, you call C/C++ runtime library routines, the final code 
is not located via LOAD, but via some table with entry point addresses. This is 
what the stub code does. In the example given, the CUSERID code was not found, 
unless the stub was linked to the module, or the CUSERID stub was LOADed. 
Unfortunately, the stub does not contain the C/C+ signature CSECT, thus the 
entry point address was not found, hence the S0C1.




I agree that there is no difference between your own C/C++ code and runtime 
library functions when takling about parameters and return values.


I would assume all the above equally applies to the other LE HLLs, such as PL/I 
and Cobol.


--
Peter Hunkeler



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

Re: Opinion: Using C "standard library" routines in COBOL.

[Farley, Peter x23353]

Peter,

There is no way in COBOL (at least not in any version of which I am aware) to 
tell the compiler that a called module is written in another language.

The importance of being able to dynamically call C library routines is only 
that some shops forbid using static calls as part of normal program development 
and automatically enforce the rule (my shop is one such) to prevent the ancient 
problem of shop-wide subroutines changed and needing to re-link all programs 
that use those shop-wide subroutines.

But you are correct - from a first look, dynamic calls of C library routines 
would probably be a "bad thing" to do as a general rule, due to the no-doubt 
extensive interconnections between them.

HOWEVER, because the SYS1.SCEELKED C library routines are all actually just 
stubs to the "real" routines, I think it will work just fine.  The "real" 
routines are where the cross-linkage exists, not between the stubs.

Now, whether C library routines or even their stubs should be coded to ASSUME 
static linking is a different question.  I would argue that any good library 
routine design should ASSUME dynamic calling from the start, but that is just 
my humble opinion.

I think IBM has solved the design problem with these stubs, since none of them 
actually contains any C library code, thus bypassing any problem with 
cross-linked subroutines.

Whether allowing the use of SYS1.SCEELKED in STEPLIB or JOBLIB in a production 
JCL is a good idea or not is probably a judgment call for each unique shop.  
Understanding the technology, I would support it as reasonable when the C 
library functions provide good ROI for the development team.

Again, just my humble opinion.

Peter

(BTW, good name, there are not that many of us around . . . :) )

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Peter Hunkeler
Sent: Monday, April 10, 2017 9:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Opinion: Using C "standard library" routines in COBOL.

Sorry for the late reply. I've been trying to find the documentation that talks 
about calling C/C++ library functions from other HLL code, such as Cobol. All I 
found was information about doing interlanguage calls, but this is all about 
"own" code, not the functions that the C/C++ runtime library provides.

>Subsequent COBOL V5.2 testing showed that including CEESG003 at link/bind time 
>also works for COBOL V5.2 dynamic call.  SYS1.SCEELKED is still required in 
>STEPLIB/JOBLIB/LINKLIST for dynamic calls to work. 

Language Environment uses signature CSECTs CEESGnnn to represent those LE 
supported HLL languages that are being used in the current load module.

When a new (or first) load module is loaded into the enclave, LE looks for the 
signature CSECTs that are present in the load module, compares that with the 
list of LE languages already initialized, and then initializes any new 
language. This process, amongst other things, lets the pointer in the CAA point 
to the correct structures.

Pardon my ignorance, I'm not fluent in Cobol, but the code you showed does not 
seem to tell the compiler that the dynamically called routine CUSERID is a C 
routine. Therefore the compiler does not include CSECT CEESG003. Is there a 
means in Cobol to declare a certain dynamically called routine is written in C, 
so that the compiler would know?

The stubs in SYS1.SCEELKED are not complete load modules, they are intended to 
be used in the link/bind step (yes, I'm still eager to find this documented 
explicitly). The do not the signature CSECTs, so LE has not handle to recognize 
a new language is to be initialized when one of those routines is dynamically 
called.

Apart from all that, I still do not understand why it is so important to you to 
have those calls be dynamic calls. When you code a C routine, you are using a 
lot of the runtime library functions, aren't you? All of those are statically 
bound. If there was danger of missing an important LE service update with 
those, IBM would need to mark those PTFs with a HOLD action "Must rebind any 
and alll your programs using C functions". Not something I can imagine to ever 
happen.

I would not have a good feeling with manually including signature CSECTs and 
running with SYS1.SCEELKED in the steplib concatention. 
--

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to 

Fw: z/OS with ASCII and Non-ASCII input

[william janulin]

To list;
  I am sending this question again as I do not recall receiving a response. 

I recently received a request to produce a UNICODE table to allow zOS to accept 
Non-ASCII input. Currently, the system recives ASCII input. Apparently there is 
a scenario in IBM developer works to product this UNICODE table.
My question then, if I do this, will z/OS accept both ASCII and Non-ascii input?
Has anyone gone through this exercise?
Thank you in advance, Bill J.


 On Thursday, March 30, 2017 3:52 PM, william janulin  
wrote:
 

 To list;
  I recently received a request to produce a UNICODE table to allow zOS to 
accept Non-ASCII input. Currently, the system recives ASCII input. Apparently 
there is a scenario in IBM developer works to product this UNICODE table.
My question then, if I do this, will z/OS accept both ASCII and Non-ascii input?
Has anyone gone through this exercise?
Thank you in advance, Bill J.


   

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

Re: RMDS for reporting on Mainframe

[Lizette Koehler]

There are products out there

Systemware XPTR (not sure of today's name)

CA View (Old Mobius product I think)

$AVERS

And more

It will depend on $$ to spend and what features you need.

Searching the internet should be able to start your review process.

Not only look at the features, but how the conversion from RMDS to new product 
will be handled.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of SrinivasG
> Sent: Monday, April 10, 2017 2:28 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: RMDS for reporting on Mainframe
> 
> Hi,
> 
> Is anyone using RMDS on Mainframe?
> Since its being discontinued , I am interested in knowing what other shops are
> doing.
> Please share your solutions as far as RMDS is concerned.
> 
> Thanks in advance.
> 
> Regards,
> Srinivas G
> 

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

Re: Opinion: Using C "standard library" routines in COBOL.

[John McKown]

On Mon, Apr 10, 2017 at 9:16 AM, Jack J. Woehr  wrote:

> Peter Hunkeler wrote:
>
>>   All I found was information about doing interlanguage calls, but this
>> is all about "own" code, not the functions that the C/C++ runtime library
>> provides.
>>
>
>
> What's the difference between calling C/C++ runtime library functions and
> your own library functions? There's no difference in the C/C++ languages
> per se.


​True. I have seen people who would replace "core" functions, such as
"malloc()" with their own code (usually for some sort of tracking).​



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



-- 
"Irrigation of the land with seawater desalinated by fusion power is
ancient. It's called 'rain'." -- Michael McClary, in alt.fusion

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: Opinion: Using C "standard library" routines in COBOL.

[Jack J. Woehr]

Peter Hunkeler wrote:

  All I found was information about doing interlanguage calls, but this is all about 
"own" code, not the functions that the C/C++ runtime library provides.



What's the difference between calling C/C++ runtime library functions and your own library functions? There's no 
difference in the C/C++ languages per se.


--
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: Opinion: Using C "standard library" routines in COBOL.

[Peter Hunkeler]

Sorry for the late reply. I've been trying to find the documentation that talks 
about calling C/C++ library functions from other HLL code, such as Cobol. All I 
found was information about doing interlanguage calls, but this is all about 
"own" code, not the functions that the C/C++ runtime library provides.



>Subsequent COBOL V5.2 testing showed that including CEESG003 at link/bind time 
>also works for COBOL V5.2 dynamic call.  SYS1.SCEELKED is still required in 
>STEPLIB/JOBLIB/LINKLIST for dynamic calls to work.




Language Environment uses signature CSECTs CEESGnnn to represent those LE 
supported HLL languages that are being used in the current load module.


When a new (or first) load module is loaded into the enclave, LE looks for the 
signature CSECTs that are present in the load module, compares that with the 
list of LE languages already initialized, and then initializes any new 
language. This process, amongst other things, lets the pointer in the CAA point 
to the correct structures.




Pardon my ignorance, I'm not fluent in Cobol, but the code you showed does not 
seem to tell the compiler that the dynamically called routine CUSERID is a C 
routine. Therefore the compiler does not include CSECT CEESG003. Is there a 
means in Cobol to declare a certain dynamically called routine is written in C, 
so that the compiler would know?




The stubs in SYS1.SCEELKED are not complete load modules, they are intended to 
be used in the link/bind step (yes, I'm still eager to find this documented 
explicitly). The do not the signature CSECTs, so LE has not handle to recognize 
a new language is to be initialized when one of those routines is dynamically 
called.




Apart from all that, I still do not understand why it is so important to you to 
have those calls be dynamic calls. When you code a C routine, you are using a 
lot of the runtime library functions, aren't you? All of those are statically 
bound. If there was danger of missing an important LE service update with 
those, IBM would need to mark those PTFs with a HOLD action "Must rebind any 
and alll your programs using C functions". Not something I can imagine to ever 
happen.




I would not have a good feeling with manually including signature CSECTs and 
running with SYS1.SCEELKED in the steplib concatention.



--
Peter Hunkeler

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

Re: CPU Timerons/Seconds vs Wall-clock Time

[Tom Marchant]

On Sun, 9 Apr 2017 15:48:12 +, Lindy Mayfield wrote:

>if an MVS job ran and consumed 10 CPU seconds (SMF 30 I think), can I assume 
>that it at least took 10 seconds of elapsed time to run?

If it is a single task application, yes.
If it runs multiple tasks, not necessarily. For example, if you have an 
application that attaches 4 additional tasks and each of the 5 tasks uses 5 
seconds of CPU during the 10 seconds elapsed time, it would use a total of 25 
seconds of CPU time.

-- 
Tom Marchant

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

Re: CPU Timerons/Seconds vs Wall-clock Time

[Avram Friedman]

On Sun, 9 Apr 2017 15:48:12 +, Lindy Mayfield  
wrote:

The easy answer is no it is not reasonable to think that.

Min elapsed time
=
corrected recorded CPU time
/
# CPs

Avram Friedman

>This may or may not be the dumbest question I've asked this week, but I've 
>been working with Linux a lot lately so that's my excuse.
>
>For example, if an MVS job ran and consumed 10 CPU seconds (SMF 30 I think), 
>can I assume that it at least took 10 seconds of elapsed time to run?
>
>Regards,
>Lindy
>
>--
>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: 360 announce day

[Tom Marchant]

On Sat, 8 Apr 2017 16:13:16 -0500, Paul Gilmartin wrote:

>What's the "performance range" of currently marketed z models?

There is no simple ratio to compare the performance of different models, 
but you can figure out something that interests you from the LSPR.

https://www-304.ibm.com/servers/resourcelink/lib03060.nsf/pages/lsprindex?OpenDocument

-- 
Tom Marchant

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

Re: RLS for catalogs

[Vernooij, Kees (ITOPT1) - KLM]

Moving from MIM to GRS STAR can be done in flight, it only requires good 
preparation. Moving back requires IPLs.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Joe Owens
> Sent: 10 April, 2017 13:29
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: RLS for catalogs
> 
> Hi everyone, thanks for replys.
> 
> We use MIM historically. I know we can convert to GRS STAR, which is
> quite a big change and needs to be done carefully. It would probably
> need an all systems IPL. In terms of cost, we have several CA products
> bundled, and dropping one generally does not save money.
> 
> We do convert the SYSIGGV2 reserve. But RLS eliminates the reserve, and
> seems to be a good thing to do,
> 
> It seems we may be alone with MIM/RLS? and the particular issue of the
> order of initialisation.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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: RLS for catalogs

[Joe Owens]

Hi everyone, thanks for replys.

We use MIM historically. I know we can convert to GRS STAR, which is quite a 
big change and needs to be done carefully. It would probably need an all 
systems IPL. In terms of cost, we have several CA products bundled, and 
dropping one generally does not save money.

We do convert the SYSIGGV2 reserve. But RLS eliminates the reserve, and seems 
to be a good thing to do,

It seems we may be alone with MIM/RLS? and the particular issue of the order of 
initialisation.

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

Re: CPU Timerons/Seconds vs Wall-clock Time

[Massimo Biancucci]

Guessing once again,

if for "offending" you mean jobs using lot of CPU within one interval, it's
better to look at SMF30 subtype other than 4 (2,3, or 6 maybe).

Usually this "prunes" problems like jobs waiting for init or HSM recall and
so on and gives you a good understanding about ASs using more CPU. With
SMFINTVL little (reasonably) enough it can be a good point view.

Regards.
Massimo

2017-04-10 10:48 GMT+02:00 Lindy Mayfield :

> My question I guess was a bit more theoretical.
>
> If I submitted an assembler job that ran in a tight loop doing nothing but
> using CPU, it went straight into the RDR, high service class, and ran for
> 10 CPU seconds.
>
> I'd expect the job to run at least 10 seconds wall clock time, plus the
> overhead of the system, but never under 10 seconds unless it is
> multithreaded perhaps.
>
> From SMF recs I can identify jobs sorted on cpu and excp to try to get the
> worst offenders in all cases, but then I have to go into the individual job
> log and see elapsed time.  I have already discovered huge wait times that I
> cannot explain due to what I think is taking 20 minutes to not find a
> dataset, perhaps some sort of catalog search problem.
>
> So, as Lizette pointed out, my scheme has flaws because there are too many
> factors that influence elapsed time, including locating system issues from
> RMF3 and other nasty SMF record types.  It's easier to write a program to
> parse the job logs. :)
>
> Thanks for all you help and knowledge.  I joined this group about 17 years
> ago, and I'm still the baby of the group. :)
>
> /Lindy
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Lizette Koehler
> Sent: sunnuntai 9. huhtikuuta 2017 22.16
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: CPU Timerons/Seconds vs Wall-clock Time
>
> I am not sure that looking at one SMF record can tell the story.
>
> If the job ran long, was it due to
>
> I/O
>
> Looping Code
>
> Larger than normal Data Load
>
> And so on.
>
> Maybe other can provide better insight.
>
> Lizette
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Lindy Mayfield
> > Sent: Sunday, April 09, 2017 9:42 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: CPU Timerons/Seconds vs Wall-clock Time
> >
> > I only have CPU time from SMF 30 but I don't have elapsed time which
> > is very important.  I'd like to somewhat infer that a high CPU time
> > means the job ran a long time.
> >
> > /Lindy
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> > On Behalf Of Lizette Koehler
> > Sent: sunnuntai 9. huhtikuuta 2017 18.55
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: CPU Timerons/Seconds vs Wall-clock Time
> >
> > What are you trying to solve?
> >
> > Jobs get swapped in and out depending on what work they are doing.
> >
> >
> > Are you trying to relate wall clock to cpu time?  I have seen jobs run
> > 2 hours wall clock time and only take 10 mins of CPU time.
> >
> > Lizette
> >
> >
> > > -Original Message-
> > > From: IBM Mainframe Discussion List
> > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lindy Mayfield
> > > Sent: Sunday, April 09, 2017 8:48 AM
> > > To: IBM-MAIN@LISTSERV.UA.EDU
> > > Subject: CPU Timerons/Seconds vs Wall-clock Time
> > >
> > > This may or may not be the dumbest question I've asked this week,
> > > but I've been working with Linux a lot lately so that's my excuse.
> > >
> > > For example, if an MVS job ran and consumed 10 CPU seconds (SMF 30 I
> > > think), can I assume that it at least took 10 seconds of elapsed
> > > time to
> > run?
> > >
> > > Regards,
> > > Lindy
>
> --
> 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: RMDS for reporting on Mainframe

[Brian France]

We moved from RMDS more years ago than I can remember. We use JSF from 
Mackinney.



On 4/10/2017 5:27 AM, SrinivasG wrote:

Hi,

Is anyone using RMDS on Mainframe?
Since its being discontinued , I am interested in knowing what other shops are 
doing.
Please share your solutions as far as RMDS is concerned.

Thanks in advance.

Regards,
Srinivas G

--
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: FTP TLS options

[Mike Wawiorko]

Frank,

You should change to AT-TLS

SECURE_MECHANISM  ATTLS   

That will get TLSv1.2 support but just as important will allow you to use newer 
cipher suites.

Many of the older cipher suites supported by the FTP client (or server) 
internal SSL/TLS function have been the subject of security warnings over the 
last couple of years.

Do you subscribe to IBM's security vulnerability warnings?

Mike Wawiorko
   
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Frank Swarbrick
Sent: 07 April 2017 19:28
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: FTP TLS options

Does z/OS 2.2 support TLS v1.2 for FTP clients without the use of AT-TLS?  This 
new server we have is (currently) configured to support only TLS v1.2, and 
nothing earlier.  We're trying to get approval to "back down" to TLS v1.0, but 
I figured I'd ask this anyway.

Frank
nstructions, 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 with the message: INFO IBM-MAIN

RMDS for reporting on Mainframe

[SrinivasG]

Hi,

Is anyone using RMDS on Mainframe? 
Since its being discontinued , I am interested in knowing what other shops are 
doing.
Please share your solutions as far as RMDS is concerned.

Thanks in advance.

Regards,
Srinivas G

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

Re: CPU Timerons/Seconds vs Wall-clock Time

[Lindy Mayfield]

My question I guess was a bit more theoretical.  

If I submitted an assembler job that ran in a tight loop doing nothing but 
using CPU, it went straight into the RDR, high service class, and ran for 10 
CPU seconds.  

I'd expect the job to run at least 10 seconds wall clock time, plus the 
overhead of the system, but never under 10 seconds unless it is multithreaded 
perhaps.

>From SMF recs I can identify jobs sorted on cpu and excp to try to get the 
>worst offenders in all cases, but then I have to go into the individual job 
>log and see elapsed time.  I have already discovered huge wait times that I 
>cannot explain due to what I think is taking 20 minutes to not find a dataset, 
>perhaps some sort of catalog search problem.  

So, as Lizette pointed out, my scheme has flaws because there are too many 
factors that influence elapsed time, including locating system issues from RMF3 
and other nasty SMF record types.  It's easier to write a program to parse the 
job logs. :)

Thanks for all you help and knowledge.  I joined this group about 17 years ago, 
and I'm still the baby of the group. :)

/Lindy

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: sunnuntai 9. huhtikuuta 2017 22.16
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: CPU Timerons/Seconds vs Wall-clock Time

I am not sure that looking at one SMF record can tell the story.

If the job ran long, was it due to

I/O

Looping Code

Larger than normal Data Load

And so on.

Maybe other can provide better insight.

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Lindy Mayfield
> Sent: Sunday, April 09, 2017 9:42 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: CPU Timerons/Seconds vs Wall-clock Time
> 
> I only have CPU time from SMF 30 but I don't have elapsed time which 
> is very important.  I'd like to somewhat infer that a high CPU time 
> means the job ran a long time.
> 
> /Lindy
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Lizette Koehler
> Sent: sunnuntai 9. huhtikuuta 2017 18.55
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: CPU Timerons/Seconds vs Wall-clock Time
> 
> What are you trying to solve?
> 
> Jobs get swapped in and out depending on what work they are doing.
> 
> 
> Are you trying to relate wall clock to cpu time?  I have seen jobs run 
> 2 hours wall clock time and only take 10 mins of CPU time.
> 
> Lizette
> 
> 
> > -Original Message-
> > From: IBM Mainframe Discussion List 
> > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lindy Mayfield
> > Sent: Sunday, April 09, 2017 8:48 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: CPU Timerons/Seconds vs Wall-clock Time
> >
> > This may or may not be the dumbest question I've asked this week, 
> > but I've been working with Linux a lot lately so that's my excuse.
> >
> > For example, if an MVS job ran and consumed 10 CPU seconds (SMF 30 I 
> > think), can I assume that it at least took 10 seconds of elapsed 
> > time to
> run?
> >
> > Regards,
> > Lindy

--
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: MAS to Standalone Spool

[Mike Shorkend]

The only thing I can think of is, if the old MAS would still exist , and
the system coming out would still have connectivity to the old checkpoints
and spools, you would need to create new ones for the new system


Mike



On 10 April 2017 at 06:28, Jesse 1 Robinson  wrote:

> I'm not sure that anything has to be done at the outset. There is
> essentially no difference between MEMBERA running by itself in a MAS and
> MEMBERA running in its own separate MAS. There either is or is not another
> member to talk to. If MEMBERA is IPLed first in a MAS, for example, it is
> running more or less standalone until another member is IPLed.
>
> The tricky stuff arises if and when you want this reincarnated MEMBERA to
> talk to other JES nodes. In other words, it's not a MAS issue but rather an
> NJE issue. Those are the parameters you need to focus on. Most of them can
> be changed dynamically after MEMBERA is running.
>
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> robin...@sce.com
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Peter
> Sent: Saturday, April 08, 2017 3:24 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):MAS to Standalone Spool
>
> Hi
>
> Can someone guide me on what would be the procedure to move an LPAR from
> MAS( Multi Access Spool) to a standalone Spool. What are the changes
> required from JES2PARM and other library ?
>
> We are moving an LPAR from z hardware to zPDT.
>
> Any advice would be appreciated.
>
> Peter
>
>
> --
> 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: Program software to make SMS calls

[Brian Westerman]

Hi,

Two of our Automation Suite products, SyzCMD/z (command scripting) and SyzMPF/z 
(Console monitor) send both EMAIL and SMS text messages of any content, (one 
example is that we send automatic EMAIL or TEXT messages when a job ends (or 
any event happens) that  contains all of the step condition codes, programs 
used, start/stop times, any dynamically generated text and much more (it's 
currently patent pending but we've been shipping it for quite a while with over 
300 customers), and the products cost roughly 10% of the IBM or CA products.  I 
know that when we send the "EMAIL" messages to Google mail ID's that people can 
have it read to them from Google Mail and several other email clients will read 
the message (just like as if it was sent via voice).  

The big advantage to sending via text (and not voice) is that we can show a lot 
of data (sysout, JCL, etc) and nice graphs and tables, which would be VERY 
difficult to do verbally.

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

Re: Unexplained delays in WLM managed jobclasses

[Vernooij, Kees (ITOPT1) - KLM]

This is mixed environment of JES2 and WLM managed initiators.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Patrick Falcone
> Sent: 08 April, 2017 3:00
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Unexplained delays in WLM managed jobclasses
> 
> I seem to remember a similar type problem from very early days of WLM
> Managed Initiators. Thanks for the heads up Mark.
> Kees, curious if this is a full on WLM Managed environment or a mix of
> JES and WLM managed.
> 
>   From: Mark Zelden 
>  To: IBM-MAIN@LISTSERV.UA.EDU
>  Sent: Friday, April 7, 2017 9:18 AM
>  Subject: Re: Unexplained delays in WLM managed jobclasses
> 
> On Fri, 7 Apr 2017 06:34:54 +, Vernooij, Kees (ITOPT1) - KLM
>  wrote:
> 
> >>
> 
> >> See if you have APAR OA51343 and prereq's
> installed.
> >> http://www-
> 01.ibm.com/support/docview.wss?crawler=1=isg1OA51343
> >>
> 
> >> The APAR talks about a zero or negative count, but we saw a high
> count.
> >> It
> also
> >> applies to z/OS 2.1 but we never say any problem on z/OS
> 2.1.  We
> >> started
> seeing
> >> the problem when z/OS 2.2 was being rolled out to the first wave
> of
> >> LPARs
> in
> >> a large
> sysplex.
> >>
> 
> >>
> 
> >>
> Regards,
> 
> >>
> 
> >>
> Mark
> 
> >> --
> 
> 
> >
> 
> >Great!
> 
> >We are  2.2 and we have the OA50359 fix, but the OA51343 fix was just
> late
> >for our latest update.  I will check the WLM init the next case I see
> the
> >problem.
> 
> >
> 
> >Btw. INIT WLM shows the number of inactive WLM Initiators,while
> $DSRVCLASS
> >shows total inits and active inits, the difference must be be the INIT
> WLM
> >initiators.
> 
> >
> 
> >We will apply this and see if the problem is
> solved.
> >
> 
> >Is there any metric in SMF 99 showing these
> figures?
> >
> 
> >Thanks,
> 
> >Kees.
> 
> 
> The SMF 99 might have the WLM / correct values (I've never looked at
> them
> that close, so I'm not sure if that's in there).  Both WLM and JES2 keep
> track of
> the number of WLM initiators there are by SRVCLASS.  It's the JES2 code
> that
> is doing that incorrectly.
> 
> Regards,
> 
> Mark
> --
> Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
> ITIL v3 Foundation Certified
> mailto:m...@mzelden.com
> Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
> Systems Programming expert at
> http://search390.techtarget.com/ateExperts/
> 
> 
> --
> 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 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: V XCF,xxxx,OFFLINE,REIPL not working

[Jim Mulder]

> It's been long time since I had this problem. I'm fuzzy on the 
> solution, but I think it's either
> 
> a. Status Detect parameter in sysplex couple data set definition, or
> b. LPAR cross partition authority in IMAGE profile
> 

  As stated in a prior response, it is most likely OA50533, 
if there is a BCPii connection between the system in the
basic sysplex.  AutoIPL does initiate the reIPL, but then
while the Load Clear is clearing storage, another system
in the sysplex sends a System Reset via BCPii to allow 
partitioning to proceed, and that ends up stopping the
the reIPL.

  The fix to OA50533 changes AutoIPL to use Load Normal
instead of Load Clear to reIPL, so the reIPL action more
quickly proceeds to a point where the SE is notified that 
a reset from another system is no long valid and should be
rejected.

> For sure CF connection is not necessary. There is a functional 
> difference between 'automatic IPL' after wait state, and REIPL 
> specified on the V XCF,OFF command. Hopefully someone else can clarify. 

  There is no functional difference between 'automatic IPL'
after wait state, and REIPL specified on the V XCF,OFF command.
V XCF,OFF,REIPL  simply causes a particular wait state
and reason code to be loaded, which drives AutoIPL. 

Jim Mulder z/OS Diagnosis, Design, Development, Test  IBM Corp. 
Poughkeepsie NY


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