Re: z/OS Container Extensions

[Matt Hogstrom]

Think of ZCX as a means of hosting Linux based software inside of a z/OS system 
much like one would run VirtualBox or VMware on a system to host another OS.  
For z/OS I see two main benefits.  First, the open source software that so much 
new tech is built on does not have to be ported to USS but we can use it 
natively (notwithstanding the need for 390x binaries).  

You could run dependent systems on platform where you used to run the software 
in another cloud.  Service Management Unit, zAware, IBM operations Analytics 
for Z and a number of other current products are based on Linux open source.  
You get to save time, money, and run your supporting software on platform.

Also, new work can be hosted on platform and co-located with other runtimes 
like CICS, IMS or Db2 and enjoy the lower latency, and business continuity of 
running in a Sysplex.  

Winner winner chicken dinner I think.

Matt Hogstrom
m...@hogstrom.org
+1-919-656-0564
PGP Key: 0x90ECB270
Facebook   LinkedIn 
  Twitter 

“It may be cognitive, but, it ain’t intuitive."
— Hogstrom

> On May 17, 2019, at 1:52 PM, Kirk Wolf  wrote:
> 
> Docker is a virtualization technology which is different from a "virtual
> machine".
> See an overview like:
> https://www.infoworld.com/article/3204171/what-is-docker-docker-containers-explained.html
> 
> The zCX engine/host operating may be based on Ubuntu Linux; it isn't
> technically correct to say the the "Linux *kernel* is Ubuntu".
> Also, it doesn't matter too much that the Docker engine/host operating
> system is a particular Linux distribution.  Docker images derived from
> different distributions can run in it.
> 
> To confuse things, the zCX engine/host linux operating system runs inside a
> z/OS address space using virtual machine technology.
> 
> I'm sure I helped not at all :-)
> 
> 
> On Thu, May 16, 2019 at 3:31 PM David Purdy <
> 00ac4b1d56b3-dmarc-requ...@listserv.ua.edu> wrote:
> 
>> We learned at Share Phoenix that the Linux kernel is Ubuntu.
>> 
>> David
>> 
>> 
>> On Thursday, May 16, 2019 Jousma, David  wrote:
>> I've seen bits and piecesI believe It's a blackbox secure setup.  No
>> on-site Linux administration aside from application admin or maintenance
>> required, no ROOT access.  All handled by IBM AFAIK.
>> 
>> 
>> _
>> Dave Jousma
>> AVP | Manager, Systems Engineering
>> 
>> Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand
>> Rapids, MI 49546
>> 616.653.8429  |  fax: 616.653.2717
>> 
>> 
>> 
>> -Original Message-
>> From: IBM Mainframe Discussion List  On Behalf
>> Of Frank Swarbrick
>> Sent: Thursday, May 16, 2019 3:02 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: z/OS Container Extensions
>> 
>> **CAUTION EXTERNAL EMAIL**
>> 
>> **DO NOT open attachments or click on links from unknown senders or
>> unexpected emails**
>> 
>> Don't really know anything about this, but does anyone know what advantage
>> there is to running a Docker container on z/OS over just running it Linux
>> for Z?  Is it just for those who don't have Linux for Z but want to run
>> Linux applications on the mainframe?  Does it allow "direct access" to z/OS
>> resources (databases, CICS, etc.)?
>> 
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions, send email
>> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION
>> EXTERNAL EMAIL**
>> 
>> **DO NOT open attachments or click on links from unknown senders or
>> unexpected emails**
>> 
>> 
>> This e-mail transmission contains information that is confidential and may
>> be privileged.  It is intended only for the addressee(s) named above. If
>> you receive this e-mail in error, please do not read, copy or disseminate
>> it in any manner. If you are not the intended recipient, any disclosure,
>> copying, distribution or use of the contents of this information is
>> prohibited. Please reply to the message immediately by informing the sender
>> that the message was misdirected. After replying, please erase it from your
>> computer system. Your assistance in correcting this error is appreciated.
>> 
>> --
>> 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

Re: Ancient DASD connectivity

[Seymour J Metz]

3350 models C2 and C2F were tail of string units. As I recall, for 3375 the C 
boxes included a control unit so it could attach directly to the channel.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Martin Packer 
Sent: Friday, May 17, 2019 10:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ancient DASD connectivity

And then there were double-ended strings of disks. 3350s? Just before my
time, really.

Martin Packer

zChampion, Systems Investigator & Performance Troubleshooter, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker

Blog:
https://secure-web.cisco.com/1zkSbtFDHOQs-i0S-NWG9whv4u3IVZLV4iwAsKJoL2wW0OBmxiXP49rPpM1hT28C5b05szJKbesmdCwEEpD05FwEH50B6ARq7H4b8Zh6IJr0tPsuzoBPiFXQPDfQxYaPQYvyOvy4G4ln6n4_9ms5P4hMeiNmq_UYxcH9QVEOrWeEbnycJFVTjqY_VuZ2F1xvASndlQXGyymvVCnHH2aIspYvzxF-0v8HOHELGUtxn0k3au6EUwcA6JbLaxD8trjCjyKkhMbn2UTBk5SPRnwKUsrJkFPfKX_m0eFWLqK4Dpf_7hxz6bRU96J927VJx72fgLXSwle86AKD9TflIwL0F5YWlHRJ4iU607AikyfCE2ITitcGvm3snmAwlVhIt26GhilCuUJS5OFV9C9IrAF0iI3FXKM55EISaE0TLMl0ogj_jVq_hpJg6Cv8d12MymWJX/https%3A%2F%2Fwww.ibm.com%2Fdeveloperworks%2Fmydeveloperworks%2Fblogs%2FMartinPacker

Podcast Series (With Marna Walle): 
https://secure-web.cisco.com/17KFRTNtw8jfbbM3KsapTPl1kUL2e-A2T3RRirEQef-5zKhaDfIaoQ_kHlL0yVxsqdBBDxqf9CXdbupf2MnBsASYjnviXkJ9jRWLAC5v943HBI13uSh2iuQmpypV1xgZcxrt5ebRbKLdQZkY_BNXmjANax89CByWOJP7STOCVY7uwa6DHHuPGSLwwPa2dMb94riZ72R-fmAnpuWeGC01zG7qlp9uerNzhLgGHKIeQIEUPzm6gaNIXoTcPo4iLXm9wnlXFL-7ZJ91d7Bzjl7dJYj5fgHRjrSc0CaBv4OfZJ4BTd8akyp4TwyEpa8bUwDbqMIhtipc7LGiitUrTVmSzhK3vt2ZgiEt_nyHFFW42RBrSul6uEtbZKEdjmChauSiicHsmtpqltjfyEkP71GopsRXX0jJqxdXhZLnhnW6ekDnCO3tf05rhz_nSlVpPGA7Y/https%3A%2F%2Fdeveloper.ibm.com%2Ftv%2Fmpt%2F
or

https://secure-web.cisco.com/1pQriJXHvVuThP0MiibJcjZPe99XVSGA8WIXKQWnnbEK60K2jHF9_I_b5NcG8qrUysHmYu4IaCDP9G2UOzIqYQUb7dBLJ02sIhkPnPIakC2kn4HehGcYblVT2oM6DfmZviasdke8CJiDf1YWoOcHZdDS5foOvVkuR7k9zEwD_fb-Kegv_pXrdLjF6BSSzoI98D4xr8xCUw-zjIFjew3TUxeZhkFlrIJerjVQaoNdWOo7CzKEkrgRzh-UuK_7_76_HY7Kh2aBn63ONaxP2Nt-2CNwKf_QPi2y4-IySqKvp7KyrcYDPu33ivqtcnHxuFp9UvxEzbKILV-2b_IqVhq08fqsDdvYBQyxZrP-XHsx7-pqmtWJTJQk71WA5nugG5ZtJBbmjkiHHd-MgjaS82K7xVnfY3FNi0mZsGjMIX4b909pJHeTJnu0HMU-OIEpwGDJl/https%3A%2F%2Fitunes.apple.com%2Fgb%2Fpodcast%2Fmainframe-performance-topics%2Fid1127943573%3Fmt%3D2


Youtube channel: 
https://secure-web.cisco.com/1-SK3lE2EgsiE4OF0AoD5ULNOh2Fz_tyO-k4W60ndX3c6VFQjlBkkxbpfn4MpvEIaSlm5GI7vZ29LRnhBlFYkgmQZO3tJHPC_ax49nYsCpfw4knMzI6s3_KCx0M55RlORonHtJgl90mttVWoblAfIIcjxNgvG9zl_r5O-vFZ73ds0yJ_XeqA34PPXjQbXNJ986sBIAvd5Tu-ZHyECEkw5L-8VyXjn5F0ljxt-rTGa_YA8ADXp-IGOCUkt0h9WBwC_JMfeB8RR405hRrLUFCmTRwue45LSMEWOmeiq-i7SXrbWKB9qBm7Q1UgKR--N95bOOSR8B9M69Bxve_3-Obvmyv6Qbw2lWQcjZ8BjYSPgB8Repe1OxME27iHLTrV2p7m362cHxqxVYB17Wztqi5trWP1PPerMGXT_hNG8e0CN9jE/https%3A%2F%2Fwww.youtube.com%2Fchannel%2FUCu_65HaYgksbF6Q8SQ4oOvA



From:   Seymour J Metz 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   17/05/2019 15:18
Subject:Re: Ancient DASD connectivity
Sent by:IBM Mainframe Discussion List 



T A unit attached to a CU; it was the CU that attached directly to the
channel. There is some overloaded nomenclature here; the control function
of an A unit is entirely different from a control unit.


--
Shmuel (Seymour J.) Metz
https://secure-web.cisco.com/192B_8vChSMEyndnDPZG4RNlm17VN3PY80ixM5PthJQg8MVIiqCvk9ByLRPOEMdWbZdqGwhf4ppFbu3Lu1yy9-DSjADiZM3jzcZ4UZOo_drGdzNjGpAjEJpZ9JLRrGARR_uXICqAlkz1Yov-GLPH8yR57rGEmecK6kz3PmnVnXrn0FuQO0BktLd5oYo0NkdzPMGQ59teedMN8CJ6sG-WVK9CHUcHTGJYS1ZdAHJLA85oxsmKA0m3obsoSufzR1CArcEmQoyq4F3aFPIZa7aC-ukShghPM2JEiKAM8d1iMop2PkRl3lvlhA_d71aBCSPuNh1-ViaUQhBT22zIYIys3lNRGcep-3yXPDvn2z4L58b2Vhtv-5f8hqyWhdIUM6xJ0CdX8qEVYPY-fxg4SGfkS3831zr_4754rutnDDNCVyeM/https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__mason.gmu.edu_-7Esmetz3%26d%3DDwIFAw%26c%3Djf_iaSHvJObTbx-siA1ZOg%26r%3DBsPGKdq7-Vl8MW2-WOWZjlZ0NwmcFSpQCLphNznBSDQ%26m%3DsbtcjKhJzgcjkqtihVmO6CFwHrRj5q-KUW7yT03NU7Q%26s%3DUjmNKh0zJMgKPveYfD_9y2AfqLn86GvSJJsO6tUpx0Y%26e%3D



From: IBM Mainframe Discussion List  on behalf
of Alan Altmark 
Sent: Friday, May 17, 2019 10:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ancient DASD connectivity

On Thu, 16 May 2019 15:26:45 +, Seymour J Metz  wrote:
>Well, for some devices the CU and device were in the same box, e.g.,
2501.

Yes.  A-units (Axx models) often include(d) at least one, possibly two or
even four, I/O devices, with B units (Bxx models) providing expansion.
Last CU standing in the A/B world was, I think, the IBM 3590, but it all
went out the window when the 3592s made their debut.

While it was interesting for IBM to wear it's engineering designs on its
visible sleeve, it was confusing.   Model numbers today are more
expressions of marketing than of the underlying technology.

Fun times.

Alan Altmark
IBM

--

Re: DFDSS copy to pre-allocated dsn

[Robert2 Gensler]

Hi Elaine,

Assuming you are getting a ADR380E reason code 75, the message is saying
that sys7.r30.v22.root.hfs resides on more volumes than just the volume
pointed to by DASD1.  It was mentioned by a couple people already to
specify SELECTMULTI(ANY), that should do the trick for you.  If not, please
include the entire error message and I will see what I can do.

Thanks,
Robert
DFSMSdss Architecture and Development
Tucson, AZ
rgen...@us.ibm.com

IBM Mainframe Discussion List  wrote on
05/16/2019 05:50:46 PM:

> From: Elaine Beal 
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 05/16/2019 05:51 PM
> Subject: [EXTERNAL] DFDSS copy to pre-allocated dsn
> Sent by: IBM Mainframe Discussion List 
>
> I've found a lot of " it's " confusing comments on this topic and I
> am beleaguered-
> I am trying to copy a file to an existing, pre-allocated new name.
> Seems that should be pretty straight forward... but having to
> specify rename to make a copy is anything but straight forward
>
> I'm getting ADR380E (001)-FDSCO(08) indicating REPLACEUNCONDITIONAL
> is not specified
> but I get this whether I specify it or not-
>
>
>   COPY DATASET(INCLUDE(SYS7.R30.V22.ROOT.HFS))  -
>   LOGINDDNAME(DASD1)  -
>   OUTDDNAME(DASD2,DASD3,DASD4)  -
>   RENAMEU((SYS7.R30.V22.ROOT.HFS,   -
>   SYS7.R30.V22.RSU.ROOT.HFS)) -
>   REPLACEUNCONDITIONAL   -
>   NULLSTORCLAS BYPASSACS(**) -
>   ALLDATA(*) ALLEXCP CANCELERROR -
>   SHARE -
>   WRITECHECK
>
> Thanks for any help-
> Elaine
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: z/OS Container Extensions

[Farley, Peter x23353]

That link helped me understand quite a lot, thank you!

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Kirk Wolf
Sent: Friday, May 17, 2019 1:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: z/OS Container Extensions

Docker is a virtualization technology which is different from a "virtual 
machine".
See an overview like:
https://www.infoworld.com/article/3204171/what-is-docker-docker-containers-explained.html

The zCX engine/host operating may be based on Ubuntu Linux; it isn't 
technically correct to say the the "Linux *kernel* is Ubuntu".
Also, it doesn't matter too much that the Docker engine/host operating system 
is a particular Linux distribution.  Docker images derived from different 
distributions can run in it.

To confuse things, the zCX engine/host linux operating system runs inside a 
z/OS address space using virtual machine technology.

I'm sure I helped not at all :-)


On Thu, May 16, 2019 at 3:31 PM David Purdy < 
00ac4b1d56b3-dmarc-requ...@listserv.ua.edu> wrote:

> We learned at Share Phoenix that the Linux kernel is Ubuntu.
>
> David
>
> On Thursday, May 16, 2019 Jousma, David  wrote:
> I've seen bits and piecesI believe It's a blackbox secure setup.  
> No on-site Linux administration aside from application admin or 
> maintenance required, no ROOT access.  All handled by IBM AFAIK.
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Frank Swarbrick
> Sent: Thursday, May 16, 2019 3:02 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: z/OS Container Extensions
>
> Don't really know anything about this, but does anyone know what 
> advantage there is to running a Docker container on z/OS over just 
> running it Linux for Z?  Is it just for those who don't have Linux for 
> Z but want to run Linux applications on the mainframe?  Does it allow 
> "direct access" to z/OS resources (databases, CICS, etc.)?
--


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


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

Re: Metal-C exits

[Clark Morris]

[Default] On 16 May 2019 10:06:47 -0700, in bit.listserv.ibm-main
sasd...@gmail.com (Steve Smith) wrote:

>Well, XLC already provides a DSECT to struct conversion tool.  I haven't
>found its output to be as awful as it once was.

The need is for the ability to use IBM data descriptions of any IBM
provided records that someone might want to process in the language of
choice and of data areas needed to use callable services.  The
languages that probably should be supported are C/C++, COBOL, FORTRAN,
Java, and PL/1.  Having a program that converts from either PL/S or
Assembler to the other languages will ease the problem of keeping the
descriptions synchronized. 

Clark Morris
>
>One thing I might suggest is to get header files out of SAMPLIB.  There are
>now two system-level header libraries (SYS1.SIEAHDR.H, and
>SYS1.SIEAHDRV.H), which could also be better advertised as being in
>existence.  Maybe I'm slow, but it took quite a while to figure out that's
>where the headers for Pause/Release are.
>
>They could also be consolidated; FB80 libraries for C source is ludicrous.
>
>sas
>
>
>On Thu, May 16, 2019 at 8:26 AM Clark Morris  wrote:
>
>> [Default] On 16 May 2019 04:55:33 -0700, in bit.listserv.ibm-main
>> rel...@us.ibm.com (Peter Relson) wrote:
>>
>> >
>> >...where IBM provides some guidelines for doing exit work in Metal-C
>> >
>> >
>> >I'd say that the guideline is to get Metal C to do what you would have
>> >done if you were coding in assembler.
>> >
>> >What you typically need are mappings in (Metal) C for the data structures
>> >that the exit routine needs to access. Most ISVs have likely rolled their
>> >own over time, but z/OS is (finally) beginning to provide some (and is
>> >looking for help in prioritizing which to provide first -- the goal is to
>> >do most of the mappings in maclib and modgen, but that goal would be
>> >accomplished incrementally). If you have such a prioritized list (it can
>> >be for your own needs, or a group's or any scale you choose) please send
>> >it to me so that we can try to make the best plan. Of course exit
>> routines
>> >are not the only things that can benefit from the availability of such
>> >mappings.
>> While being retired I am in no position to submit an RFE, what I have
>> alway wanted was a tool that would convert Assembler DSECTs to COBOL
>> record descriptions, PL1 mappings etc..  It would have saved me much
>> time in writing COBOL programs to deal with SMF records and would
>> allow easier usage of IBM callable routines.  This would be a better
>> approach for providing C mappings because it then allows relatively
>> easy update and doesn't require manual effort for each update.
>>
>> Clark Morris
>> >
>> >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
>>
>> --
>> 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: TSO Reconnect ABEND=S622

[Cieri, Anthony]

If "in the DMZ" means behind a firewall, then it is possible that the 
firewall has an "inactivity" time out values of its own!!



-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Roland Kinsman
Sent: Thursday, May 16, 2019 4:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TSO Reconnect ABEND=S622

[[ SEI WARNING *** This email was sent from an external source. Do not open 
attachments or click on links from unknown or suspicious senders. *** ]]


IEFUTL is exactly the same on both systems.

Not sure if this is helpful, but the system with the short timeout is "in the 
DMZ"

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

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

Re: z/OS Container Extensions

[Kirk Wolf]

Docker is a virtualization technology which is different from a "virtual
machine".
See an overview like:
https://www.infoworld.com/article/3204171/what-is-docker-docker-containers-explained.html

The zCX engine/host operating may be based on Ubuntu Linux; it isn't
technically correct to say the the "Linux *kernel* is Ubuntu".
Also, it doesn't matter too much that the Docker engine/host operating
system is a particular Linux distribution.  Docker images derived from
different distributions can run in it.

To confuse things, the zCX engine/host linux operating system runs inside a
z/OS address space using virtual machine technology.

I'm sure I helped not at all :-)


On Thu, May 16, 2019 at 3:31 PM David Purdy <
00ac4b1d56b3-dmarc-requ...@listserv.ua.edu> wrote:

> We learned at Share Phoenix that the Linux kernel is Ubuntu.
>
> David
>
>
> On Thursday, May 16, 2019 Jousma, David  wrote:
> I've seen bits and piecesI believe It's a blackbox secure setup.  No
> on-site Linux administration aside from application admin or maintenance
> required, no ROOT access.  All handled by IBM AFAIK.
>
>
> _
> Dave Jousma
> AVP | Manager, Systems Engineering
>
> Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand
> Rapids, MI 49546
> 616.653.8429  |  fax: 616.653.2717
>
>
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Frank Swarbrick
> Sent: Thursday, May 16, 2019 3:02 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: z/OS Container Extensions
>
> **CAUTION EXTERNAL EMAIL**
>
> **DO NOT open attachments or click on links from unknown senders or
> unexpected emails**
>
> Don't really know anything about this, but does anyone know what advantage
> there is to running a Docker container on z/OS over just running it Linux
> for Z?  Is it just for those who don't have Linux for Z but want to run
> Linux applications on the mainframe?  Does it allow "direct access" to z/OS
> resources (databases, CICS, etc.)?
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN **CAUTION
> EXTERNAL EMAIL**
>
> **DO NOT open attachments or click on links from unknown senders or
> unexpected emails**
>
>
> This e-mail transmission contains information that is confidential and may
> be privileged.  It is intended only for the addressee(s) named above. If
> you receive this e-mail in error, please do not read, copy or disseminate
> it in any manner. If you are not the intended recipient, any disclosure,
> copying, distribution or use of the contents of this information is
> prohibited. Please reply to the message immediately by informing the sender
> that the message was misdirected. After replying, please erase it from your
> computer system. Your assistance in correcting this error is appreciated.
>
> --
> 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: Exit Question

[scott Ford]

Eladus,
My friend I have an exit feeding a piece of storage I had an inquiry asking
could we write what we captured
straight to disk ...

Scott

On Fri, May 17, 2019 at 1:36 PM Elardus Engelbrecht <
elardus.engelbre...@sita.co.za> wrote:

> scott Ford wrote:
>
> >It is still true you can do I/O , disk I/O in particular from say a RACF
> exit, in particular IRREVX01 ?
>
> You can only use what is documented. I did a quick RTFM, apparently
> IRREVX01 is not (or cannot!) doing disk I/O due to the nature of how it is
> being called in the first place. IRREVX01 receives the command issued twice
> during pre and post processing calls.
>
> I am not sure where the IRREVX01 is running - in the address space of the
> RACF command issuer or in RACF system address space.
>
> The only inputs for IRREVX01 are some flags in the parameter list and
> command buffer. IRREVX01 can modify the contents of the keywords of the
> intended command issued. Output allowed is a message area which you can
> place your own message. There is also a communication area for exchange
> between the pre and post processing.
>
> I know you're a developer, you probably should know that some exits are
> assembled and later called in a specific way and environment. SMF exits can
> for example do some I/O, issue WTOs, calling other services, etc., but then
> only if it is documented and usable.
>
> For what is worth, I don't know if z/OS is _actively suppressing_
> undocumented things like I/O for exits or just let you have a nasty Abend
> plus dumps.
>
>
> >Or am i mistaken..I was thinking about somehow talking to LOGGER ...
>
> LOGGER? What LOGGER? System Logger? Syslog? LOGREC? SMF exits/macros used
> to write out something? Or something else?
>
> Or, if you can, why are you asking or what are you trying to solve?
>
> Groete / Greetings
> Eladus Engelbrecht
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 



*IDMWORKS *

Scott Ford

z/OS Dev.




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



www.idmworks.com

scott.f...@idmworks.com

Blog: www.idmworks.com/blog





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

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

Re: Exit Question

[Elardus Engelbrecht]

scott Ford wrote:

>It is still true you can do I/O , disk I/O in particular from say a RACF exit, 
>in particular IRREVX01 ?

You can only use what is documented. I did a quick RTFM, apparently IRREVX01 is 
not (or cannot!) doing disk I/O due to the nature of how it is being called in 
the first place. IRREVX01 receives the command issued twice during pre and post 
processing calls.

I am not sure where the IRREVX01 is running - in the address space of the RACF 
command issuer or in RACF system address space.
 
The only inputs for IRREVX01 are some flags in the parameter list and command 
buffer. IRREVX01 can modify the contents of the keywords of the intended 
command issued. Output allowed is a message area which you can place your own 
message. There is also a communication area for exchange between the pre and 
post processing.

I know you're a developer, you probably should know that some exits are 
assembled and later called in a specific way and environment. SMF exits can for 
example do some I/O, issue WTOs, calling other services, etc., but then only if 
it is documented and usable.

For what is worth, I don't know if z/OS is _actively suppressing_ undocumented 
things like I/O for exits or just let you have a nasty Abend plus dumps.


>Or am i mistaken..I was thinking about somehow talking to LOGGER ...

LOGGER? What LOGGER? System Logger? Syslog? LOGREC? SMF exits/macros used to 
write out something? Or something else?

Or, if you can, why are you asking or what are you trying to solve?

Groete / Greetings
Eladus Engelbrecht

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

Exit Question

[scott Ford]

All:

Here is my dumb Friday question guys and gals. It is still true you can do
I/O , disk I/O in particular from say a RACF exit, in particular IRREVX01 ?
Or am i mistaken..I was thinking about somehow talking to LOGGER ...

Scott

-- 



*IDMWORKS *

Scott Ford

z/OS Dev.




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



www.idmworks.com

scott.f...@idmworks.com

Blog: www.idmworks.com/blog





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

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

Re: File 228 CBT tape - HSM panel recovery

[Peter Vander Woude]

I just submitted to the cbt site, an updated file 228, that works correctly.

The problem lies in how the clist was parsing the output from the hsm command.  

The format changed a long time ago.  I had got it working for me, just didn't 
think about submitting the changes.

Peter

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

Re: DFDSS copy to pre-allocated dsn

[Paul Gilmartin]

On 2019-05-17, at 07:58:45, Styles, Andy (ITS zPlatform Services) wrote:

> Assuming we're talking copying to disk (I'm not sure you could copy a dataset 
> to tape, never tried),
> but ZFS's, being VSAM, must be cataloged; you couldn't thus copy a ZFS to two 
> different volumes
> with the same dataset name because of the catalog clash.
>  
Could it be catalogued in a different catalog?

-- gil

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

Re: Address space dump for Exit usage

[Peter Relson]

When we take a SVCDUMP for an active address space . Does the dump shows 
if
that particular address space uses particular EXIT ?


We need to start with understanding the question. What do you mean "dump 
shows"? And what do you mean by "uses"?''

If by "dump shows" you are asking about evidence in the system trace of a 
call to a particular exit (and/or a particular exit routine) there is 
unlikely to be any, although for some there might be evidence of a PC to 
the dynamic exits service. But that PC would not show what exit or what 
exit routine.

If by "uses" you mean "the system calls a particular exit for that 
particular address space", if you know the system control blocks you can 
likely figure out if a particular exit applies to a particular address 
space. But that would require a lot of internal knowledge.  An "address 
space dump" is likely not useful at all. You'd need a dump of common 
storage and/or the address space that houses the information about calling 
exits.

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: Ancient DASD connectivity

[Martin Packer]

And then there were double-ended strings of disks. 3350s? Just before my 
time, really.

Martin Packer

zChampion, Systems Investigator & Performance Troubleshooter, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker

Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker

Podcast Series (With Marna Walle): https://developer.ibm.com/tv/mpt/or 
  
https://itunes.apple.com/gb/podcast/mainframe-performance-topics/id1127943573?mt=2


Youtube channel: https://www.youtube.com/channel/UCu_65HaYgksbF6Q8SQ4oOvA



From:   Seymour J Metz 
To: IBM-MAIN@LISTSERV.UA.EDU
Date:   17/05/2019 15:18
Subject:Re: Ancient DASD connectivity
Sent by:IBM Mainframe Discussion List 



T A unit attached to a CU; it was the CU that attached directly to the 
channel. There is some overloaded nomenclature here; the control function 
of an A unit is entirely different from a control unit.


--
Shmuel (Seymour J.) Metz
https://urldefense.proofpoint.com/v2/url?u=http-3A__mason.gmu.edu_-7Esmetz3&d=DwIFAw&c=jf_iaSHvJObTbx-siA1ZOg&r=BsPGKdq7-Vl8MW2-WOWZjlZ0NwmcFSpQCLphNznBSDQ&m=sbtcjKhJzgcjkqtihVmO6CFwHrRj5q-KUW7yT03NU7Q&s=UjmNKh0zJMgKPveYfD_9y2AfqLn86GvSJJsO6tUpx0Y&e=



From: IBM Mainframe Discussion List  on behalf 
of Alan Altmark 
Sent: Friday, May 17, 2019 10:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ancient DASD connectivity

On Thu, 16 May 2019 15:26:45 +, Seymour J Metz  wrote:
>Well, for some devices the CU and device were in the same box, e.g., 
2501.

Yes.  A-units (Axx models) often include(d) at least one, possibly two or 
even four, I/O devices, with B units (Bxx models) providing expansion. 
Last CU standing in the A/B world was, I think, the IBM 3590, but it all 
went out the window when the 3592s made their debut.

While it was interesting for IBM to wear it's engineering designs on its 
visible sleeve, it was confusing.   Model numbers today are more 
expressions of marketing than of the underlying technology.

Fun times.

Alan Altmark
IBM

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




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


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

Re: [EXTERNAL] Re: TSO Reconnect ABEND=S622

[Bill Bishop (TMNA)]

I believe so.

Thanks

Bill Bishop
Consultant, Mainframe Engineer
Mainframe and Scheduling | Infrastructure Technology Services 
Toyota Motor North America
 bill.bis...@toyota.com
Office:  (469) 292-5149
Cell:  (502) 316-4386

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Roland Kinsman
Sent: Friday, May 17, 2019 9:22 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: TSO Reconnect ABEND=S622

I'll find out about that.  Would that manifest itself as an S622 abend?

--
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: TSO Reconnect ABEND=S622

[Roland Kinsman]

I'll find out about that.  Would that manifest itself as an S622 abend?

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

Re: TSO Reconnect ABEND=S622

[Carmen Vitullo]

could it be something as simple as a different timeout value in your session 
manager product ? 
or a vtam, tcp/telnet setting that different on that system? 



Carmen Vitullo 

- Original Message -

From: "Roland Kinsman"  
To: IBM-MAIN@LISTSERV.UA.EDU 
Sent: Friday, May 17, 2019 9:22:26 AM 
Subject: Re: TSO Reconnect ABEND=S622 

I'll find out about that. Would that manifest itself as an S622 abend? 

-- 
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: Ancient DASD connectivity

[Seymour J Metz]

T A unit attached to a CU; it was the CU that attached directly to the channel. 
There is some overloaded nomenclature here; the control function of an A unit 
is entirely different from a control unit.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


From: IBM Mainframe Discussion List  on behalf of 
Alan Altmark 
Sent: Friday, May 17, 2019 10:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Ancient DASD connectivity

On Thu, 16 May 2019 15:26:45 +, Seymour J Metz  wrote:
>Well, for some devices the CU and device were in the same box, e.g., 2501.

Yes.  A-units (Axx models) often include(d) at least one, possibly two or even 
four, I/O devices, with B units (Bxx models) providing expansion.  Last CU 
standing in the A/B world was, I think, the IBM 3590, but it all went out the 
window when the 3592s made their debut.

While it was interesting for IBM to wear it's engineering designs on its 
visible sleeve, it was confusing.   Model numbers today are more expressions of 
marketing than of the underlying technology.

Fun times.

Alan Altmark
IBM

--
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: [EXTERNAL] Re: TSO Reconnect ABEND=S622

[Bill Bishop (TMNA)]

You mentioned that the one system existed in the DMZ.  

Is it possible that the DMZ has a different policy that terminates inactive IP 
sessions?

Thanks

Bill Bishop
Consultant, Mainframe Engineer
Mainframe and Scheduling | Infrastructure Technology Services 
Toyota Motor North America
 bill.bis...@toyota.com
Office:  (469) 292-5149
Cell:  (502) 316-4386

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Roland Kinsman
Sent: Friday, May 17, 2019 9:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: TSO Reconnect ABEND=S622

IEFUTL is pretty simple, nothing system-specific.  It does do a RACROUTE 
looking for read access to a certain resource, but on both systems, that 
resource has universal read.

--
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: DFDSS copy to pre-allocated dsn

[Styles, Andy (ITS zPlatform Services)]

Assuming we're talking copying to disk (I'm not sure you could copy a dataset 
to tape, never tried), but ZFS's, being VSAM, must be cataloged; you couldn't 
thus copy a ZFS to two different volumes with the same dataset name because of 
the catalog clash.

Andy Styles
z/Series System Programmer



From: IBM Mainframe Discussion List  on behalf of 
Allan Staller 
Sent: 17 May 2019 14:18
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFDSS copy to pre-allocated dsn

-- This email has reached the Bank via an external source --


Presuming this is an HFS, (and based on the supplied dsn) I believe you are 
correct.
If this is a mis-named ZFS, IIRC it can span volumes.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jackson, Rob
Sent: Thursday, May 16, 2019 6:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFDSS copy to pre-allocated dsn

I don't know for sure if OUTDD works exactly like OUTDY; I was wondering.  I 
used (no longer a DSS shop) OUTDY to list candidate volumes; COPY makes only 
one copy, whether it exists on one volume or is spread across multiple ones.  
Anyway, since this is non-SMS managed, it can be on only one volume--assuming 
it's really HFS.  I guess the same restriction would apply to ZFS.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mike Schwab
Sent: Thursday, May 16, 2019 7:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFDSS copy to pre-allocated dsn

[External Email]

So you are making 3 copies on 3 different OUTDDNAMES?
If it is one dataset on 3 volumes it would be one OUTDDNAME, right?

On Thu, May 16, 2019 at 4:51 PM Elaine Beal  wrote:
>
> I've found a lot of " it's " confusing comments on this topic and I am
> beleaguered- I am trying to copy a file to an existing, pre-allocated new 
> name.
> Seems that should be pretty straight forward... but having to specify
> rename to make a copy is anything but straight forward
>
> I'm getting ADR380E (001)-FDSCO(08) indicating REPLACEUNCONDITIONAL is
> not specified but I get this whether I specify it or not-
>
>
>   COPY DATASET(INCLUDE(SYS7.R30.V22.ROOT.HFS))  -
>   LOGINDDNAME(DASD1)  -
>   OUTDDNAME(DASD2,DASD3,DASD4)  -
>   RENAMEU((SYS7.R30.V22.ROOT.HFS,   -
>   SYS7.R30.V22.RSU.ROOT.HFS)) -
>   REPLACEUNCONDITIONAL   -
>   NULLSTORCLAS BYPASSACS(**) -
>   ALLDATA(*) ALLEXCP CANCELERROR -
>   SHARE -
>   WRITECHECK
>
> Thanks for any help-
> Elaine
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



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

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

Confidentiality notice:
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.


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

Re: TSO Reconnect ABEND=S622

[Roland Kinsman]

IEFUTL is pretty simple, nothing system-specific.  It does do a RACROUTE 
looking for read access to a certain resource, but on both systems, that 
resource has universal read.

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

Re: Ancient DASD connectivity

[Alan Altmark]

On Thu, 16 May 2019 15:26:45 +, Seymour J Metz  wrote:
>Well, for some devices the CU and device were in the same box, e.g., 2501.

Yes.  A-units (Axx models) often include(d) at least one, possibly two or even 
four, I/O devices, with B units (Bxx models) providing expansion.  Last CU 
standing in the A/B world was, I think, the IBM 3590, but it all went out the 
window when the 3592s made their debut.  

While it was interesting for IBM to wear it's engineering designs on its 
visible sleeve, it was confusing.   Model numbers today are more expressions of 
marketing than of the underlying technology.

Fun times.

Alan Altmark
IBM

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

Re: [External] Re: DFDSS QUESTION - PHYSICAL DATASET BACKUP

[Pommier, Rex]

John,

That's bizarre.  The only thing I saw different was the region size, and I 
dropped mine to 4M - and it worked with that region as well for me.  Anyway, 
glad it's working.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
John Dawes
Sent: Friday, May 17, 2019 7:29 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: DFDSS QUESTION - PHYSICAL DATASET BACKUP

 Rex,
I used your jcl and it worked.  I was successful with and without the NORUN 
parm. A massive thanks. 
On Thursday, 16 May 2019, 7:35:43 pm UTC, Pommier, Rex 
 wrote:  
 
 John,

I'm running 2.2 as well.  I was able to run it successfully copying 2 datasets 
to a tape.  And just for kicks and giggles, I removed the TYPRUN parm and it 
dumped the 2 datasets to a single tape. 

Here's my JCL/parms:

//STEP005 EXEC  PGM=ADRDSSU,REGION=0M,PARM='TYPRUN=NORUN'
//SYSPRINT DD  SYSOUT=*
//DASD1    DD  UNIT=3390,VOL=SER=S10057,DISP=SHR
//OUTVOL1  DD  UNIT=VTS,DISP=(,CATLG), //    DSN=RRP.PHYS.DUMP //SYSIN  DD  *
  DUMP DATASET(                            -
          INCLUDE(                          -
      RRP.ROCKET.SJHNCLIB                    -
      RRP.ROCKET.SJHNLOAD                    -
                  ))                        -
        CANCELERROR                          -
        OPT(4) ALLDATA(*) ALLEXCP            -
        INDDNAME(DASD1)                      -
        OUTDDNAME(                          -
                  OUTVOL1                    -
                )                          -
        TOL(ENQF)                            -
        WAIT(1,1)
/*                                                        

And my output:

ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'DUMP ' 
ADR109I (R/I)-RI01 (01), 2019.136 14:32:16 INITIAL SCAN OF USER CONTROL 
STATEMENTS COMPLETED ADR146I (R/I)-RI03 (15), OBSOLETE KEYWORD INDDNAME 
SPECIFIED. PHYSINDDNAME WILL BE USED ADR016I (001)-PRIME(01), RACF LOGGING 
OPTION IN EFFECT FOR THIS TASK ADR006I (001)-STEND(01), 2019.136 14:32:16 
EXECUTION BEGINS ADR329I (001)-DTDS (01), DATA SET DUMP OF VOLUME S10057 BEGINS 
ON TAPE A04491 SEQUENCE 0001 ADR329I (001)-DTDS (02), DATA SET DUMP OF VOLUME 
S10057 ENDS ON TAPE A04491 SEQUENCE 0001 ADR378I (001)-DTDS (01), THE FOLLOWING 
DATA SETS WERE SUCCESSFULLY PROCESSED FROM VOLUME S10057
                          RRP.ROCKET.SJHNCLIB
                          RRP.ROCKET.SJHNLOAD ADR006I (001)-STEND(02), 2019.136 
14:32:17 EXECUTION ENDS ADR013I (001)-CLTSK(01), 2019.136 14:32:17 TASK 
COMPLETED WITH RETURN CODE  ADR012I (SCH)-DSSU (01), 2019.136 14:32:17 
DFSMSDSS PROCESSING COMPLETE. HIGHEST RETURN CODE IS   

So, yes, DFDSS is OK dumping more than one physical dataset to a tape.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
John Dawes
Sent: Thursday, May 16, 2019 11:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: DFDSS QUESTION - PHYSICAL DATASET BACKUP

 Rex,I tried both INDDNAME & PHYSINDD as well.  I can confirm that both dsns 
are on the same volume.Maybe you can try a test to see if you can do a 
successful Physical backup of 2 dsns.I am curious if it works for you.  I am 
running V2R02.0
    On Thursday, 16 May 2019, 4:47:56 pm UTC, Pommier, Rex 
 wrote:  
 
 John,

Do you need to change your INDDNAME to PHYSINDD?  The 2.2 manual indicates that 
INDDNAME is used for full or track copying and PHYSINDD is used for datasets.  
Are both the datasets you're going after on the same volume?

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
John Dawes
Sent: Thursday, May 16, 2019 10:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: DFDSS QUESTION - PHYSICAL DATASET BACKUP

 I tried your suggestion but it didn't work:
ADR129E (001)-RI01 (01), KEYWORD '      ' IS IMPROPER 

    On Thursday, 16 May 2019, 3:13:43 pm UTC, Mike Schwab 
 wrote:  
 
 
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.adru000/r2298.htm

INCLUDE(data.set.one, -
                data.set.two)

Commas are REQUIRED.

On Thu, May 16, 2019 at 9:51 AM John Dawes 
<00ff0e22811f-dmarc-requ...@listserv.ua.edu> wrote:
>
> G'Day,
> I am encountering a problem performing a Physical dataset backup of 
> several dsn which are on a specific volume.  For some reason it doesn't work. 
> I receive the error message ADR129E (001)-RI01 (01), KEYWORD '      ' IS 
> IMPROPER Below is the job output and the JCL.  Can you spot my error?  Does 
> DFDSS support a phyisical backup of multiple dsns?
> ADR031I (SCH)-PRIME(01), TYPRUN=NORUN REQUESTED. TASKS WILL EXECUTE 
> INNORUN MODE DUMP INDDNAME(DASD1)OUTDDNAME(TAPE1)        -                    
>               DATASET(INCLUDE(HESP.IMS.PROD.MATRIX              -             
>                                  HESP.NETVIEW.PRF))          -                
>             TOL(ENQF)            -        OPT(4)ALLDATA(*) ALLEXCP ADR101I 
> (R/I)-RI01 (01), TASKID 0

Re: DFDSS copy to pre-allocated dsn

[Allan Staller]

Presuming this is an HFS, (and based on the supplied dsn) I believe you are 
correct.
If this is a mis-named ZFS, IIRC it can span volumes.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jackson, Rob
Sent: Thursday, May 16, 2019 6:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFDSS copy to pre-allocated dsn

I don't know for sure if OUTDD works exactly like OUTDY; I was wondering.  I 
used (no longer a DSS shop) OUTDY to list candidate volumes; COPY makes only 
one copy, whether it exists on one volume or is spread across multiple ones.  
Anyway, since this is non-SMS managed, it can be on only one volume--assuming 
it's really HFS.  I guess the same restriction would apply to ZFS.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mike Schwab
Sent: Thursday, May 16, 2019 7:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFDSS copy to pre-allocated dsn

[External Email]

So you are making 3 copies on 3 different OUTDDNAMES?
If it is one dataset on 3 volumes it would be one OUTDDNAME, right?

On Thu, May 16, 2019 at 4:51 PM Elaine Beal  wrote:
>
> I've found a lot of " it's " confusing comments on this topic and I am
> beleaguered- I am trying to copy a file to an existing, pre-allocated new 
> name.
> Seems that should be pretty straight forward... but having to specify
> rename to make a copy is anything but straight forward
>
> I'm getting ADR380E (001)-FDSCO(08) indicating REPLACEUNCONDITIONAL is
> not specified but I get this whether I specify it or not-
>
>
>   COPY DATASET(INCLUDE(SYS7.R30.V22.ROOT.HFS))  -
>   LOGINDDNAME(DASD1)  -
>   OUTDDNAME(DASD2,DASD3,DASD4)  -
>   RENAMEU((SYS7.R30.V22.ROOT.HFS,   -
>   SYS7.R30.V22.RSU.ROOT.HFS)) -
>   REPLACEUNCONDITIONAL   -
>   NULLSTORCLAS BYPASSACS(**) -
>   ALLDATA(*) ALLEXCP CANCELERROR -
>   SHARE -
>   WRITECHECK
>
> Thanks for any help-
> Elaine
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



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

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

Confidentiality notice:
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.


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

Re: [External] Re: Ancient DASD connectivity

[Ron Hawkins]

Rex,

I cannot find Alan's quoted passage, but I think it is a stretch to say " With 
the arrival of 2105s, the CU was inside the same cabinet as the drives and 
Logical CUs (LCUs) were born."

I'm fairly certain that EMC, STK, and HDS delivering this well before IBM could 
get the E10 and F20 out of the door.

I think it was more like last to market in IBM's case.

Ron


RON HAWKINS
Director, Ipsicsopt Pty Ltd (ACN: 627 705 971)
m+61 400029610| t: +1 4085625415 | f: +1 4087912585

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Pommier, Rex
Sent: Thursday, 16 May 2019 05:53
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [IBM-MAIN] [External] Re: Ancient DASD connectivity


It was sheer size of the componentry that drove this design.   I think the 3990 
was the last stand-alone disk controller.  With the arrival of 2105s, the CU 
was inside the same cabinet as the drives and Logical CUs (LCUs) were born.  
One big black box (literally).  Adding additional cabinets no longer affected 
the I/O configuration - just capacity.  


We don't hear much about them, but where did the 9340 subsystem fit in the 
timeline between 3990 and 2105? or the RAMAC2?  Both those devices had the 
controller built in the same frame as the disk spindles.  How about the RVA?  

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Alan Altmark
Sent: Wednesday, May 15, 2019 1:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: Ancient DASD connectivity

On Wed, 15 May 2019 14:59:00 +0200, R.S.  wrote:

>In the old days there was a Storage Control Unit, i.e. 3830 and disk 
>controller within disk cabinet, i.e. 3350-A2
>
>So, we have CPC-cable1-3830-cable2-3350A2controller-internal_cable3-disk.
>
>I'm trying to understand separation of duties between 3830 and 3350A2 
>controller.
>What was defined as CU - it was 3830 or controller within 3350 cabinet?
>Which cable was a channel (Bus&Tag)? I guess it is "cable1" connecting 
>CPC and 3830.
>
>Not to mention that some old reference manual's diagram shows yet 
>another box between CPC and 3830 SCU.

Depending on the year, you might find (rusty memory):

host
 - channel 0
 - channel 1
 - switch (2814/2914)
- channel 1
- Control unit 0 (bus & tag from channel/switch)
  - device 0 ("string header") (A-Unit)
  - device 1 (B unit)
  - device 2 (B unit)
  - device 3 (B unit)
- Control unit 1 (bus & tag) from CU 0
- repeat
 - channel 2
 - repeat

The A units handled the fan-out (signal and power) to dependent devices (B 
units) in the string and had the logic to talk to the channel.  The B units 
were just dumb slaves to the A unit.   The A units could only talk to B units 
of the same type since all the power and signaling was custom.  The interface 
between the CU and the A unit was generally such that a CU could handle strings 
of newer and older device types.   The number of A units required, the number 
of I/O devices included in an A unit, and the way B units were attached was 
generally model specific, so you would see variations on the above.  (Don't 
confuse with more modern UNIT=3390B to indicate a PAV to MVS!)   

It was sheer size of the componentry that drove this design.   I think the 3990 
was the last stand-alone disk controller.  With the arrival of 2105s, the CU 
was inside the same cabinet as the drives and Logical CUs (LCUs) were born.  
One big black box (literally).  Adding additional cabinets no longer affected 
the I/O configuration - just capacity.  

We still have switches, of course, but they're no longer pull-turn-push.  :-) 

Alan Altmark
IBM Systems Lab Services

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


The information contained in this message is confidential, protected from 
disclosure and may be legally privileged.  If the reader of this message is not 
the intended recipient or an employee or agent responsible for delivering this 
message to the intended recipient, you are hereby notified that any disclosure, 
distribution, copying, or any action taken or action omitted in reliance on it, 
is strictly prohibited and may be unlawful.  If you have received this 
communication in error, please notify us immediately by replying to this 
message and destroy the material in its entirety, whether in electronic or hard 
copy format.  Thank you.


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

Re: [External] Re: DFDSS QUESTION - PHYSICAL DATASET BACKUP

[John Dawes]

 Rex,
I used your jcl and it worked.  I was successful with and without the NORUN 
parm.  
A massive thanks. 
On Thursday, 16 May 2019, 7:35:43 pm UTC, Pommier, Rex 
 wrote:  
 
 John,

I'm running 2.2 as well.  I was able to run it successfully copying 2 datasets 
to a tape.  And just for kicks and giggles, I removed the TYPRUN parm and it 
dumped the 2 datasets to a single tape. 

Here's my JCL/parms:

//STEP005 EXEC  PGM=ADRDSSU,REGION=0M,PARM='TYPRUN=NORUN'  
//SYSPRINT DD  SYSOUT=*                                    
//DASD1    DD  UNIT=3390,VOL=SER=S10057,DISP=SHR          
//OUTVOL1  DD  UNIT=VTS,DISP=(,CATLG),                    
//    DSN=RRP.PHYS.DUMP                                    
//SYSIN  DD  *                                            
  DUMP DATASET(                            -            
          INCLUDE(                          -            
      RRP.ROCKET.SJHNCLIB                    -            
      RRP.ROCKET.SJHNLOAD                    -            
                  ))                        -            
        CANCELERROR                          -            
        OPT(4) ALLDATA(*) ALLEXCP            -            
        INDDNAME(DASD1)                      -            
        OUTDDNAME(                          -            
                  OUTVOL1                    -            
                )                          -            
        TOL(ENQF)                            -            
        WAIT(1,1)                                          
/*                                                        

And my output:

ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'DUMP '        
                      
ADR109I (R/I)-RI01 (01), 2019.136 14:32:16 INITIAL SCAN OF USER CONTROL 
STATEMENTS COMPLETED          
ADR146I (R/I)-RI03 (15), OBSOLETE KEYWORD INDDNAME SPECIFIED. PHYSINDDNAME WILL 
BE USED                
ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK            
                      
ADR006I (001)-STEND(01), 2019.136 14:32:16 EXECUTION BEGINS                     
                       
ADR329I (001)-DTDS (01), DATA SET DUMP OF VOLUME S10057 BEGINS ON TAPE A04491 
SEQUENCE 0001            
ADR329I (001)-DTDS (02), DATA SET DUMP OF VOLUME S10057 ENDS ON TAPE A04491 
SEQUENCE 0001              
ADR378I (001)-DTDS (01), THE FOLLOWING DATA SETS WERE SUCCESSFULLY PROCESSED 
FROM VOLUME S10057        
                          RRP.ROCKET.SJHNCLIB                                   
                       
                          RRP.ROCKET.SJHNLOAD                                   
                       
ADR006I (001)-STEND(02), 2019.136 14:32:17 EXECUTION ENDS                       
                       
ADR013I (001)-CLTSK(01), 2019.136 14:32:17 TASK COMPLETED WITH RETURN CODE  
                       
ADR012I (SCH)-DSSU (01), 2019.136 14:32:17 DFSMSDSS PROCESSING COMPLETE. 
HIGHEST RETURN CODE IS   

So, yes, DFDSS is OK dumping more than one physical dataset to a tape.

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
John Dawes
Sent: Thursday, May 16, 2019 11:55 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: [External] Re: DFDSS QUESTION - PHYSICAL DATASET BACKUP

 Rex,I tried both INDDNAME & PHYSINDD as well.  I can confirm that both dsns 
are on the same volume.Maybe you can try a test to see if you can do a 
successful Physical backup of 2 dsns.I am curious if it works for you.  I am 
running V2R02.0 
    On Thursday, 16 May 2019, 4:47:56 pm UTC, Pommier, Rex 
 wrote:  
 
 John,

Do you need to change your INDDNAME to PHYSINDD?  The 2.2 manual indicates that 
INDDNAME is used for full or track copying and PHYSINDD is used for datasets.  
Are both the datasets you're going after on the same volume?

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
John Dawes
Sent: Thursday, May 16, 2019 10:21 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: DFDSS QUESTION - PHYSICAL DATASET BACKUP

 I tried your suggestion but it didn't work:
ADR129E (001)-RI01 (01), KEYWORD '      ' IS IMPROPER 

    On Thursday, 16 May 2019, 3:13:43 pm UTC, Mike Schwab 
 wrote:  
 
 
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.adru000/r2298.htm

INCLUDE(data.set.one, -
                data.set.two)

Commas are REQUIRED.

On Thu, May 16, 2019 at 9:51 AM John Dawes 
<00ff0e22811f-dmarc-requ...@listserv.ua.edu> wrote:
>
> G'Day,
> I am encountering a problem performing a Physical dataset backup of 
> several dsn which are on a specific volume.  For some reason it doesn't work. 
> I receive the error message ADR129E (001)-RI01 (01), KEYWORD '      ' IS 
> IMPROPER Below is the job output and the JCL.  Can you spot my error?  Does 
> DFDSS support a phyisical backup of multiple dsns?
> ADR031I (SCH)-PRIME(01), TYPRUN=NORUN REQUESTED. TASKS WILL EXECUTE 
> INNORUN MODE DUMP INDDNAME(DASD1)OUTDDNAME(TAPE1)        -    

Re: DFDSS QUESTION - PHYSICAL DATASET BACKUP

[John Dawes]

 For some reason the output seems to get misaligned.  Here it is again.
ADR031I (SCH)-PRIME(01), TYPRUN=NORUN REQUESTED. TASKS WILL EXECUTE IN NORUN 
MOD DUMP INDDNAME(DASD1) OUTDDNAME(TAPE1)        -                              
         DATASET(INCLUDE(HESP.IMS.PROD.MATRIX     -                             
                                   HESP.NETVIEW.PRF))          -                
              TOL(ENQF)                          -                              
              OPT(4) ALLDATA(*) ALLEXCP                                         
        ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'DUMP 
'        ADR109I (R/I)-RI01 (01), 2019.136 11:19:22 INITIAL SCAN OF USER 
CONTROL STATEMENADR129E (001)-RI01 (01), KEYWORD '      ' IS IMPROPER           
                ADR131E (001)-RI03 (01), ABOVE TEXT BYPASSED UNTIL NEXT COMMAND 
                ADR017E (001)-CLTSK(01), 2019.136 11:19:22 TASK NOT SCHEDULED 
DUE TO ERROR. TASKADR012I (SCH)-DSSU (01), 2019.136 11:19:22 DFSMSDSS 
PROCESSING COMPLETE. HIGHEST                         SYNTAX                     
                            

On Thursday, 16 May 2019, 6:10:06 pm UTC, Jousma, David 
<01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:  
 
 One other tidbit.  The SYSIN data, and all of the lines must be contained 
between columns 2-72.  Not column 1.  It would be really helpful if you could 
post the job with the correct formatting.  Whatever is messing it up appears to 
be removing spaces between some of your keywords.

_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
John Dawes
Sent: Thursday, May 16, 2019 11:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFDSS QUESTION - PHYSICAL DATASET BACKUP

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

 John,The - or , are both acceptable.  I use the - all the time and never had a 
problem.
    On Thursday, 16 May 2019, 2:59:16 pm UTC, John McKown 
 wrote:  
 
 It's hard for me to read the reformatted text. But you need a comma between 
the two DSNs in the INCLUDE list. I don't see any comma.

On Thu, May 16, 2019 at 9:51 AM John Dawes < 
00ff0e22811f-dmarc-requ...@listserv.ua.edu> wrote:

> G'Day,
> I am encountering a problem performing a Physical dataset backup of  
>several dsn which are on a specific volume.  For some reason it doesn't  
>work. I receive the error message ADR129E (001)-RI01 (01), KEYWORD '      '
> IS IMPROPER
> Below is the job output and the JCL.  Can you spot my error?  Does 
>DFDSS  support a phyisical backup of multiple dsns?
> ADR031I (SCH)-PRIME(01), TYPRUN=NORUN REQUESTED. TASKS WILL EXECUTE  
>INNORUN MODE DUMP INDDNAME(DASD1)OUTDDNAME(TAPE1)        -
>                DATASET(INCLUDE(HESP.IMS.PROD.MATRIX              -
>                                      HESP.NETVIEW.PRF))          -
>                      TOL(ENQF)            -        OPT(4)ALLDATA(*)  
>ALLEXCP  ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO 
>COMMAND  'DUMP'
>
> ADR109I (R/I)-RI01 (01), 2019.136 10:21:19 INITIAL SCAN OF USER 
> CONTROLSTATEMENT
>
> ADR129E (001)-RI01 (01), KEYWORD '    ' IS IMPROPER
>
> ADR131E (001)-RI03 (01), ABOVE TEXT BYPASSED UNTIL NEXT COMMAND
>
> ADR017E (001)-CLTSK(01), 2019.136 10:21:19 TASK NOT SCHEDULED DUE TOERROR.
> TASK
>
> /*
>
> //NORUN  EXECPGM=ADRDSSU,REGION=4096K,PARM='TYPRUN=NORUN'
>
> //*STEP1  EXECPGM=ADRDSSU,REGION=4M,TIME=1440,PARM='UTILMSG=YES'
>
> //DASD1    DD  UNIT=SYSDA,VOL=SER=PROD03,DISP=SHR
>
> //TAPE1    DD  DSN=MVS.PHYSICAL.BKUP.PROD03,
>
> //            DISP=(,CATLG,DELETE),UNIT=3490,VOL=(,,,99)
>
> //SYSPRINT DD  SYSOUT=*
>
> //SYSMAP  DD SYSOUT=*
>
> //SYSIN    DD  *
>  DUMP INDDNAME(DASD1)OUTDDNAME(TAPE1)        -
>  DATASET(INCLUDE(HESP.IMS.PROD.MATRIX        -
> HESP.NETVIEW.PRF))            -  TOL(ENQF)                          -
>    OPT(4) ALLDATA(*) ALLEXCP
> /*
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


--
This is clearly another case of too many mad scientists, and not enough 
hunchbacks.


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
**CAUTION EXTERNAL 

Re: DFDSS QUESTION - PHYSICAL DATASET BACKUP

[John Dawes]

 David,I rechecked the job.  The DUMP command is in column 2, the 
DATASET(INCLUDE starts at col  7.
On Thursday, 16 May 2019, 6:13:10 pm UTC, Jousma, David 
<01a0403c5dc1-dmarc-requ...@listserv.ua.edu> wrote:  
 
 This would be correct syntax.  Comma's are optional, dash is not.  By your 
other post where you said it worked with one dataset, it almost looks like your 
HESP. Dataset name starts in column 1? 

//SYSIN    DD  *
  DUMP INDDNAME(DASD1) OUTDDNAME(TAPE1)        -
    DATASET(INCLUDE(HESP.IMS.PROD.MATRIX        -
                HESP.NETVIEW.PRF))            -  
                TOL(ENQF)                          -
                OPT(4) ALLDATA(*) ALLEXCP
/*

_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
John Dawes
Sent: Thursday, May 16, 2019 11:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFDSS QUESTION - PHYSICAL DATASET BACKUP

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

 John,The - or , are both acceptable.  I use the - all the time and never had a 
problem.
    On Thursday, 16 May 2019, 2:59:16 pm UTC, John McKown 
 wrote:  
 
 It's hard for me to read the reformatted text. But you need a comma between 
the two DSNs in the INCLUDE list. I don't see any comma.

On Thu, May 16, 2019 at 9:51 AM John Dawes < 
00ff0e22811f-dmarc-requ...@listserv.ua.edu> wrote:

> G'Day,
> I am encountering a problem performing a Physical dataset backup of  
>several dsn which are on a specific volume.  For some reason it doesn't  
>work. I receive the error message ADR129E (001)-RI01 (01), KEYWORD '      '
> IS IMPROPER
> Below is the job output and the JCL.  Can you spot my error?  Does 
>DFDSS  support a phyisical backup of multiple dsns?
> ADR031I (SCH)-PRIME(01), TYPRUN=NORUN REQUESTED. TASKS WILL EXECUTE  
>INNORUN MODE DUMP INDDNAME(DASD1)OUTDDNAME(TAPE1)        -
>                DATASET(INCLUDE(HESP.IMS.PROD.MATRIX              -
>                                      HESP.NETVIEW.PRF))          -
>                      TOL(ENQF)            -        OPT(4)ALLDATA(*)  
>ALLEXCP  ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO 
>COMMAND  'DUMP'
>
> ADR109I (R/I)-RI01 (01), 2019.136 10:21:19 INITIAL SCAN OF USER 
> CONTROLSTATEMENT
>
> ADR129E (001)-RI01 (01), KEYWORD '    ' IS IMPROPER
>
> ADR131E (001)-RI03 (01), ABOVE TEXT BYPASSED UNTIL NEXT COMMAND
>
> ADR017E (001)-CLTSK(01), 2019.136 10:21:19 TASK NOT SCHEDULED DUE TOERROR.
> TASK
>
> /*
>
> //NORUN  EXECPGM=ADRDSSU,REGION=4096K,PARM='TYPRUN=NORUN'
>
> //*STEP1  EXECPGM=ADRDSSU,REGION=4M,TIME=1440,PARM='UTILMSG=YES'
>
> //DASD1    DD  UNIT=SYSDA,VOL=SER=PROD03,DISP=SHR
>
> //TAPE1    DD  DSN=MVS.PHYSICAL.BKUP.PROD03,
>
> //            DISP=(,CATLG,DELETE),UNIT=3490,VOL=(,,,99)
>
> //SYSPRINT DD  SYSOUT=*
>
> //SYSMAP  DD SYSOUT=*
>
> //SYSIN    DD  *
>  DUMP INDDNAME(DASD1)OUTDDNAME(TAPE1)        -
>  DATASET(INCLUDE(HESP.IMS.PROD.MATRIX        -
> HESP.NETVIEW.PRF))            -  TOL(ENQF)                          -
>    OPT(4) ALLDATA(*) ALLEXCP
> /*
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


--
This is clearly another case of too many mad scientists, and not enough 
hunchbacks.


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
**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

This e-mail transmission contains information that is confidential and may be 
privileged.  It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.


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

Re: DFDSS QUESTION - PHYSICAL DATASET BACKUP

[John Dawes]

 Rex,
I am glad that it works for you and not me.  Could you post the output of the 
job?  Maybe I will see something that I may be missing?
Thanks.
On Thursday, 16 May 2019, 7:45:36 pm UTC, Pommier, Rex 
 wrote:  
 
 I just changed my SYSIN to look as close to identical to yours as I can see, 
given the formatting problems you're having, and it still worked.  Regarding 
the "column 1" question David had, I just tried it, and all DFDSS did was 
ignore the first character of the dataset name and tell me it couldn't find 
"RP.ROCKET.SJHNLOAD" and continue on its merry way.

  DUMP  INDDNAME(DASD1) OUTDDNAME(OUTVOL1) -      
    DATASET(INCLUDE(RRP.ROCKET.SJHNCLIB        -  
    RRP.ROCKET.SJHNLOAD))      -                  
        TOL(ENQF)                            -    
        OPT(4) ALLDATA(*) ALLEXCP                  

Rex

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Jousma, David
Sent: Thursday, May 16, 2019 1:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [External] Re: DFDSS QUESTION - PHYSICAL DATASET BACKUP

This would be correct syntax.  Comma's are optional, dash is not.  By your 
other post where you said it worked with one dataset, it almost looks like your 
HESP. Dataset name starts in column 1? 

//SYSIN    DD  *
  DUMP INDDNAME(DASD1) OUTDDNAME(TAPE1)        -
    DATASET(INCLUDE(HESP.IMS.PROD.MATRIX        -
                HESP.NETVIEW.PRF))            -  
                TOL(ENQF)                          -
                OPT(4) ALLDATA(*) ALLEXCP
/*

_
Dave Jousma
AVP | Manager, Systems Engineering  

Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546
616.653.8429  |  fax: 616.653.2717



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
John Dawes
Sent: Thursday, May 16, 2019 11:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFDSS QUESTION - PHYSICAL DATASET BACKUP

**CAUTION EXTERNAL EMAIL**

**DO NOT open attachments or click on links from unknown senders or unexpected 
emails**

 John,The - or , are both acceptable.  I use the - all the time and never had a 
problem.
    On Thursday, 16 May 2019, 2:59:16 pm UTC, John McKown 
 wrote:  
 
 It's hard for me to read the reformatted text. But you need a comma between 
the two DSNs in the INCLUDE list. I don't see any comma.

On Thu, May 16, 2019 at 9:51 AM John Dawes < 
00ff0e22811f-dmarc-requ...@listserv.ua.edu> wrote:

> G'Day,
> I am encountering a problem performing a Physical dataset backup of 
>several dsn which are on a specific volume.  For some reason it doesn't 
>work. I receive the error message ADR129E (001)-RI01 (01), KEYWORD '      '
> IS IMPROPER
> Below is the job output and the JCL.  Can you spot my error?  Does 
>DFDSS  support a phyisical backup of multiple dsns?
> ADR031I (SCH)-PRIME(01), TYPRUN=NORUN REQUESTED. TASKS WILL EXECUTE 
>INNORUN MODE DUMP INDDNAME(DASD1)OUTDDNAME(TAPE1)        -
>                DATASET(INCLUDE(HESP.IMS.PROD.MATRIX              -
>                                      HESP.NETVIEW.PRF))          -
>                      TOL(ENQF)            -        OPT(4)ALLDATA(*) 
>ALLEXCP  ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO 
>COMMAND  'DUMP'
>
> ADR109I (R/I)-RI01 (01), 2019.136 10:21:19 INITIAL SCAN OF USER 
> CONTROLSTATEMENT
>
> ADR129E (001)-RI01 (01), KEYWORD '    ' IS IMPROPER
>
> ADR131E (001)-RI03 (01), ABOVE TEXT BYPASSED UNTIL NEXT COMMAND
>
> ADR017E (001)-CLTSK(01), 2019.136 10:21:19 TASK NOT SCHEDULED DUE TOERROR.
> TASK
>
> /*
>
> //NORUN  EXECPGM=ADRDSSU,REGION=4096K,PARM='TYPRUN=NORUN'
>
> //*STEP1  EXECPGM=ADRDSSU,REGION=4M,TIME=1440,PARM='UTILMSG=YES'
>
> //DASD1    DD  UNIT=SYSDA,VOL=SER=PROD03,DISP=SHR
>
> //TAPE1    DD  DSN=MVS.PHYSICAL.BKUP.PROD03,
>
> //            DISP=(,CATLG,DELETE),UNIT=3490,VOL=(,,,99)
>
> //SYSPRINT DD  SYSOUT=*
>
> //SYSMAP  DD SYSOUT=*
>
> //SYSIN    DD  *
>  DUMP INDDNAME(DASD1)OUTDDNAME(TAPE1)        -
>  DATASET(INCLUDE(HESP.IMS.PROD.MATRIX        -
> HESP.NETVIEW.PRF))            -  TOL(ENQF)                          -
>    OPT(4) ALLDATA(*) ALLEXCP
> /*
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


--
This is clearly another case of too many mad scientists, and not enough 
hunchbacks.


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 **CAUTION EXTERNAL 
EMAIL**

Re: DFDSS copy to pre-allocated dsn

[willie bunter]

 Just to add my 2 cents you will need to add parm REPLACEU  if the target dsn 
exists and cataloged.
On Friday, May 17, 2019, 9:59:24 a.m. UTC, Richards, Robert B. 
<01c91f408b9e-dmarc-requ...@listserv.ua.edu> wrote:  
 
 Try added SELECTMULTI(ANY)

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jackson, Rob
Sent: Thursday, May 16, 2019 7:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFDSS copy to pre-allocated dsn

I don't know for sure if OUTDD works exactly like OUTDY; I was wondering.  I 
used (no longer a DSS shop) OUTDY to list candidate volumes; COPY makes only 
one copy, whether it exists on one volume or is spread across multiple ones.  
Anyway, since this is non-SMS managed, it can be on only one volume--assuming 
it's really HFS.  I guess the same restriction would apply to ZFS.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mike Schwab
Sent: Thursday, May 16, 2019 7:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFDSS copy to pre-allocated dsn

[External Email]

So you are making 3 copies on 3 different OUTDDNAMES?
If it is one dataset on 3 volumes it would be one OUTDDNAME, right?

On Thu, May 16, 2019 at 4:51 PM Elaine Beal  wrote:
>
> I've found a lot of " it's " confusing comments on this topic and I am 
> beleaguered- I am trying to copy a file to an existing, pre-allocated new 
> name.
> Seems that should be pretty straight forward... but having to specify 
> rename to make a copy is anything but straight forward
>
> I'm getting ADR380E (001)-FDSCO(08) indicating REPLACEUNCONDITIONAL is 
> not specified but I get this whether I specify it or not-
>
>
>  COPY DATASET(INCLUDE(SYS7.R30.V22.ROOT.HFS))  -
>      LOGINDDNAME(DASD1)  -
>      OUTDDNAME(DASD2,DASD3,DASD4)  -
>      RENAMEU((SYS7.R30.V22.ROOT.HFS,  -
>      SYS7.R30.V22.RSU.ROOT.HFS)) -
>      REPLACEUNCONDITIONAL  -
>      NULLSTORCLAS BYPASSACS(**) -
>      ALLDATA(*) ALLEXCP CANCELERROR -
>      SHARE -
>      WRITECHECK
>
> Thanks for any help-
> Elaine
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



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

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

Confidentiality notice: 
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.


--
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: DFDSS copy to pre-allocated dsn

[Richards, Robert B.]

Try added SELECTMULTI(ANY)

Bob

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jackson, Rob
Sent: Thursday, May 16, 2019 7:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFDSS copy to pre-allocated dsn

I don't know for sure if OUTDD works exactly like OUTDY; I was wondering.  I 
used (no longer a DSS shop) OUTDY to list candidate volumes; COPY makes only 
one copy, whether it exists on one volume or is spread across multiple ones.  
Anyway, since this is non-SMS managed, it can be on only one volume--assuming 
it's really HFS.  I guess the same restriction would apply to ZFS.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Mike Schwab
Sent: Thursday, May 16, 2019 7:13 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: DFDSS copy to pre-allocated dsn

[External Email]

So you are making 3 copies on 3 different OUTDDNAMES?
If it is one dataset on 3 volumes it would be one OUTDDNAME, right?

On Thu, May 16, 2019 at 4:51 PM Elaine Beal  wrote:
>
> I've found a lot of " it's " confusing comments on this topic and I am 
> beleaguered- I am trying to copy a file to an existing, pre-allocated new 
> name.
> Seems that should be pretty straight forward... but having to specify 
> rename to make a copy is anything but straight forward
>
> I'm getting ADR380E (001)-FDSCO(08) indicating REPLACEUNCONDITIONAL is 
> not specified but I get this whether I specify it or not-
>
>
>   COPY DATASET(INCLUDE(SYS7.R30.V22.ROOT.HFS))  -
>   LOGINDDNAME(DASD1)  -
>   OUTDDNAME(DASD2,DASD3,DASD4)  -
>   RENAMEU((SYS7.R30.V22.ROOT.HFS,   -
>   SYS7.R30.V22.RSU.ROOT.HFS)) -
>   REPLACEUNCONDITIONAL   -
>   NULLSTORCLAS BYPASSACS(**) -
>   ALLDATA(*) ALLEXCP CANCELERROR -
>   SHARE -
>   WRITECHECK
>
> Thanks for any help-
> Elaine
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



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

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

Confidentiality notice: 
This e-mail message, including any attachments, may contain legally privileged 
and/or confidential information. If you are not the intended recipient(s), or 
the employee or agent responsible for delivery of this message to the intended 
recipient(s), you are hereby notified that any dissemination, distribution, or 
copying of this e-mail message is strictly prohibited. If you have received 
this message in error, please immediately notify the sender and delete this 
e-mail message from your computer.


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