Re: Would encryption have prevented known major breaches?

[Anne & Lynn Wheeler]

we were somewhat involved in (original) cal. data breach notification
act ... having been brought in to help wordsmith the electronic
signature act and several of the players were heavily involved in
privacy ... and had done in depth public surveys and #1 was fraudulent
financial transactions somewhat as the result of various kinds of
breaches (before notification each member of public thot it was isolated
incident affecting only them).  Problem was that little or nothing was
being done about the breaches and it was hoped that publicity from the
notifications might prompt corrective action. The issue is that entities
normally take security measures in self interest/protection. In the case
of breaches, it wasn't the institutions that are risk, but the
public. Since then there has been a dozen or so federal bills proposed
about evenly divided between those similar to the cal. state act and
those that effectively negate need for notification (in some cases,
specifying a combination of information compromised that would
essentially never occur).

We had aksi been brought in as consultants into small client/server
startup that wanted to do payment transactions on their server, they had
also invented this technology called "SSL" they wanted to use, the
result is now frequently called "electronic commerce". Somewhat for
having done "electronic commerce", we get brought in to the X9A10
financial standard working group that had been given the requirement to
preserve the integrity of finanical infrastructure for *ALL* retail
payments. We did detailed end-to-end vulnerability and exploit studies
of various kinds of payments and eventually wrote a standard that
slightly changes the current paradigm ... and eliminates the ability of
crooks to use information from previous transactions, records and/or
account numbers to perform fraudulent transaction. As a result it is no
longer necessary to hide/encrypt such information ... either in transit
and/or at rest (somewhat negating the earlier work with SSL for
electronic commerce).

dual-use metaphor; transaction account number is used for business
processes and must be readily available for scores of business processes
and millions of locations around the planet. at the same time it is used
for authentication and therefor must *NEVER* be
divulged. The conflicting requirements has resulted in us observing that
even if the planet was buried under miles of information hiding
encryption, it still wouldn't stop information leakage

security proportional to risk metaphor; value of transaction information
to merchant is profit from the transaction ... possibly a couple of
dollars (and value to infrastructure operators a few cents) while the
value of the information to the crooks is the account balance and/or
credit limit. As a result, the crooks may be able to outspend attacking
the system by a factor of 100 times what the defenders can afford to
spend.

Part of the issue now is there are lot of stakeholders with vested
interest in the unchanged paradigm.

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

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

Re: Snap data to a PDS Question About LIST parameter IEATDUMP

[Joseph Reichman]

First off I didn't realize I would get an IPCS dump

I seemed to have dumped the PSA in other words the address I dumped was 0

My LIST parm is coded LIST=START


Where START is defined as follows as in this example I would like to dump 16
bytes of data

START  DC X'11F3E788'  
  DCX'91F3E798'
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Binyamin Dissen
Sent: Friday, September 15, 2017 5:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Snap data to a PDS

You should look at IEATDUMP rather than SNAP, especially when storing to a
dataset. Of course, if you want multiple SNAPs to the same open DCB, you
must use SNAP (in your case you want individual members IEATDUMP would be
better).

On Thu, 14 Sep 2017 21:53:47 -0400 Joseph Reichman 
wrote:

:>Don't know if this doable but I would snap dump data to a pds
 
:>Looking at the snap dump DCB macros DSORG=PS,MACRF=W

:>That would lead me to think I would have to use (if this doable) RDJFCB
and :>move the member name in 

:>BSAM has a exlst parameter and I use X'07' to get the JFCB area then do
OPEN :>TPYE=J

--
Binyamin Dissen  http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me, you
should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems, especially
those from irresponsible companies.

--
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: Would encryption have prevented known major breaches?

[Phil Smith]

Jesse Robinson wrote:
>I have to keep harping on this. The looming EU regulation on hacking is a 
>potentially huge legal liability. You cannot defend yourself in court by 
>arguing that you hire the best people. You can defend yourself only by showing 
>that the hacked data was encrypted.

Sure, and that IS worth repeating. GDPR is going to be a bus that hits a few 
folks before the even know it exists, I suspect.

I assume the point of "hire competent people" was "because they'll be smart 
enough not to use admin/admin for the management system logon". While 
"competent" doesn't necessarily imply doing the right thing all the time, using 
admin/admin definitely precludes the use of the term "competent", I submit!

...phsiii

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

Re: Would encryption have prevented known major breaches?

[Tony Harminc]

On 15 September 2017 at 15:37, John McKown  wrote:

> I think that more than encryption would need to be shown. I'm thinking
> that the algorithm must be "robust" (or whatever word the crypto people
> use). If not, then let's just use ROT13.

It's always best to use double ROT13 for defence in depth.

Tony H.

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

Re: Would encryption have prevented known major breaches?

[John McKown]

On Fri, Sep 15, 2017 at 2:36 PM, Bill Wilkie  wrote:

> What if your data was encrypted, you read it into a sort, put the sort
> output to a data set where it was NOT encrypted, and someone copied it? Or,
> they got it from sort work areas that were left on disk and not erased?
> Does that count?
>

​I was told of a company, back in the 3330 days, where the accounting dept
had their own set of 3330 disk packs. All their data & their temporary data
sets were on these packs. When the "secure" accounting cycle was running​,
a person from the department brought those pack down. The operators removed
the normal temporary storage disks, then mounted the accounting data & work
disks. When the cycle ended, the department person took the packs back to
the accounting dept and locked them up in a safe. Now that was fairly
secure. Oh, and the output was actually taken off the printer by the
accounting person. This was in OS/MVT days, and there was no TSO on that
system.



>
>
> Bill
>
>
> 
> From: IBM Mainframe Discussion List  on behalf
> of Jesse 1 Robinson 
> Sent: Friday, September 15, 2017 7:21 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Would encryption have prevented known major breaches?
>
> I have to keep harping on this. The looming EU regulation on hacking is a
> potentially huge legal liability. You cannot defend yourself in court by
> arguing that you hire the best people. You can defend yourself only by
> showing that the hacked data was encrypted.
>
> .
> .
> 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 zMan
> Sent: Friday, September 15, 2017 12:16 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: Would encryption have prevented known major
> breaches?
>
> Hiring competent people. That's so 20th-century. Get with the program, man!
>
> On Fri, Sep 15, 2017 at 8:51 AM, John McKown  >
> wrote:
>
> > On Thu, Sep 14, 2017 at 7:41 PM, Tom Brennan
> > 
> > wrote:
> >
> > > John McKown wrote:
> > >
> > >> IMO, encrypting data is a very good defense. Another good defense
> > >> is hiring competent people rather than inexpensive people and
> > >> giving them
> > the
> > >> time to design, code, and test their solutions. I don't have
> > >> statistics, but many attacks are based on coding errors such as the
> > >> infamous "SQL Injection" attacks. On the almost hilarious attacks
> > >> which succeed
> > because
> > >> "whomever" didn't bother to configure the security on some piece of
> > >> equipment, and left the administrator credentials as "admin/admin".
> > >> Of course, the people & time requirements that I mentioned "cost too
> much"
> > >> and
> > >> "delay time to market". Today's world is based on think up
> > >> something in the morning, design over lunch, create before dinner,
> > >> ship the next morning.
> > >>
> > >
> > > Did you mention admin/admin because of this news report, or just
> > > coincidence?
> > >
> > > https://nam04.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fwww.bbc.com%2Fnews%2Ftechnology-41257576&
> data=02%7C01%7Cbillwilkie%40hotmail.com%7C119fcd6b7a8a4006ca7d08d4fc6f
> 0771%7C84df9e7fe9f640afb435%7C1%7C0%
> 7C636411001169882688=NoMB%2BXNEHgLO6qX0aYduhy5TP4x0ANW4Q
> ugDNJVVHCc%3D=0
> >
> >
> > That was the reason. I just couldn't remember if it was Equifax or
> > something else in the news recently; and I was too lazy to double check.
> >
> > --
> > UNIX was not designed to stop you from doing stupid things, because
> > that would also stop you from doing clever things. -- Doug Gwyn
> >
> > Maranatha! <><
> > John McKown
>
>
> --
> 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
>



-- 
UNIX was not designed to stop you from doing stupid things, because that
would also stop you from doing clever things. -- Doug Gwyn

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: Would encryption have prevented known major breaches?

[John McKown]

On Fri, Sep 15, 2017 at 2:21 PM, Jesse 1 Robinson 
wrote:

> I have to keep harping on this. The looming EU regulation on hacking is a
> potentially huge legal liability. You cannot defend yourself in court by
> arguing that you hire the best people. You can defend yourself only by
> showing that the hacked data was encrypted.
>

​I think that more than encryption would need to be shown​. I'm thinking
that the algorithm must be "robust" (or whatever word the crypto people
use). If not, then let's just use ROT13. Oh, and you'd best be sure that
the passphrase, digital cert, etc is properly secured. It doesn't do any
good to encrypt a file and have the decryption key be easily found.


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

-- 
UNIX was not designed to stop you from doing stupid things, because that
would also stop you from doing clever things. -- Doug Gwyn

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: Can you run multiple jobs with the same job name at the same time on JES2?

[Lizette Koehler]

I think that JES2 z/OS V2.2 is starting to include some basic job scheduling 
functions.

Configuring and activating job groups

There is a new JES2 initialization statement and command, GRPDEF, that controls 
job group processing. Keywords on GRPDEF control the number of data areas 
available for group processing and the number of jobs that can run 
concurrently. Data for job groups is stored in a data area called a ZJC. The 
number of data areas needed to represent a group is dictated by the complexity 
of the group. One data area is needed for the group, one for each job in the 
group, and one for each dependency. The 4 job group described earlier would 
require 1 ZJC for the group, 4 for jobs in the group, and 4 for each of the 
dependencies, for a total of 9 data areas.

The number of ZJCs (ZJCNUM=) is defaulted to 1000, allowing limited usage of 
the function. The value can be configured from 6 (only useful for basic 
testing) to 500,000.

The other configuration keyword on GRPDEF is the number of concurrent jobs that 
can be configured in a single job group. This is the CONCURRENT_MAX= keyword. 
By default, the limit is set to zero, disabling the function. To allow users to 
use concurrent execution, this needs to be configured to a higher value. Valid 
range is 0 to 200.

All the functions of job groups are only available when JES2 is in the z22 
$ACTIVATE mode. The current $ACTIVATE mode can be displayed using the $D 
ACTIVATE command. The command also list any reasons why you cannot activate to 
z22, if you are in z11 mode. There is also a health check that reports if you 
are not in z22 mode and what is needed to activate to z22 mode. In general, all 
members must be running z/OS 2.2 or later. SPOOLDEF CYL_MANAGED=ALLOWED must be 
set, and the checkpoint data sets have to be large enough to hold the larger 
data areas.

Doing a $ACTIVATE to z22 mode also enables a number of other functions in JES2 
2.2, such as increased limits for checkpoint data, dynamic changes to the 
checkpoint size, and a large cache for spool space allocations.

JES2 can be retroactivated to z11 mode by the $ACTIVATE command, but to do 
this, there can be no job groups defined in the system

Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jesse 1 Robinson
> Sent: Friday, September 15, 2017 12:14 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Can you run multiple jobs with the same job name at the same
> time on JES2?
> 
> I do sympathize with shops that cannot afford a highfalutin job scheduling
> package. I've heard of fairly cheap alternatives although I have no
> recommendations. WLM should help with managing batch load.
> 
> The most promising new mechanism is the one (being) built into JES2 itself.
> It's designed to handle the serialization function--even fairly complex
> relationships--not just overall system load. You have to get current to
> implement it, but once there the price is attractive. ;-)
> 
> .
> .
> 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 Tom Marchant
> Sent: Friday, September 15, 2017 11:11 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: Can you run multiple jobs with the same job name at
> the same time on JES2?
> 
> On Fri, 15 Sep 2017 11:26:53 -0500, David G. Yeager wrote:
> 
> >If there is one thing I've learned from following these threads is
> >that every shop is different.   If we ran (could afford) Thru-Put
> >manager , we wouldn't rely on single threading same name jobs, but we
> >do it , not for order , so much as to limit "thruput", because we need
> >a poor man's solution being poor men.
> 
> Have you considered WLM managed Initiators?
> 
> --
> Tom Marchant
> 

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

Re: Would encryption have prevented known major breaches?

[Bill Wilkie]

What if your data was encrypted, you read it into a sort, put the sort output 
to a data set where it was NOT encrypted, and someone copied it? Or, they got 
it from sort work areas that were left on disk and not erased? Does that count?


Bill



From: IBM Mainframe Discussion List  on behalf of 
Jesse 1 Robinson 
Sent: Friday, September 15, 2017 7:21 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Would encryption have prevented known major breaches?

I have to keep harping on this. The looming EU regulation on hacking is a 
potentially huge legal liability. You cannot defend yourself in court by 
arguing that you hire the best people. You can defend yourself only by showing 
that the hacked data was encrypted.

.
.
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 zMan
Sent: Friday, September 15, 2017 12:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Would encryption have prevented known major breaches?

Hiring competent people. That's so 20th-century. Get with the program, man!

On Fri, Sep 15, 2017 at 8:51 AM, John McKown 
wrote:

> On Thu, Sep 14, 2017 at 7:41 PM, Tom Brennan
> 
> wrote:
>
> > John McKown wrote:
> >
> >> IMO, encrypting data is a very good defense. Another good defense
> >> is hiring competent people rather than inexpensive people and
> >> giving them
> the
> >> time to design, code, and test their solutions. I don't have
> >> statistics, but many attacks are based on coding errors such as the
> >> infamous "SQL Injection" attacks. On the almost hilarious attacks
> >> which succeed
> because
> >> "whomever" didn't bother to configure the security on some piece of
> >> equipment, and left the administrator credentials as "admin/admin".
> >> Of course, the people & time requirements that I mentioned "cost too much"
> >> and
> >> "delay time to market". Today's world is based on think up
> >> something in the morning, design over lunch, create before dinner,
> >> ship the next morning.
> >>
> >
> > Did you mention admin/admin because of this news report, or just
> > coincidence?
> >
> > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.bbc.com%2Fnews%2Ftechnology-41257576=02%7C01%7Cbillwilkie%40hotmail.com%7C119fcd6b7a8a4006ca7d08d4fc6f0771%7C84df9e7fe9f640afb435%7C1%7C0%7C636411001169882688=NoMB%2BXNEHgLO6qX0aYduhy5TP4x0ANW4QugDNJVVHCc%3D=0
>
>
> That was the reason. I just couldn't remember if it was Equifax or
> something else in the news recently; and I was too lazy to double check.
>
> --
> UNIX was not designed to stop you from doing stupid things, because
> that would also stop you from doing clever things. -- Doug Gwyn
>
> Maranatha! <><
> John McKown


--
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: zEDC Compression & DFSMSDSS Move

[Pew, Curtis G]

On Sep 15, 2017, at 12:31 PM, Steve Smith  wrote:
> 
> Yes, of course.  And by the way, encryption (with any decent
> algorithm) will render the data "incompressible*".  To coin a word...
> spell-check suggests "incomprehensible" (well, duh.. :-).
> 
> IBM has wisely implemented their new Data Set Encryption to be done
> after Data Set Compression is done.  And warns that for manual
> operations, you'd best not do it the other way around.

It’s not hard to understand why. At the highest level, all compression 
algorithms work by finding patterns in the data and replacing them with 
descriptions of the patterns, while the job of encryption algorithms is to hide 
all the patterns in the data. The output of a good encryption algorithm won’t 
have any patterns except relatively rare random ones.

This is also why compression can be used to help defeat encryption. If an 
attacker knows the original size of the data, he can infer things about it from 
the size of the compressed version, even if it’s been encrypted. This is 
particularly true if the attacker can insert something into the data before 
it’s compressed; this is what’s behind some of the successful attacks on 
SSL/TLS.

-- 
Pew, Curtis G
curtis@austin.utexas.edu
ITS Systems/Core/Administrative Services


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

Re: Would encryption have prevented known major breaches?

[John McKown]

On Fri, Sep 15, 2017 at 2:15 PM, zMan  wrote:

> Hiring competent people. That's so 20th-century. Get with the program, man!
>
>
​Amusingly, from some of what I've read, one of the reasons for the COBOL
language was so that "lower trained" enlisted men (& women) could produce
quality code just using the English language ( versus Fortran et al). We
are _still_ coming up with languages for "the average person"
(inexperienced & inexpensive) to be able to write quality code which​ "just
works". Too bad the hardware people haven't come up with the DWIM opcode
yet.


-- 
UNIX was not designed to stop you from doing stupid things, because that
would also stop you from doing clever things. -- Doug Gwyn

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: Would encryption have prevented known major breaches?

[Jesse 1 Robinson]

I have to keep harping on this. The looming EU regulation on hacking is a 
potentially huge legal liability. You cannot defend yourself in court by 
arguing that you hire the best people. You can defend yourself only by showing 
that the hacked data was encrypted. 

.
.
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 zMan
Sent: Friday, September 15, 2017 12:16 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Would encryption have prevented known major breaches?

Hiring competent people. That's so 20th-century. Get with the program, man!

On Fri, Sep 15, 2017 at 8:51 AM, John McKown 
wrote:

> On Thu, Sep 14, 2017 at 7:41 PM, Tom Brennan 
> 
> wrote:
>
> > John McKown wrote:
> >
> >> ​IMO, encrypting data is a very good defense. Another good defense 
> >> is hiring competent people rather than inexpensive people and 
> >> giving them
> the
> >> time to design, code, and test their solutions. I don't have 
> >> statistics, but many attacks are based on coding errors such as the 
> >> infamous "SQL Injection" attacks. ​On the almost hilarious attacks 
> >> which succeed
> because
> >> "whomever" didn't bother to configure the security on some piece of 
> >> equipment, and left the administrator credentials as "admin/admin". 
> >> Of course, the people & time requirements that I mentioned "cost too much"
> >> and
> >> "delay time to market". Today's world is based on think up 
> >> something in the morning, design over lunch, create before dinner, 
> >> ship the next morning.
> >>
> >
> > Did you mention admin/admin because of this news report, or just 
> > coincidence?
> >
> > http://www.bbc.com/news/technology-41257576
>
>
> ​That was the reason. I just couldn't remember if it was Equifax or 
> something else in the news recently; and I was too lazy to double check.
>
> --
> UNIX was not designed to stop you from doing stupid things, because 
> that would also stop you from doing clever things. -- Doug Gwyn
>
> 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: Would encryption have prevented known major breaches?

[zMan]

Hiring competent people. That's so 20th-century. Get with the program, man!

On Fri, Sep 15, 2017 at 8:51 AM, John McKown 
wrote:

> On Thu, Sep 14, 2017 at 7:41 PM, Tom Brennan 
> wrote:
>
> > John McKown wrote:
> >
> >> ​IMO, encrypting data is a very good defense. Another good defense is
> >> hiring competent people rather than inexpensive people and giving them
> the
> >> time to design, code, and test their solutions. I don't have statistics,
> >> but many attacks are based on coding errors such as the infamous "SQL
> >> Injection" attacks. ​On the almost hilarious attacks which succeed
> because
> >> "whomever" didn't bother to configure the security on some piece of
> >> equipment, and left the administrator credentials as "admin/admin". Of
> >> course, the people & time requirements that I mentioned "cost too much"
> >> and
> >> "delay time to market". Today's world is based on think up something in
> >> the
> >> morning, design over lunch, create before dinner, ship the next morning.
> >>
> >
> > Did you mention admin/admin because of this news report, or just
> > coincidence?
> >
> > http://www.bbc.com/news/technology-41257576
>
>
> ​That was the reason. I just couldn't remember if it was Equifax or
> something else in the news recently; and I was too lazy to double check.
>
> --
> UNIX was not designed to stop you from doing stupid things, because that
> would also stop you from doing clever things. -- Doug Gwyn
>
> Maranatha! <><
> John McKown
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
zMan -- "I've got a mainframe and I'm not afraid to use it"

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

Re: Can you run multiple jobs with the same job name at the same time on JES2?

[Jesse 1 Robinson]

I do sympathize with shops that cannot afford a highfalutin job scheduling 
package. I've heard of fairly cheap alternatives although I have no 
recommendations. WLM should help with managing batch load.

The most promising new mechanism is the one (being) built into JES2 itself. 
It's designed to handle the serialization function--even fairly complex 
relationships--not just overall system load. You have to get current to 
implement it, but once there the price is attractive. ;-)

.
.
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 Tom Marchant
Sent: Friday, September 15, 2017 11:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Can you run multiple jobs with the same job name at the 
same time on JES2?

On Fri, 15 Sep 2017 11:26:53 -0500, David G. Yeager wrote:

>If there is one thing I've learned from following these threads is 
>that every shop is different.   If we ran (could afford) Thru-Put 
>manager , we wouldn't rely on single threading same name jobs, but we 
>do it , not for order , so much as to limit "thruput", because we need 
>a poor man's solution being poor men.

Have you considered WLM managed Initiators?

--
Tom Marchant


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

Re: Can you run multiple jobs with the same job name at the same time on JES2?

[Tom Marchant]

On Fri, 15 Sep 2017 11:26:53 -0500, David G. Yeager wrote:

>If there is one thing I've learned from following these threads is 
>that every shop is different.   If we ran (could afford) Thru-Put 
>manager , we wouldn't rely on single threading same name jobs, 
>but we do it , not for order , so much as to limit "thruput",  
>because we need a poor man's solution being poor men.

Have you considered WLM managed Initiators?

-- 
Tom Marchant

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

Re: zEDC Compression & DFSMSDSS Move

[Steve Smith]

Yes, of course.  And by the way, encryption (with any decent
algorithm) will render the data "incompressible*".  To coin a word...
spell-check suggests "incomprehensible" (well, duh.. :-).

IBM has wisely implemented their new Data Set Encryption to be done
after Data Set Compression is done.  And warns that for manual
operations, you'd best not do it the other way around.

*Friday etymology: "uncompressible" would imply to me "capable of
being uncompressed".  Not a terribly useful concept, but there you
are.

sas

On Fri, Sep 15, 2017 at 12:44 PM, retired mainframer
 wrote:
> Doesn't it depend on the quality of both compression algorithms? In the
> literature I've seen, attempting to compress "dense" data can actually
> produce output larger than the input.
>
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
>> Behalf Of Buckton, T. (Theo)
>> Sent: Friday, September 15, 2017 5:45 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: zEDC Compression & DFSMSDSS Move
>>
>> Hi,
>>
>> Just one question... Will a dataset that was previously created with
> generic or tailored
>> compression, be further compressed if it is copied with DFSMSDSS and with
> zEDC
>> enabled?
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
sas

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

Re: FTP JCL EXAMPLE - FTP PDS

[Jesse 1 Robinson]

It's Friday. Long ago I was a Peace Corps Volunteer in Nigeria. Rode once in a 
taxi whose driver kept a switch (thin tree branch) on the dashboard. Whenever a 
swerving bicycle rider came too close, driver would grab the switch and whip 
the rider. No special automotive accessory required. 

.
.
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 John McKown
Sent: Friday, September 15, 2017 7:17 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: FTP JCL EXAMPLE - FTP PDS

On Fri, Sep 15, 2017 at 9:01 AM, Paul Gilmartin < 
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Fri, 15 Sep 2017 08:28:37 -0500, John McKown wrote
> >>
> >> Why restrict yourself to 72 characters?  For many releases now, JCL 
> >> has imposed no such restriction on SYSIN.
> >>
> >> Old habits, however detrimental, die hard.
> >
> >​Job may be in a "normal" production JCL library. Trying to convince 
> >a production control person that JCL can be in anything other than an 
> >FB/80 library is likely to be a very frustrating experience. 
> >Sometimes we must
> do
> >things old style just to placate other people.  ...
> >
> Sigh.  Will this take longer than it took to remove the whipsockets 
> from the design of motorcar dashboards?
>

​Oh, wow! I want a whipsocket on my dashboard. I could use it to hold a very 
long bull whip to use on people who are irritating me while I drive.
Why did we ever remove such a useful facility?!?​



>
> OK.  An alternative technology, but alas, newer and subject perhaps to 
> greater future shock:
>
> Define the long data set name in a SET statement.
> code "INPUT DD *,SYMBOLS=JCLONLY" to enable substitution of the 
> symbol.
>
> Caution: if the SET precedes an EXEC, astonishing, perhaps undesirable 
> results may occur.
>
> -- gil
>


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

Re: ShopzSeries FTP password in the clear

[Richards, Robert B.]

Gil,

I was aware of Kurt's response. It doesn't solve my problem with FTPS and Shopz 
though. 

It merely provides a different method of obtaining the order...one I am not 
prepared to regularly use at the moment but have in my back pocket if FTPS 
becomes unavailable.

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, September 15, 2017 12:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ShopzSeries FTP password in the clear

On 2017-09-15, at 10:25, Richards, Robert B. wrote:

> You are using HTTPS. I am using FTPS.  :-)
>  
So it appears that's the solution to your problem.  I believe IBM recommends 
that.  (See ply by Kurt Quackenbush on 2017-08-07
https://listserv.ua.edu/cgi-bin/wa?A2=ind1708=ibm-main=R9940
)

-- 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: zEDC Compression & DFSMSDSS Move

[retired mainframer]

Doesn't it depend on the quality of both compression algorithms? In the
literature I've seen, attempting to compress "dense" data can actually
produce output larger than the input.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Buckton, T. (Theo)
> Sent: Friday, September 15, 2017 5:45 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: zEDC Compression & DFSMSDSS Move
> 
> Hi,
> 
> Just one question... Will a dataset that was previously created with
generic or tailored
> compression, be further compressed if it is copied with DFSMSDSS and with
zEDC
> enabled?

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

Re: ShopzSeries FTP password in the clear

[Paul Gilmartin]

On 2017-09-15, at 10:25, Richards, Robert B. wrote:

> You are using HTTPS. I am using FTPS.  :-)
>  
So it appears that's the solution to your problem.  I believe IBM
recommends that.  (See ply by Kurt Quackenbush on 2017-08-07
https://listserv.ua.edu/cgi-bin/wa?A2=ind1708=ibm-main=R9940
)

-- gil

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

Re: Can you run multiple jobs with the same job name at the same time on JES2?

[David G. Yeager]

If there is one thing I've learned from following these threads is that every 
shop is different.   If we ran (could afford) Thru-Put manager , we wouldn't 
rely on single threading same name jobs,  but we do it , not for order , so 
much as to limit "thruput",  because we need a poor man's solution being poor 
men.

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

Re: ShopzSeries FTP password in the clear

[Richards, Robert B.]

You are using HTTPS. I am using FTPS.  :-)

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Tom Conley
Sent: Friday, September 15, 2017 12:23 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ShopzSeries FTP password in the clear

On 9/15/2017 9:41 AM, Richards, Robert B. wrote:
> My cyber security folks are asking me about why I am doing FTPs with the 
> password "in the clear". At first, I did not know what they talking about.
> 
> It appears that within the SERVINFO data "user=" and "pw=" are *in the 
> clear*. Not always, but often enough.
> 
> I sent an email to L2 Shopz over a week ago and have not heard back from them.
> 
> Before I open a PMR, I wondered if the list had some sage advice (like an 
> options statement that I am missing).
> 
> Thanks in advance,
> 
> Bob
> 

Bob,

Here are my client and server datasets.  No user= or pw=.  So whatchoo talkin' 
'bout Willis?




https://eccgw02.rochester.ibm.com/services/projects/ecc/ws/;
keyring="FTPSERVE/SHOPZRING2048"
certificate="SMPE Client Certificate2048"> 

Regards,
Tom Conley

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

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

Re: ShopzSeries FTP password in the clear

[Richards, Robert B.]

Actually both.

I am doing FTPS for all my FTPs.

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Chris Hoelscher
Sent: Friday, September 15, 2017 12:08 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ShopzSeries FTP password in the clear

Did the op mean FTPs as in the product FTPS ? or as in multiple FTP executions? 

Chris Hoelscher
Technology Architect, Database Infrastructure Services Technology Solution 
Services

123 East Main Street
Louisville, KY 40202
Humana.com
(502) 476-2538 or 407-7266

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Allan Staller
Sent: Friday, September 15, 2017 10:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] ShopzSeries FTP password in the clear

They do not know what they are talking about. 
The primary difference between FTP and FTPS is the FTPS encrypts the password.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Richards, Robert B.
Sent: Friday, September 15, 2017 8:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ShopzSeries FTP password in the clear

My cyber security folks are asking me about why I am doing FTPs with the 
password "in the clear". At first, I did not know what they talking about.

It appears that within the SERVINFO data "user=" and "pw=" are *in the clear*. 
Not always, but often enough.

I sent an email to L2 Shopz over a week ago and have not heard back from them.

Before I open a PMR, I wondered if the list had some sage advice (like an 
options statement that I am missing).

Thanks in advance,

Bob


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


::DISCLAIMER::


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



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

--
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: ShopzSeries FTP password in the clear

[Tom Conley]

On 9/15/2017 9:41 AM, Richards, Robert B. wrote:

My cyber security folks are asking me about why I am doing FTPs with the password 
"in the clear". At first, I did not know what they talking about.

It appears that within the SERVINFO data "user=" and "pw=" are *in the clear*. 
Not always, but often enough.

I sent an email to L2 Shopz over a week ago and have not heard back from them.

Before I open a PMR, I wondered if the list had some sage advice (like an 
options statement that I am missing).

Thanks in advance,

Bob



Bob,

Here are my client and server datasets.  No user= or pw=.  So whatchoo 
talkin' 'bout Willis?





https://eccgw02.rochester.ibm.com/services/projects/ecc/ws/;
   keyring="FTPSERVE/SHOPZRING2048"
   certificate="SMPE Client Certificate2048">


Regards,
Tom Conley

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

Re: ShopzSeries FTP password in the clear

[Chris Hoelscher]

Did the op mean FTPs as in the product FTPS ? or as in multiple FTP executions? 

Chris Hoelscher
Technology Architect, Database Infrastructure Services
Technology Solution Services

123 East Main Street
Louisville, KY 40202
Humana.com
(502) 476-2538 or 407-7266

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Allan Staller
Sent: Friday, September 15, 2017 10:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] ShopzSeries FTP password in the clear

They do not know what they are talking about. 
The primary difference between FTP and FTPS is the FTPS encrypts the password.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Richards, Robert B.
Sent: Friday, September 15, 2017 8:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ShopzSeries FTP password in the clear

My cyber security folks are asking me about why I am doing FTPs with the 
password "in the clear". At first, I did not know what they talking about.

It appears that within the SERVINFO data "user=" and "pw=" are *in the clear*. 
Not always, but often enough.

I sent an email to L2 Shopz over a week ago and have not heard back from them.

Before I open a PMR, I wondered if the list had some sage advice (like an 
options statement that I am missing).

Thanks in advance,

Bob


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


::DISCLAIMER::


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



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

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

Re: Snap data to a PDS

[Joseph Reichman]

Thanks binyamin didn't see your response 



> On Sep 15, 2017, at 5:16 AM, Binyamin Dissen  
> wrote:
> 
> You should look at IEATDUMP rather than SNAP, especially when storing to a
> dataset. Of course, if you want multiple SNAPs to the same open DCB, you must
> use SNAP (in your case you want individual members IEATDUMP would be better).
> 
> On Thu, 14 Sep 2017 21:53:47 -0400 Joseph Reichman 
> wrote:
> 
> :>Don't know if this doable but I would snap dump data to a pds
> 
> :>Looking at the snap dump DCB macros DSORG=PS,MACRF=W
> 
> :>That would lead me to think I would have to use (if this doable) RDJFCB and
> :>move the member name in 
> 
> :>BSAM has a exlst parameter and I use X'07' to get the JFCB area then do OPEN
> :>TPYE=J
> 
> --
> Binyamin Dissen 
> http://www.dissensoftware.com
> 
> Director, Dissen Software, Bar & Grill - Israel
> 
> 
> Should you use the mailblocks package and expect a response from me,
> you should preauthorize the dissensoftware.com domain.
> 
> I very rarely bother responding to challenge/response systems,
> especially those from irresponsible companies.
> 
> --
> 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: zEDC Compression & DFSMSDSS Move

[Lizette Koehler]

The dataclass is only updated when the dataset is created. Once that is done, it
is not changed.

However, if you do a MIG/RECALL then the dataset will be created and the
Dataclas changed.

So depending on how you are doing your DFDSS test, it may or may not change the
Dataclas.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Buckton, T. (Theo)
> Sent: Friday, September 15, 2017 6:57 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: zEDC Compression & DFSMSDSS Move
> 
> Hi Robert,
> 
> Thanks I got it. I tested it by creating a data set without ZP in the
> dataclas. I updated the DCACS to point the data set to a DC with ZP
> specified. However, moving the data set around with ADRDSSU does not change
> the compression attribute.
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Robert2 Gensler
> Sent: 15 September 2017 03:42 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: zEDC Compression & DFSMSDSS Move
> 
> Hi Theo,
> 
> I want to make sure I understand your question.  Are you asking that if you
> have a data set compressed with generic or tailored compression and use
> DFSMSdss to DUMP that data set specifying ZCOMPRESS, will that data set be
> sent through zEDC for further compression?  If so, the answer is yes, if you
> specify ZCOMPRESS DFSMSdss will send generic and tailored compressed data set
> through zEDC for further compression.  I cannot speak to whether or not you
> will see added benefit by compressing already compressed data with zEDC.
> 
> Thanks,
> Robert Gensler
> DFSMSdss Architecture and Development
> Tucson, AZ
> 1-720-349-5211
> rgen...@us.ibm.com
> 
> IBM Mainframe Discussion List  wrote on
> 09/15/2017 08:44:46 AM:
> 
> > From: "Buckton, T. (Theo)" 
> > To: IBM-MAIN@LISTSERV.UA.EDU
> > Date: 09/15/2017 08:45 AM
> > Subject: zEDC Compression & DFSMSDSS Move Sent by: IBM Mainframe
> > Discussion List 
> >
> > Hi,
> >
> > Just one question... Will a dataset that was previously created with
> > generic or tailored compression, be further compressed if it is copied
> > with DFSMSDSS and with zEDC enabled?
> >
> > Regards
> > Theo
> > 
> >
> > Nedbank disclaimer and confidentiality notice:

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

Re: Snap data to a PDS

[Joseph Reichman]

So the  DSORG parameter on the TSO allocate is PS ?



> On Sep 14, 2017, at 10:53 PM, Paul Gilmartin 
> <000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> 
>> On Thu, 14 Sep 2017 21:53:47 -0400, Joseph Reichman  wrote:
>> 
>> Don't know if this doable but I would snap dump data to a pds
>> 
>> Looking at the snap dump DCB macros DSORG=PS,MACRF=W
>> 
>> That would lead me to think I would have to use (if this doable) RDJFCB and
>> move the member name in
>> 
>> BSAM has a exlst parameter and I use X'07' to get the JFCB area then do OPEN
>> TPYE=J
>> 
> In Rexx (YMMV) if I allocate a PDS with DSORG=PS, I read the directory blocks.
> If I specify a member, OPEN gives me DCBDSORG=PO, contrary to Using Data
> Sets' assertion that specifying a member is a sequential allocation.
> 
> -- 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: FTP JCL EXAMPLE - FTP PDS

[John McKown]

On Fri, Sep 15, 2017 at 9:01 AM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Fri, 15 Sep 2017 08:28:37 -0500, John McKown wrote
> >>
> >> Why restrict yourself to 72 characters?  For many releases now, JCL
> >> has imposed no such restriction on SYSIN.
> >>
> >> Old habits, however detrimental, die hard.
> >
> >​Job may be in a "normal" production JCL library. Trying to convince a
> >production control person that JCL can be in anything other than an FB/80
> >library is likely to be a very frustrating experience. Sometimes we must
> do
> >things old style just to placate other people.  ...
> >
> Sigh.  Will this take longer than it took to remove the whipsockets from
> the design of motorcar dashboards?
>

​Oh, wow! I want a whipsocket on my dashboard. I could use it to hold a
very long bull whip to use on people who are irritating me while I drive.
Why did we ever remove such a useful facility?!?​



>
> OK.  An alternative technology, but alas, newer and subject perhaps to
> greater future shock:
>
> Define the long data set name in a SET statement.
> code "INPUT DD *,SYMBOLS=JCLONLY" to enable substitution of the
> symbol.
>
> Caution: if the SET precedes an EXEC, astonishing, perhaps undesirable
> results may occur.
>
> -- gil
>


-- 
UNIX was not designed to stop you from doing stupid things, because that
would also stop you from doing clever things. -- Doug Gwyn

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: ShopzSeries FTP password in the clear

[Paul Gilmartin]

On Fri, 15 Sep 2017 14:02:29 +, Allan Staller wrote:

>They do not know what they are talking about. 
>The primary difference between FTP and FTPS is the FTPS encrypts the password.
> 
The problem is that even though it's encrypted over the network, it appears in 
the
clear in the SERVINFO data set.

I don't know that RACF protecting that data set will placate the security folks.

>-Original Message-
>From: Richards, Robert B.
>Sent: Friday, September 15, 2017 8:43 AM
>
>My cyber security folks are asking me about why I am doing FTPs with the 
>password "in the clear". At first, I did not know what they talking about.
>
>It appears that within the SERVINFO data "user=" and "pw=" are *in the clear*. 
>Not always, but often enough.
>
>I sent an email to L2 Shopz over a week ago and have not heard back from them.
>
>Before I open a PMR, I wondered if the list had some sage advice (like an 
>options statement that I am missing).

-- gil

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

Re: FTP JCL EXAMPLE - FTP PDS

[willie bunter]

Thanks John, I will try out your suggestion. 
Thanks to all who responded and help.

  From: John McKown 
 To: IBM-MAIN@LISTSERV.UA.EDU 
 Sent: Friday, September 15, 2017 9:23 AM
 Subject: Re: FTP JCL EXAMPLE - FTP PDS
   
On Fri, Sep 15, 2017 at 7:54 AM, willie bunter <
001409bd2345-dmarc-requ...@listserv.ua.edu> wrote:

> John,
> Quick question.  Could you tell me how I can continue on the next line.
> For example :mvsput 'FTP.V8050.MVS.BUILDJCL'  'DRP.V8050.MVS.BUILDJCL.NEW'
> (REAllocate
>
> If the output disn has more characters I run out of space .  I  tried
> typing + as a continuation (in col 72) and then on the next lineI typed '
> (REAllocate.
> mvsput 'FTP.V8050.MVS.BUILDJCL'  'DRP.V8050.MVS.BUILDJCL.NEW'
>    +(REAllocate
>
>  However the command didn't work because of unbalanced parenthesis.  Do
> you have a solution?
>

​Hum, seems like it should work according to
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.halu001/ftpreq.htm

mvsput 'FTP.V8050.MVS.BUILDJCJ' 'DRP.V8050.MVS.BUILDJCL.NEW' +
  (REALLOCATE

or maybe try

mvsput 'FTP.V8050.MVS.BUILDJCJ' +
      'DRP.V8050.MVS.BUILDJCL.NEW'  (REALLOCATE





> Thanks.      From: John McKown 
>  To: IBM-MAIN@LISTSERV.UA.EDU
>  Sent: Thursday, September 7, 2017 2:04 PM
>  Subject: Re: FTP JCL EXAMPLE - FTP PDS
>
> On Thu, Sep 7, 2017 at 12:40 PM, Cieri, Anthony  wrote:
>
> >
> >        If you are transferring a PDS from one MVS LPAR to another and
> > creating the target PDS, couldn't you use:
> >
> >        mvsput 'FTP.V8050.MVS.BUILDJCL'  'DRP.V8050.MVS.BUILDJCL.NEW'
> > (REAllocate
>
>
> ​Oh, that is good. I'm still stuck on z/OS 1.12, so I'm not up on the
> newest and greatest FTP commands. I need to go read the 2.3 books on that
> to see what other goodies exist.​
>
>
> --
> UNIX was not designed to stop you from doing stupid things, because that
> would also stop you from doing clever things. -- Doug Gwyn
>
> Maranatha! <><
> John McKown
>
> --
> 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
>



-- 
UNIX was not designed to stop you from doing stupid things, because that
would also stop you from doing clever things. -- Doug Gwyn

Maranatha! <><
John McKown

--
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: ShopzSeries FTP password in the clear

[Allan Staller]

They do not know what they are talking about. 
The primary difference between FTP and FTPS is the FTPS encrypts the password.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Richards, Robert B.
Sent: Friday, September 15, 2017 8:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: ShopzSeries FTP password in the clear

My cyber security folks are asking me about why I am doing FTPs with the 
password "in the clear". At first, I did not know what they talking about.

It appears that within the SERVINFO data "user=" and "pw=" are *in the clear*. 
Not always, but often enough.

I sent an email to L2 Shopz over a week ago and have not heard back from them.

Before I open a PMR, I wondered if the list had some sage advice (like an 
options statement that I am missing).

Thanks in advance,

Bob


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


::DISCLAIMER::


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



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

Re: FTP JCL EXAMPLE - FTP PDS

[Paul Gilmartin]

On Fri, 15 Sep 2017 08:28:37 -0500, John McKown wrote
>>
>> Why restrict yourself to 72 characters?  For many releases now, JCL
>> has imposed no such restriction on SYSIN.
>>
>> Old habits, however detrimental, die hard.
>
>​Job may be in a "normal" production JCL library. Trying to convince a
>production control person that JCL can be in anything other than an FB/80
>library is likely to be a very frustrating experience. Sometimes we must do
>things old style just to placate other people.  ...
> 
Sigh.  Will this take longer than it took to remove the whipsockets from
the design of motorcar dashboards?

OK.  An alternative technology, but alas, newer and subject perhaps to
greater future shock:

Define the long data set name in a SET statement.
code "INPUT DD *,SYMBOLS=JCLONLY" to enable substitution of the
symbol.

Caution: if the SET precedes an EXEC, astonishing, perhaps undesirable
results may occur.

-- gil

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

Re: zEDC Compression & DFSMSDSS Move

[Buckton, T. (Theo)]

Hi Robert, 

Thanks I got it. I tested it by creating a data set without ZP in the dataclas. 
I updated the DCACS to point the data set to a DC with ZP specified. However, 
moving the data set around with ADRDSSU does not change the compression 
attribute.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Robert2 Gensler
Sent: 15 September 2017 03:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: zEDC Compression & DFSMSDSS Move

Hi Theo,

I want to make sure I understand your question.  Are you asking that if you 
have a data set compressed with generic or tailored compression and use 
DFSMSdss to DUMP that data set specifying ZCOMPRESS, will that data set be sent 
through zEDC for further compression?  If so, the answer is yes, if you specify 
ZCOMPRESS DFSMSdss will send generic and tailored compressed data set through 
zEDC for further compression.  I cannot speak to whether or not you will see 
added benefit by compressing already compressed data with zEDC.

Thanks,
Robert Gensler
DFSMSdss Architecture and Development
Tucson, AZ
1-720-349-5211
rgen...@us.ibm.com

IBM Mainframe Discussion List  wrote on
09/15/2017 08:44:46 AM:

> From: "Buckton, T. (Theo)" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 09/15/2017 08:45 AM
> Subject: zEDC Compression & DFSMSDSS Move Sent by: IBM Mainframe 
> Discussion List 
>
> Hi,
>
> Just one question... Will a dataset that was previously created with 
> generic or tailored compression, be further compressed if it is copied 
> with DFSMSDSS and with zEDC enabled?
>
> Regards
> Theo
> 
>
> Nedbank disclaimer and confidentiality notice:
>
> This email may contain information that is confidential, privileged or 
> otherwise protected from disclosure. If you are not an intended 
> recipient of this email or all or some of the information contained 
> therein, do not duplicate or redistribute it by any means. Please 
> delete it and any attachments and notify the sender that you have 
> received it in error. Unless specifically indicated, this email is 
> neither an offer or a solicitation to buy or sell any securities, 
> investment products or other financial product or service, nor is it 
> an official confirmation of any transaction or an official statement 
> of Nedbank. Any views or opinions presented are solely those of the 
> author and do not necessarily represent those of Nedbank. Nedbank Ltd 
> Reg No 1951/09/06.
>
> The following link displays the names of the Nedbank Board of 
> Directors and Company Secretary. [https://urldefense.proofpoint.com/
> v2/url?
>
u=http-3A__www.nedbank.co.za_terms_DirectorsNedbank.htm=DwIFAg=jf_iaSHvJObTbx-

>
siA1ZOg=4IouVQcajkz0Xk8aBQYNyp4CJn0tmfX31FiYrnNQujA=c0Lw15IR_PclQhZqHvCnCQJ_vegryoFIEZuex0poeQs=yeLEbaFLEru8PMylmSgQDVdtVVq8JslMBOWrL2bzecE=

> ]
>
> If you do not want to click on a link, please type the relevant 
> address in your browser
>
> 
>
> --
> 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


Nedbank disclaimer and confidentiality notice:

This email may contain information that is confidential, privileged or 
otherwise protected from disclosure. If you are not an intended recipient of 
this email or all or some of the information contained therein, do not 
duplicate or redistribute it by any means. Please delete it and any attachments 
and notify the sender that you have received it in error. Unless specifically 
indicated, this email is neither an offer or a solicitation to buy or sell any 
securities, investment products or other financial product or service, nor is 
it an official confirmation of any transaction or an official statement of 
Nedbank. Any views or opinions presented are solely those of the author and do 
not necessarily represent those of Nedbank. Nedbank Ltd Reg No 1951/09/06.

The following link displays the names of the Nedbank Board of Directors and 
Company Secretary. [http://www.nedbank.co.za/terms/DirectorsNedbank.htm]

If you do not want to click on a link, please type the relevant address in your 
browser



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

ShopzSeries FTP password in the clear

[Richards, Robert B.]

My cyber security folks are asking me about why I am doing FTPs with the 
password "in the clear". At first, I did not know what they talking about.

It appears that within the SERVINFO data "user=" and "pw=" are *in the clear*. 
Not always, but often enough.

I sent an email to L2 Shopz over a week ago and have not heard back from them.

Before I open a PMR, I wondered if the list had some sage advice (like an 
options statement that I am missing).

Thanks in advance,

Bob


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

Re: zEDC Compression & DFSMSDSS Move

[Robert2 Gensler]

Hi Theo,

I want to make sure I understand your question.  Are you asking that if you
have a data set compressed with generic or tailored compression and use
DFSMSdss to DUMP that data set specifying ZCOMPRESS, will that data set be
sent through zEDC for further compression?  If so, the answer is yes, if
you specify ZCOMPRESS DFSMSdss will send generic and tailored compressed
data set through zEDC for further compression.  I cannot speak to whether
or not you will see added benefit by compressing already compressed data
with zEDC.

Thanks,
Robert Gensler
DFSMSdss Architecture and Development
Tucson, AZ
1-720-349-5211
rgen...@us.ibm.com

IBM Mainframe Discussion List  wrote on
09/15/2017 08:44:46 AM:

> From: "Buckton, T. (Theo)" 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 09/15/2017 08:45 AM
> Subject: zEDC Compression & DFSMSDSS Move
> Sent by: IBM Mainframe Discussion List 
>
> Hi,
>
> Just one question... Will a dataset that was previously created with
> generic or tailored compression, be further compressed if it is
> copied with DFSMSDSS and with zEDC enabled?
>
> Regards
> Theo
> 
>
> Nedbank disclaimer and confidentiality notice:
>
> This email may contain information that is confidential, privileged
> or otherwise protected from disclosure. If you are not an intended
> recipient of this email or all or some of the information contained
> therein, do not duplicate or redistribute it by any means. Please
> delete it and any attachments and notify the sender that you have
> received it in error. Unless specifically indicated, this email is
> neither an offer or a solicitation to buy or sell any securities,
> investment products or other financial product or service, nor is it
> an official confirmation of any transaction or an official statement
> of Nedbank. Any views or opinions presented are solely those of the
> author and do not necessarily represent those of Nedbank. Nedbank
> Ltd Reg No 1951/09/06.
>
> The following link displays the names of the Nedbank Board of
> Directors and Company Secretary. [https://urldefense.proofpoint.com/
> v2/url?
>
u=http-3A__www.nedbank.co.za_terms_DirectorsNedbank.htm=DwIFAg=jf_iaSHvJObTbx-

>
siA1ZOg=4IouVQcajkz0Xk8aBQYNyp4CJn0tmfX31FiYrnNQujA=c0Lw15IR_PclQhZqHvCnCQJ_vegryoFIEZuex0poeQs=yeLEbaFLEru8PMylmSgQDVdtVVq8JslMBOWrL2bzecE=

> ]
>
> If you do not want to click on a link, please type the relevant
> address in your browser
>
> 
>
> --
> 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

Fwd: z14 PoO Available

[John McKown]

-- Forwarded message --
From: Dan Greiner 
Date: Fri, Sep 15, 2017 at 1:07 AM
Subject: z14 PoO Available
To: assembler-l...@listserv.uga.edu


The IBM z14 processor is generally available today (14 September 2017).

The z/Architecture Principles of Operation corresponding to the new z14
processor is available at http://publibfp.dhe.ibm.com/epubs/pdf/dz9zr011.pdf

The z/Architecture Reference Summary corresponding to the new z14 processor
is available at http://publibfp.dhe.ibm.com/epubs/pdf/dz9zs009.pdf



-- 
UNIX was not designed to stop you from doing stupid things, because that
would also stop you from doing clever things. -- Doug Gwyn

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: FTP JCL EXAMPLE - FTP PDS

[John McKown]

On Fri, Sep 15, 2017 at 8:18 AM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Fri, 15 Sep 2017 12:54:06 +, willie bunter  wrote:
>
> >John,
> >Quick question.  Could you tell me how I can continue on the next line.
> For example :mvsput 'FTP.V8050.MVS.BUILDJCL'  'DRP.V8050.MVS.BUILDJCL.NEW'
> (REAllocate
> >
> >If the output disn has more characters I run out of space .  I  tried
> typing + as a continuation (in col 72) and then on the next lineI typed '
> (REAllocate.
> >mvsput 'FTP.V8050.MVS.BUILDJCL'  'DRP.V8050.MVS.BUILDJCL.NEW'
>+(REAllocate
> >
> Why restrict yourself to 72 characters?  For many releases now, JCL
> has imposed no such restriction on SYSIN.
>
> Old habits, however detrimental, die hard.
>

​Job may be in a "normal" production JCL library. Trying to convince a
production control person that JCL can be in anything other than an FB/80
library is likely to be a very frustrating experience. Sometimes we must do
things old style just to placate other people. Yes, it would be nice to
educate people. But it can be _impossible_ in some cases. I had a JCL
checker which I set up to do a WARNING if the JCL contained obsolete but
acceptable parameters. I was raked over the coals by a programmer who "has
been coding JCL for over 25 years, damn it!" when I flagged a SEP= in his
JCL. He _refused_ to stop coding it. And he complained up the chain that
the JCL checker was broken because it flagged the statement as "accepted by
unneeded". He demanded it be changed to not issue the warning because it
was distracting to him and "hiding" any "real problems".



>
> -- gil
>
>

-- 
UNIX was not designed to stop you from doing stupid things, because that
would also stop you from doing clever things. -- Doug Gwyn

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: FTP JCL EXAMPLE - FTP PDS

[John McKown]

On Fri, Sep 15, 2017 at 7:54 AM, willie bunter <
001409bd2345-dmarc-requ...@listserv.ua.edu> wrote:

> John,
> Quick question.  Could you tell me how I can continue on the next line.
> For example :mvsput 'FTP.V8050.MVS.BUILDJCL'  'DRP.V8050.MVS.BUILDJCL.NEW'
> (REAllocate
>
> If the output disn has more characters I run out of space .  I  tried
> typing + as a continuation (in col 72) and then on the next lineI typed '
> (REAllocate.
> mvsput 'FTP.V8050.MVS.BUILDJCL'  'DRP.V8050.MVS.BUILDJCL.NEW'
>+(REAllocate
>
>   However the command didn't work because of unbalanced parenthesis.  Do
> you have a solution?
>

​Hum, seems like it should work according to
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.halu001/ftpreq.htm

mvsput 'FTP.V8050.MVS.BUILDJCJ' 'DRP.V8050.MVS.BUILDJCL.NEW' +
  (REALLOCATE

or maybe try

mvsput 'FTP.V8050.MVS.BUILDJCJ' +
   'DRP.V8050.MVS.BUILDJCL.NEW'  (REALLOCATE





> Thanks.  From: John McKown 
>  To: IBM-MAIN@LISTSERV.UA.EDU
>  Sent: Thursday, September 7, 2017 2:04 PM
>  Subject: Re: FTP JCL EXAMPLE - FTP PDS
>
> On Thu, Sep 7, 2017 at 12:40 PM, Cieri, Anthony  wrote:
>
> >
> >If you are transferring a PDS from one MVS LPAR to another and
> > creating the target PDS, couldn't you use:
> >
> >mvsput 'FTP.V8050.MVS.BUILDJCL'  'DRP.V8050.MVS.BUILDJCL.NEW'
> > (REAllocate
>
>
> ​Oh, that is good. I'm still stuck on z/OS 1.12, so I'm not up on the
> newest and greatest FTP commands. I need to go read the 2.3 books on that
> to see what other goodies exist.​
>
>
> --
> UNIX was not designed to stop you from doing stupid things, because that
> would also stop you from doing clever things. -- Doug Gwyn
>
> Maranatha! <><
> John McKown
>
> --
> 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
>



-- 
UNIX was not designed to stop you from doing stupid things, because that
would also stop you from doing clever things. -- Doug Gwyn

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: FTP JCL EXAMPLE - FTP PDS

[Paul Gilmartin]

On Fri, 15 Sep 2017 12:54:06 +, willie bunter  wrote:

>John,
>Quick question.  Could you tell me how I can continue on the next line.  For 
>example :mvsput 'FTP.V8050.MVS.BUILDJCL'  'DRP.V8050.MVS.BUILDJCL.NEW' 
>(REAllocate
>
>If the output disn has more characters I run out of space .  I  tried typing + 
>as a continuation (in col 72) and then on the next lineI typed ' (REAllocate.
>mvsput 'FTP.V8050.MVS.BUILDJCL'  'DRP.V8050.MVS.BUILDJCL.NEW'                
>+(REAllocate
> 
Why restrict yourself to 72 characters?  For many releases now, JCL
has imposed no such restriction on SYSIN.

Old habits, however detrimental, die hard.

-- gil

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

Re: FTP JCL EXAMPLE - FTP PDS - CORRECTION

[willie bunter]

Sorry it wasn't parenthesis but: Mismatched quotes on pathname 
'DRP.V8050.MVS.BUILDJCL.NEW'(REAllocate

  From: willie bunter <001409bd2345-dmarc-requ...@listserv.ua.edu>
 To: IBM-MAIN@LISTSERV.UA.EDU 
 Sent: Friday, September 15, 2017 8:54 AM
 Subject: Re: FTP JCL EXAMPLE - FTP PDS
   
John,
Quick question.  Could you tell me how I can continue on the next line.  For 
example :mvsput 'FTP.V8050.MVS.BUILDJCL'  'DRP.V8050.MVS.BUILDJCL.NEW' 
(REAllocate

If the output disn has more characters I run out of space .  I  tried typing + 
as a continuation (in col 72) and then on the next lineI typed ' (REAllocate.
mvsput 'FTP.V8050.MVS.BUILDJCL'  'DRP.V8050.MVS.BUILDJCL.NEW'                
+(REAllocate

  However the command didn't work because of unbalanced parenthesis.  Do you 
have a solution?
Thanks.      From: John McKown 
 To: IBM-MAIN@LISTSERV.UA.EDU 
 Sent: Thursday, September 7, 2017 2:04 PM
 Subject: Re: FTP JCL EXAMPLE - FTP PDS
  
On Thu, Sep 7, 2017 at 12:40 PM, Cieri, Anthony  wrote:

>
>        If you are transferring a PDS from one MVS LPAR to another and
> creating the target PDS, couldn't you use:
>
>        mvsput 'FTP.V8050.MVS.BUILDJCL'  'DRP.V8050.MVS.BUILDJCL.NEW'
> (REAllocate


​Oh, that is good. I'm still stuck on z/OS 1.12, so I'm not up on the
newest and greatest FTP commands. I need to go read the 2.3 books on that
to see what other goodies exist.​


-- 
UNIX was not designed to stop you from doing stupid things, because that
would also stop you from doing clever things. -- Doug Gwyn

Maranatha! <><
John McKown

--
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: FTP JCL EXAMPLE - FTP PDS

[willie bunter]

John,
Quick question.  Could you tell me how I can continue on the next line.  For 
example :mvsput 'FTP.V8050.MVS.BUILDJCL'  'DRP.V8050.MVS.BUILDJCL.NEW' 
(REAllocate

If the output disn has more characters I run out of space .  I  tried typing + 
as a continuation (in col 72) and then on the next lineI typed ' (REAllocate.
mvsput 'FTP.V8050.MVS.BUILDJCL'  'DRP.V8050.MVS.BUILDJCL.NEW'                
+(REAllocate

  However the command didn't work because of unbalanced parenthesis.  Do you 
have a solution?
Thanks.  From: John McKown 
 To: IBM-MAIN@LISTSERV.UA.EDU 
 Sent: Thursday, September 7, 2017 2:04 PM
 Subject: Re: FTP JCL EXAMPLE - FTP PDS
   
On Thu, Sep 7, 2017 at 12:40 PM, Cieri, Anthony  wrote:

>
>        If you are transferring a PDS from one MVS LPAR to another and
> creating the target PDS, couldn't you use:
>
>        mvsput 'FTP.V8050.MVS.BUILDJCL'  'DRP.V8050.MVS.BUILDJCL.NEW'
> (REAllocate


​Oh, that is good. I'm still stuck on z/OS 1.12, so I'm not up on the
newest and greatest FTP commands. I need to go read the 2.3 books on that
to see what other goodies exist.​


-- 
UNIX was not designed to stop you from doing stupid things, because that
would also stop you from doing clever things. -- Doug Gwyn

Maranatha! <><
John McKown

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

zEDC Compression & DFSMSDSS Move

[Buckton, T. (Theo)]

Hi,

Just one question... Will a dataset that was previously created with generic or 
tailored compression, be further compressed if it is copied with DFSMSDSS and 
with zEDC enabled?

Regards
Theo


Nedbank disclaimer and confidentiality notice:

This email may contain information that is confidential, privileged or 
otherwise protected from disclosure. If you are not an intended recipient of 
this email or all or some of the information contained therein, do not 
duplicate or redistribute it by any means. Please delete it and any attachments 
and notify the sender that you have received it in error. Unless specifically 
indicated, this email is neither an offer or a solicitation to buy or sell any 
securities, investment products or other financial product or service, nor is 
it an official confirmation of any transaction or an official statement of 
Nedbank. Any views or opinions presented are solely those of the author and do 
not necessarily represent those of Nedbank. Nedbank Ltd Reg No 1951/09/06.

The following link displays the names of the Nedbank Board of Directors and 
Company Secretary. [http://www.nedbank.co.za/terms/DirectorsNedbank.htm]

If you do not want to click on a link, please type the relevant address in your 
browser



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

Re: "Breach" (fka Would encryption have prevented known major breaches?)

[Peter Relson]

In my view, your definition is not what most people mean with the word
"breach."


And in my view my definition is exactly what is meant by breach. A breach 
is unintended entrance. And that is exactly what the dictionary reference 
says. 

The consequences of that unintended entrance are not relevant to whether 
or not there was a breach.

Peter Relson
z/OS Core Technology Design


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

Re: Can you run multiple jobs with the same job name at the same time on JES2?

[Elardus Engelbrecht]

Jesse Robinson wrote:

>Depending on the one-jobname restriction was indeed a 'convenient' method of 
>serialization--but a method fraught with peril.

Yaaa, tell me. ;-)

 
>One-jobname was always a poor man's solution to a complex problem. With even a 
>modestly sophisticated job scheduling system, serialization was achieved far 
>more capably.   

Very true. Use Automation Software to schedule jobs based on Return Code (from 
SYSLOG or from jobs themselves) and success/failure of previous jobs ran on 
same or other LPARs. Use the Automation Software handling of 'incoming' and 
'outgoing' condition codes.
 
With this setup there is not a problem with same or different jobnames and the 
order in which they are running.

One example: every day we run SMF Dump, Automation Software collects the 
results of those SMF jobs and pass it on as conditions to release other jobs 
which post process SMF data. The jobnames can be the same or not, it does not 
matter.

Before we got Automation Software, it was a real PITA to ensure jobs with the 
same names ran in the right sequence. The Operators sometimes released the 
wrong job, surely all h*ll broke loose when the angry client had to restore 
their data.

Groete / Greetings
Elardus Engelbrecht

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

Re: Snap data to a PDS

[Binyamin Dissen]

You should look at IEATDUMP rather than SNAP, especially when storing to a
dataset. Of course, if you want multiple SNAPs to the same open DCB, you must
use SNAP (in your case you want individual members IEATDUMP would be better).

On Thu, 14 Sep 2017 21:53:47 -0400 Joseph Reichman 
wrote:

:>Don't know if this doable but I would snap dump data to a pds
 
:>Looking at the snap dump DCB macros DSORG=PS,MACRF=W

:>That would lead me to think I would have to use (if this doable) RDJFCB and
:>move the member name in 

:>BSAM has a exlst parameter and I use X'07' to get the JFCB area then do OPEN
:>TPYE=J

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

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