Re: any interest: FTOSTPR exit (z/OS FTP server exit).

[Paul Gilmartin]

On Sun, 13 Aug 2017 17:27:24 -0500, John McKown wrote:
>
>Looking at
>https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.halz002/ftp_cfg_opt_user_exits.htm
>
>It looks like something could possible be done using the FTOSTPR exit. This
>appears to get control after a number of commands, namely RETR (send file
>to remote), STOR (get file from remote), STOU (store unique), APPE (append
>to existing file on z/OS), DELE (delete z/OS DSN or file), RTNO (Rename
>z/OS file or DSN).
>
>I was thinking that this might be a way to "do something" when one of these
>events occurs. Some of my ideas were along the lines of sending: a email
>that a file has been received; sending a email when a remote user downloads
>a file; run a batch job or UNIX script when a specific DSN/file was
>uploaded.
>
When is the exit entered?  When the command begns?  When it completes?  Both?
For a dropbox-type upload, it should be possible to rename the file into a 
protected
directory as soon as the transfer begins.  This does not terminate the transfer 
--
the descriptor remains valid, identifying a valid inode.  As soon as the rename 
is
complete (a minuscule timing window) neither the sender nor anyone else can
stat(), open(), or unlink() it.

-- gil

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

[Jim Mulder]

  As someone who spends a considerable amount of time reading dumps,
I have some requirements for anyone who uses a product like this on a dump
and then sends the dump to IBM.

1.  You must inform IBM that the dump you are sending has been modified.

2.  You must supply a list of all of the modified or deleted storage 
ranges. 
  This could be a report produced by the product.  Or, 
  the  product could append SC (COMPDATA) records to the dump, 
  which contain descriptions of the storage ranges which have been 
  omitted or modified.  The 8 character component identifier for these 
 
  records would be something which starts with a 3 character prefix 
that 
  IBM has assigned  to the vendor. 

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


> From: Thomas Loges 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 08/13/2017 11:11 PM
> Subject: Re: Scrubbing sensitive data in dumps
> Sent by: IBM Mainframe Discussion List 
> 
> Here is a link to the description of a product for log and dump
> anonymization called SF-SafeDump:
> 
> http://www.fedtke.com/exchange/SF_SafeDump_for_zos.pdf
> 



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

any interest: FTOSTPR exit (z/OS FTP server exit).

[John McKown]

I was just looking at the FTP exits. Mainly because, at work, we use an ISV
ftp server on the Windows side of the house. What is different about this
server is that it can be "scripted" so that when some event occurs (such as
storing or retrieving a specific file) a "script" can be executed.

Looking at
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.halz002/ftp_cfg_opt_user_exits.htm

It looks like something could possible be done using the FTOSTPR exit. This
appears to get control after a number of commands, namely RETR (send file
to remote), STOR (get file from remote), STOU (store unique), APPE (append
to existing file on z/OS), DELE (delete z/OS DSN or file), RTNO (Rename
z/OS file or DSN).

I was thinking that this might be a way to "do something" when one of these
events occurs. Some of my ideas were along the lines of sending: a email
that a file has been received; sending a email when a remote user downloads
a file; run a batch job or UNIX script when a specific DSN/file was
uploaded.

I was just wondering if anyone else thinks that something along these lines
would be useful. I don't know if there are any existing IBM or ISV products
which do this already. I do know that CA-7 can track an "external data set"
creation even to trigger a CA-7 job.

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

[Edward Gould]

> On Aug 13, 2017, at 12:44 PM, scott Ford  wrote:
> 
> This exists in differences between UK English and , what they call you
> speak 'American', which is to say there is a difference.
> 
> Scott
Scott:
About 30 years ago we were looking at up grading to MVS from VS1. The 
additional cost of ISPF and a security system and a few other products broke 
the budget.
We were told we had to do a justification for ISPF and the other add ons.
We spent about three weeks writing the justification up. We all read it and 
OK’d the presentation.
We presented it about 10 AM to the VP.
About a half hour later the VP came by and tossed the justification on the desk 
and said “You used the British spelling, change it to the American”
We were aghast as we didn’t do that. Each of us took a part of it and did a 
really hard spell check on the pages we each had.
We narrowed it down to one word (long since forgotten). We decided to change it 
and drop it back on the VP’s desk.
The budgeting process is difficult to describe here, but I think a short 
description would be, any additional money we had to ask for was taken out of 
the profits of other companies.
The President took our estimate and massaged it into the budget. Since we were 
not privy to what went on at these meetings, the only option was to wait.
Three weeks later the VP called us in and said the budget had been approved and 
we went ahead and ordered MVS.
We got the conversion done, and everyone was happy, for a while. Then as 
predicted, we were paging like crazy during the day (because of TSO). Response 
time was pretty bad. 
The VP wanted to know what we had to do to fix it and we looked at him and 
asked if he had read the final page of the proposal, he said yes. I piped up 
and said that we would very soon need to order more memory.
He was really mad and walked out the door. We were asked what it would cost to 
add more memory, and we looked it up and asked him if this was for all the 
machines and he said yes.
So the President had to go back to the “owners” and ask them for additional 
money for the upgrades. We got the money.
Ed

> 
> On Sun, Aug 13, 2017 at 1:21 PM scott Ford  > wrote:
> 
>> David,
>> 
>> I had to learn French just work and do everyday functions in Switzerland,
>> canton de Vaud.
>> But the company I worked for realized this an proved free French lessons
>> which helped a
>> Great deal.
>> 
>> Scott
>> 


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

Amen to that Ed


On Sun, Aug 13, 2017 at 1:54 PM Edward Gould 
wrote:

> > On Aug 12, 2017, at 5:38 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
>
> Charles,
>
> The Japanese never learned that lesson. To this day I cannot figure out
> how to change one of the clock in the car.
>
> Ed
>
>
> --
> 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

Storage Key question

[Joe Reichman]

Hi,

 

I executed IVSK instruction and got a value in bits 24 - 31 of R1 of X'A0' 

 

Looking at Pops book its say bits 24 - 31 are broken up as the following 24
- 27 is access control bit 28 fetch bit and 29 - 31 all zeros

 

So that means X'A0' is storage key A (typically  ranging from 0 - F)  fetch
bit is 0 

 


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

[Edward Gould]

> On Aug 12, 2017, at 5:38 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

Charles,

The Japanese never learned that lesson. To this day I cannot figure out how to 
change one of the clock in the car.

Ed


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

Re: Google 'doo wop'

[Edward Gould]

> On Aug 12, 2017, at 10:43 PM, Edward Finnell 
> <000248cce9f3-dmarc-requ...@listserv.ua.edu> wrote:
> 
> 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. 
And remember the badge, “Even Linda Lovelace Can’r Swallow VS2”

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

[scott Ford]

This exists in differences between UK English and , what they call you
speak 'American', which is to say there is a difference.

Scott

On Sun, Aug 13, 2017 at 1:21 PM scott Ford  wrote:

> David,
>
> I had to learn French just work and do everyday functions in Switzerland,
> canton de Vaud.
> But the company I worked for realized this an proved free French lessons
> which helped a
> Great deal.
>
> Scott
>
>
> On Sun, Aug 13, 2017 at 11:00 AM David Boyes 
> 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."
>>
>> Which only shows how prevalent really rotten translations done by people
>> who don’t understand the material are. Il traduttore è un traditore, as the
>> Italians would say.
>>
>> The translation people that Fuji Xerox had were really good (the German
>> version of the Alto and D-machine docs were both readable and
>> understandable), but I think Epson takes the prize for the manual for the
>> MX80 printer.  I teach technical writing occasionally, and that 25+ year
>> old manual is still the one I use examples from (IBM ID materials are 2nd
>> in line – thanks, IBM).
>>
>> Translation lives and dies by how well you understand what the author was
>> originally intending to say, which is why machine translation – and
>> translation done by the lowest bidder -- is still so poor. You get what you
>> pay for.
>>
>>
>>
>> --
>> 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
>
-- 
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

[scott Ford]

David,

I had to learn French just work and do everyday functions in Switzerland,
canton de Vaud.
But the company I worked for realized this an proved free French lessons
which helped a
Great deal.

Scott


On Sun, Aug 13, 2017 at 11:00 AM David Boyes  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."
>
> Which only shows how prevalent really rotten translations done by people
> who don’t understand the material are. Il traduttore è un traditore, as the
> Italians would say.
>
> The translation people that Fuji Xerox had were really good (the German
> version of the Alto and D-machine docs were both readable and
> understandable), but I think Epson takes the prize for the manual for the
> MX80 printer.  I teach technical writing occasionally, and that 25+ year
> old manual is still the one I use examples from (IBM ID materials are 2nd
> in line – thanks, IBM).
>
> Translation lives and dies by how well you understand what the author was
> originally intending to say, which is why machine translation – and
> translation done by the lowest bidder -- is still so poor. You get what you
> pay for.
>
>
>
> --
> 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

[David Boyes]

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

Which only shows how prevalent really rotten translations done by people who 
don’t understand the material are. Il traduttore è un traditore, as the 
Italians would say.

The translation people that Fuji Xerox had were really good (the German version 
of the Alto and D-machine docs were both readable and understandable), but I 
think Epson takes the prize for the manual for the MX80 printer.  I teach 
technical writing occasionally, and that 25+ year old manual is still the one I 
use examples from (IBM ID materials are 2nd in line – thanks, IBM).

Translation lives and dies by how well you understand what the author was 
originally intending to say, which is why machine translation – and translation 
done by the lowest bidder -- is still so poor. You get what you pay for.



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

[David Boyes]

> 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.  [...snip…]
> 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).

It has a lot to do with the history of the people involved – the people most 
sensitive to this issue tend to have long histories of not being permitted to 
use their indigenous languages, and quietly resent being told that the fiat 
language is the only one that matters even if they are perfectly capable of 
doing their jobs in the fiat language. It’s a matter of pride – it doesn’t have 
a rational basis, but bien, tu l'as maintenant. :) I dealt with a customer that 
was maintaining a Aranese (a dialect used in Catalonia) copy of the IBM message 
repository for just this reason, and there are still lots of sites in France 
and Quebec that insist on messages and docs in French. 

It also has a lot to do with the cost of translating the messages – nobody 
wants to pay extra for it.  I find it interesting that (at least for VM) the 
last non-English options offered were German, Japanese and uppercase English 
(commonly used to deal with Hebrew and Russian conventions for text mapping and 
display) which map to the largest concentrations of non-US mainframe users. IBM 
and DEC (and to some extent, HP by way of inheriting the DEC user base as well 
as their own user base) did a better than average job here, but it still needs 
work. (If you want to find out how much impact this can be, enable Mandarin 
support in your copy of Windows and watch the bloat -- oink). 
I think there’s also a question of having predictable patterns for automation 
packages – many explicitly set AMENG as the language so you don’t have to 
replicate a bunch of code for matching patterns.  

It’s probably less relevant now than it was when there were lots of interactive 
users, but I have heard non-US users comment on it as a barrier that needed to 
be overcome. 


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

[Timothy Sipples]

Tony Thigpen wrote:
>In other words, the GDPR can claim to reach into other countries, but
>legally, it can not.

*Legally*, of course they can. GDPR is a set of European Union regulations.
They say what they say.

It's a separate question whether, when, and how the European Union and its
member countries enforce GDPR. For your hypothetical bed and breakfast in
Florida there's probably not much the European Union can immediately do if
there's a GDPR violation. However, the B's proprietors might want to
avoid visiting the EU. :-)

Practically every country demands that other countries (and the entities
within them) treat its citizens according to certain minimum standards.
GDPR will soon become part of the minimum standards that EU countries
demand.


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