Google 'doo wop'

[Edward Finnell]

As a diversion google is celebrating the birth of 'doo wop' on it's logo.  
Mix and match your own 45's.
Without choosing sides, some of those voices were just amazing many were  
crossovers from gospel. For some reason it seemed coincidental with a large 
CPU  upgrade E Power Biggs 'Air on a G-string'  resonates. 

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

Re: Researching Destination z article on non-US mainframes

[scott Ford]

I worked in Mexico saw CICS maps translated into Spanish.
Lived and worked for a large US/International Co. and at the Data Center in
Switzerland we spoke in Franlish ..Swiss French and English and keyboards
were in several place Swiss French. Data Center had 33 nationalities
working together.
It was quite an adventure ..


Scott

On Sat, Aug 12, 2017 at 9:09 PM Roger Bolan  wrote:

> That's very true and it works in the other direction too.  We worked on a
> product that started out in Japan and the manual for it had  been
> translated into English by someone in Japan.  It was completely unusable .
> We had to start over from scratch and rewrite the manual in English.
>
> On Aug 12, 2017 4:39 PM, "Charles Mills"  wrote:
>
> > I once had a customer say "PLEASE DON'T translate your manuals. We are
> > used to technical materials in English and know what they mean. If you
> > translate it into [French? German? I don't recall] we will have no idea
> > what you are trying to say."
> >
> > Charles
> >
> >
> > -Original Message-
> > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> > Behalf Of Brian Westerman
> > Sent: Saturday, August 12, 2017 5:44 PM
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Subject: Re: Researching Destination z article on non-US mainframes
> >
> > Actually, even with the foreign sites, I believe that most of them elect
> > to not run the translated messages options.  I don't normally go to the
> > sites (actually I never go there), but it seems to me in the meetings
> that
> > (at least the people I deal with) seem to speak English as well (or
> better)
> > than I do.  In fact, they seem to take it as high praise if I should
> > mention it.  The few discussions I have had about the subject are that
> it's
> > no harder to learn English for manual reading than any other language.  I
> > have been told that  having the manuals in digital format makes it VERY
> > easy to cut and paste the text into their translation program of choice.
> > It's only the English idioms and jokes that give them problems, and IBM
> > books are any BUT funny.
> >
> > The decline in alternate language options though (at least for messages)
> > seems to be more because of lack of desire on the part of the sites
> rather
> > than the vendors not creating the option(s).
> >
> > Our automation products used to have the option of (I think) 12 languages
> > for the messages and manuals, but I can't even remember the last time
> > someone asked for a local language message module.  With our last two
> > versions we elected to remove most of the messages (almost) completely.
>  I
> > think we still might have some translated manuals, but that's about it.
> >
> > --
> > 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
>
-- 
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: Researching Destination z article on non-US mainframes

[Roger Bolan]

That's very true and it works in the other direction too.  We worked on a
product that started out in Japan and the manual for it had  been
translated into English by someone in Japan.  It was completely unusable .
We had to start over from scratch and rewrite the manual in English.

On Aug 12, 2017 4:39 PM, "Charles Mills"  wrote:

> I once had a customer say "PLEASE DON'T translate your manuals. We are
> used to technical materials in English and know what they mean. If you
> translate it into [French? German? I don't recall] we will have no idea
> what you are trying to say."
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Brian Westerman
> Sent: Saturday, August 12, 2017 5:44 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Researching Destination z article on non-US mainframes
>
> Actually, even with the foreign sites, I believe that most of them elect
> to not run the translated messages options.  I don't normally go to the
> sites (actually I never go there), but it seems to me in the meetings that
> (at least the people I deal with) seem to speak English as well (or better)
> than I do.  In fact, they seem to take it as high praise if I should
> mention it.  The few discussions I have had about the subject are that it's
> no harder to learn English for manual reading than any other language.  I
> have been told that  having the manuals in digital format makes it VERY
> easy to cut and paste the text into their translation program of choice.
> It's only the English idioms and jokes that give them problems, and IBM
> books are any BUT funny.
>
> The decline in alternate language options though (at least for messages)
> seems to be more because of lack of desire on the part of the sites rather
> than the vendors not creating the option(s).
>
> Our automation products used to have the option of (I think) 12 languages
> for the messages and manuals, but I can't even remember the last time
> someone asked for a local language message module.  With our last two
> versions we elected to remove most of the messages (almost) completely.   I
> think we still might have some translated manuals, but that's about it.
>
> --
> 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: Researching Destination z article on non-US mainframes

[Bernd Oppolzer]

True. We had some manuals translated in German (PL/1, IIRC),
where the translation was so bad that it was almost unusable.
It turned out that the translation had been done by people
who had no understanding of the topic (PL/1, programming language).
This was in the 1980s, BTW. We used english manuals from then on,
exclusively. OTOH, there were some really good translations of the
Principles of Operation; I recall having a German version from the
43xx period. It always depends if the translator knows what he/she
is talking about.

Kind regards

Bernd


Am 13.08.2017 um 00:38 schrieb Charles Mills:

I once had a customer say "PLEASE DON'T translate your manuals. We are used to 
technical materials in English and know what they mean. If you translate it into [French? 
German? I don't recall] we will have no idea what you are trying to say."

Charles




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

Re: list of cobol load modules and their cobol version

[scott Ford]

Does FileManager also provide this information ?



On Thu, Aug 10, 2017 at 3:12 PM Roy Reynolds  wrote:

> Many thanks for your recommendations!  Roy
>
> --
> 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: GDPR for US companies (Was: Scrubbing sensitive data in dumps)

[Charles Mills]

Mmm, a reverse hijack.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Edward Gould
Sent: Saturday, August 12, 2017 6:09 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: GDPR for US companies (Was: Scrubbing sensitive data in dumps)

> On Aug 12, 2017, at 4:05 PM, Charles Mills  wrote:
> 
> @Tony, thanks for starting a new thread. I was about to do so, realizing I 
> had hijacked a perfectly good dump-scrubbing thread.
> 
> There was a lot of "how are they going to enforce it on us?" at the SHARE 
> sessions. My reply was "if you have deep pockets, I'm sure there is a team of 
> lawyers that would be happy to help you be a test case." I'm not a lawyer, 
> but my daughter is (albeit not an international justice lawyer) and might 
> have some experience in this area. I am with her next week and will ask her.
> 
> The borderline examples are myriad. Here was mine. You are a bank. A customer 
> checks off US citizen on the account form and gives a US address. But she 
> also is an EU National and has an EU residence. You would have no way of 
> knowing that.
> 
> And pity the poor Brits! Brexit comes *after* the effective date of GDPR, so 
> they have to make all the preparations for a law that will soon not affect 
> them.
> 
> There was discussion about how you would erase every trace of someone's 
> existence if you have DB2 volume backup tapes buried deep in Iron Mountain. 
> And what if the lawyers were also telling you "you can't erase that -- we 
> have an open discovery action going on that"?
> 
> I thought the most interesting observation came from two different companies 
> that said "we have to implement this -- so we might just as well do it for 
> all of our customers."
> 
> Charles

Charles: 
This per se is not about dump scrubbing, but it does have to do with dumps.
In the 1980’s I had a job interview with an unnamed part of the government.
To say the least they handled a lot of Top Secret data.
I asked how they handled the dumps with IBM. Their answer was they didn’t. I 
asked, How do you send dumps to IBM. Their answer was that you didn’t.
All problem determination was done on the spot. I then asked what about IBM 
source? You can’t debug (very much) by looking at just instructions.
Their answer was (the best I can remember) was something like this, “the 
problem is not fixed”, I asked incredulously and you can work like this?
Their answer was “yes”.
Now, since then I have found out that at other secret installations, they have 
IBM people that have the right clearences that can talk on secure likes to 
other IBMers to resolve these types of issues.
Apparently this installation did not do this.
I turned down the job mainly because of that and I didn’t like living out in 
the desert.
Ed 
> 


--
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: Researching Destination z article on non-US mainframes

[Charles Mills]

I once had a customer say "PLEASE DON'T translate your manuals. We are used to 
technical materials in English and know what they mean. If you translate it 
into [French? German? I don't recall] we will have no idea what you are trying 
to say."

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Brian Westerman
Sent: Saturday, August 12, 2017 5:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Researching Destination z article on non-US mainframes

Actually, even with the foreign sites, I believe that most of them elect to not 
run the translated messages options.  I don't normally go to the sites 
(actually I never go there), but it seems to me in the meetings that (at least 
the people I deal with) seem to speak English as well (or better) than I do.  
In fact, they seem to take it as high praise if I should mention it.  The few 
discussions I have had about the subject are that it's no harder to learn 
English for manual reading than any other language.  I have been told that  
having the manuals in digital format makes it VERY easy to cut and paste the 
text into their translation program of choice.  It's only the English idioms 
and jokes that give them problems, and IBM books are any BUT funny.

The decline in alternate language options though (at least for messages) seems 
to be more because of lack of desire on the part of the sites rather than the 
vendors not creating the option(s).

Our automation products used to have the option of (I think) 12 languages for 
the messages and manuals, but I can't even remember the last time someone asked 
for a local language message module.  With our last two versions we elected to 
remove most of the messages (almost) completely.   I think we still might have 
some translated manuals, but that's about it. 

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

Re: GDPR for US companies (Was: Scrubbing sensitive data in dumps)

[Edward Gould]

> On Aug 12, 2017, at 4:05 PM, Charles Mills  wrote:
> 
> @Tony, thanks for starting a new thread. I was about to do so, realizing I 
> had hijacked a perfectly good dump-scrubbing thread.
> 
> There was a lot of "how are they going to enforce it on us?" at the SHARE 
> sessions. My reply was "if you have deep pockets, I'm sure there is a team of 
> lawyers that would be happy to help you be a test case." I'm not a lawyer, 
> but my daughter is (albeit not an international justice lawyer) and might 
> have some experience in this area. I am with her next week and will ask her.
> 
> The borderline examples are myriad. Here was mine. You are a bank. A customer 
> checks off US citizen on the account form and gives a US address. But she 
> also is an EU National and has an EU residence. You would have no way of 
> knowing that.
> 
> And pity the poor Brits! Brexit comes *after* the effective date of GDPR, so 
> they have to make all the preparations for a law that will soon not affect 
> them.
> 
> There was discussion about how you would erase every trace of someone's 
> existence if you have DB2 volume backup tapes buried deep in Iron Mountain. 
> And what if the lawyers were also telling you "you can't erase that -- we 
> have an open discovery action going on that"?
> 
> I thought the most interesting observation came from two different companies 
> that said "we have to implement this -- so we might just as well do it for 
> all of our customers."
> 
> Charles

Charles: 
This per se is not about dump scrubbing, but it does have to do with dumps.
In the 1980’s I had a job interview with an unnamed part of the government.
To say the least they handled a lot of Top Secret data.
I asked how they handled the dumps with IBM. Their answer was they didn’t. I 
asked, How do you send dumps to IBM. Their answer was that you didn’t.
All problem determination was done on the spot. I then asked what about IBM 
source? You can’t debug (very much) by looking at just instructions.
Their answer was (the best I can remember) was something like this, “the 
problem is not fixed”, I asked incredulously and you can work like this?
Their answer was “yes”.
Now, since then I have found out that at other secret installations, they have 
IBM people that have the right clearences that can talk on secure likes to 
other IBMers to resolve these types of issues.
Apparently this installation did not do this.
I turned down the job mainly because of that and I didn’t like living out in 
the desert.
Ed 
> 


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

Re: Researching Destination z article on non-US mainframes

[Farley, Peter x23353]

PMJFI here, but don't the laws in Canada require at least one alternate 
language message set (French) if you do any business there?

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Brian Westerman
Sent: Saturday, August 12, 2017 5:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Researching Destination z article on non-US mainframes

Actually, even with the foreign sites, I believe that most of them elect to not 
run the translated messages options.  I don't normally go to the sites 
(actually I never go there), but it seems to me in the meetings that (at least 
the people I deal with) seem to speak English as well (or better) than I do.  
In fact, they seem to take it as high praise if I should mention it.  The few 
discussions I have had about the subject are that it's no harder to learn 
English for manual reading than any other language.  I have been told that  
having the manuals in digital format makes it VERY easy to cut and paste the 
text into their translation program of choice.  It's only the English idioms 
and jokes that give them problems, and IBM books are any BUT funny.

The decline in alternate language options though (at least for messages) seems 
to be more because of lack of desire on the part of the sites rather than the 
vendors not creating the option(s).

Our automation products used to have the option of (I think) 12 languages for 
the messages and manuals, but I can't even remember the last time someone asked 
for a local language message module.  With our last two versions we elected to 
remove most of the messages (almost) completely.   I think we still might have 
some translated manuals, but that's about it. 

Brian
--


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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Researching Destination z article on non-US mainframes

[Brian Westerman]

Actually, even with the foreign sites, I believe that most of them elect to not 
run the translated messages options.  I don't normally go to the sites 
(actually I never go there), but it seems to me in the meetings that (at least 
the people I deal with) seem to speak English as well (or better) than I do.  
In fact, they seem to take it as high praise if I should mention it.  The few 
discussions I have had about the subject are that it's no harder to learn 
English for manual reading than any other language.  I have been told that  
having the manuals in digital format makes it VERY easy to cut and paste the 
text into their translation program of choice.  It's only the English idioms 
and jokes that give them problems, and IBM books are any BUT funny.

The decline in alternate language options though (at least for messages) seems 
to be more because of lack of desire on the part of the sites rather than the 
vendors not creating the option(s).

Our automation products used to have the option of (I think) 12 languages for 
the messages and manuals, but I can't even remember the last time someone asked 
for a local language message module.  With our last two versions we elected to 
remove most of the messages (almost) completely.   I think we still might have 
some translated manuals, but that's about it. 

Brian

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

Re: GDPR for US companies (Was: Scrubbing sensitive data in dumps)

[Charles Mills]

@Tony, thanks for starting a new thread. I was about to do so, realizing I had 
hijacked a perfectly good dump-scrubbing thread.

There was a lot of "how are they going to enforce it on us?" at the SHARE 
sessions. My reply was "if you have deep pockets, I'm sure there is a team of 
lawyers that would be happy to help you be a test case." I'm not a lawyer, but 
my daughter is (albeit not an international justice lawyer) and might have some 
experience in this area. I am with her next week and will ask her.

The borderline examples are myriad. Here was mine. You are a bank. A customer 
checks off US citizen on the account form and gives a US address. But she also 
is an EU National and has an EU residence. You would have no way of knowing 
that.

And pity the poor Brits! Brexit comes *after* the effective date of GDPR, so 
they have to make all the preparations for a law that will soon not affect them.

There was discussion about how you would erase every trace of someone's 
existence if you have DB2 volume backup tapes buried deep in Iron Mountain. And 
what if the lawyers were also telling you "you can't erase that -- we have an 
open discovery action going on that"?

I thought the most interesting observation came from two different companies 
that said "we have to implement this -- so we might just as well do it for all 
of our customers."

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tony Thigpen
Sent: Saturday, August 12, 2017 12:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: GDPR for US companies (Was: Scrubbing sensitive data in dumps)

Charles,

Even if the regulation says:

"Non-Eu businesses processing the data of EU citizens will also have to appoint 
a representative in the EU."

What legal recourse does the EU have to go after a US company that does not 
"appoint a representative in the EU"?

I think the trick here is that should a company "appoint a representative in 
the EU" thinking that it's something simple to appease the EU, then they have a 
business presence in the UA. Once they have "a representative in the EU", then 
the EU has a legal entity to go after for non-compliance.

The company I work for has determined that under no circumstance will we 
"appoint a representative in the EU". And, if the EU attempts legal action, our 
defense is that EU do not apply to a US business that only does work in the US. 
Just because a EU citizen chooses to use our services while in the US, that 
does not constitute a EU business presence. (No matter what the GDPR is trying 
to claim.)

Take a simple example. A EU person stays at a Florida based Bed & Breakfast. 
And, the guest supplies his address and phone number. The GDPR 'claims' that 
the GDPR now applies. But, such a claim violates the the sovereignty of the 
USA. And, since the Bed & Breakfast does not have a presence in the EU, that 
sovereignty protects it.

In other words, the GDPR can claim to reach into other countries, but legally, 
it can not. It's just trying to scare people into compliance.

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

GDPR for US companies (Was: Scrubbing sensitive data in dumps)

[Tony Thigpen]

Charles,

Even if the regulation says:

"Non-Eu businesses processing the data of EU citizens will also have to 
appoint a representative in the EU."


What legal recourse does the EU have to go after a US company that does 
not "appoint a representative in the EU"?


I think the trick here is that should a company "appoint a 
representative in the EU" thinking that it's something simple to appease 
the EU, then they have a business presence in the UA. Once they have "a 
representative in the EU", then the EU has a legal entity to go after 
for non-compliance.


The company I work for has determined that under no circumstance will we 
"appoint a representative in the EU". And, if the EU attempts legal 
action, our defense is that EU do not apply to a US business that only 
does work in the US. Just because a EU citizen chooses to use our 
services while in the US, that does not constitute a EU business 
presence. (No matter what the GDPR is trying to claim.)


Take a simple example. A EU person stays at a Florida based Bed & 
Breakfast. And, the guest supplies his address and phone number. The 
GDPR 'claims' that the GDPR now applies. But, such a claim violates the 
the sovereignty of the USA. And, since the Bed & Breakfast does not have 
a presence in the EU, that sovereignty protects it.


In other words, the GDPR can claim to reach into other countries, but 
legally, it can not. It's just trying to scare people into compliance.


Tony Thigpen

Charles Mills wrote on 08/12/2017 10:05 AM:

My understanding is that the XBridge product was successful at this technically. CA has a new 
product in this area that is successful technically. (By "technically" I mean that the 
technology is successful in recognizing credit card numbers, SSNs, and so forth. There is more 
pattern to a credit card number than just "16 numeric digits.")

These products address files and datasets, but the same pattern recognition 
would apply to dumps.

The problem as I see it -- after taking several sessions at SHARE on data privacy -- is that the 
definition of "personal information" is endlessly elastic. Read "What constitutes 
personal data?" on http://www.eugdpr.org/gdpr-faqs.html.

And by the way, if you are in the US and think that the GDPR is a Europe-only thing, read "Who 
does the GDPR affect?" and "What are the penalties for non-compliance?" on the same 
page. Also note the countdown clock on their home page!

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, August 11, 2017 11:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Scrubbing sensitive data in dumps

On Fri, 11 Aug 2017 17:09:10 -0400, Jim Mulder wrote:


  We did have a meeting in z/OS development quite a few years ago to
discuss someone's wish for this type of function for z/OS dumps.  We
concluded that in general, identifying the sensitive data to be
modified would be so problematic that it was not worth pursuing.


This is reminiscent of a question posed (here?) (years?) ago concerning 
detecting credit card numbers in data sets, with the objective of obfuscating 
them.

OK.  Any 16 numeric digits, or packed, or 64-bit binary in range, or ...
Validate check digit?

Same answer.

Or SSNs.

--
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: Scrubbing sensitive data in dumps

[ITschak Mugzach]

few years ago `i wrote a program to mask business data from dumps. it
masked Hebrew text, zone decimal numbers (if the are larger then 3 chars)
and some Luhn baed numbers by replacing them with dots on both sides of a
printed dump. I don't have access to the code now, but it is quit simple
and base on clients secrets (the way they generate key numbers like brunch
number, account, etc.).

Itschak

On Sat, Aug 12, 2017 at 5:05 PM, Charles Mills  wrote:

> My understanding is that the XBridge product was successful at this
> technically. CA has a new product in this area that is successful
> technically. (By "technically" I mean that the technology is successful in
> recognizing credit card numbers, SSNs, and so forth. There is more pattern
> to a credit card number than just "16 numeric digits.")
>
> These products address files and datasets, but the same pattern
> recognition would apply to dumps.
>
> The problem as I see it -- after taking several sessions at SHARE on data
> privacy -- is that the definition of "personal information" is endlessly
> elastic. Read "What constitutes personal data?" on
> http://www.eugdpr.org/gdpr-faqs.html.
>
> And by the way, if you are in the US and think that the GDPR is a
> Europe-only thing, read "Who does the GDPR affect?" and "What are the
> penalties for non-compliance?" on the same page. Also note the countdown
> clock on their home page!
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Friday, August 11, 2017 11:23 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Scrubbing sensitive data in dumps
>
> On Fri, 11 Aug 2017 17:09:10 -0400, Jim Mulder wrote:
> >
> >  We did have a meeting in z/OS development quite a few years ago to
> >discuss someone's wish for this type of function for z/OS dumps.  We
> >concluded that in general, identifying the sensitive data to be
> >modified would be so problematic that it was not worth pursuing.
> >
> This is reminiscent of a question posed (here?) (years?) ago concerning
> detecting credit card numbers in data sets, with the objective of
> obfuscating them.
>
> OK.  Any 16 numeric digits, or packed, or 64-bit binary in range, or ...
> Validate check digit?
>
> Same answer.
>
> Or SSNs.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
ITschak Mugzach
*|** IronSphere Platform* *|** Automatic ISCM**  (Information Security
Contiguous Monitoring) **|  *

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

Re: Scrubbing sensitive data in dumps

[Charles Mills]

My understanding is that the XBridge product was successful at this 
technically. CA has a new product in this area that is successful technically. 
(By "technically" I mean that the technology is successful in recognizing 
credit card numbers, SSNs, and so forth. There is more pattern to a credit card 
number than just "16 numeric digits.")

These products address files and datasets, but the same pattern recognition 
would apply to dumps.

The problem as I see it -- after taking several sessions at SHARE on data 
privacy -- is that the definition of "personal information" is endlessly 
elastic. Read "What constitutes personal data?" on 
http://www.eugdpr.org/gdpr-faqs.html. 

And by the way, if you are in the US and think that the GDPR is a Europe-only 
thing, read "Who does the GDPR affect?" and "What are the penalties for 
non-compliance?" on the same page. Also note the countdown clock on their home 
page!

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, August 11, 2017 11:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Scrubbing sensitive data in dumps

On Fri, 11 Aug 2017 17:09:10 -0400, Jim Mulder wrote:
>
>  We did have a meeting in z/OS development quite a few years ago to  
>discuss someone's wish for this type of function for z/OS dumps.  We 
>concluded that in general, identifying the sensitive data to be 
>modified would be so problematic that it was not worth pursuing.
> 
This is reminiscent of a question posed (here?) (years?) ago concerning 
detecting credit card numbers in data sets, with the objective of obfuscating 
them.

OK.  Any 16 numeric digits, or packed, or 64-bit binary in range, or ...
Validate check digit?

Same answer.

Or SSNs.

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

Re: Failed or Quiesced XCF groups/members

[Bill Neiman]

Leo,

 The sample JCL in SYS1.SAMPLIB(IXCDELUT) should do what you want.

 Bill Neiman
 Parallel Sysplex development

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

Re: MSGIEW2678S Module contains one or more deferred classes

[Giliad Wilf]

On Fri, 11 Aug 2017 15:59:08 -0700, Tom Ross  
wrote:


>
>>Everyone talks about WSOPT vs NOWSOPT compiler option, but I can't find the=
>>m documented in COBOL documentation library.
>>Are WSOPT and NOWSOPT some nicknames of the accurate terms?
>>Where are they documented?
>
>Everyone?  No one should talk about this hidden option.  We added it to V5
>for a specific customer situatation.  We did not want to change V5 behavior
>for everyone.  COBOL V6 is now using the preferred WSOPT behavior.  That
>means that WORKING-STORAGE is acquired from HEAP just like all COBOL versions
>did before COBOL V5.  This in turn means that the STORAGE option can again be
>used to set initial values of WOKRING-STORAGE to x'00' or x'FF' or anything.
>
>We have improved the "How to find WORKING-STORAGE at runtime" instructions
>in the COBOL V6.2 Migration Guide.  This has been a work in progress, starting
>with trying to do things the 'C' way (WSA) and then moving back to having the
>runtime allocate WORKING-STORAGE as in previous COBOL versions.
>
>By the way, COBOL V5 goes out of marketing in Sept, it will no longer be
>available.  Honestly, the only COBOL version I would think anyone would want
>is COBOL V6.2, it has lots of things to make it more natural for COBOL
>application programmers, as well as exploitation of z14 hardware and
>performance improvements!
>
>Cheers,
>TomR  >> COBOL is the Language of the Future! <<
>
 
The one thing that confused me was the word "option" which I've looked for
in vain at COBOL Customization Guides for V5.1, V5.2 and V6.1.
 
I understood "option" to refer to the selection of one of several possible
values a variable can have, at the user discretion, while a "characteristic" 
would refer to a setting the user has no control over.
 
So, WSOPT seems to a characteristic, not an "option".
 
Are you hinting that Ent. COBOL V6 for z/OS will not generate deferred 
data classes?

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