Re: Mainframe environment on AWS

2019-10-09 Thread ITschak Mugzach 
I think zPDT if for IBM partner in development and zPD is for clients for
development only. ADCD is the installed operating systems and products
running on zPDT or zPD

ITschak

On Thu, Oct 10, 2019 at 8:37 AM Matt Hogstrom  wrote:

> ZPDT is the emulator that runs on x86 emulating z instructions, I/O, etc.
> ZD is the collection of z/Software and tools to create those x86 based
> z/OS instances.
>
> Matt Hogstrom
> m...@hogstrom.org
> +1-919-656-0564
> PGP Key: 0x90ECB270
> Facebook   LinkedIn <
> https://linkedin/in/mhogstrom>  Twitter 
>
> “It may be cognitive, but, it ain’t intuitive."
> — Hogstrom
>
> > On Oct 10, 2019, at 11:06 AM, Laurence Chiu  wrote:
> >
> > I'm new to z/OS in X86. What's the difference between zPDT and ZD?  The
> > documentation I could find is not clear.
> >
> > Looks like something that might be useful in the shop where I'm currently
> > working.
> >
> > On Thu, Oct 10, 2019, 9:01 AM Sebastian Welton 
> wrote:
> >
> >> I've run both zPDT and ZD succcessfully in both AWS and Azure. In fact
> >> ZD, if not PE (Personal Edition) only works with a remote license
> server
> >> although all versions of zPDT and ZD will also work with a remote
> license
> >> server. ZD EE (Enterprise Edition) does not allow for the use of a
> >> hardware token.
> >>
> >> Sebastian.
> >>
> >> --
> >> 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
>


-- 
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Contiguous Monitoring
for Legacy **|  *

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

Re: Mainframe environment on AWS

2019-10-09 Thread Matt Hogstrom 
ZPDT is the emulator that runs on x86 emulating z instructions, I/O, etc.  ZD 
is the collection of z/Software and tools to create those x86 based z/OS 
instances.

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 Oct 10, 2019, at 11:06 AM, Laurence Chiu  wrote:
> 
> I'm new to z/OS in X86. What's the difference between zPDT and ZD?  The
> documentation I could find is not clear.
> 
> Looks like something that might be useful in the shop where I'm currently
> working.
> 
> On Thu, Oct 10, 2019, 9:01 AM Sebastian Welton  wrote:
> 
>> I've run both zPDT and ZD succcessfully in both AWS and Azure. In fact
>> ZD, if not PE (Personal Edition) only works with a remote license server
>> although all versions of zPDT and ZD will also work with a remote license
>> server. ZD EE (Enterprise Edition) does not allow for the use of a
>> hardware token.
>> 
>> Sebastian.
>> 
>> --
>> 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: Mainframe environment on AWS

2019-10-09 Thread Laurence Chiu 
I'm new to z/OS in X86. What's the difference between zPDT and ZD?  The
documentation I could find is not clear.

Looks like something that might be useful in the shop where I'm currently
working.

On Thu, Oct 10, 2019, 9:01 AM Sebastian Welton  wrote:

> I've run both zPDT and ZD succcessfully in both AWS and Azure. In fact
> ZD, if not PE (Personal Edition) only works with a remote license server
> although all versions of zPDT and ZD will also work with a remote license
> server. ZD EE (Enterprise Edition) does not allow for the use of a
> hardware token.
>
> Sebastian.
>
> --
> 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: Mainframe environment on AWS

2019-10-09 Thread Sebastian Welton 
I've run both zPDT and ZD succcessfully in both AWS and Azure. In fact ZD, 
if not PE (Personal Edition) only works with a remote license server although 
all versions of zPDT and ZD will also work with a remote license server. ZD 
EE (Enterprise Edition) does not allow for the use of a hardware token.

Sebastian.

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

Re: DR Sysplex Procedure

2019-10-09 Thread Elaine Beal 
Kees, thank you. I see that would not work and it would be better to have both 
systems down and IPL one at a time.

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

DFSMS Continuous Delivery

2019-10-09 Thread Glenn Wilcock 
Two recent z/OS DFSMS Continuous Delivery projects:  
  - OA57454 Added DELETE (Archive) capability to HSM File Level Backup Support 
(base support in OA52703)
  - OA57173 Added initial support for FlashCopy to Global Mirror Primaries
 
(https://www.ibm.com/developerworks/community/blogs/e0c474f8-3aad-4f01-8bca-f2c12b576ac9/entry/FlashCopy_onto_Global_Mirror_Primaries?lang=en)

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

Re: DR Sysplex Procedure

2019-10-09 Thread Vernooij, Kees (ITOP NM) - KLM 
"Do both LPARs need to be down (not desirable) before IPLing either of them 
with the new CF and XCF?"

I would try to test the real situation as much as possible.

Besides, I think it will not work. LPAR's don't join each other, they join a 
Sysplex. After ipling one system with the new definitions, it runs from 
different Couple datasets and is a Sysplex of its own, but with XCF connections 
to the other LPAR that runs from the old Couple Datasets, so in the old 
Sysplex. This seems asking for unexpected problems.

Kees

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Elaine Beal
> Sent: 09 October, 2019 16:17
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: DR Sysplex Procedure
> 
> We are planning to test a remote copy sysplex environment and I would like
> to test it in our home DEV environment
> PROD data will not be accessible during the DR test so PROD sysplex should
> not be affected
> 
> To test in DEV I have defined a new XCF and CFRM since I will need to do
> that for DR
> to account for the different CPU serial number.
> In DEV I have not changed the serial number for the test, I'm just trying
> out the procedure.
> 
> At DR we will IPL the sysplex LPARs one at a time so I'm not concerned
> about the order, the files or the join.
> 
> I'm not sure about the order for DEV.
> 
> Do both LPARs need to be down (not desirable) before IPLing either of them
> with the new CF and XCF?
> Or is one at a time okay since one is removed from the sysplex at shutdown
> and just won't be able to join the current one at IPL
> 
> I am not planning to create new LOGR and WLM files at DR but I will need
> to create them for the test as they are shared.
> 
> so, the plan is-
> 
> 1. create new XCF and CFRM DR files (new LOGR and WLM for testing DEV at
> home but not at DR)
> 
> 2. update COUPLXX with new files
> 
> 3. shutdown LPAR1
> 
> 4. IPL LPAR1 with new COUPLxx and respond toinitialize new files
> 
> 5. Shutdown LPAR2 and IPL with new COUPLxx (no initialize)
> 
> Thanks,
> Elaine
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286



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

DR Sysplex Procedure

2019-10-09 Thread Elaine Beal 
We are planning to test a remote copy sysplex environment and I would like to 
test it in our home DEV environment
PROD data will not be accessible during the DR test so PROD sysplex should not 
be affected

To test in DEV I have defined a new XCF and CFRM since I will need to do that 
for DR 
to account for the different CPU serial number.
In DEV I have not changed the serial number for the test, I'm just trying out 
the procedure.

At DR we will IPL the sysplex LPARs one at a time so I'm not concerned about 
the order, the files or the join.

I'm not sure about the order for DEV.

Do both LPARs need to be down (not desirable) before IPLing either of them with 
the new CF and XCF?
Or is one at a time okay since one is removed from the sysplex at shutdown and 
just won't be able to join the current one at IPL

I am not planning to create new LOGR and WLM files at DR but I will need to 
create them for the test as they are shared.

so, the plan is-

1. create new XCF and CFRM DR files (new LOGR and WLM for testing DEV at home 
but not at DR)

2. update COUPLXX with new files

3. shutdown LPAR1

4. IPL LPAR1 with new COUPLxx and respond toinitialize new files

5. Shutdown LPAR2 and IPL with new COUPLxx (no initialize)

Thanks,
Elaine

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

Re: PDS Member updating via COBOL Program

2019-10-09 Thread S B 
 Andy 

Be aware of thePDSE solution – if your shop is like mine – Shared DASD between 
two LPARs andnot SYSPlex – PDSE will be your nightmare as it is mine currently 
and it willbe even more when  Enterprise COBOL V4.2goes out of support on 
09/30/2021. Going SYSPlex in our setup is doable but willtake some times – “the 
time we do not have” – good luck 
 Shahnaz 

On Tuesday, October 8, 2019, 06:51:31 PM EDT, Pesce, Andy 
 wrote:  
 
 I am looking for an explanation and this may be one of those "unpredictable 
results" may occur.

I have "JOBA" that executes a COBOL program to update a particular member in a 
PDS.  Within the program, it calls an internal utility that someone
wrote years ago that puts an enqueue on the dataset and its member that it is 
updating.  The dd associated with the parmlib uses DISP=SHR.

I have "JOBB" that executes a COBOL program to do the same thing, but it is a 
different member within the same dataset as "JOBA".    It is coded
to open the dataset as I/O.  After it reads the member, it then does a REWRITE. 
   It doesn't follow the rules as above and use the internal utility.
The dd associated with the parmlib also uses DISP=SHR.

Here is the issue.  Occasionally the member in "JOBA" is becoming "empty", 
while the member in JOBB is always OK.    I have looked at SMF
records and I see these jobs run at the same time.  And it is usually the same 
down to the hundreds of seconds.

My suggestion was that JOBB needs to be fixed to use the "enqueue and dequeue" 
utility, since it is using DISP-SHR.  This parmlib is
used heavily and extensively by applications, and no way to get it DISP=OLD.  
Any thoughts or explanation would truly be 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