Re: changing batch job to use SSL

[Andrew Rowley]

On 16/06/2017 2:31 PM, Timothy Sipples wrote:

If you'd like an introduction to how this all works, this one is fairly
good, although it's slightly dated (written/recorded about 6 years ago):

https://www.ibm.com/support/docview.wss?uid=swg27028558

That still doesn't really help me. I'm trying to understand how AT-TLS 
guards against MITM for client connections.


E.g. lets say I had a Cobol job that sent email. I now want to connect 
to Gmail which uses TLS. Can I plug in AT-TLS without changing the job? 
How is the server certificate validated?


Any answer that requires enumerating all possible Gmail IP addresses or 
all possible Gmail certificates is impractical. The normal answer is 
that the name in the certificate is compared to the name you tried to 
connect to, but it is not clear that AT-TLS has that information at that 
point.


(I'm not actually setting this up, just trying to understand AT-TLS as a 
suggested solution. I chose Gmail as an example because they have caused 
me difficulties in the past by returning different certificates from 
different IP addresses.)



--
Andrew Rowley
Black Hill Software
+61 413 302 386

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

Re: changing batch job to use SSL

[Anthony Thompson]

I will also note that z/OSMF provides a Configuration Assistant that can help 
set up AT/TLS, which might be easier for first-time exploiters of TLS.

Ant.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Timothy Sipples
Sent: Friday, 16 June 2017 2:01 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: changing batch job to use SSL

Andrew,

The mechanics are pretty basic, at least conceptually. AT-TLS (in 
Communications Server for z/OS) supports both TLS/SSL server certificate 
authentication and TLS/SSL client certificate authentication. The Policy Agent 
configuration is what decides which authentication(s) apply.

If you'd like an introduction to how this all works, this one is fairly good, 
although it's slightly dated (written/recorded about 6 years ago):

https://www.ibm.com/support/docview.wss?uid=swg27028558

As a reminder, IPsec is another potential option. It depends on what you're 
trying to accomplish, but both approaches have their roles.


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

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

Re: ISPF variable selection menu

[Donald Likens]

They have been very helpful. It turns out this is dynamic area as documented in 
"Dialog Developer's Guide and Reference".

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

Re: changing batch job to use SSL

[Timothy Sipples]

Andrew,

The mechanics are pretty basic, at least conceptually. AT-TLS (in
Communications Server for z/OS) supports both TLS/SSL server certificate
authentication and TLS/SSL client certificate authentication. The Policy
Agent configuration is what decides which authentication(s) apply.

If you'd like an introduction to how this all works, this one is fairly
good, although it's slightly dated (written/recorded about 6 years ago):

https://www.ibm.com/support/docview.wss?uid=swg27028558

As a reminder, IPsec is another potential option. It depends on what you're
trying to accomplish, but both approaches have their roles.


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: EREP Symptom and/or Software Records

[Jim Mulder]

  Catalog processing is not my area of expertise, but I think that this 
symptom 
record is the result of a catalog service task being ABTERMed with code 
91A,
possibly by a catalog analysis task.  I don't remember offhand if a 91A
is also used to terminate a service task when the suspended requesting 
task 
gets ABTERMed. 
I would suggest looking at the syslog to see if there are any catalog 
messages
at the times of these symrecs which might explain the situation.  Absent 
that,
I would do 
SLIP MOD,ID=X91A,DISABLE 
to get a dump of a 91A abend, and look at that.
You may need to open a PMR to catalog for assistance with dump analysis.
I would at least look at the SYSTRACE in the dump to see who initiated the
91A ABTERM. 


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

IBM Mainframe Discussion List  wrote on 
06/15/2017 05:20:21 PM:

> From: Turner Cheryl L 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 06/15/2017 11:03 PM
> Subject: Re: EREP Symptom and/or Software Records
> Sent by: IBM Mainframe Discussion List 
> 
> I understand why you may have thought that but no I understand it is
> not the slip that spawns the records.  But couldn't it be said that 
> the slip parms are indicating IBM's view of the severity of the 
> event? I am so new to this that heck I may not be even asking the 
> questions right.  For that I'm sorry.
> 
> For example.  Here is one symptom record in particular we are 
> constantly seeing (there are others but let's use this as an example): 
> 
> PIDS/5695DF105 RIDS/IGG0CLA9 RIDS/IGG0CLX0#L PRCS/00F6 PRCS/ 

>  PRCS/ JOBN/DBP1DBM1< 
> the JOBN changes but they all seem to be DB2 related tasks. All 
> the other information is the same.
> 
>  SYSTEM ENVIRONMENT: 
>  CPU MODEL:  2964   DATE:  166  17 
>  CPU SERIAL: 0207C7 TIME:  01:06:27.72 
>  SYSTEM: MBI2   BCP:   MVS 
>  RELEASE LEVEL OF SERVICE ROUTINE:  HBB77A0 
>  SYSTEM DATA AT ARCHITECTURE LEVEL: 10 
>  COMPONENT DATA AT ARCHITECTURE LEVEL:  10 
>  SYSTEM DATA:   || 
>  COMPONENT INFORMATION: 
>  COMPONENT ID: 5695DF105 
>  COMPONENT RELEASE LEVEL:  220 
>  SERVICE RELEASE LEVEL:UA82137 
>  DESCRIPTION OF FUNCTION:  CATPROB DATA 
> 
> PRIMARY SYMPTOM STRING: 
> PIDS/5695DF105 RIDS/IGG0CLA9 RIDS/IGG0CLX0#L PRCS/00F6 
> PRCS/ JOBN/DBP3DBM1 
> 
> SYMPTOMSYMPTOM DATA EXPLANATION 
> ------- 
> PIDS/5695DF105 5695DF105COMPONENT IDENTIFIER 
> RIDS/IGG0CLA9  IGG0CLA9 ROUTINE IDENTIFIER 
> RIDS/IGG0CLX0#LIGG0CLX0#L   ROUTINE IDENTIFIER 
> PRCS/00F6  00F6 RETURN CODE 
> PRCS/   RETURN CODE 
> JOBN/DBP3DBM1  DBP3DBM1 JOB NAME 
> 
> THE SYMPTOM RECORD DOES NOT CONTAIN A SECONDARY SYMPTOM STRING. 
> FREE FORMAT COMPONENT INFORMATION:  
> 
> And then there appears to be a snap dump of storage on each one.
> 
> Nothing on IBMLINK matching anything that I can think to search on 
> from the fields.  In the syslog we see IBM slip trap x91A taken 
> about the time of each record. 
> 2017166 01:06:27.72  0284  IEA989I SLIP TRAP ID=X91A 
> MATCHED.  JOBNAME=CATALOG , ASID=0086.
> 
> And there are sometimes 100s of this particular symptom records on a
> given lpar, per day.
> Slip settings are:
> ID=X91A,NONPER,ENABLED 
> ACTION=NODUMP,SET BY CONS INTERNAL,RBLEVEL=ERROR,COMP=91A
> 
> 91A  
>  
>  Explanation:  A request to abnormally end the catalog address space 
(CAS) 
>  service task was issued either through the MODIFY CATALOG,RESTART 
command, 
>  or through catalog analysis task processing.  
>  
>  System Action:  The system re-drives the catalog request currently in   
 
>  process.  
> 
> We are not issuing a MODIFY CATALOG RESTART command at the time of 
> any of the logrecs being cut.  SO might there something wrong with 
> the catalog process that all these redrives are necessary?  Is it 
> normal behavior?  So many questions and I'm clueless, unfortunately.
> 
> So what I guess I was trying to wrap my head around is:  if there 
> isn't a need to take a dump, etc. (as specified in the SLIP setting)
> then why have logic to cut 100's of symptom records at all for that 
> particular issue?  And if we're cutting 100's of records - is it 
> really a problem? And like Ed said, it's noise, and I don't know 
> enough to know it's a problem or not and sometimes how to go about 
> diagnosing.  So I was hoping to get some help (which I have) in how 
> to handle these and others going forward. 
> 
> Thanks for your and others responses, though. It's much appreciated 
> and I'm taking it all in as much as I can.

> 

Re: RFE? xlc compile option for C integers to be "Intel compat" or Little-Endian

[Paul Gilmartin]

On Thu, 15 Jun 2017 18:18:47 -0300, Clark Morris wrote:

>[Default] On 14 Jun 2017 14:57:21 -0700, (Frank Swarbrick) wrote:
>
>>I won't try to justify EBCDIC, but big-endian rules!  :-)
>>
>Unfortunately, little-endian which comes from the same warped thinking
>that went into the COND JCL statement seems to be ubiquitous.
>Little-endian is illogical and a royal pain in so many ways.  The
>developers of it should be ashamed of themselves.
> 
There's a lot of epistemology here.  People firmly believe the scheme they
learned earliest is Natural Law, whether little-endian vs big-endian or
EBCDIC vs. ASCII.

In both cases there were in the day minor hardware economies to flouting
established convention: programmed arithmetic could be done low-to-high
and existing punched cards could be translated to EBCDIC with fewer gates
than to ASCII.

JCL COND isn't "warped thinking"; merely tunnel vision.  An assembler
programmer thinking of branching around a block of code if the CC mask
matches thought likewise of bypassing a job step if COND matches.

-- gil

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

Re: changing batch job to use SSL

[Andrew Rowley]

On 16/06/2017 5:30 AM, Gibney, Dave wrote:

I think Tony is correct. If the external server's signing CA is defined using 
the appropriate Policy Rules for the z/OS Policy Agent and covering the local 
Cobol client, a secure connection, transparent to the Cobol client should work.

How do you know which signing CA they use? I know I have encountered TLS 
connections to the same DNS name that resolved to multiple IP addresses 
with different certificates. Can AT-TLS cope with this as a client?


How does AT-TLS verify that the certificate presented belongs to the 
site that the Cobol client intended to connect to i.e. not a MITM attack?


AT-TLS looks like a nice solution for a server, but for a client I don't 
understand how it works.


--
Andrew Rowley
Black Hill Software
+61 413 302 386

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

Re: RFE? xlc compile option for C integers to be "Intel compat" or Little-Endian

[John McKown]

On Thu, Jun 15, 2017 at 5:05 PM, Frank Swarbrick <
frank.swarbr...@outlook.com> wrote:

> The following link gives a few reasons why little-endian might be
> preferred:  https://softwareengineering.stackexchange.com/questions/
> 95556/what-is-the-advantage-of-little-endian-format.  As a human I still
> prefer big-endian, regardless of any perceived advantages for little-endian!
>

I must disagree with the "as a human" portion of the above. It is more a
"as a speaker of a Western European language using Arabic numering"
​( in UNICODE these are called "European digits")​
. We got our writing  direction, left to right, from the Romans (I'm not
sure where they got it). But we got our positional numbering system from
the Hindus via the Arabs (thus the "Arabic Numerals"). We write the most
significant digit on the left because they Arabs did it that way. But the
Arab languages are written right to left. So, from their view point, they
are reading the least significant digit first. I.e. Arabic Numerals are
written "little endian" in Arabic. Europeans just wrote it the same
physical
​direction
 because that's how they learned it. Using "little endian" is actually
easier. How we do it now: 100 + 10 = 110. In our minds we must "align" the
trailing digits (or the decimal point). But if it were written 001 + 01,
you could just add the digits in the order in which we write them without
"aligning" them in your mind. In the example, add the first two 0s
together. Then add the second 0 & second 1. Finally "add" the last 1 just
by writing it out. In a totally logical universe, the least significant
digit (or bit if we are speaking binary) should be the first digit (or bit)
encountered as we read. So the number one in an octet
​ (aka byte)​
, in hex, would be written 0x10 or in binary as b'1000'. And just to
round out this totally off topic weirdness, we can all be glad that we
don't write in boustrophedon style
​ (switch directions every line)  ref: http://wordinfo.info/unit/3362/ip:21​


>
>
>
> Frank
>
> [https://cdn.sstatic.net/Sites/softwareengineering/img/
> apple-touch-i...@2.png?v=1ef7363febba] stackexchange.com/questions/95556/what-is-the-advantage-
> of-little-endian-format>
>
> architecture - What is the advantage of little endian ... softwareengineering.stackexchange.com/questions/
> 95556/what-is-the-advantage-of-little-endian-format>
> softwareengineering.stackexchange.com
> There are arguments either way, but one point is that in a little-endian
> system, the address of a given value in memory, taken as a 32, 16, or 8 bit
> width, is the same.
>
>

-- 
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: RFE? xlc compile option for C integers to be "Intel compat" or Little-Endian

[Mike Schwab]

The original reason was math.  Process the first order byte, determine
overflow, store result, increment address, process next bytes.
Instead of determining the end address and decrementing.

On Thu, Jun 15, 2017 at 5:39 PM, Jesse 1 Robinson
 wrote:
> Thanks for being gentle. I had it backwards. I owned a hobby machine based on 
> a Z89 processor where I learned the 'opposite orientation'. I should have 
> headed straight to Wikipedia today before advertising my ignorance. ;-(
>
> .
> .
> 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 Clark Morris
> Sent: Thursday, June 15, 2017 2:48 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: RFE? xlc compile option for C integers to be "Intel 
> compat" or Little-Endian
>
> [Default] On 15 Jun 2017 14:41:50 -0700, in bit.listserv.ibm-main 
> jesse1.robin...@sce.com (Jesse 1 Robinson) wrote:
>
>>I guess I could use a bit of (gentle) education. S/360  was the first 
>>architecture I learned, so little-endian seems pretty natural. My occasional 
>>forays into big-endian mystified me (still) as to why it would be preferable 
>>to interpret an address from right to left, including literal street 
>>addresses. I don't read decimal numbers that way. Why is it any more sensible 
>>for binary (hex)? Or am I misremembering my hazy knowledge of big-endian?
>>
> S360 was big-endian.  z series are predominantly big-endian with 
> little-endian capabilities.  DEC and Intel can be blamed for little-endian.
>
> Clark Morris
>>.
>>.
>>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 Clark Morris
>>Sent: Thursday, June 15, 2017 2:19 PM
>>To: IBM-MAIN@LISTSERV.UA.EDU
>>Subject: (External):Re: RFE? xlc compile option for C integers to be
>>"Intel compat" or Little-Endian
>>
>>[Default] On 14 Jun 2017 14:57:21 -0700, in bit.listserv.ibm-main 
>>frank.swarbr...@outlook.com (Frank Swarbrick) wrote:
>>
>>>I won't try to justify EBCDIC, but big-endian rules!  :-)
>>>
>>Unfortunately, little-endian which comes from the same warped thinking that 
>>went into the COND JCL statement seems to be ubiquitous.
>>Little-endian is illogical and a royal pain in so many ways.  The developers 
>>of it should be ashamed of themselves.
>>
>>Clark Morris
>>
>>>
>>>From: IBM Mainframe Discussion List  on
>>>behalf of Paul Gilmartin
>>><000433f07816-dmarc-requ...@listserv.ua.edu>
>>>Sent: Wednesday, June 14, 2017 3:44 PM
>>>To: IBM-MAIN@LISTSERV.UA.EDU
>>>Subject: Re: RFE? xlc compile option for C integers to be "Intel
>>>compat" or Little-Endian
>>>
>>>On Wed, 14 Jun 2017 20:29:22 +, Frank Swarbrick wrote:
>>>
There are big-endian machines other than z.  Shouldn't you investigate how 
the issue is dealt with outside of z before asking for z exclusive language 
extensions?

>>>Yes.  But big-endian is a vanishing breed.  Motorola 68K is gone;
>>>PowerPC is mostly gone, and its endianness was selectable.  There's
>>>little interest in Sparc.  Others?
>>>
>>>Dismayinglly, big-endian may come to be perceived as the same sort of
>>>lunatic fringe as EBCDIC, and support will evaporate with the scarcity
>>>of testing platforms.  But the EBCDIC nightmare can be avoided:  Linux
>>>runs fine on z hardware.
>>>
>>>-- gil
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



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

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

Re: Syncsort With Splunk

[Jake Anderson]

Hi All

Apart from using ironstream. Is there a way to upload just the SMF, RMF and
any SYSLOG reading to SPLUNK to generate dashboard ?

Any samples or whitepaper where I can get yo understand ?

Regards
Jake

On Jun 10, 2017 8:38 PM, "Lizette Koehler"  wrote:

> Jake,
>
> If you are that interested in this function, I would recommend you contact
> Syncsort Sales and request further information.  That way you can be
> connected directly with the vendor and how their product Ironstream feeds
> Splunk.  (Yes, I saw Chris has responded)
>
> Note: it is not Syncsort the product that feeds Splunk.  It is Ironstream
> product by Syncsort to feed Splunk.  Go to Syncsort.com for more details on
> Ironstream.
>
>
>
> I have found with past companies they did not like me downloading trial
> versions as it could put them on the path of having to purchase the product.
>
> I do not think Syncsort would do that, but it is something to consider.
>
> If this is just a curiosity question, what specifically do you need to
> know that has not already been discussed?
>
>
> Got Splunk? Add Ironstream!
>
> Get security insights & operational intelligence from the mainframe in
> real time
>
>
> With Ironstream, you collect log data from SMF, RMF, Syslog and other z/OS
> sources, and forward that data in real time to the Splunk® Enterprise
> analytics platform. That gives you visibility into your z/OS environment as
> well as your distributed and open-systems environment. Total visibility, in
> other word. This is done without the need for z/OS monitoring systems or
> for specialized, scarce, and costly mainframe expertise.
>
> Comprehensive and powerful business intelligence reporting is at hand as
> users can easily search, analyze, and visualize the mainframe log data
> along with log data from distributed and open-source systems.
>
> Ironstream also integrates with Splunk’s Enterprise Security and IT
> Service Intelligence applications. This goes beyond IT operational
> analytics to give you a firmer grasp of potential security threats in your
> z/OS environment. It ensures that your critical business services are being
> delivered on time.
>
>
> Lizette
>
>
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Jake Anderson
> > Sent: Saturday, June 10, 2017 6:07 AM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Syncsort With Splunk
> >
> > I have used syncsort in Mainframe but don't know how splunk would speak
> to
> > syncsort running in zOS.
> >
> > Is there any architecture diagram or Manual which can help me to
> understand ?
> >
> > On Jun 8, 2017 10:24 PM, "Pew, Curtis G" 
> > wrote:
> >
> > > On Jun 8, 2017, at 11:03 AM, Jake Anderson  > > mailto:justmainfra...@gmail.com>> wrote:
> > >
> > > Is there anybody in the group who have used syncsort with Splunk ?
> > >
> > > We forward our OPERLOG to Splunk, although we don’t use Syncsort’s
> > > forwarder. (I wrote my own; it wasn’t that hard.)
> > >
> > > Our main motivation was to show that the mainframe group are “team
> > > players” since everyone else around here was investing in Splunk, but
> > > it is actually quite useful. We’ve set up a few regular reports of
> > > classes of ABENDs or other errors we like to keep track of, and it
> > > allows us to go back and do searches for messages when an issue arises
> > > that we hadn’t foreseen.
> > >
>
> --
> 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: IBM customer anchor

[scott Ford]

Guys:

My friend another vendor says it was good as a jumping off point , aka
Vector to point to for example our routines.
I can see advantages and advantages to NAME/TOKEN,  we use that now.  What
started this process was we need a way to pass information to an exit like
LOGEVX01 or TSSINSTX and the first item came to mind was NAME/TOKEN, then
my asso ciate mentioned anchor table...we all ready have our xxx product
codes.

Scott

On Thu, Jun 15, 2017 at 10:10 AM, Charles Mills  wrote:

> > occasionally we would have people step on us
>
> We have not run into that problem, fortunately.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Brian Westerman
> Sent: Wednesday, June 14, 2017 5:49 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: IBM customer anchor
>
> We have several products on the market and while we exclusively used to
> use the anchor when we start(ed) our Syzygy subsystem, it's now just one of
> several way we keep track of things.  We still support it being there
> (after all we "own" the registration of the slot), but we mostly use the
> name/token facility now (one for the subsystem and one per product, and
> then each of the products has between 1 and "many" that can be active at a
> time).  Actually our IBM anchor points to a Vtable which includes those
> name/token addresses (we didn't trust the name/token facility at first so
> we keep track of everything we do with them 'just in case") and we have a
> name/token that points back to the anchor (just in case).
>
> There are advantages to the anchor entry, but one problem we kept running
> into was that not everyone registered their use with IBM, and apparently we
> had some people's favorite offset number, so occasionally we would have
> people step on us.  Debugging who that was was not always easy at all.
> Especially when it was something that one of the local site sysprogs
> "copied" from one of their old job sites.
>
> So, while the anchor is very useful and quite simple to maintain, so are
> name/tokens and we don't have to ask anyone to use them.  If you are
> marketing software that can use the anchor, I highly suggest you ask for a
> slot, but you may not end up using it to the extent that you think you will.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 



*IDMWORKS *

Scott Ford

z/OS Dev.




“By elevating a friend or Collegue you elevate yourself, by demeaning a
friend or collegue you demean yourself”



www.idmworks.com

scott.f...@idmworks.com

Blog: www.idmworks.com/blog





*The information contained in this email message and any attachment may be
privileged, confidential, proprietary or otherwise protected from
disclosure. If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination, distribution, copying or
use of this message and any attachment is strictly prohibited. If you have
received this message in error, please notify us immediately by replying to
the message and permanently delete it from your computer and destroy any
printout thereof.*

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

Re: EREP Symptom and/or Software Records

[Lizette Koehler]

Cheryl,

So, IBM supplies many standard Slip Suppressions.  the ACTION would be NODUMP.  
This is due to various events in z/OS that will just issue them, 91A, 133, D37, 
B37, E37 just because dumps are not really needed and "everyone" just knows 
what they are.  I consider these annoyance and just part of the process.

As for Logrec, IBM uses the philosophy, just in case - create a logrec record.  
Sometimes with storage sometimes without storage.

This is incase you need to go back and look for symptoms about an event.  If 
the Logrec data is kept longer than a day then you would be able be able to go 
and see if there are system control block information that could be helpful in 
diagnosing the issue.

What I usually go by are the following guidelines
1) How often is the event occurring


-Original Message-
>From: Turner Cheryl L 
>Sent: Jun 15, 2017 2:20 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: EREP Symptom and/or Software Records
>
>I understand why you may have thought that but no I understand it is not the 
>slip that spawns the records.  But couldn't it be said that the slip parms are 
>indicating IBM's view of the severity of the event? I am so new to this that 
>heck I may not be even asking the questions right.  For that I'm sorry.
>
>For example.  Here is one symptom record in particular we are constantly 
>seeing (there are others but let's use this as an example): 
>
>PIDS/5695DF105 RIDS/IGG0CLA9 RIDS/IGG0CLX0#L PRCS/00F6 PRCS/ 
> PRCS/ JOBN/DBP1DBM1< the JOBN 
> changes but they all seem to be DB2 related tasks. All the other 
> information is the same.
>  
> SYSTEM ENVIRONMENT:  
> CPU MODEL:  2964   DATE:  166  17
> CPU SERIAL: 0207C7 TIME:  01:06:27.72
> SYSTEM: MBI2   BCP:   MVS
> RELEASE LEVEL OF SERVICE ROUTINE:  HBB77A0   
> SYSTEM DATA AT ARCHITECTURE LEVEL: 10
> COMPONENT DATA AT ARCHITECTURE LEVEL:  10
> SYSTEM DATA:   ||
> COMPONENT INFORMATION:   
> COMPONENT ID: 5695DF105  
> COMPONENT RELEASE LEVEL:  220
> SERVICE RELEASE LEVEL:UA82137
> DESCRIPTION OF FUNCTION:  CATPROB DATA  
>
>PRIMARY SYMPTOM STRING:   
>PIDS/5695DF105 RIDS/IGG0CLA9 RIDS/IGG0CLX0#L PRCS/00F6
>PRCS/ JOBN/DBP3DBM1   
>  
>SYMPTOMSYMPTOM DATA EXPLANATION   
>-------   
>PIDS/5695DF105 5695DF105COMPONENT IDENTIFIER  
>RIDS/IGG0CLA9  IGG0CLA9 ROUTINE IDENTIFIER
>RIDS/IGG0CLX0#LIGG0CLX0#L   ROUTINE IDENTIFIER
>PRCS/00F6  00F6 RETURN CODE   
>PRCS/   RETURN CODE   
>JOBN/DBP3DBM1  DBP3DBM1 JOB NAME  
>  
>THE SYMPTOM RECORD DOES NOT CONTAIN A SECONDARY SYMPTOM STRING.   
>FREE FORMAT COMPONENT INFORMATION: 
>
>And then there appears to be a snap dump of storage on each one.
>
>Nothing on IBMLINK matching anything that I can think to search on from the 
>fields.  In the syslog we see IBM slip trap x91A taken about the time of each 
>record.  
>2017166 01:06:27.72  0284  IEA989I SLIP TRAP ID=X91A MATCHED.  
>JOBNAME=CATALOG , ASID=0086.
>
>And there are sometimes 100s of this particular symptom records on a given 
>lpar, per day.
>Slip settings are:
>ID=X91A,NONPER,ENABLED   
>ACTION=NODUMP,SET BY CONS INTERNAL,RBLEVEL=ERROR,COMP=91A
>
>91A  
> 
> Explanation:  A request to abnormally end the catalog address space (CAS)   
> service task was issued either through the MODIFY CATALOG,RESTART command,  
> or through catalog analysis task processing.
> 
> System Action:  The system re-drives the catalog request currently in   
> process.
>
>We are not issuing a MODIFY CATALOG RESTART command at the time of any of the 
>logrecs being cut.  SO might there 

Re: RFE? xlc compile option for C integers to be "Intel compat" or Little-Endian

[Jesse 1 Robinson]

Thanks for being gentle. I had it backwards. I owned a hobby machine based on a 
Z89 processor where I learned the 'opposite orientation'. I should have headed 
straight to Wikipedia today before advertising my ignorance. ;-(

.
.
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 Clark Morris
Sent: Thursday, June 15, 2017 2:48 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: RFE? xlc compile option for C integers to be "Intel 
compat" or Little-Endian

[Default] On 15 Jun 2017 14:41:50 -0700, in bit.listserv.ibm-main 
jesse1.robin...@sce.com (Jesse 1 Robinson) wrote:

>I guess I could use a bit of (gentle) education. S/360  was the first 
>architecture I learned, so little-endian seems pretty natural. My occasional 
>forays into big-endian mystified me (still) as to why it would be preferable 
>to interpret an address from right to left, including literal street 
>addresses. I don't read decimal numbers that way. Why is it any more sensible 
>for binary (hex)? Or am I misremembering my hazy knowledge of big-endian?
>
S360 was big-endian.  z series are predominantly big-endian with little-endian 
capabilities.  DEC and Intel can be blamed for little-endian.

Clark Morris
>.
>.
>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 Clark Morris
>Sent: Thursday, June 15, 2017 2:19 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: (External):Re: RFE? xlc compile option for C integers to be 
>"Intel compat" or Little-Endian
>
>[Default] On 14 Jun 2017 14:57:21 -0700, in bit.listserv.ibm-main 
>frank.swarbr...@outlook.com (Frank Swarbrick) wrote:
>
>>I won't try to justify EBCDIC, but big-endian rules!  :-)
>>
>Unfortunately, little-endian which comes from the same warped thinking that 
>went into the COND JCL statement seems to be ubiquitous.
>Little-endian is illogical and a royal pain in so many ways.  The developers 
>of it should be ashamed of themselves.
>
>Clark Morris
>
>>
>>From: IBM Mainframe Discussion List  on 
>>behalf of Paul Gilmartin 
>><000433f07816-dmarc-requ...@listserv.ua.edu>
>>Sent: Wednesday, June 14, 2017 3:44 PM
>>To: IBM-MAIN@LISTSERV.UA.EDU
>>Subject: Re: RFE? xlc compile option for C integers to be "Intel 
>>compat" or Little-Endian
>>
>>On Wed, 14 Jun 2017 20:29:22 +, Frank Swarbrick wrote:
>>
>>>There are big-endian machines other than z.  Shouldn't you investigate how 
>>>the issue is dealt with outside of z before asking for z exclusive language 
>>>extensions?
>>>
>>Yes.  But big-endian is a vanishing breed.  Motorola 68K is gone; 
>>PowerPC is mostly gone, and its endianness was selectable.  There's 
>>little interest in Sparc.  Others?
>>
>>Dismayinglly, big-endian may come to be perceived as the same sort of 
>>lunatic fringe as EBCDIC, and support will evaporate with the scarcity 
>>of testing platforms.  But the EBCDIC nightmare can be avoided:  Linux 
>>runs fine on z hardware.
>>
>>-- gil


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

Re: RFE? xlc compile option for C integers to be "Intel compat" or Little-Endian

[Frank Swarbrick]

The following link gives a few reasons why little-endian might be preferred:  
https://softwareengineering.stackexchange.com/questions/95556/what-is-the-advantage-of-little-endian-format.
  As a human I still prefer big-endian, regardless of any perceived advantages 
for little-endian!


Frank

[https://cdn.sstatic.net/Sites/softwareengineering/img/apple-touch-i...@2.png?v=1ef7363febba]

architecture - What is the advantage of little endian 
...
softwareengineering.stackexchange.com
There are arguments either way, but one point is that in a little-endian 
system, the address of a given value in memory, taken as a 32, 16, or 8 bit 
width, is the same.





From: IBM Mainframe Discussion List  on behalf of 
Clark Morris 
Sent: Thursday, June 15, 2017 3:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RFE? xlc compile option for C integers to be "Intel compat" or 
Little-Endian

[Default] On 14 Jun 2017 14:57:21 -0700, in bit.listserv.ibm-main
frank.swarbr...@outlook.com (Frank Swarbrick) wrote:

>I won't try to justify EBCDIC, but big-endian rules!  :-)
>
Unfortunately, little-endian which comes from the same warped thinking
that went into the COND JCL statement seems to be ubiquitous.
Little-endian is illogical and a royal pain in so many ways.  The
developers of it should be ashamed of themselves.

Clark Morris

>
>From: IBM Mainframe Discussion List  on behalf of 
>Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
>Sent: Wednesday, June 14, 2017 3:44 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: RFE? xlc compile option for C integers to be "Intel compat" or 
>Little-Endian
>
>On Wed, 14 Jun 2017 20:29:22 +, Frank Swarbrick wrote:
>
>>There are big-endian machines other than z.  Shouldn't you investigate how 
>>the issue is dealt with outside of z before asking for z exclusive language 
>>extensions?
>>
>Yes.  But big-endian is a vanishing breed.  Motorola 68K is gone; PowerPC is
>mostly gone, and its endianness was selectable.  There's little interest in
>Sparc.  Others?
>
>Dismayinglly, big-endian may come to be perceived as the same sort
>of lunatic fringe as EBCDIC, and support will evaporate with the scarcity
>of testing platforms.  But the EBCDIC nightmare can be avoided:  Linux
>runs fine on z hardware.
>
>-- gil
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
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: RFE? xlc compile option for C integers to be "Intel compat" or Little-Endian

[Clark Morris]

[Default] On 15 Jun 2017 14:41:50 -0700, in bit.listserv.ibm-main
jesse1.robin...@sce.com (Jesse 1 Robinson) wrote:

>I guess I could use a bit of (gentle) education. S/360  was the first 
>architecture I learned, so little-endian seems pretty natural. My occasional 
>forays into big-endian mystified me (still) as to why it would be preferable 
>to interpret an address from right to left, including literal street 
>addresses. I don't read decimal numbers that way. Why is it any more sensible 
>for binary (hex)? Or am I misremembering my hazy knowledge of big-endian?
>
S360 was big-endian.  z series are predominantly big-endian with
little-endian capabilities.  DEC and Intel can be blamed for
little-endian.

Clark Morris
>.
>.
>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 Clark Morris
>Sent: Thursday, June 15, 2017 2:19 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: (External):Re: RFE? xlc compile option for C integers to be "Intel 
>compat" or Little-Endian
>
>[Default] On 14 Jun 2017 14:57:21 -0700, in bit.listserv.ibm-main 
>frank.swarbr...@outlook.com (Frank Swarbrick) wrote:
>
>>I won't try to justify EBCDIC, but big-endian rules!  :-)
>>
>Unfortunately, little-endian which comes from the same warped thinking that 
>went into the COND JCL statement seems to be ubiquitous.
>Little-endian is illogical and a royal pain in so many ways.  The developers 
>of it should be ashamed of themselves.
>
>Clark Morris
>
>>
>>From: IBM Mainframe Discussion List  on 
>>behalf of Paul Gilmartin 
>><000433f07816-dmarc-requ...@listserv.ua.edu>
>>Sent: Wednesday, June 14, 2017 3:44 PM
>>To: IBM-MAIN@LISTSERV.UA.EDU
>>Subject: Re: RFE? xlc compile option for C integers to be "Intel 
>>compat" or Little-Endian
>>
>>On Wed, 14 Jun 2017 20:29:22 +, Frank Swarbrick wrote:
>>
>>>There are big-endian machines other than z.  Shouldn't you investigate how 
>>>the issue is dealt with outside of z before asking for z exclusive language 
>>>extensions?
>>>
>>Yes.  But big-endian is a vanishing breed.  Motorola 68K is gone; 
>>PowerPC is mostly gone, and its endianness was selectable.  There's 
>>little interest in Sparc.  Others?
>>
>>Dismayinglly, big-endian may come to be perceived as the same sort of 
>>lunatic fringe as EBCDIC, and support will evaporate with the scarcity 
>>of testing platforms.  But the EBCDIC nightmare can be avoided:  Linux 
>>runs fine on z hardware.
>>
>>-- gil
>
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: RFE? xlc compile option for C integers to be "Intel compat" or Little-Endian

[Jesse 1 Robinson]

I guess I could use a bit of (gentle) education. S/360  was the first 
architecture I learned, so little-endian seems pretty natural. My occasional 
forays into big-endian mystified me (still) as to why it would be preferable to 
interpret an address from right to left, including literal street addresses. I 
don't read decimal numbers that way. Why is it any more sensible for binary 
(hex)? Or am I misremembering my hazy knowledge of big-endian?

.
.
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 Clark Morris
Sent: Thursday, June 15, 2017 2:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: RFE? xlc compile option for C integers to be "Intel 
compat" or Little-Endian

[Default] On 14 Jun 2017 14:57:21 -0700, in bit.listserv.ibm-main 
frank.swarbr...@outlook.com (Frank Swarbrick) wrote:

>I won't try to justify EBCDIC, but big-endian rules!  :-)
>
Unfortunately, little-endian which comes from the same warped thinking that 
went into the COND JCL statement seems to be ubiquitous.
Little-endian is illogical and a royal pain in so many ways.  The developers of 
it should be ashamed of themselves.

Clark Morris

>
>From: IBM Mainframe Discussion List  on 
>behalf of Paul Gilmartin 
><000433f07816-dmarc-requ...@listserv.ua.edu>
>Sent: Wednesday, June 14, 2017 3:44 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: RFE? xlc compile option for C integers to be "Intel 
>compat" or Little-Endian
>
>On Wed, 14 Jun 2017 20:29:22 +, Frank Swarbrick wrote:
>
>>There are big-endian machines other than z.  Shouldn't you investigate how 
>>the issue is dealt with outside of z before asking for z exclusive language 
>>extensions?
>>
>Yes.  But big-endian is a vanishing breed.  Motorola 68K is gone; 
>PowerPC is mostly gone, and its endianness was selectable.  There's 
>little interest in Sparc.  Others?
>
>Dismayinglly, big-endian may come to be perceived as the same sort of 
>lunatic fringe as EBCDIC, and support will evaporate with the scarcity 
>of testing platforms.  But the EBCDIC nightmare can be avoided:  Linux 
>runs fine on z hardware.
>
>-- gil


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

Re: EREP Symptom and/or Software Records

[Turner Cheryl L]

I understand why you may have thought that but no I understand it is not the 
slip that spawns the records.  But couldn't it be said that the slip parms are 
indicating IBM's view of the severity of the event? I am so new to this that 
heck I may not be even asking the questions right.  For that I'm sorry.

For example.  Here is one symptom record in particular we are constantly seeing 
(there are others but let's use this as an example): 

PIDS/5695DF105 RIDS/IGG0CLA9 RIDS/IGG0CLX0#L PRCS/00F6 PRCS/ 
 PRCS/ JOBN/DBP1DBM1< the JOBN 
changes but they all seem to be DB2 related tasks. All the other 
information is the same.
  
 SYSTEM ENVIRONMENT:  
 CPU MODEL:  2964   DATE:  166  17
 CPU SERIAL: 0207C7 TIME:  01:06:27.72
 SYSTEM: MBI2   BCP:   MVS
 RELEASE LEVEL OF SERVICE ROUTINE:  HBB77A0   
 SYSTEM DATA AT ARCHITECTURE LEVEL: 10
 COMPONENT DATA AT ARCHITECTURE LEVEL:  10
 SYSTEM DATA:   ||
 COMPONENT INFORMATION:   
 COMPONENT ID: 5695DF105  
 COMPONENT RELEASE LEVEL:  220
 SERVICE RELEASE LEVEL:UA82137
 DESCRIPTION OF FUNCTION:  CATPROB DATA  

PRIMARY SYMPTOM STRING:   
PIDS/5695DF105 RIDS/IGG0CLA9 RIDS/IGG0CLX0#L PRCS/00F6
PRCS/ JOBN/DBP3DBM1   
  
SYMPTOMSYMPTOM DATA EXPLANATION   
-------   
PIDS/5695DF105 5695DF105COMPONENT IDENTIFIER  
RIDS/IGG0CLA9  IGG0CLA9 ROUTINE IDENTIFIER
RIDS/IGG0CLX0#LIGG0CLX0#L   ROUTINE IDENTIFIER
PRCS/00F6  00F6 RETURN CODE   
PRCS/   RETURN CODE   
JOBN/DBP3DBM1  DBP3DBM1 JOB NAME  
  
THE SYMPTOM RECORD DOES NOT CONTAIN A SECONDARY SYMPTOM STRING.   
FREE FORMAT COMPONENT INFORMATION: 

And then there appears to be a snap dump of storage on each one.

Nothing on IBMLINK matching anything that I can think to search on from the 
fields.  In the syslog we see IBM slip trap x91A taken about the time of each 
record.  
2017166 01:06:27.72  0284  IEA989I SLIP TRAP ID=X91A MATCHED.  
JOBNAME=CATALOG , ASID=0086.

And there are sometimes 100s of this particular symptom records on a given 
lpar, per day.
Slip settings are:
ID=X91A,NONPER,ENABLED   
ACTION=NODUMP,SET BY CONS INTERNAL,RBLEVEL=ERROR,COMP=91A

91A  
 
 Explanation:  A request to abnormally end the catalog address space (CAS)   
 service task was issued either through the MODIFY CATALOG,RESTART command,  
 or through catalog analysis task processing.
 
 System Action:  The system re-drives the catalog request currently in   
 process.

We are not issuing a MODIFY CATALOG RESTART command at the time of any of the 
logrecs being cut.  SO might there something wrong with the catalog process 
that all these redrives are necessary?  Is it normal behavior?  So many 
questions and I'm clueless, unfortunately.

So what I guess I was trying to wrap my head around is:  if there isn't a need 
to take a dump, etc. (as specified in the SLIP setting) then why have logic to 
cut 100's of symptom records at all for that particular issue?  And if we're 
cutting 100's of records - is it really a problem? And like Ed said, it's 
noise, and I don't know enough to know it's a problem or not and sometimes how 
to go about diagnosing.  So I was hoping to get some help (which I have) in how 
to handle these and others going forward.  

Thanks for your and others responses, though. It's much appreciated and I'm 
taking it all in as much as I can.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf 
Of Peter Hunkeler
Sent: Thursday, June 15, 2017 4:20 PM
To: IBM-MAIN@listserv.ua.edu
Subject: AW: Re: EREP Symptom and/or Software Records

>But I still can't 

Re: RFE? xlc compile option for C integers to be "Intel compat" or Little-Endian

[Clark Morris]

[Default] On 14 Jun 2017 14:57:21 -0700, in bit.listserv.ibm-main
frank.swarbr...@outlook.com (Frank Swarbrick) wrote:

>I won't try to justify EBCDIC, but big-endian rules!  :-)
>
Unfortunately, little-endian which comes from the same warped thinking
that went into the COND JCL statement seems to be ubiquitous.
Little-endian is illogical and a royal pain in so many ways.  The
developers of it should be ashamed of themselves.

Clark Morris

>
>From: IBM Mainframe Discussion List  on behalf of 
>Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
>Sent: Wednesday, June 14, 2017 3:44 PM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: RFE? xlc compile option for C integers to be "Intel compat" or 
>Little-Endian
>
>On Wed, 14 Jun 2017 20:29:22 +, Frank Swarbrick wrote:
>
>>There are big-endian machines other than z.  Shouldn't you investigate how 
>>the issue is dealt with outside of z before asking for z exclusive language 
>>extensions?
>>
>Yes.  But big-endian is a vanishing breed.  Motorola 68K is gone; PowerPC is
>mostly gone, and its endianness was selectable.  There's little interest in
>Sparc.  Others?
>
>Dismayinglly, big-endian may come to be perceived as the same sort
>of lunatic fringe as EBCDIC, and support will evaporate with the scarcity
>of testing platforms.  But the EBCDIC nightmare can be avoided:  Linux
>runs fine on z hardware.
>
>-- gil
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

AW: Re: EREP Symptom and/or Software Records

[Peter Hunkeler]

>But I still can't get my head around, why cut 100's of symptom/software 
>records a day at all for a particular problem, if we're just going to ignore 
>them - abend or not. But I'll try to let that not keep me awake at night.



I may well be wrong with my interpretation of the above statement and a similar 
one in you initial post. Anyway, here I go...


I seem to understand that you got the impression that it is all those SLIPs 
that are responsible for the logrec entries, that is, the logrec records are 
written because of a SLIP. This is not the case. A problem arises in the 
software, and this may lead to an ABEND (SVC 13) being issued either by the 
software explicitly, or by some service routine that was called. Logrec records 
are a consequence of this.


SLIPs are set to perform an action when events, such as ABENDs, and a lot more, 
occur. The logrec records are written independently.


--
Peter Hunkeler



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

Re: EREP Symptom and/or Software Records

[Edward Gould]

> On Jun 14, 2017, at 8:47 AM, Turner Cheryl L  wrote:
> 
> was hoping you'd chime in John (and I appreciate the responses from Skip, 
> Lizette and EdG, as well).  Since I am the person that does the maintenance 
> and OS upgrades now, I was taking it upon myself to be a bit proactive (or 
> creating busy work?) and looking at the EREP reports for potential problems 
> where there may be PTFs available but maybe we just didn't have them on at 
> the time due to our maintenance windows.  We are still in the process of fine 
> tuning which reports to generate and we are unloading the reports to GDGs .
> 
> So I will summarize the advice as this:  Look at them, as you have time.  
> Decide if any of them are a true problem or something worth investigating 
> further, check out IBMLINK and/or look for a way to fix it. Open a PMR to 
> IBM/vendor if really unsure.
> 
> But I still can't get my head around, why cut 100's of symptom/software 
> records a day at all for a particular problem, if we're just going to ignore 
> them - abend or not. But I'll try to let that not keep me awake at night.   
> 
> Thanks everyone.

I don’t know about others but I like a clean ship. Its a few minutes a day 
routine. If you spot anything that looks unusual then its worth a look. Unusual 
is different for each person. If I saw more than 2 that was unusual to me.
The research was done with the daily look at any hyper APARS. The number of 
hypers was small (usually). I hated to call IBM for a problem that was already 
addressed. Generally talking with IBM was not an issue except for thing like 
CBPDO and other system distributions. The CBPDO calls turned to longish calls 
and were on average the least productive. Other places at IBM were superb and 
it was 5 minute at most, unless we forget the PSF people who were thorough and 
understood traces better than I. When it came to level 3 the phone calls were 
longish but except for a couple of instances relatively painless. When I got 
into a disagreement with level 2, I just called the duty manager and explained 
the issue and he seemed to always come out on my side.
This clean ship as I called it, showed in the fact we almost always never had 
an outage due to software. We were on the bleeding edge with DASD and always 
had to keep DFDSS up to date. That was the other reason I kept the system up to 
date.

Ed


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

Re: changing batch job to use SSL

[Gibney, Dave]

I think Tony is correct. If the external server's signing CA is defined using 
the appropriate Policy Rules for the z/OS Policy Agent and covering the local 
Cobol client, a secure connection, transparent to the Cobol client should work. 

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Denis
> Sent: Thursday, June 15, 2017 11:44 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: changing batch job to use SSL
> 
> Tony,
> 
> yes I missed the part of a z/os client, sorry for that.
> But it only makes sense, if both z/os are on different boxes or use external
> tcpip paths, otherwise since between tcpip and the calling application of the
> socket api its unencrypted anyway, it would be a waste of cpu cycles.
> 
> Denis.
> 
> 
> -Original Message-
> From: Tony Harminc 
> To: IBM-MAIN 
> Sent: Thu, Jun 15, 2017 07:12 PM
> Subject: Re: changing batch job to use SSL
> 
> 
> On 15 June 2017 at 12:24, Denis <
> 01664d8ede6c-dmarc- href="mailto:requ...@listserv.ua.edu;>requ...@listserv.ua.edu>
> wrote:
> 
> > This is new for me, can you point me to docs how to set up at-tls on
> > windows for a tcpip c client program connecting to z/os?
> 
> 
> Denis, I don't think Windows is in this picture anywhere; certainly it was not
> mentioned until now. The OP spoke of a COBOL client program on z/OS
> talking to a platform-unspecified external server (presumably not under his
> control). AT-TLS on z/OS can provide the required client side protocol
> support for TLS. The OP said that the server program already supports TLS, so
> it's mostly a matter of getting the certificate stuff and the AT-TLS config 
> right.
> 
> Tony H.
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email to
> mailto:lists...@listserv.ua.edu;>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: changing batch job to use SSL

[Denis]

Tony,

yes I missed the part of a z/os client, sorry for that.
But it only makes sense, if both z/os are on different boxes or use external 
tcpip paths, otherwise since between tcpip and the calling application of the 
socket api its unencrypted anyway, it would be a waste of cpu cycles.

Denis.


-Original Message-
From: Tony Harminc 
To: IBM-MAIN 
Sent: Thu, Jun 15, 2017 07:12 PM
Subject: Re: changing batch job to use SSL


On 15 June 2017 at 12:24, Denis <
01664d8ede6c-dmarc-mailto:requ...@listserv.ua.edu;>requ...@listserv.ua.edu> wrote:

> This is new for me, can you point me to docs how to set up at-tls on
> windows for a tcpip c client program connecting to z/os?


Denis, I don't think Windows is in this picture anywhere; certainly it was
not mentioned until now. The OP spoke of a COBOL client program on z/OS
talking to a platform-unspecified external server (presumably not under his
control). AT-TLS on z/OS can provide the required client side protocol
support for TLS. The OP said that the server program already supports TLS,
so it's mostly a matter of getting the certificate stuff and the AT-TLS
config right.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to mailto:lists...@listserv.ua.edu;>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: changing batch job to use SSL

[Lizette Koehler]

You may wish to join the TCPIP list.  They may also be able to help

TCPIP   To subscribe, send mail to lists...@vm.marist.edu  with the 
command (paste it!) in the e-mail message body: 
  SUBSCRIBE IBMTCP-L

Or this url and go to the bottom of the webpage:  
http://www2.marist.edu/htbin/wlvindex?IBMTCP-L

Lizette

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Denis
> Sent: Thursday, June 15, 2017 9:24 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: changing batch job to use SSL
> 
> Hi Tony,
> 
> This is new for me, can you point me to docs how to set up at-tls on windows
> for a tcpip c client program connecting to z/os?
> 
> Thanks,
> Denis.
> 
> 
> -Original Message-
> From: Tony Harminc 
> To: IBM-MAIN 
> Sent: Thu, Jun 15, 2017 05:05 PM
> Subject: Re: changing batch job to use SSL
> 
> 
> On 15 June 2017 at 08:02, Denis <
> 01664d8ede6c-dmarc- href="mailto:requ...@listserv.ua.edu;>requ...@listserv.ua.edu> wrote:
> 
> > AT-TLS is only for the server side, so you also need something for the
> > client side, e.g. stunnel (I am mentioning it, because I have worked
> > with
> > it) or others.
> 
> 
> This is not right. AT-TLS works fine at the client or server end. You can
> configure it for either or both for any given TCP application. AT-TLS is a
> big thing to understand the details of, and the configuration and debugging
> are particularly and annoyingly difficult, but conceptually it's quite
> simple.
> 
> Tony H.
> 

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

Re: changing batch job to use SSL

[Tony Harminc]

On 15 June 2017 at 12:24, Denis <
01664d8ede6c-dmarc-requ...@listserv.ua.edu> wrote:

> This is new for me, can you point me to docs how to set up at-tls on
> windows for a tcpip c client program connecting to z/os?


Denis, I don't think Windows is in this picture anywhere; certainly it was
not mentioned until now. The OP spoke of a COBOL client program on z/OS
talking to a platform-unspecified external server (presumably not under his
control). AT-TLS on z/OS can provide the required client side protocol
support for TLS. The OP said that the server program already supports TLS,
so it's mostly a matter of getting the certificate stuff and the AT-TLS
config right.

Tony H.

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

Re: Customer is Using CPACF (Crypto) purchased Crypto Express

[Kirk Wolf]

"SSL" (or TLS) is a client-server secure connection protocol, not a
file/disk encryption protocol.

It involves both:
a) key exchange (handshake) which uses asymmetric key operations
 (handshake happens once or periodically for long sessions)

b) symmetric ciphers using a shared session key negotiated by (a)
 (ciphers are used for encrypting each block of data)

Crypto Express is the best for (a), but not for (b).
CPACF is best for (b), but doesn't do (a).

CPACF does either clear-key or wrapped-key symmetric ciphers.

S/MIME, which is similar to SSL would be commonly used for file encryption,
as would CMS or PGP.
For any of these, the actual cipher (AES) would be best done with CPACF on
z.

FWIW, you can use CPACF Ciphers via ICSF calls or direct use of  the CPACF
instructions.



Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Thu, Jun 15, 2017 at 1:14 AM, Arye Shemer  wrote:

> Hello Todd,
> I'll try answer your questions as best I can.
> 1. I am talking about  z/VM z/VSE customer who is using currently CPACF to
> encrypt data going to the disk and (I am not sure)
> some software using CPACF for SSL.
> 2. Customer predict workload increase and expect to get more performance
> using the Crypto Express especially in the growing SSL
> demand
> 3. Customer is currently using CPACF with key length of 128  bits for clear
> key encryption and (by internal demand) expect to move to 256 bits with the
> Crypto Express
> 4. As far as I know there are no immediate requirements for high secured
>  key protection (which provided of course
> by the Crypto Express)
> 5. The Crypto Express is offered to the customer for marketing reasons (Can
> not  elaborate and have to leave it vague)
>
> Thanks for your interests and suggestions,
>
> Arye.
>
> On Wed, Jun 14, 2017 at 3:46 PM, Todd Arnold  wrote:
>
> > As Phil said:
> > > (arguably the firmware is slightly less secure than the
> tamper-resistant
> > HSM, but the memory
> > > used in the firmware to hold that key is protected-it's apparently not
> > even visible in HMC dumps)
> >
> > That is correct.  The memory where the key is held is associated with the
> > CPACF hardware and its operation.  That memory is part of the internal z
> > hardware and is completely separate from any memory that the applications
> > or operating system can see or use.
> >
> > --
> > 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: changing batch job to use SSL

[Denis]

Hi Tony,

This is new for me, can you point me to docs how to set up at-tls on windows 
for a tcpip c client program connecting to z/os?

Thanks,
Denis.


-Original Message-
From: Tony Harminc 
To: IBM-MAIN 
Sent: Thu, Jun 15, 2017 05:05 PM
Subject: Re: changing batch job to use SSL


On 15 June 2017 at 08:02, Denis <
01664d8ede6c-dmarc-mailto:requ...@listserv.ua.edu;>requ...@listserv.ua.edu> wrote:

> AT-TLS is only for the server side, so you also need something for the
> client side, e.g. stunnel (I am mentioning it, because I have worked with
> it) or others.


This is not right. AT-TLS works fine at the client or server end. You can
configure it for either or both for any given TCP application. AT-TLS is a
big thing to understand the details of, and the configuration and debugging
are particularly and annoyingly difficult, but conceptually it's quite
simple.

Tony H.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to mailto:lists...@listserv.ua.edu;>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: changing batch job to use SSL

[Tony Harminc]

On 15 June 2017 at 08:02, Denis <
01664d8ede6c-dmarc-requ...@listserv.ua.edu> wrote:

> AT-TLS is only for the server side, so you also need something for the
> client side, e.g. stunnel (I am mentioning it, because I have worked with
> it) or others.


This is not right. AT-TLS works fine at the client or server end. You can
configure it for either or both for any given TCP application. AT-TLS is a
big thing to understand the details of, and the configuration and debugging
are particularly and annoyingly difficult, but conceptually it's quite
simple.

Tony H.

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

Re: ISPF variable selection menu

[Donald Likens]

I have joined the ISPF list and posted questions... Thanks

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

Re: ISPF variable selection menu

[Donald Likens]

Using the ISPF list was useful in that it gave me the idea to use TBDISPL. I 
also found an item suggesting that IBM document how to use zdata (in 2004). 

TBDISPL might work for me (but I still would rather have a panel like ISPF 3.4 
where I supply the commands and data.

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

Re: Customer is Using CPACF (Crypto) purchased Crypto Express

[Phil Smith]

Arye Shemer wrote:
>I'll try answer your questions as best I can.
>1. I am talking about  z/VM z/VSE customer who is using currently CPACF to
>encrypt data going to the disk and (I am not sure)
>some software using CPACF for SSL.

>2. Customer predict workload increase and expect to get more performance
>using the Crypto Express especially in the growing SSL
>demand

For SSL, yes; for basic encryption, no. It will almost certainly be slower. If 
the blocks are big enough it's possible it might be faster, but I wouldn't bet 
on it (well, I guess it depends how bad their software encryption 
implementation is).

>3. Customer is currently using CPACF with key length of 128  bits for clear
>key encryption and (by internal demand) expect to move to 256 bits with the
>Crypto Express

Again, if this is for basic AES/DES and the existing implementation isn't too 
horrible, don't bet on better performance.

>4. As far as I know there are no immediate requirements for high secured
> key protection (which provided of course
>by the Crypto Express)

>5. The Crypto Express is offered to the customer for marketing reasons (Can
>not  elaborate and have to leave it vague)

Um. OK. Not sure what that means, but I guess that's the point!
--

...phsiii

Phil Smith III
Senior Architect & Product Manager, Mainframe & Enterprise
Distinguished Technologist
HPE Data Security

phs...@hpe.com
T 703-476-4511
M 703-568-6662
Hewlett Packard Enterprise
Herndon, VA


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

Re: IBM customer anchor

[Charles Mills]

> occasionally we would have people step on us

We have not run into that problem, fortunately.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Brian Westerman
Sent: Wednesday, June 14, 2017 5:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IBM customer anchor

We have several products on the market and while we exclusively used to use the 
anchor when we start(ed) our Syzygy subsystem, it's now just one of several way 
we keep track of things.  We still support it being there (after all we "own" 
the registration of the slot), but we mostly use the name/token facility now 
(one for the subsystem and one per product, and then each of the products has 
between 1 and "many" that can be active at a time).  Actually our IBM anchor 
points to a Vtable which includes those name/token addresses (we didn't trust 
the name/token facility at first so we keep track of everything we do with them 
'just in case") and we have a name/token that points back to the anchor (just 
in case).

There are advantages to the anchor entry, but one problem we kept running into 
was that not everyone registered their use with IBM, and apparently we had some 
people's favorite offset number, so occasionally we would have people step on 
us.  Debugging who that was was not always easy at all.  Especially when it was 
something that one of the local site sysprogs "copied" from one of their old 
job sites.

So, while the anchor is very useful and quite simple to maintain, so are 
name/tokens and we don't have to ask anyone to use them.  If you are marketing 
software that can use the anchor, I highly suggest you ask for a slot, but you 
may not end up using it to the extent that you think you will.

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

Re: ES/9000 microcode

[Jim Stefanik]

Will,

If you can find one (they're on eBay, but the cables are rare); a company 
called Inline makes these really sweet converter boxes which accept input from 
nearly anything (IBM terminals, VAX's, MDA, CGA, etc - you name it, it's 
probably able to accept it) and it converts that to standard 5-BNC VGA.

The product page is here.  There's a ton of different models (2000, 2005, etc); 
but the mostly all do the same.

http://www.inlineinc.com/products/intrface/2005hr.htm

-Jim

From: IBM Mainframe Discussion List  on behalf of 
William Donzelli 
Sent: Wednesday, June 14, 2017 23:25
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ES/9000 microcode

No, the console is an IBM PC750 (I think an early Pentium machine), so
just about any VGA or XGA tube will work.

I assume the original console was a PS/2 of some flavor.

--
Will

On Wed, Jun 14, 2017 at 11:01 PM, Edward Finnell
<000248cce9f3-dmarc-requ...@listserv.ua.edu> wrote:
> What was the little box- Info Window 319x? COAX in VGA out. After our CRT's
>  started fading we replaced all the consoles with the boxes and 19" VGA
> monitors.  Huge improvement. There were also the PCI emulator cards
>
>
> In a message dated 6/14/2017 9:29:49 P.M. Central Daylight Time,
> t...@vse2pdf.com writes:
>
> Most of  the old PCs will
> not sync with newer LCD based monitors. (We keep those in  stock too.)
>
>
>
> --
> 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: EREP Symptom and/or Software Records

[Turner Cheryl L]

Thank you Bruce.  A coworker had downloaded the Logrec Viewer many moons ago, 
but I wasn't aware of it or that we had it.  Your post reminded him to tell me 
about it and confirm it still works :)

We are not currently exploiting PFA.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] On Behalf 
Of Bruce Hewson
Sent: Thursday, June 15, 2017 1:20 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: EREP Symptom and/or Software Records

Hello Cheryl,

check out the Logrec Viewer exec - 


https://www.ibm.com/systems/z/os/zos/tools/downloads/logrec-viewer.html


also you can monitor the PFA_LOGREC_ARRIVAl_RATE healthcheck to tell you when 
you get a burst of LOGREC events.

Regards
Bruce

On Tue, 13 Jun 2017 16:24:34 -0500, Turner Cheryl L  
wrote:

>Greetings.
>Our former sysprog, who paid attention to the more finer system details, has 
>left the building for greener pastures.  So now we seem to have to step up our 
>game.  However, I'm not sure what to do or how.
>
>We are running several EREP reports to see what software or symptom records 
>are being cut per LPAR (mostly just HISTORY reports for now).  We are finding 
>that a lot of records are being cut at the time an IBM supplied SLIP trap is 
>taken (for example X13E, X47B, X91A).  Some of these records can exceed 
>hundreds on a given day.
>
>What should we/I be doing? Reporting them to IBM? I just don't understand why 
>IBM would set the SLIP yet cut a symptom or software record too.  We can't be 
>the only shop seeing these. Yet I've tried to research a few on IBMLINK but 
>can't find any hits for known problems.  Or maybe there is a way to turn of 
>the creation of the software/symptom record?  Though I can't wrap my head 
>around that either, thinking why are they then being cut at all if it's not 
>anything to look into?
>
>Any schooling you can give, would be most appreciated! But please, be gentle. 
>I'm out of my element. Many thanks to you all.
>
>--
>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: changing batch job to use SSL

[Denis]

Hi Andrew,
 
AT-TLS is only for the server side, so you also need something for the client 
side, e.g. stunnel (I am mentioning it, because I have worked with it) or 
others.
Assuming you have a TCPIP client and a TCPIP Server and you want to SSL enable 
it, add AT-TLS to the server (which means that the connection between TCPIP 
Server and AT-TLS is unencrypted) and either add a piece of software/hardware 
on the client side to transfrom the SSL encrypted stream into TCPIP and pass it 
to your client or rewrite the client to be native SSL capable.
There are languages (e.g. Java) where a TCPIP client can be turned into a SSL 
enabled client just with some parameters and there are languages, where it will 
be a complete rewrite.
 
 Hope that helps.
Denis.
 
 
-Original Message-
From: Andrew Rowley 
To: IBM-MAIN 
Sent: Thu, Jun 15, 2017 1:52 pm
Subject: Re: changing batch job to use SSL

On 10/06/2017 08:41 PM, Timothy Sipples wrote:
> Have you looked at AT-TLS yet? It's a feature within Communications Server
> for z/OS.
>
I don't quite understand how AT-TLS works as a client. If it inserts 
itself at the TCP level, how does it perform functions like e.g. 
validating the certificate from the server?

--
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: changing batch job to use SSL

[Andrew Rowley]

On 10/06/2017 08:41 PM, Timothy Sipples wrote:

Have you looked at AT-TLS yet? It's a feature within Communications Server
for z/OS.

I don't quite understand how AT-TLS works as a client. If it inserts 
itself at the TCP level, how does it perform functions like e.g. 
validating the certificate from the server?


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

Re: Customer is Using CPACF (Crypto) purchased Crypto Express

[Arye Shemer]

Hello Todd,
I'll try answer your questions as best I can.
1. I am talking about  z/VM z/VSE customer who is using currently CPACF to
encrypt data going to the disk and (I am not sure)
some software using CPACF for SSL.
2. Customer predict workload increase and expect to get more performance
using the Crypto Express especially in the growing SSL
demand
3. Customer is currently using CPACF with key length of 128  bits for clear
key encryption and (by internal demand) expect to move to 256 bits with the
Crypto Express
4. As far as I know there are no immediate requirements for high secured
 key protection (which provided of course
by the Crypto Express)
5. The Crypto Express is offered to the customer for marketing reasons (Can
not  elaborate and have to leave it vague)

Thanks for your interests and suggestions,

Arye.

On Wed, Jun 14, 2017 at 3:46 PM, Todd Arnold  wrote:

> As Phil said:
> > (arguably the firmware is slightly less secure than the tamper-resistant
> HSM, but the memory
> > used in the firmware to hold that key is protected-it's apparently not
> even visible in HMC dumps)
>
> That is correct.  The memory where the key is held is associated with the
> CPACF hardware and its operation.  That memory is part of the internal z
> hardware and is completely separate from any memory that the applications
> or operating system can see or use.
>
> --
> 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