Reading MCDS ML2 Tape on a different Lpar? Possible?

[fred glenlake]

Hello Listers,

I have a small remote site that we are upgrading the physical tape library to a 
virtual TS7700 library.  All went well until the old library had a serious 
hardware error.   My leadership has decided not to spend the money to repair 
the old failed library (of course now out of warranty and maintenance).   
However, I still have one more ML2 tape worth of data to migrate to the new 
library.

If we bring the ML2 tape back to our main site would it be possible to read the 
ML2 tape to extract the data off of it?   The only way I can think of is to 
also bring copies of all the CDS's and Journal from the remote site, restore 
those CDS's (MCDS, BCDS, OCDS) and Journal.  Then bring down the "real" DFHSM 
and bring up the "Remote" DFHSM to be able to recall the data off of the ML2 
tape.

Unfortunately running the "hsend list dsname both" commands on the ML2 datasets 
shows No BCDS records so I cannot just recover the ML2 datasets from BCDS 
copies.

Any suggestions would be welcomed.

Thanks,

Fred G.

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

Unable to delete uncataloged migrated datasets

[fred glenlake]

Hi List,

I recently inherited DFHSM responsibilities at my account, previous person 
decided to take the money and run towards retirement.   Just to see the lay of 
the land I ran an HSM AUDIT and it reported errors on a number of migrated 
datasets on both ML1 DASD and ML2 Tape.   The Audit reported showed ERR 03 
errors such as:

ERR or Userhlq.system.cntl NOT CATALOGED, HAS MIGRATION COPY +
DFHSM.HHMIG.T290510.Userhlq.system.B2021

I tried deleting the dataset using HDELETE and HSEND DELETE commands, did not 
seem to work.   I also tried IDCAMS DELETE but did not work.   I found a hit 
"https://bit.listserv.ibm-main.narkive.com/VxAz3kU0/dfhsm-uncatalog-migrated-dataset-how-to-fix";
 from many years ago that had a list of commands to do this.   I followed the 
instructions and the entry in DFHSM still exists.
DFHSM Uncatalog Migrated dataset - How to 
Fix
Kenneth, 1) HSEND FIXCDS D dsn - will give you listing of the d record. You 
will see the ML1 volume(+000) and the funny name(+009C). 2) Do an ISPF 3.4 for 
the ML1 volume found in 1
bit.listserv.ibm-main.narkive.com
1) HSEND FIXCDS D dsn - will give you listing of the d record. You will
see the ML1 volume(+000) and the funny name(+009C).
2) Do an ISPF 3.4 for the ML1 volume found in 1
3) Find the "funny" dataset name from 1
4) On the command line issue a delete of the dataset
5) Again on the command line issue HSEND FIXCDS A / DELETE
6) Issue HSEND FIXCDS D DSN DELETE using dsn from 1

I am more than happy to continue with RTFM's but thus far nothing that 
addresses this situation.

Any suggestions, recommendations would be greatly appreciated.

Many thanks,

Fred G.




Sent from Outlook

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

Courses for Storage Admin Newbies

[fred glenlake]

Hi List-ers,

Would any of you be able to recommend courses for newbie Storage 
Administrators??   The shop is mostly IBM products, very few if any ISV 
products.   DFDSS is used for backups, restores.   DFSMS is installed but 
settings seem to be more minimal in nature with management classes settings set 
to NOLIMIT for most management classes.   DFHSM is installed but not really 
doing anything since the management classes tell it not to do anything.   The 
previous Storage Admin retired (good for him) but he took most of the working 
knowledge about the shop with him.   I was brought in to help train up some 
newbie resources to be Storage Admins.   They have expressed an interest in 
attending more formal courses along with the one-on-one training I am 
providing.   IBM has Tech U, SHARE is also usually really good however both of 
these I would think would be for more experienced Storage folks.   Any 
suggestions for courses for newbies or material they could review would be 
greatly appreciated.

Many thanks.

Fred G.


Sent from Outlook


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

GDPS Manuals Link

[fred glenlake]

Hi List,

I am unsuccessfully trying to locate the hiding spot of the GDPS Manuals for 
V4R1 so I can download a few.   If anyone can share the link of where I could 
download them please.

Sent from Outlook

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

Re: Unix Permissions Display Question

[fred glenlake]

Hi List,

Amazing response by so many members, very much appreciated.   Just to close the 
loop, I don't have Vista so that's out.   The Unix display that I re-typed was 
with the + in front of the 755.   From the follow-on copy and pastes below of 
your suggested commands it shows I have 2 USER ACL's defined somewhere in RACF 
that are likely the cause of my access issues when I try to rename this file in 
a simulated DR test scenario.

I issued the GETFACL command as suggested and that display is copied and pasted 
below.

$ getfacl SYSTEM/etc/pagent_TTLS.conf
#file:  SYSTEM/etc/pagent_TTLS.conf
#owner: 30456
#group: SYS1
user::rwx
group::r-x
other::r-x
user:DRTSTCPY:-w-
user:DREVTCPY:-w-

I also displayed file attributes in TSO ishell and that display is copied and 
pasted below

TSO ishell
Display File Attributes (Option 2 or A)

Pathname : /SYSTEM/etc/pagent_TTLS.conf
 More: +
File type . . . . . . : Regular file
Permissions . . . . . : 755 rwxr-xr-x
Access control list . : 1
File size . . . . . . : 8562
File owner  . . . . . : (30456)
Group owner . . . . . : SYS1(2)
Last modified . . . . : 2021-03-25 16:09:34
Last changed  . . . . : 2021-07-01 11:01:20
Last accessed . . . . : 2021-07-02 09:10:43
Created . . . . . . . : 2020-10-25 01:46:59
Link count  . . . . . : 1
Pathname : /SYSTEM/etc/pagent_TTLS.conf
 More:   - +
Link count  . . . . . : 1
Set UID bit . . . . . : 0
Set GID bit . . . . . : 0
Sticky bit  . . . . . : 0
Auditor audit . . . . : R= W= E=
User audit  . . . . . : R= F   W= F   E= F
Device number . . . . : 4
Inode number  . . . . : 53
Major device  . . . . : 0
Minor device  . . . . : 0
File format . . . . . : NA
Pathname : /SYSTEM/etc/pagent_TTLS.conf
 More:   -
Major device  . . . . : 0
Minor device  . . . . : 0
File format . . . . . : NA
Shared AS . . . . . . : 1
APF authorized  . . . : 0
Program controlled  . : 0
Shared library  . . . : 0
Char Set ID/Text flag : 0 OFF
Directory default ACL : 0
File default ACL  . . : 0
Seclabel  . . . . . . :

I also displayed the file in TSO ISPF 3.17 and that display is below as well as 
the follow-on display manage ACL's

TSO ISPF 3.17 Display
   z/OS UNIX Directory List Row 29 to 43 of 65
Command ===>  Scroll ===> CSR

Pathname . : /SYSTEM/etc

Command  FilenameMessage  Type Permission Audit  Ext  Fmat
---
 pagent_TTLS.con  File rwxr-xr-x+ fff--- --s- 


OPTION # 23 Manage ACLs Display

z/OS UNIX ACL ListRow 1 from 2
Command ===> Scroll ===> CSR

S   UID   Read  Write  eXecute  Name  Type
69234537  W DRTSTCPY  USER
69234538  W DREVTCPY  USER


Sent from Outlook<http://aka.ms/weboutlook>


From: IBM Mainframe Discussion List  on behalf of 
fred glenlake 
Sent: July 1, 2021 1:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Unix Permissions Display Question

Hi List,

I am trying to understand what I am seeing when I display my /SYSTEM/etc files 
especially for my PAGENT files.   I re-typed the display below:

Type   Perm   Permission   Owner   Filename
File 755  rwxr-xr-x   BPXROOT  pagent_TTLS.bkup20191118
File   +755+rwxr-xr-x  pagent_TTLS.conf
File 755  rwxr-xr-x   BPXROOT  pagent_TTLS.conf.oldcert

I am really interested in what the "+" means in front of the 755 and the 
permissions rwxr-xr-x.   I think it means the file pagent_TTLS.conf is somehow 
protected externally by RACF but I am not sure.   I have not been able to 
locate a redbook or manual that tells me what the "+" means.   In a CHMOD 
command the + means adding permissions, that I know (or think I know).   I am 
not a z/UNIX guru by any stretch of the imagination.   I am hoping someone can 
enlighten me please.  Also if it is externally protected how I could go about 
displaying the RACF protection or profile or ??   I have a started task that 
tries to copy in an new version of this file when we do a DR test but my 
started task fails and I need to do it manually as SuperUser.

Thanks,

FredG.

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

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

Unix Permissions Display Question

[fred glenlake]

Hi List,

I am trying to understand what I am seeing when I display my /SYSTEM/etc files 
especially for my PAGENT files.   I re-typed the display below:

Type   Perm   Permission   Owner   Filename
File 755  rwxr-xr-x   BPXROOT  pagent_TTLS.bkup20191118
File   +755+rwxr-xr-x  pagent_TTLS.conf
File 755  rwxr-xr-x   BPXROOT  pagent_TTLS.conf.oldcert

I am really interested in what the "+" means in front of the 755 and the 
permissions rwxr-xr-x.   I think it means the file pagent_TTLS.conf is somehow 
protected externally by RACF but I am not sure.   I have not been able to 
locate a redbook or manual that tells me what the "+" means.   In a CHMOD 
command the + means adding permissions, that I know (or think I know).   I am 
not a z/UNIX guru by any stretch of the imagination.   I am hoping someone can 
enlighten me please.  Also if it is externally protected how I could go about 
displaying the RACF protection or profile or ??   I have a started task that 
tries to copy in an new version of this file when we do a DR test but my 
started task fails and I need to do it manually as SuperUser.

Thanks,

FredG.

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

GDPS, Metro Mirror, Global Mirror

[fred glenlake]

Hi List,

I am looking for some direction on how to get up to speed with GDPS, Metro 
Mirror, Global Mirror, etc.   My site has been a single site for quite some 
time and DR tests have been go to a DR provider, lug the physical tapes along 
of the latest backups and spend a few days restoring before turning it over to 
selected users to break...ertest.

Now the light bulbs have gone off in the executive suites and they want to 
establish and second and possibly third site with replication out of state 
(200+ miles away), the whole ball of wax.   Go from zero to 200MPH right away 
and of course I have never set one of these up and made them work.

I am starting to download the IBM manuals on the stuff so I can enhance my 
insomnia reading collection, I just want to make sure I am reading up on the 
correct material as there seems to be quite a bit available.

Hence any suggestions, comments on how to get myself up to speed in a 
reasonable amount of time would be greatly appreciated.

Also if this is not the correct list for this type of question and there is 
another more appropriate list please let me know so I may ask in the 
appropriate list.

Many thanks,

Fred G.

Sent from Outlook

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

RACF on a Sysplex??

[fred glenlake]

Hello,

We are going from one production lpar and one test lpar to two sysplexs, one 
plex for production, one plex for test.   Currently the RACF databases are 
shared (yeah not ideal) but they will be split (prod and test on their own 
databases) once we are sysplexed.

In preparation for the split and the new sysplexes I want to split up the 
databases ahead of time.   I am new to sysplexes so excuse the silly questions.

Currently my primary and backup RACF databases are on DASD, shared DASD between 
prod and test.   I am going to move them to non-shared DASD so prod has its own 
databases and test has its own.   In a Sysplex should the RACF databases still 
reside on DASD that both sides of the sysplexes share (so both prod lpars in 
the plex) or should they reside in the coupling facility or ??

Are there any tools that will help me get to my end state, split up the 
databases, report on the databases, etc.??   Normally I just use the RACF 
utilities ICH* but perhaps other sites use different tools I could look 
into.

Any suggestions, comments are most welcome.

FredG.


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

Re: Hardware upgrade z13 to z14....Yikes

[fred glenlake]

Hi Jesse,

From what I understand the current plan to be as of typing of this response, 
the plan is to merge/move the lpars from the z13's to the z14.   There is no 
plan to collapse lpars into smaller number of lpars so no need to break out the 
abacus and slide rules to figure out workloads that need to merge and all that 
mess.   Those are my current marching orders and I am working towards that.   
Having said that a couple of weeks ago the marching orders were build a new 
sysplex, then last week it was upgrade from a single z13 to a z14 and this week 
it has morphed into merge/move all lpars from the two z13's into one z14.   The 
beauty of management directions and the right to change their minds 😊

Fred G.


From: IBM Mainframe Discussion List  on behalf of 
Jesse 1 Robinson 
Sent: March 1, 2018 12:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Hardware upgrade z13 to z14Yikes

I'm not clear on the scope of 'merging'. If you are just moving LPARs wholesale 
from two CECs to one CEC, it should not be too complicated. In particular, if 
you're careful, there should be minimal impact on users.

If you're consolidating LPARs, then you're in a whole new ballgame. That 
requires a great deal of planning and preparation.

In either case, you have to choose between push-pull and 'incorporation'. In 
the latter case, you add the new CEC into your configuration and move things 
gradually, then remove the old CEC. In the former case, you have to deal with a 
big bang event. Keep in mind a back-out plan in case the new configuration 
falls horribly flat. I've come over the years to prefer a 'fix forward' 
strategy that determines to correct problems and move on. Nevertheless you 
could encounter a problem so severe that the business would not put up the 
ensuing outage.

So many variables.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of fred glenlake
Sent: Thursday, March 01, 2018 6:36 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Hardware upgrade z13 to z14Yikes

Hi Chuck and list members,

I would be interested in knowing once you figure out the cause.   My upgrade is 
actually much more complicated that first presented.   We are going from two 
z13's with about 6 lpars on each to one z14 so not only are we upgrading we are 
merging as well just to make things more interesting.

We are going to run into duplicate definitions for channels, devices, etc. that 
we will need to rectify when we do the odd 30 minutes of planningHa.   The 
new z14 came with of course other new hardware HMC, routers, etc.   I 
personally have not had the experience of gluing two into one, all of the 
upgrades I have worked on have been one for oneup until now.

I would be interested in hearing if anyone else has merged two to one or three 
to one and their experiences.

FredG.


From: IBM Mainframe Discussion List  on behalf of 
Chuck Kreiter 
Sent: March 1, 2018 8:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Hardware upgrade z13 to z14Yikes

We recently did an upgrade to z14's and have seen some unexplained problems.
It appears (unconfirmed as of yet, but should be soon) to be related to some CA 
products.  We should have confirmation later today or tomorrow.  Our upgrade 
was z12's to z14's and we are running z/OS 2.2.  If I get confirmation, I'll 
pass along more details.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of fred glenlake
Sent: Monday, February 26, 2018 11:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Hardware upgrade z13 to z14Yikes

Hi List,

My management must be in line to cash in on performance bonuses because they
have decreed we will upgrade our z13's to z14's in 90 days.   This was a
total out of left field surprise, perhaps our hardware vendor had a sale on for 
"Presidents Day", right next to the slacks and shirts and CEC's??

I am just starting to review the IBM considerations of going to z14's, lots
to consider and read which I do not mind.   Wondered if any list members had
already moved to z14's and could share any land mines they encountered 
upgrading.

At the 10,000 foot level I am thinking to get this done quickly hardware
wise we drop the new CEC's next to the existing ones.   Hook them up to
power, HMC's, etc.  Then grab a couple of cables from existing CEC's for
DASD and Tape, swing them over.   Use the existing IOCP and IOCDS as the
basis of the new IOCP/IOCDS, update serial numbers, models, etc.  Then bring up 
our sysprog lpar on the new CEC,

Re: Hardware upgrade z13 to z14....Yikes

[fred glenlake]

Hi Chuck and list members,

I would be interested in knowing once you figure out the cause.   My upgrade is 
actually much more complicated that first presented.   We are going from two 
z13's with about 6 lpars on each to one z14 so not only are we upgrading we are 
merging as well just to make things more interesting.

We are going to run into duplicate definitions for channels, devices, etc. that 
we will need to rectify when we do the odd 30 minutes of planningHa.   The 
new z14 came with of course other new hardware HMC, routers, etc.   I 
personally have not had the experience of gluing two into one, all of the 
upgrades I have worked on have been one for oneup until now.

I would be interested in hearing if anyone else has merged two to one or three 
to one and their experiences.

FredG.


From: IBM Mainframe Discussion List  on behalf of 
Chuck Kreiter 
Sent: March 1, 2018 8:39 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Hardware upgrade z13 to z14Yikes

We recently did an upgrade to z14's and have seen some unexplained problems.
It appears (unconfirmed as of yet, but should be soon) to be related to some
CA products.  We should have confirmation later today or tomorrow.  Our
upgrade was z12's to z14's and we are running z/OS 2.2.  If I get
confirmation, I'll pass along more details.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of fred glenlake
Sent: Monday, February 26, 2018 11:11 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Hardware upgrade z13 to z14Yikes

Hi List,

My management must be in line to cash in on performance bonuses because they
have decreed we will upgrade our z13's to z14's in 90 days.   This was a
total out of left field surprise, perhaps our hardware vendor had a sale on
for "Presidents Day", right next to the slacks and shirts and CEC's??

I am just starting to review the IBM considerations of going to z14's, lots
to consider and read which I do not mind.   Wondered if any list members had
already moved to z14's and could share any land mines they encountered
upgrading.

At the 10,000 foot level I am thinking to get this done quickly hardware
wise we drop the new CEC's next to the existing ones.   Hook them up to
power, HMC's, etc.  Then grab a couple of cables from existing CEC's for
DASD and Tape, swing them over.   Use the existing IOCP and IOCDS as the
basis of the new IOCP/IOCDS, update serial numbers, models, etc.  Then bring
up our sysprog lpar on the new CEC, get that one going, update and fix
software keys/licenses, issues with first IPL's on new CEC, etc.   Once all
the work is done in terms of getting ready for the rest of the lpars, then
go for the big bang one weekend.  Bring down the rest of the lpars, drop the
cables, swing over to new CEC, hook up and IPL remaining lpars.   Assuming
no phat thumb checks it should work.  Of course there are a ton of
considerations to review and check, coupling facility stuff, software stuff,
compatibility maintenance, etc.   However all things being equal I am
thinking this approach is likely the safest in terms of risk avoidance and
getting this done with the 90 days.   We could go the move one lpar at a
time route but that would mean more work and it would take longer especially
with our change management processes (bless their little hearts).

Any alternate suggestions or comments would be appreciated as I am sure
there will still be a few land mines with my name on them waiting in the
woods.

FredG.




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

Hardware upgrade z13 to z14....Yikes

[fred glenlake]

Hi List,

My management must be in line to cash in on performance bonuses because they 
have decreed we will upgrade our z13's to z14's in 90 days.   This was a total 
out of left field surprise, perhaps our hardware vendor had a sale on for 
"Presidents Day", right next to the slacks and shirts and CEC's??

I am just starting to review the IBM considerations of going to z14's, lots to 
consider and read which I do not mind.   Wondered if any list members had 
already moved to z14's and could share any land mines they encountered 
upgrading.

At the 10,000 foot level I am thinking to get this done quickly hardware wise 
we drop the new CEC's next to the existing ones.   Hook them up to power, 
HMC's, etc.  Then grab a couple of cables from existing CEC's for DASD and 
Tape, swing them over.   Use the existing IOCP and IOCDS as the basis of the 
new IOCP/IOCDS, update serial numbers, models, etc.  Then bring up our sysprog 
lpar on the new CEC, get that one going, update and fix software keys/licenses, 
issues with first IPL's on new CEC, etc.   Once all the work is done in terms 
of getting ready for the rest of the lpars, then go for the big bang one 
weekend.  Bring down the rest of the lpars, drop the cables, swing over to new 
CEC, hook up and IPL remaining lpars.   Assuming no phat thumb checks it should 
work.  Of course there are a ton of considerations to review and check, 
coupling facility stuff, software stuff, compatibility maintenance, etc.   
However all things being equal I am thinking this approach is likely the safest 
in terms of risk avoidance and getting this done with the 90 days.   We could 
go the move one lpar at a time route but that would mean more work and it would 
take longer especially with our change management processes (bless their little 
hearts).

Any alternate suggestions or comments would be appreciated as I am sure there 
will still be a few land mines with my name on them waiting in the woods.

FredG.




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

Re: Setting up a new parallel sysplex

[fred glenlake]

Hi Kees and Allan,

Thank you both for your suggestions.   I greatly appreciate all the input I am 
receiving as I get through the "Insomnia Cure"I mean the IBM Red Book on 
Setting up a Sysplex.  I will definitely include your input in my notes I am 
making as I read through the book.

Fred G.


From: IBM Mainframe Discussion List  on behalf of 
Vernooij, Kees (ITOPT1) - KLM 
Sent: February 6, 2018 8:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Setting up a new parallel sysplex

In addition to that, if you are implementing LOGGER CF Logstreams: beware if 
you read about putting more than 1 Logstream in a CF structure. As I 
understand, these are old recommendations and it is often difficult to convert 
them to 1 Logstream per CF structure.

Kees.

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Allan Staller
> Sent: 06 February, 2018 14:46
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Setting up a new parallel sysplex
>
> I would attempt to make any decisions regarding the CFRM policy first.
> This is the one act with the most potential for "harm".
>
> Decide which structures you will want in the CF (GRS, JES,..) and
> use CFSIZER to obtain sizing estimates.
> (shared spool vs. multi-jesplex).. HSM is of particular interest since
> it requires reconfiguration to run properly in a multi-image
> environment.
> Alter the CF LPAR(s) accordingly and then generate a new CFRM policy.
>
> Then proceed w/"sysplexification" of each component.
>
> This would also be a great time to review "new" features introduced in
> earlier releases of z/OS for inclusion.
>
> HTH,
>
> -----Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Fred Glenlake
> Sent: Monday, February 5, 2018 3:11 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Setting up a new parallel sysplex
>
> Thank you Mr. Staller for the manual recommendation, I have downloaded
> it (another 500+ pages of fun reading), and Yes TEST TEST TEST is
> definitely the plan.
>
> Thank you Mr. Robinson for your input.   I am a relatively new hire (6
> months) and I am still discovering where my predecessors hid all the
> skeletons.   However what I have learned thus far leads me to believe my
> site has a fairly good unique naming convention and standards so I am
> hoping adding a new lpar and merging it with the existing production
> lpar should not have issues with duplicate names.   If you or anyone
> else could suggest a sequence of events to follow to get from "see spot
> run/bronzeplex" sysplex to full parallel sysplex that would be greatly
> appreciated.   Not messing up what is already there in the current
> coupling datasets and defining new ones to house all the new structures
> I would think would be up near the very beginning of the process of
> defining a new parallel sysplex.   I need to make sure we have enough
> memory available to house the new couple datasets in the coupling
> facility.
>
> My own planning is to go through the process using our sandbox lpar
> first and joining it with another test lpar before even considering
> trying this out with the real production lpar.  (Again thank you Mr.
> Staller for the TEST TEST TEST advice, it was already carved in stone in
> my hard head).
>
> I appreciate your advice and suggestions very much.
>
> Thank you again,
>
> Fred G.
>
> --
> 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,
> distribut

Re: Setting up a new parallel sysplex

[Fred Glenlake]

Thank you Mr. Staller for the manual recommendation, I have downloaded it 
(another 500+ pages of fun reading), and Yes TEST TEST TEST is definitely the 
plan.

Thank you Mr. Robinson for your input.   I am a relatively new hire (6 months) 
and I am still discovering where my predecessors hid all the skeletons.   
However what I have learned thus far leads me to believe my site has a fairly 
good unique naming convention and standards so I am hoping adding a new lpar 
and merging it with the existing production lpar should not have issues with 
duplicate names.   If you or anyone else could suggest a sequence of events to 
follow to get from "see spot run/bronzeplex" sysplex to full parallel sysplex 
that would be greatly appreciated.   Not messing up what is already there in 
the current coupling datasets and defining new ones to house all the new 
structures I would think would be up near the very beginning of the process of 
defining a new parallel sysplex.   I need to make sure we have enough memory 
available to house the new couple datasets in the coupling facility.

My own planning is to go through the process using our sandbox lpar first and 
joining it with another test lpar before even considering trying this out with 
the real production lpar.  (Again thank you Mr. Staller for the TEST TEST TEST 
advice, it was already carved in stone in my hard head).

I appreciate your advice and suggestions very much.

Thank you again,

Fred G.

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

Setting up a new parallel sysplex

[Fred Glenlake]

I am looking for documentation on how to set up a full parallel sysplex from a 
"sham-plex".   We are running all the usual cast of characters, IMS, DB2, CICS, 
MQ, etc.   We have a basic sysplex in place to be able to qualify for IBM 
sysplex pricing.   The management team has decided we should have a full 
parallel sysplex to be able to do z/OS maintenance, etc. without taking an 
outage to the client applications.  They would also like to reduce the amount 
of time it takes us to bring up our DR systems.   It might mean we are going to 
have a physically separate processor in another location/city, that has not yet 
been decided yet.

It has been a while since I have worked with setting up a sysplex so I was 
hoping someone could direct me to where I might find documentation on setting 
up a full parallel sysplex with CICSPLEX, IMSPLEX, DB2PLEX, JESPLEX, etc.   I 
have the IBM redbook on Sysplex Considerations (all 500+) pages of it and I am 
starting to go through it.   What I don't see and have not found yet is 
something that would help me determine what do to first, what can I do ahead of 
time to prepare or position for the new full parallel sysplex.  Perhaps if 
there is a document or manual or informational APAR that indicates how to get 
from basic sysplex to full parallel sysplex.

Many thanks in advance for any pearls of wisdom.

Fred G.

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