Re: So Long, and Thanks for All the Fish*

[Art Gutowski]

Cheryl,

Thank you for all the knowledge, experience, and guidance over the years.  I 
appreciate all you've done for the mainframe ecosystem, from the Tuning Letters 
to Cheryl's Hot Flashes, the Road Shows and everything in between.  I've 
learned from your questions here on IBM-MAIN as much as your answers.  I look 
forward to seeing you once more at SHARE in Orlando in March.  

As you travel the globe, make sure you pack your Guide, your electronic thumb, 
and always have your towel with you!

Art Gutowski
Huntington National Bank

On Mon, 22 Jan 2024 23:33:20 -0500, Cheryl Watson  
wrote:

>* For those too young to remember, check out Wiki
>
>Hi all,
>
>I’m retiring, but first want to send out a thank you to all the IBM-Mainers 
>still posting, as well as those who are no longer active. IBM-Main has 
>provided a life-line to me at times when I had nowhere else to turn. (I 
>remember one night at 3 am, where I was stuck on a problem, and found someone 
>who could help me here.) 
>
>I’ve found IBM-Main a wonderful place to learn new tricks, ponder the pros and 
>cons of different approaches, and learn from some of the brightest in the 
>industry. (I have to admit that I tend to ignore the posts that delve into the 
>far annals of time, because I’m more focused on what is happening now.)
>
>I haven’t been too active recently because Frank Kyne, our outstanding Editor 
>and President has been more involved in the technical side of things. But I 
>want you all to know how valuable this group has been to me since it started. 
>(Yes, I was one of those at the very beginning.)
>
>For more info on our retirement, please see our blog post at 
>https://watsonwalker.com/were-retiring/.
>
>Thanks from the bottom of my heart!
>
>All my best,
>Cheryl Watson
>==
>Cheryl Watson Walker, CEO
>Watson & Walker, Inc.
>Sarasota, FL USA
>www.watsonwalker.com
>Cell/Text: 941-266-6609
>==

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

Re: zOSMF install

[Art Gutowski]

You may need to configure and stand up z/OSMF on z/OS 3.1 for other z/OS 3.1 
capabilities, but you don't need to configure it to install z/OS 3.1.  CBPDO is 
still available as an installation option.

Art Gutowski


On Mon, 4 Dec 2023 16:23:34 +, Pommier, Rex  wrote:

>Hi Richard, 
>
>I know I need zOSMF to install 3.1.  My question is, in essence, can (or 
>should) I order and install a stand-alone zOSMF 3.1 and use that for my z/OS 
>3.1 install or am I better off (or is this the only option) installing zOSMF 
>2.4 before even heading down the 3.1 path?
>
>Thanks again,
>Rex
>
>-Original Message-
>From: IBM Mainframe Discussion List  On Behalf Of 
>Richard McIntosh
>Sent: Monday, December 4, 2023 10:10 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: [EXTERNAL] Re: zOSMF install
>
>You need zOSMF to install 3.1.
>
>-Original Message-
>From: IBM Mainframe Discussion List  On Behalf Of 
>Pommier, Rex
>Sent: Monday, December 4, 2023 10:07 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: [External] : zOSMF install
>
>Hi all,
>
>Just looking for opinions on this.
>
>Scenario is we're running z/OS 2.4.  We don't have zOSMF installed.  Sometime 
>next year we're going to migrate to 3.1.  Would we be better off 
>installing/implementing zOSMF 2.4 today in preparation for installing 3.1 or 
>should we install zOSMF 3.1 and implement that before installing z/OS 3.1?  
>Can we even install zOSMF 3.1 without having a running zOSMF install already?
>
>Thanks,
>
>Rex

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

Re: z/OSMF

[Art Gutowski]

On Tue, 20 Jun 2023 23:46:28 -0500, Brian Westerman 
 wrote:

>As you all know, the z/OSMF product is the ONLY way to install z/OS, (without 
>using COS), and the product doesn't even run in a usable way on their 
>smallest, (but still supported and sold) processors.  

CBPDO still works for installation.  Migration is the rub, since the Migration 
Guide has been discontinued.  I've been told you can extract the z/OSMF 
workflow into a printable/readable format that provides essentially the same 
thing, but I have not done that myself.  Of course, that requires bringing 
z/OSMF up long enough to accomplish the task.

Keeping up with Health Checker will help, but it won't catch everything.  As of 
2.5, there is still an Introduction and Release Guide, a Planning for 
Installation and a Release Upgrade Reference Summary, and a Planning for 
Installation manual for 2.5.  In 2.4, there was a publication number associated 
with the the z/OSMF workflow, as if you could download it, but I don't see it 
in the 2.5 shelves.  These books may enable you to piece it together without 
the workflow, but they're a far cry from the once extant, solid, reliable, 
one-stop-shop Migration Guide.

Art Gutowski
arthur.gutow...@huntington.com

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

Re: Installing a new version of z/OS using z/OSMF

[Art Gutowski]

On Wed, 24 May 2023 11:37:25 +, Gadi Ben-Avi  wrote:

>Hi,
>I've been tasked with installing a new version of z/OS.
>The only way to do it these days is to use z/OSMF.
>
>I've done this many times using the ServerPac dialog, so I'm familiar with 
>that process.
>
>We are currently using z/OS v2.3 which is already unsupported, so IBM is not 
>really helping.
>
>Do you know of any resources that would help me with this?
>

It's not the only way.  You can still order and install a z/OS CBPDO.

Art Gutowski

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

Re: Are you serious about wanting a better IBM doc RCF-type process?

[Art Gutowski]

On Tue, 23 May 2023 12:40:34 +, Allan Staller  wrote:

>Classification: Confidential
>
>This entire thread comes down to "the "new tools" are neither as available, 
>functional ore reliable as those they replace".
>
I was hoping you'd say that.

+1 on RCFs and +1 on the above.

Art Gutowski

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

Re: CF links and non-IBM machines (historical)

[Art Gutowski]

On Sun, 19 Mar 2023 23:34:48 +0100, Radoslaw Skorupka  
wrote:

>I'm aware it is quite obsolete topic.
>Q: was it possible to connect Amdahl or Hitachi machines with IBM CPC
>using sysplex links?
>Did they use the same hardware and protocol?
>
>BTW: I found the following Hitachi CF link descriptions: ISCH2, ICF,
>ISB, ICC. Any of them is similar to IBM links (I know IBM channels, its
>names, etc.)
>Any clue?
>
>Another question: I found some non-IBM machines offered over 256
>channels. How???
>Note, it was definitely before XMP machines (multiple CSS).

I know of a customer who connected IBM z (maybe 9672) with Amdahl and Hitachi 
equivalents.  It was bumpy at times, and there was some finger-pointing between 
the suppliers, but they ran more than one such mixed sysplex.  I don't know 
much of the details, but the suppliers would have had to follow the same 
signalling protocols.  That they didn't exactly do so may very have been the 
root of their interoperability issues in the beginning.  I would think they 
either had to use the same connectors or else run through ESCON/FICON 
directors, or at least a patch panel.  While the internal hardware layer could 
be different, it would have to "look" the same to the OS (XCF, etc.) - again, 
another potential source of the interoperability problems.

Art Gutowski

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

Re: I want to cry

[Art Gutowski]

On Fri, 3 Feb 2023 20:15:21 -0500, Bob Bridges  wrote:

>[...]

>When nearly an hour had passed, the phone rang again:
>
>Customer:  I need a new power supply.
>
>Technician:  How did you come to that conclusion?
>
>Customer:  Well, I called Microsoft and told the technician what you said, and 
>he started asking me questions about the make of the power supply.
>
>Technician:  What did he tell you?
>
>Customer:  He said my power supply isn't compatible with NOSMOKE.

Well done!  That has got to be the most creative, tag-team problem solving 
effort I've read.  The attention to detail...  I am in tears (of laughter).

Art Gutowski

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

Re: z/OSMF - again, next issue

[Art Gutowski]

On Wed, 31 Aug 2022 14:01:37 +0100, Keith Gooding  wrote:

>Why would anyone use CBPDO + SMP/E to install z/OS ? (Not a rhetorical 
>question).
>
>Z/OSMF Serverpac installation is good but you may not want to use a Serverpac 
>to install a single product such as z/secure.

Would you take a sledgehammer to your walls, hang new drywall, mud, tape, sand, 
and prime every time you wanted to slap a new coat of paint on them?  

CBPDO is no more difficult for z/OS than it is for a product.  A z/OS order 
contains more data, so it takes a little longer to process.  The 
post-installation steps are the same, regardless of the method you choose.  The 
biggest thing ServerPac buys you over CBPDO, is that the SMP/E work is 
_largely_ done for you.  Obviously, if you're a new z/OS shop, you have to 
start somewhere, and ServerPac is likely the better option.  However, if you 
are an established shop with a well-defined cloning process (implying at least 
rudimentary JCL and SMP/E skills), ServerPac may be an over-engineered 
approach, and CBPDO is a feasible alternative.

Art Gutowski
Huntington National Bank

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

Re: z/OSMF - again, next issue

[Art Gutowski]

On Tue, 30 Aug 2022 08:01:53 -0500, Carmen Vitullo  wrote:

>from what I was told by my teammate, Zsecure version 2.5 requires
>z/osmf, I could be wrong, she could be mistaken, but the issues she's
>having I think would affect Serverpac, or whatever it's called now,
>build JCL and submit JCL.
>
>my case I opened was initially on the errors we were seeing on the
>submit errors, that was not addressed, just the easy stuff, now I have
>to recreate the issue again and make sure I have the correct error
>message for support. typical of z/osmf support; my first case I opened
>for z/osmf issues was open and not resolved for 364 days, so, so far I'm
>ahead of the game I support
>
>Carmen

I installed zSecure 2.5 with CBPDO and SMP/E using ISPF just fine.  No issues.  
CBPDO is available for products, and for z/OS itself, and as far as I'm aware, 
no timeline has been announced for phasing it out.  If you like z/OSMF, use it; 
if you prefer ISPF and SMP/E, use CBPDO...it's really not that difficult.

Art Gutowski
Mainframe Engineer
Huntington National Bank
arthur.gutow...@huntington.com

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

Re: System Logstreams

[Art Gutowski]

On Wed, 25 May 2022 15:12:34 -0500, Scott Barry  wrote:

>For SMF Logstreams, there is no "I SMF" -- instead, only option is IFASMFDL 
>(batch) invocation to offload any given / named SMF LOGSTREAM.  And consider 
>staggering the individual START   command invocations, that is 
>if you are using zEDC and are not yet at z15, where/when PCIe card use is 
>eliminated.

I SMF still "works" with Logstreams, just differently.  It does not "switch" 
datasets, but it still flushes the in-storage SMF buffers to the logstream 
staging/offload datasets (which Z EOD also does, among other functions), and 
then passes control to IEFU29L, if it's active.

Art Gutowski
Huntington National Bank

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

Re: LPA

[Art Gutowski]

As the OP and responders thus far are experienced and aware...

Mind your (E)CSA allocations and utilization.  Suggestion: use CSAMIN= other 
than the default (0,0), particularly with MASK=*.  When moving 
modules/libraries from LPALSTxx to Dynamic LPA, remember to adjust IEASYSxx 
CSA= accordingly, and validate the Private areas before and after the IPL.  

Just stating for anyone who isn't as familiar with SETPROG LPA and/or CSVDYLPA. 
 Which reminds me if any of the modules in question are also dynamic exit 
routines, those pointers may need to be refreshed as well.  There are other 
restrictions, e.g., adding SVCs, entry points in the PC table, etc.

Regards,
Art Gutowski


On Tue, 5 Apr 2022 07:29:56 +, Rob Scott  wrote:

>Also consider putting all LPA modules into a single function pack load module 
>so that the SETPROG LPA is always for the same module name (if a contained 
>CSECT is updated by maintenance). CSVQUERY SEARCH=LPA can be used to locate 
>your function pack when server/client starts.
>
>You need a header structure that is a vector table of the included CSECTs at 
>the start of the LPA load module.
>
>Your server/client code just need a mapping of the vector table so that it can 
>slice-and-dice the LPA load module to find the service entry points.
>
>Rob Scott
>Rocket Software
>
>From: IBM Mainframe Discussion List  On Behalf Of Ed 
>Jaffe
>Sent: 05 April 2022 04:04
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: LPA
>
>On 4/4/2022 5:13 PM, Rob Schramm orote:
>> I am feeling particularly annoyed. I don't want to use LPALSTxx for
>> products. I want to be able to upgrade a product with a minimum of fuss.
>> I would like to use PROGXX and manage LPA dynamically. But the PROGxx and
>> SETPROG seem woefully under-powered for such a thing. This is more pointed
>> when systems have infrequent IPLs.
>
>SETPROG LPA,ADD,MASK=*,DSN=data.set.name

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

Re: z/OSMF Migration Workflow Question

[Art Gutowski]

On Fri, 25 Mar 2022 11:05:18 -0500, Marna WALLE  wrote:

>[...]
>For the Help:  actually, I've found that unlike other Help (in ISPF) this 
>z/OSMF Help is pretty good. [...]

Beg pardon?  I've never had an issue with ISPF help.  I've found any of the 
supplied help to be quite useful and pretty darn good, particularly the 
tutorials.  

Art Gutowski

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

Re: Solutions Not Problems - Dilbert Comic Strip on 2022-02-25 | Dilbert by Scott Adams

[Art Gutowski]

On Fri, 25 Feb 2022 16:19:21 -0500, Mark Regan  wrote:

>https://dilbert.com/strip/2022-02-25 

Priceless.  I once knew a manager who insisted on calling bugs "opportunities". 
 To wit, a colleague responded, "Sure, a bug is an opportunity...if you're a 
frog."

Cheers,
Art Gutowski

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

Re: Sysplex Command Routing

[Art Gutowski]

On Mon, 17 Jan 2022 09:25:13 -0800, Ed Jaffe  
wrote:

>I remember people asking this question years ago when "shamplexes" were
>all the rage. A sysplex is supposed to be comprised of equal systems --
>at least as envisaged.
>
>If the systems really are different and are connected into a sysplex for
>some reason of arbitrary convenience, then I'm guessing they have
>different security data bases (e.g., RACF, CA-ACF2 or CA-TSS). Do they?
>
>If so, will it work to simply disallow select userids from issuing
>commands on the systems you don't want them issuing commands on?

If you run GDPS, depending on your configuration, Shamplex is still "the rage". 
 Regardless, with respect to K systems, the ESM databases are unique.  Other 
Shamplex configurations could of course include a RACF (or other ESM) Plex, 
making security by system name difficult, at best, at least with RACF.  There 
exists a wide swath of arbitrary (in)conveniences for which, IIRC, the 
"official" term was Bronzeplex,


Art Gutowski

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

Re: More z/OS 2.5 install fun

[Art Gutowski]

On Thu, 13 Jan 2022 20:26:55 +, Seymour J Metz  wrote:

Chuck Norris doesn't need documentation...


>Is there any zOSMF documentation on SMS/ACS requirements? Any references to 
>Chapter 85. VATLSTxx (volume attribute list in the initialization and tuna 
>reference?
>
>--
>Shmuel (Seymour J.) Metz
>http://mason.gmu.edu/~smetz3

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

Re: CF structure type SERLIST

[Art Gutowski]

On Fri, 17 Dec 2021 01:46:59 +0100, Radoslaw Skorupka  
wrote:


>Another question, CF links: Assuming a sysplex has two Coupling
>Facilities - do CFs need to be connected one to each other?
>Note, I don't mean z/OS - CF connection. It is about CF-CF connection.
>I know it *was* a requirement, but maybe something has changed.
>
IIRC, the original requirement was for timing links only.  The CFs only need to 
be connected for structure duplexing, and that is still true.  From the z/OS 
2.4 Setting Up a Sysplex book:

"PR/SM Planning Guide describes the different type of coupling facility 
channels, including peer mode
links, which can provide both sender and receiver capability on the same link 
by being configured as an
unshared channel path to a single coupling facility and at the same time as a 
shared channel path among
several sender LPARs. CF-to-CF links allow a coupling facility sender channel 
to communicate with
another coupling facility, a function that is required for system-managed 
duplexing rebuild."

Art Gutowski
Huntington National Bank

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

Re: New Java vulnerability

[Art Gutowski]

On Tue, 14 Dec 2021 00:23:21 -0500, Cheryl Watson  
wrote:

>Hi all,
>
>SAS uses Java and has issued a blog post.  Many SAS products use Java and are 
>susceptible to this exposure.  Each site should ensure that all SAS users and 
>the Security staff are made aware of this.  Please see their post (updated 
>today) here:
>
>https://blogs.sas.com/content/sgf/2021/12/13/cve-2021-44228-log4j/.
>
>The two statements relating to base SAS are:
>
>•  For the SAS®  9.4M7 maintenance release, SAS is recommending that the 
>log4j2.formatMsgNoLookups system property be set to true, as documented in the 
>CVE. SAS is working on instructions and will link to them when published.
>
>•  The SAS®  9.4M6 maintenance release and earlier releases are under active 
>review.
>
>Best regards,
>Cheryl
>

Assuming WPS would be similarly affected...

Regards,
Art Gutowski
arthur.gutow...@huntington.com

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

Re: IBM Zcloud - is it just outsourcing ?

[Art Gutowski]

I wouldn't be.  Maybe no problem with licensing, but support is another matter. 
 If it's not their product, how would they know?  They don't license other ISV 
products internally, so all learning is in the field, or "handled" by 
sub-contracting out the work (as we often did in ITS), or by buying out the 
customer's IT staff (as they often did in Outsourcing).  If that didn't work, 
or if it broke down, due to repeated downsizing and/or waves of voluntary 
departures, IBM then "dealt with it" by attempting to convert off of ISVs to 
their own "equivalents" (FSVO, equivalents).  I lost count of how many times I 
asked, "the marketing rep told you it would do what, exactly?" 

Perhaps things have improved in the 15 years since I departed, but perhaps not, 
given that ITS has since been disbanded, outsourcing has now been spun off, and 
some marketing reps are still prone to hyperbole.

Art Gutowski


On Tue, 1 Jun 2021 12:17:36 +, Seymour J Metz  wrote:

>Yes, like any other outsourcing and time-sharing contract, you need to define 
>your requirements before committing to it, and that includes license issues.  
>It's your responsibility to include what you need in the contract, but I would 
>be very surprised if IBM was unable to deal with 3rd party software.
>
>--
>Shmuel (Seymour J.) Metz
>http://mason.gmu.edu/~smetz3

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

Re: ILR012W ALL LOCAL PAGING SPACE IS FULL OR BAD, ASM WAIT03C RSN=01

[Art Gutowski]

Awesome tip, folks, thanks!  We are seeing high SCM utilization on one of our 
test systems, and this is a fantastic time saver.  Whoever wrote this EXEC, 
kudos!  It even sorts by slots used.  

Just shows how valuable this forum is, and how some information never goes out 
of date.  Worth every second it took to login and search.

Art Gutowski
General Motors, LLC

On Mon, 7 Sep 2020 12:42:51 +, Mark Jacobs  
wrote:

>Thanks. I didn't know about that hidden panel. Yes, it does report on SCM;
>
>ASID=0003 JOB=RASP SLOTS= VIO= SCM=17A9
>
>Mark Jacobs
>
>Sent from ProtonMail, Swiss-based encrypted email.
>
>GPG Public Key - 
>https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com
>
>‐‐‐ Original Message ‐‐‐
>On Monday, September 7, 2020 12:42 AM, Barbara Nitz  wrote:
>
>> > ASSBNVSC and ASSBVSC tell you the number of slots each address space is
>>
>> > using. You can look at those in the dump.
>>
>> To make that easier, use the IPCS 'hidden' panels, specifically 2.6i (that's 
>> the level2 toolkit). Use SLOTCNT, it will do the math for you and you'll see 
>> the who gobbled up your aux. (I haven't tried it on SCM storage, so I just 
>> hope it works for that as well as it did for DASD AUX.)
>> You can (and should) use the same command for comparison with the crashed 
>> system. I believe this command works when set to active storage. You may be 
>> surprised which address spaces use a lot regularly.
>>
>> Regards, Barbara
>>
>> ---
>>
>> 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: Don't Hire Chuck Norris was Re: restart GIMSMP in unpack step

[Art Gutowski]

On Wed, 10 Jun 2020 22:32:31 +0300, Binyamin Dissen 
 wrote:

>On Wed, 10 Jun 2020 15:18:40 -0300 Clark Morris  wrote:
>
>:>[Default] On 10 Jun 2020 07:43:41 -0700, in bit.listserv.ibm-main
>:>ku...@us.ibm.com (Kurt Quackenbush) wrote:
>:>
>:>>> snip
>:>>Kurt Quackenbush -- IBM, SMP/E Development
>:>>Chuck Norris never uses CHECK when he applies PTFs.
>:>
>:>Don't Hire Chuck Norris for any systems work.
>
>Well..
>
>Back  years ago, it was much faster to backup the resvol+smp datasets,
>do the apply, and then do a restore than the APPLY CHECK.
>
>Now, APPLYing to the running system ...

Chuck Norris doesn't need to APPLY PTFs.  He just stares down the console until 
the code straightens itself out.

Art

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

Re: Catalogs in parallel sysplex ECS vs RLS

[Art Gutowski]

One or the other, not both.  It's OK to use either/or on a catalog by catalog 
basis, but you cannot double down.  Reference z/OS 2.2.0 DFSMS Managing 
Catalogs -  Accessing Catalogs for Record Level Sharing, Restrictions:

* Master catalogs are currently not supported in RLS mode. Ensure that any 
catalog in RLS mode is not being shared as a master catalog by any system in 
the plex.
* RLS protocol cannot be used simultaneously with either ECS or VVDS protocol 
for a catalog. This is enforced by the SMSVSAM address space. If you attempt to 
use a catalog currently in RLS mode from a non-RLS system in the sysplex, the 
associated catalog request will fail with return code RC4 and reason code 
RSN124. If a catalog is currently in either ECS mode or VVDS mode and is shared 
by a system that cannot support RLS for catalogs, the attempt to use the 
catalog in RLS mode will also fail with return code RC4 and reason code RSN124.

To place a catalog in RLS, it must be SMS-managed, and the SMSVSAM server must 
be active on all systems in the sysplex. You can move a catalog in and out or 
RLS mode with RLSQUIESCE and RLSENABLE, for emergency or maintenance purposes, 
but it's not recommended to do so frequently.

We put all of our user catalogs in RLS, except for two specific catalogs with 
system-critical dataset entries, that don't get hit that often.  These are in 
VLF.  RLS seems to be the better performing option for us.

Art Gutowski
General Motors, LLC

On Thu, 23 Apr 2020 16:43:44 +, Allan Staller  wrote:

>ITYM ECS. (Enahnced Catalog Sharing).
>
>ECS is specific to catalogs and uses a structure for inter-image communication.
>RLS uses a local address space (SMSVSAM) for local communication  AND a 
>structure for inter-image communication.
>
>Both are performance related.
>
>IMO, RLS is more appropriate for applications.  ECS is less overhead.
>
>ECS should be sufficient for most purposes. I have not researched the 
>practicality or  mpact of attempting both on the same catalog (KSDS).
>
>-Origanal Message-
>From: IBM Mainframe Discussion List  On Behalf Of 
>Peter Vander Woude
>Sent: Thursday, April 23, 2020 9:29 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Catalogs in parallel sysplex ECS vs RLS
>
>Ok, building parallel sysplex.  Forhthe catalogs I am planning on using ECS 
>for the shared catalogs (which is all of them).
>
>What is the recommended method for handling the catalogs in a parallel 
>sysplex, ECS or VSAM RLS?

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

Re: z/OS 2.4 Migration manual and z/OSMF usage

[Art Gutowski]

On Fri, 27 Mar 2020 08:30:42 -0400, Kurt Quackenbush  wrote:

>Kurt Quackenbush -- IBM, SMP/E Development
>Chuck Norris never uses CHECK when he applies PTFs.

Chuck Norris doesn't need a a Web App to apply PTFs, he just roundhouse kicks 
them in.

Art Gutowski
General Motors, LLC
arthur.gutow...@gm.com

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

Re: $HASP003 RC=(136) with $MSPL

[Art Gutowski]

Lucas,

Thank you!  That is exactly what I was looking for.  I normally would have 
humbly accepted "RTFM" as a response, but I'm not sure I would have found it.  
The manual (in KC and the online PDF) doesn't describe it in a way that's 
intuitive to me, and the example they give:

$dspl(*),unitdata
$HASP893 VOLUME(SPOOL1)
$HASP893 VOLUME(SPOOL1) UNITDATA=(EXTENT=00,TRKRANGE=(0087,
$HASP893 0293),RECMAX=12,TRKPERCYL=15)
$HASP893 VOLUME(SPOOL2)
$HASP893 VOLUME(SPOOL2) UNITDATA=(EXTENT=01,TRKRANGE=(0001,
$HASP893 001E),BASETRAK=0E,RECMAX=10,
$HASP893 TRKPERCYL=15)
$HASP646 2.5225 PERCENT SPOOL UTILIZATION
Unit-specific information about spool volumes SPOOL1 and SPOOL2 is displayed. 
Note that SPOOL1 is using absolute addressing and SPOOL2 is using relative 
addressing.

doesn't match what my system tells me (which is fortunately displayed just as 
plainly as you described):

$DSPOOL,UNITDATA
RESPONSE=
 $HASP893 VOLUME(vv)
 $HASP893 VOLUME(vv)  UNITDATA=(EXTENT=00,TRKRANGE=(,
 $HASP893 ),RECMAX=12,TRKPERCYL=15,
 $HASP893 ATTRIBUTE=ABSOLUTE)

I'm glad IBM improved the display.  Hopefully the doc caught up in v2r3...

Art

On Thu, 17 May 2018 18:39:29 -0300, Lucas Rosalen  
wrote:

>Hello Art,
>
>I think $DSPOOL(vv),UNITDATA would show that information in ATTRIBUTE
>parm.
>
>---
>*Lucas Rosalen*
>rosalen.lu...@gmail.com / lucas.rosal...@ibm.com
>http://br.linkedin.com/in/lrosalen

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

$HASP003 RC=(136) with $MSPL

[Art Gutowski]

I've been playing around with $MIGRATE SPOOL, and have had a few degrees of 
success, however, on some of our rather archaic systems, I get:

$HASP003 RC=(136),M 775
$HASP003 RC=(136),M SPL(vv)  - Command is not allowed on a
$HASP003target volume with this format.

This is a MERGE operation...both volumes are ACTIVE.  I have read through the 
various restrictions, and the messages book.  While the plain text is useful, 
it falls short of specifying the disallowed format.  If I had to guess, and I 
don't like to guess, I'd say that my target volume is using absolute, rather 
than relative addressing.  I have tried migrating to each available target 
volume in the configuration, all with the same results.  I would assume 
therefore, that my source volume is also absolute, and hence a MOVE operation 
to a new volume would fail as unceremoniously.

Is there any way for me to know for certain that these volumes are absolute, 
rather than relative?  The $DSPOOL,MIGDATA, while useful for selecting a target 
with sufficient space, does not provide this information, and I do not see 
anything in the SDSF SP display to indicate addressing mode.

Follow up question, if I allocate and format a new spool, leaving it ACTIVE for 
a MERGE, will it default to absolute addressing like the others, or will it use 
relative addressing?  I fear offload and COLD start might be my only way around 
this mess...

I am at z/OS 2.2 JES2, $ACTIVATE=z11, LARGEDS=Allowed, CYL_MANAGED=FAIL.

Thanks,
Art Gutowski
General Motors, LLC

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

Re: Best Practices for z/OS Maintenance

[Art Gutowski]

>We don't mount the IBM provided /etc /var file systems for actual use.   We 
>use those to compare with what we have.
>AFAIK, there is NOT any SMPE that updates those anyway, its just what 
>Serverpac provides.  
>I never mount those filesystems for SMPE maintenance and never get any errors.

SMP/E LIST DDDEF will confirm that assumption.  It's been a while since I've 
had to do z/OS maintenance, but I've learned not to take anything for granted 
with SMP/E, and especially with z/OS UNIX filesystems.  

IF you find any DDDEFs pointing to /etc or /var, they would need to be changed 
to some variation of /service as you hopefully do with your version FS.  If you 
manage multiple target and distribution pairs, I highly recommend using 
automount to ensure SMP/E mounts the matching version root FS for the target 
zone and SYSRES.  A colleague (who frequents this list), set this up at a prior 
shop of ours.  It was not trivial.  He had a ServiceLink Q open with IBM for 
weeks, and there was much discussion among the team and extensive testing.  
However, once the various maps were defined (we had to support multiple 
versions of languages as well), the DDDEFs were updated, and we modified our 
cloning process to keep up, everything worked flawlessly.

IJS, I would not take the lack of errors as a golden stamp of approval.  We 
were burned badly by this assumption - our SYSRES and version FS (and SMP/E) 
got out of sync, and we had no obvious indication.  If memory serves, we had to 
dig through the SMP/E LOG (the job SYSOUT was probably long gone) to find that 
SMP/E had done exactly what it was told to do:  apply UNIX elements to the 
wrong path/filesystem.

Art

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

Re: IBM does what IBM does best: Raises the chopper again

[Art Gutowski]

On Fri, 1 Dec 2017 16:54:18 +, Stone, Marshall  
wrote:
>HEX 42 in Binary - 0100 0010  - now using fingers up/down to represent 
>digits...

Brilliant!

Art

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

Re: Last SAD (was: DLIB volume for SAD)

[Art Gutowski]

"Steely.Mark" <steely.m...@aaa-texas.com> asked:

>A little off topic - when is the last time anyone  had  to perform a SAD ?  I 
>haven’t done one in 20+ years.  
 
We've taken at least a couple in the last 4 years.  I don't recall the exact 
circumstances (lots of brush fires early in the transition), but on at least 
one occasion, IIRC, we were still working through firewall issues and had a 
hard time getting the dump to IBM.

Art Gutowski
General Motors, LLC

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

Re: SYS3 datasets

[Art Gutowski]

On Sun, 24 Sep 2017 23:39:40 -0500, Paul Gilmartin <paulgboul...@aim.com> wrote:

>On Sun, 24 Sep 2017 23:27:40 -0500, Brian Westerman wrote:
>Vendors ought to suggest installation paths for their software products.
Agreed.

>SYS3.vendor.** seems like a good idea.  Or incorporating the vendors'
>registered element prefix.
For some, perhaps, but almost assuredly not for all.

>Shops ought to follow those vendor suggestions:
Bullocks.  Shops need to do what makes sense for them.  There are certain 
aspects of software installation where vendor requirements are clear and ought 
to be followed without exception, or bad things can happen.  Dataset names 
ought not to be a problem area. As for registered prefix, these ought to be 
incorporated into LLQ/SMPE DDDEF names.  It may make sense as a mid- or 
high-level qualifier to some, but it ought not to be a requirement.

>o It allows trying samples in the vendor documents with less tailoring
>  of DD statements.
ServerPac and other sufficiently sophisticated installation tools can handle 
the bulk of this tailoring.  JCL and System symbols can make what's left much 
easier.  A system programmer ought to know how to make a few JCL or source code 
changes to get a sample working...and a newbie can be taught, no matter what 
the PHBs have read in the trade rags or social media.

>o It makes programmer skill sets more portable.  (But management
>  might consider that a bad idea.)
I fail to see how learning a shop's standards impacts skill set portability.  
SMP/E and other system programmer skills are not null and void because one shop 
uses SYS3 and another uses a separate HLQ for each vendor.  It just takes time 
to assimilate into the environment. I learned how to ride a bicycle in the US.  
I don't have to re-learn how to ride if I move to the UK, I just have to learn 
to ride on the other side of the road and look first in the opposite direction 
before crossing a road.

There are potentially as many standards as there are shops to develop them.  
Software installation tools, the people that develop them, and the people that 
use them, ought to be flexible enough to cope.

Art Gutowski
General Motors, LLC

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

Re: z/OSMF-Based Installation (WasL Re: AW: Re: EAV volumes and SYSRES)

[Art Gutowski]

On Tue, 11 Jul 2017 07:35:52 -0400, John Eells <ee...@us.ibm.com> wrote:

>Everyone: IBM is headed toward using z/OSMF Software Management as the
>installer.  Please go back to near the beginning of this thread with the
>old topic name to catch up on the discussion thus far.
>
>More on the SHARE website, here:
>
>https://share.confex.com/data/handout/share/128/Session_20728_handout_10028_0.pdf

From the previously titled thread:

>At the last SHARE, the question was asked at the multivendor 
>installation-related 
>session about how many in the room were z/OSMF users.  In the past, I've seen 
>those raising a hand to be perhaps 25% of a similarly-sized crowd, but in 
>March 
>about 2/3 of those present raised a hand (a pleasant surprise).  Of course, 
>one 
>room at SHARE does not a valid statistical sample make, but it's one data 
>point.

But is it a valid data point?  We use z/OSMF only insofar as we are forced to 
for IP configuration and upkeep.  We did not use z/OSMF to install v2.2, and I 
don't know whether we'll use it to install v2.3.  There is talk of it, but it 
seems to be largely motivated by the thought that we will be forced into it 
(kind of like zFS).  

Don't get me wrong, we've had talks... I'm with simple and common software 
management processes, and I'm glad to see ISVs on board, but I'm not convinced 
that z/OSMF in and of itself is either necessary or sufficient to achieve the 
goal.  If you have good SMP/E packaging, z/OSMF is unnecessary as an installer. 
 If you have crappy SMP/E packaging, front-ending it with z/OSMF will not be 
sufficient to address the shortfall.

I don't see the need for z/OSMF for software deployment.  We have plenty of 
experience here, and are easily passing that along to our newer sysprogs.  I 
recoil at the thought of using it for configuration.  ISPF is sufficient to 
edit PARMLIB, et al, and it runs in a WS client, if you so choose.

Seems to me, any of the substantive improvements offered by z/OSMF ought to be 
UI-agnostic.  It doesn't take a "sticky" UI and and the overhead (FSVO minimal) 
of a server address space to improve product installation.  These might have 
been made accessible ServerPac, or even the SMP/E dialogs, but they weren't.  
It's a fine thing for someone who wants the trouble of installing and 
configuring Liberty et al (and I've heard the cursing all the way from Austin 
and Phoenix), but ISPF apps ought to continue as supported options for those 
who prefer them. 

That's my buck-two-eight-five, after adjusting for inflation. :)

Art Gutowski
General Motors, LLC
PS - While some of the observations herein are the result of my place of 
employ, the opinions expressed are my own.

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

Re: "New" Java-less Operating System Messages blips like crazy

[Art Gutowski]

On Tue, 6 Jun 2017 10:49:47 -0400, Tom Conley <pinnc...@rochester.rr.com> wrote:

>On 6/6/2017 10:45 AM, Styles, Andy , ITS zPlatform Services wrote:
>> Classification: Public
>> It varies between browsers, I believe.
>>
>> Chrome 55.0.2883.87 seems to play nicely - perhaps nicer - but IE 
>> 11.0.9600.18665 is definitely not happy.
>-
>Andy,
>
>Thanks for this, it 'splains a lot.  I'm using that level of IE, but I
>can't use Chrome because popups.  IBM uses FF, so I guess it's not
>surprising they're not seeing issues.
>
-

Tom (et tu, IBM),

FYI, we also see a "choppy" OS messages.  We also had an issue with _no_ OS 
messages at all, but this was fixed with microcode.  I didn't catch what "z" 
you're at, and I've seen mention of both z12 an z13 in this thread, so for 
completeness, we are:

z13 GA2 Driver 27
At "bundle 38", we had no OS messages at all...if I recall correctly, the 
interface would come up, but nothing would display on it, no commands could be 
sent (as in we couldn't even VARY CN,ACTIVATE after NIP), basically DoA.

We since installed "bundle 46", and OS messages are available again.  I do not 
know specifically which MCL fixed the problem.

Scrolling works, but the screen is "Jumping a lot more."  Our operators have 
also observed that "some of the messages have to be selected in a check box in 
order to delete them." (interesting new "feature")
Our operations workstations currently have IE11 version 11.0.9600.18638CO 
installed (slightly down-level from Andy's installation, I think).  I don't IPL 
or watch IPLs much anymore, so I don't have occasion to use the OS interface.  
However I use Chrome, and as others have reported, that seems to work OK.
 

HTH,
Art Gutowski
General Motors, LLC

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

Re: Removing JES2 PRT and RMT definitions - Answered

[Art Gutowski]

On Sun, 21 May 2017 16:26:56 +, Jesse 1 Robinson <jesse1.robin...@sce.com> 
wrote:
>I was hoping that Tom W. or someone else from JES2 would chime in. 
>I don't recall having removed JES2 devices in a MAS, but I'll go out on a limb 
>with the observation that all-systems warm start is hardly ever required for 
>anything these days. Since the advent of dynamic modification in the 90s, 
>most changes can be implemented by command alone, or at worst by 
>command followed by single-system restart. That's not transparency, but 
>it's no worse than rolling IPL for any other purpose. 
>I suggest just removing the definitions and see what happens.  
 
As was I.  I though I tie off the thread for the curious.  As suspected by Skip 
and others, single-member warm-start removed these devices from each member in 
a rolling IPL, thus a successful sweeping of some cosmic debris.  I cannot say 
whether a hot-start would have sufficed.

For the record, we removed several dozen printers, e.g.:
PRT(nnn) CLASS=ccc,...

two REMOTE definitions, e.g.:
RMT() DEVTYPE=tt,LUNAME=,...
R(nnn).PR(n) ...
R(nnn),RD(n) ...
R(nnn).PU(n) ...

and DESTIDs for the RMTs:
DESTID() DEST=NnnnR

I know there is a $DEL DEStid, but since we had to IPL for the others, I just 
let these roll off with the lot.  Since this experiment, I intend to follow up 
with:
1) RCF against the JES2 Init & Tuning Ref to clarify the minimum requirement 
for removal of such definitions
   (again, add and modify are spelled out, but I am wont to find such explicit 
description for delete)
2) RFE against JES2 to provide $DEL commands for other devices where 
possible/practical, such as PRTs and RMTs

Thanks and regards,
Art Gutowski
General Motors, LLC

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

Re: AW: Removing JES2 PRT and RMT definitions

[Art Gutowski]

>>Since the JES2-L list seems to be defunct, and I have not found a conclusive 
>>answer in the archives nor the books, ...
>
>Have you been able to search the archives of the JES2-L list? Last time I 
>tried I did not succeed.

Bupkus.  It would seem everything on this listserv has been dismantled, or at 
least I no longer have access to view even the "list of lists".

Art Gutowski
General Motors, LLC

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

Re: Removing JES2 PRT and RMT definitions

[Art Gutowski]

On Fri, 19 May 2017 08:19:10 -0700, Lizette Koehler <stars...@mindspring.com> 
wrote:

>Here is a best guess.
>
>If the printer was added with $ADD then a hot start may work
>
>Otherwise, remove the PRINTER definitions from the INIT Deck and then try a 
>HOT Start.  IF that does not work, then you will need an IPL (WARM) Start on 
>that LPAR.
>
>Depending on your level of z/OS and JES2 - this should work.
>
>The worst case I can think of is you have 3 LPARs in the PLEX, and you will 
>need to shut down all 3 and IPL one after the PRINTER definition is removed in 
>JES.
>
>If you have Q with IBM, I would open a Usage question for a more accurate 
>answer.  

Lizette,

Thank you, a Usage Q is certainly in order.  I thought I'd tap the experience 
of the collective first...  

I'm prepared for an all-member warm-start "just in case", but it would be nice 
to know ahead of time whether that is truly necessary.  These have been in our 
JES2 parms since long before we had anything to do with these systems, and we 
had to COLD start when we brought these systems in, so no to $ADD, but I don't 
know if that diminishes the possibility of a hot-start or single-member warm 
start being sufficient.  Maybe it's just me, but the doc is far from clear on 
removal.  

When all is said and done, an RCF is also certainly in order.

Thanks,
Art Gutowski
General Motors, LLC

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

Re: Removing JES2 PRT and RMT definitions

[Art Gutowski]

>What about running a second JES2 system on where a production JES2 is already 
>running?  It can totally separate from the JES2 production system.
> And on that test JES2 system you can try removing the PRT and RMT definitian 
> and see what happens.

That gives me a single-member MAS, which I have in a sandbox, but it won't help 
me prove single-member vs all-member warm-start.  I will have a two-way MAS, 
but not in time to test this out.  I am asking for an all-member warm-start 
"just in case", but it would make life easier if I knew whether I really needed 
it.  I'm certain I've made similar changes before, but the specifics escape my 
recollection.  I was hoping for, "Artie, go to page 'x' in the 'FM' and Read 
The...", or "BTDTGTTS, and I '_fill in the blank_' is what was required to 
complete the change."

When all is said and done, I will submit an RCF...

Thanks,
Art Gutowski
General Motors, LLC

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

Removing JES2 PRT and RMT definitions

[Art Gutowski]

Since the JES2-L list seems to be defunct, and I have not found a conclusive 
answer in the archives nor the books, I'd like to know if a single-member 
warm-start is sufficient to remove PRT(xxx) and RMT(xxx) definitions from a 
MAS, or whether an all-member warm-start is required.  The complex in question 
is a 3-system MAS.  I don't have, at present, a representative test environment 
to play in.  

The requirements for adding and modifying these elements are well-documented, 
requirements for delete are not explicit, IMO.  If I have overlooked a passage, 
please correct my misunderstanding.  I did find a couple of short threads where 
this question was asked, and I see "seems to" and "assume". but nothing that 
says "I tried it and it works".  Does the venerable Mr. Wasik monitor this list?

Thanks,
Art Gutowski
General Motors, LLC

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

Re: What are mainframes

[Art Gutowski]

On Tue, 11 Apr 2017 09:22:06 -0400, Bill Ashton <bill00ash...@gmail.com> wrote:

>Wow...23 quadrillion calculations every second! At that speed, it should be
>able to come up with an answer before the question is even asked!

42

(Sorry, I know it's not Friday, but it was sitting right there.)

Art Gutowski
General Motors, LLC

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

Re: Paging subsystems in the era of bigass memory

[Art Gutowski]

Did someone on this thread say DB2??

We have been experiencing similar AUX storage creep on our DB2 systems, 
particularly during LARGE reorgs (more of a gallop than a creep).  Our DB2 guys 
did some research, opened an ETR with IBM, and found this relic:

Q:  
"[Why was] set realstorage_management to OFF when that zPARM was introduced in 
DB2 version 10?

"Details
"IBM z/OS implemented a Storage Management Design change after DB2 v10 was 
released.  
"•  Before the design change, DB2 used KEEPREAL(NO), virtual storage pages 
were really (physically) freed, high CPU cost if YES
DISCARDDATA KEEPREAL(NO), RSM has to get LPAR level serialization to manage 
those pages that are being freed immediately. That added to CPU usage and also 
caused some CPU spin at the LPAR level to get that serialization  -- excerpt 
from PTF

"To get around/minimize the impact of the original design shortcomings that was 
introduced by IBM RSM z/OS,  setting zPARM realstorage_management to OFF, would 
probably have been prudent on most LPARs.  HP/EDS tried to address this new 
issue IBM created.

"IBM create two PTFs and changed the way DB2 and RSM manages the page frames.

"•  After a design change (now) DB2 uses KEEPREAL(YES), storage is only 
virtually freed
"If DB2 doesn't tell RSM that it doesn't need a frame, then the frame will 
remain backed in real storage in some form. That causes the growth of real 
storage and paging and everything that goes with using up REAL storage. 
KEEPREAL(YES) allows DB2 to tell RSM that z/OS can steal the page if it needs 
it, but DB2 retains ownership of the page, and it remains backed with real 
storage. If z/OS needs the page, it can steal it -- excerpt from PTF

"V10 APAR PM88804 APAR PM86862 and PM99575"

So...perhaps check your DSNZPARM and make sure it's coded appropriately for 
more modern times.  FYI, we are z/OS 2.2 and DB2 11.1, NFM.  We are in the 
process of rolling out REALSTORAGE_MANAGEMENT=AUTO (the current IBM recommended 
setting) across our enterprise.

HTH,
Art Gutowski (with assist from Doug Drain, Steve Laufer and IBM)
General Motors, LLC

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

Plug Boards (was: Re: Paper tape)

[Art Gutowski]

On Thu, 19 Jan 2017 08:51:39 -0800, John Mattson <johnmattson...@gmail.com> 
wrote:

>But even more ancient were the plug boards which were used for other
>purposes.  There was one lady, Sono Obuchi, who was the only one who knew
>how to program them. I stayed as far away from them as I could.

If you are referring to the boards for the IBM 407, my father has one in his 
basement that someone gave him a few years back.  Not sure where it was rescued 
from, but he appreciated the gift.  He had wired those boards as a computer 
operator for JL Hudson back in the mid-to-late 60s.  It's neat to hear the 
tales of times when one was an operator, sysprog, and apps coder all in 
one...general purpose defined.

One day, hopefully a long, long time from now, it will be on display at the 
Computer History Museum.

Art Gutowski (Jr)
General Motors, LLC

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

Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic error

[Art Gutowski]

On Thu, 5 Jan 2017 12:19:38 -0600, Tom Marchant <m42tom-ibmm...@yahoo.com> 
wrote:

>On Thu, 5 Jan 2017 11:26:51 -0600, Art Gutowski wrote:
>
>>... it probably wouldn't hurt to do a REPORT SYSMODS <1.13 zone> 
>>COMPAREDTO(<2.2 zone>) and vice versa.
>
>Is that going to give you any useful information, Art? I believe that it is 
>possible to code the ++VER in a PTF so that the same PTF can be applied 
>to two different FMIDs, but I can't remember ever seeing it.
>
>Of course, I have been wrong before...

Duh, yes, I meant:

REPORT CROSSZONE
lists conditional requisites that must be installed in certain
zones because of SYSMODs that are installed in other zones. 
 

If memory serves, I did once upon a midnight dreary use multiple ++VER for a 
USERMOD.  Not quite sure why, but I think it was due to sharing a GLOBAL zone 
for multiple releases, and didn't want to have to change USERMOD names nor 
REJECT/RECEIVE during parallel testing/deployment.  REPORT SYSMODS would be 
marginally useful in this specific case.

Also, glad someone else pointed out LARGEDS=ALLOWED.  I thought that was a 
prereq for MODE=z11, so I neglected to mention it.

Regards,
Art Gutowski
General Motors, LLC

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

Re: IPLing z/OS 2.2 from 1.13 for first time getting JES2 catastrophic error

[Art Gutowski]

From "Pommier, Rex" <rpomm...@sfgmembers.com> on Thu, 5 Jan 2017 17:17:01 +:

>Thanks for the suggestion.  We are already running MODE=DUPLEX.

We had one or two systems where we had to make this change, and a couple that 
we had to migrate to z11 checkpoint format.  Other than that, no issues with 
upgrade and downgrade via WARMSTART between 1.13 and 2.2.

As others suggested, verify your toleration maintenance, and it probably 
wouldn't hurt to do a REPORT SYSMODS <1.13 zone> COMPAREDTO(<2.2 zone>) and 
vice versa.  I've been burned by "missing" PTFs before that make incompatible 
changes (e.g., previously mentioned incompatible parameters, though these 
usually are resolved via startup prompts).

Finally, do you have any exits installed?  We had to rewrite a few of our exits 
for 2.2.  I don't know which (I'm not on the upgrade project), but I can find 
out.

Regards,
Art Gutowski
General Motors, LLC

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

Re: Jerk dropped from IBM-MAIN at last

[Art Gutowski]

On Mon, 19 Dec 2016 23:24:31 -0600, Elardus Engelbrecht 
<elardus.engelbre...@sita.co.za> wrote:

>Good news!
>
>I have been informed that the jerk who posted junk on Sunday has been blocked.
>
>IBM-MAIN moderator also blocked four more other addresses too from IBM-MAIN.
>
>;-)

Thank you, Darren and Elardus.  Let's hope it sticks this time.  If memory 
serves, this is the second incarnation (Jerk 2.0)...

Cheers,
Art Gutowski

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

Re: Please get that jerk off our list. Thanks.

[Art Gutowski]

On Mon, 19 Dec 2016 13:15:14 +, Vernooij, Kees (ITOPT1) - KLM 
 wrote:

>Gee, now I'm getting that rubbish as private mail. 
>Kees. 


Yep, me too.  Already blocked, and hopefully our spam filters have caught up 
and can keep up with this cretin.

Art

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

Re: Reloading a member of ELPA

[Art Gutowski]

I was going to say "deprecated" (I trust Skip to correct me if the usage is 
incorrect :)  MLPA is still supported, but DLPA is greatly preferred.

CSAMIN can protect you from overrunning (E)CSA during a module reload, provided 
it is not set to (0,0).  See the z/OS MVS System Commands for details.

Regards,
Art Gutowski
General Motors, LLC

On Mon, 26 Sep 2016 10:55:05 -0400, Mark Jacobs - Listserv 
<mark.jac...@custserv.com> wrote:

>MLPA is rather obsolete and can only be created at IPL.
>
>Mark Jacobs
>
>> Steve <mailto:st...@stevebeaver.com>
>> September 26, 2016 at 10:50 AM
>>
>> Why not put it MLPA if its being called thousands of times a day?
>>
>> -Original Message-
>> From: "Tom Marchant" <000a2a8c2020-dmarc-requ...@listserv.ua.edu>
>> Sent: Monday, September 26, 2016 10:48am
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Reloading a member of ELPA
>>
>>
>> I agree with Mark's comments, and I would add that the old copy of the
>> Natural nucleus must remain where it is unless you can be absolutely
>> certain that there is no address space in the system that is using it.
>>
>> You don't say how much space is taken by the Natural nucleus. That
>> makes a difference as to whether or not you have available ECSA for it.
>>

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

Re: SHARE Atlanta proceedings

[Art Gutowski]

On Sun, 14 Aug 2016 11:49:42 -0600, Mark Post <mp...@suse.com> wrote:

>>>> On 8/14/2016 at 06:17 AM, Art Gutowski <arthur.gutow...@gm.com> wrote: 
>> I went to San Antonio in March, and not a word about a DVD or an ISO image 
>> or 
>> anything.  Remember the Alamo?  Guess not.
>
>I made a query to SHARE Operations, and they said that the San Antonio 
>proceedings would also be an ISO image, but still needed a few touches to 
>be complete.

As of 9/2, the SHARE San Antonio proceedings ISO image is available.  I am 
downloading it now.  Self-extracting ZIP is 969MB.  For my part, much easier to 
d/l the whole kit and kaboodle than hunt and peck for "just" the session folks 
at my shop would be interested in.

I apologize if this is old news, but I didn't find a follow up post to this 
thread as of this writing.  I am, however, getting to the point where reading 
glasses are in my near, rather than distant future...

Regards,
Art Gutowski
General Motors, LLC

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

Re: SHARE Atlanta proceedings

[Art Gutowski]

On Thu, 11 Aug 2016 18:11:20 -0600, Mark Post <mp...@suse.com> wrote:

>>>> On 8/11/2016 at 07:08 PM, Jesse 1 Robinson <jesse1.robin...@sce.com> 
>>>> wrote: 
>> Rather than shipping a physical DVD, SHARE will prepare a downloadable ISO 
>> image containing Atlanta proceedings. Stay tuned for drop date. 
>
>Hmm. I suggested that almost 10 years ago.  Did you hear anything about San 
>Antonio?

Same question.  Another from our shop attended Atlanta and will be downloading 
those proceedings.  I went to San Antonio in March, and not a word about a DVD 
or an ISO image or anything.  Remember the Alamo?  Guess not.

Reckon I'll write my congressman...

Art Gutowski
General Motors, LLC
SHARE MVSE Project Officer

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

Re: SHARE Atlanta proceedings

[Art Gutowski]

On Tue, 9 Aug 2016 22:17:30 +, Jesse 1 Robinson <jesse1.robin...@sce.com> 
wrote:

>According to SHARE HQ, they give speakers some time to get their pitches 
>uploaded
> (maybe with post-session tweaks) before posting a link on the web site. No 
> specific ETA, 
>but it should be soon.  

FSVO "soon".  As an offshoot of the original question, has anyone, or has 
everyone received their SHARE San Antonio DVD?  Isn't this still included with 
a full conference registration? (ISTR reading words to that effect when I 
registered...)  The last proceedings DVD I see available for purchase on the 
SHARE site is for Orlando, Summer 2015, so maybe they just haven't finished it 
yet?  Or did they just stop altogether?

Thanks,
Art Gutowski
General Motors, LLC

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

Re: XCF across two JESplexes

[Art Gutowski]

>>>On Thu, 4 Aug 2016 09:40:35 -0500, "Dyck, Lionel B. (TRA)" 
>>><lionel.d...@va.gov> wrote:

>>>Can anyone offer any advice, words of wisdom, cautions, etc. for enabling 
>>>XCF across 2 JESplexes.  Each JESplex (2 lpars >>>each) is a JES3 
>>>Global/Local and currently has its own XCF/GRS environment. Both JESplexes 
>>>share DASD with the other 
>>>(historical).  Now we are investigating, at my prompting, enabling XCF/GRS 
>>>across both JESplexes (all 4 lpars). 

>On Thu, 4 Aug 2016 08:41:30 -0700, Ed Jaffe <edja...@phoenixsoftware.com> 
>wrote:
>On 8/4/2016 8:25 AM, Ed Jaffe wrote:
> We have been running a Bronzeplex for years without problems.
>
>Though as I peruse the first publication, I think we're really running a
>Goldplex and that sounds like what you might want as well...
>
> http://www.redbooks.ibm.com/redbooks/pdfs/sg246818.pdf
> http://www.redbooks.ibm.com/redpapers/pdfs/redp3967.pdf

SG24-6818... -00? Unrevised since December 2002?  I am surprised.  Has it 
really not changed at all in 14 years?  Or does IBM think nobody merges systems 
anymore?  This and the System Programmers Guide to Parallel Sysplex Aggregation 
that Ed found (2005?) were our bible when we merged 16 systems at a prior 
installation.  We had JES3 and JES2 images, some already in a multisystem 
complex, many still in monoplex.  

No problems running that way, once you get there, but on your way, pay close 
attention to GRS inclusion / exclusion / conversion lists, and resolve as many 
duplicate names (datasets, etc.) as practical.  Oh, and definitely invest the 
time to convert to STAR if your existing systems are still in RING.

Also, if you haven't already, you'll want to consult z/OS MVS: Setting Up a 
Sysplex, SA22-7625-22.

Happy Merging!
Art Gutowski
General Motors, LLC

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

Re: Upcoming Share Conference events in 2017

[Art Gutowski]

On Sun, 24 Jul 2016 20:58:20 -0400, Edward Finnell <efinnel...@aol.com> wrote:

>Checking the Delta reservations from SFO to PVD there's no direct flight.
>The fastest is 7 1/2 hrs. It's a one stop in DTW(Detroit) and a plane change
> from 757 to Airbus A320 into Providence. Their booking only goes thru June
>2017  so it's an approximation at this time. Haven't checked American.

With any luck, I'll be at the stopover with my thumb out, so to speak.  I 
briefly considered driving (or riding), but it might be just a bit too far for 
a day's ride.  When Delta bought out Northwest, they got their own terminal, 
and DTW became a Delta hub (hint, hint :).

Regards,
Art Gutowski
General Motors, LLC
Warren, Michigan

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

Re: Minimum Volume Sizes in the Wild

[Art Gutowski]

On Tue, 28 Jun 2016 12:19:28 -0400, John Eells <ee...@us.ibm.com> wrote:

>What is the *smallest* volume size everyone sees in general use?
>
>For example, will we create any problems if we assume that "everyone"
>has or can define at least a 3390-9 size volume these days?  What if we
>chose 3390-27?

Apologies for being late to the party...to quote Reverend Jim, "ah...I've been 
busy!"

Are you asking because you are considering a ServerPac change?  

We can carve out any size volume we need to, including EAV, though our Storage 
team prefers to keep to "standard" sizes (excepting EAV).  We use and will 
likely retain m1 for Jes2 Checkpoint and Couple DS.  m9 will be used for some 
system volumes (page, spool) on our small systems.  We use m27 for SYSRES and 
DLIB today and will continue to do so until z/OS outgrows them.  We use 2 m54 
for SMP/E and other installation data, which we may eventually consolidate onto 
EAV.

Regards,
Art Gutowski
General Motors, LLC

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

Re: Manipulating system symbols

[Art Gutowski]

On Wed, 3 Feb 2016 19:53:48 -0800, Skip Robinson <jo.skip.robin...@att.net> 
wrote:

>Sweet. Did not pick up on that. All the more reason to prefix symbols with a 
>unique string. 
>
>> -Original Message-
>> On Behalf Of Anthony Thompson
>> Sent: Wednesday, February 3, 2016 07:48 PM
>> 
>> Please note that with z/OS 2.2 the length of system symbols names has
>> increased from 8 to 16, and may include the underscore character.
>> 
>> Ant.
>> 
>> -Original Message-
>> On Behalf Of Paul Gilmartin
>> Sent: Thursday, 4 February 2016 12:03 PM
>> 
>> On 2016-02-03 19:27, Skip Robinson wrote:
>> > This is why I strongly recommend that installation-defined symbols be
>> prefixed with a unique string, which I also recommend be the SHARE
>> installation code. It reduces the number of meaningful character to 5 or 6 
>> but
>> pretty much rules out stepping on toes. Debugging problems caused by
>> symbol 'overlays' could be excruciating.
>> >
>> The namespace is too small in this 21st century.
>> 
>> -- gil

In the meantime, we still have the 8-character limitation.  And whether we try 
to convert existing symbols to use a site prefix now or wait until we have 16 
characters available, that's no small feat.  Naming conventions of any kind, 
once they take hold, are time-consuming to change.  What if the installation is 
not a SHARE member?

We already use meaningful (to us) prefixes to make symbols intuitive to us 
without stepping on IBM symbols, let alone other vendors.  Further, in the case 
I pointed out previously, the vendor decided to use symbol names that conflict 
with IBM filter criterion, and could conflict with IBM symbols.  We have no 
control over such situations.  

Even if they don't conflict, should the installation be JES3, the changes won't 
get picked up, unless the product is issuing a *S ,CONNECT under the 
covers...more shenanigans.  I understand that with the advent of SETLOAD 
IEASYM, this has changed a little, but at z/OS 1.13, the vendor clearly is not 
using this facility to effect the change.

I stand by my earlier statement, no supplier should be dynmically inserting 
symbols into the table without express consent of the installation.  In other 
words, there should be a configuration switch for which the default setting 
should be OFF.  Better to document any symbols and have the customer define 
them explicitly at IPL via IEASYMxx.

I have a counter-proposal.  IBM can reserve certain prefixes or even complete 
names, as they do for SYSMOD IDs, that are off-limits, or use-at-your-own-risk. 
 They can further set up a registry, as they do for module names, and while 
this registry is voluntary, we can certainly encourage vendors to participate.

Regards,
Art Gutowski
General Motors, LLC

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

Re: Catalog VVDS confusion

[Art Gutowski]

On Fri, 5 Feb 2016 11:54:37 -0600, Tom Marchant <m42tom-ibmm...@yahoo.com> 
wrote:

>Many years ago, I had a colleague run REPOR MERGECAT as a way of creating a 
>backup 
>copy of some catalogs. I didn't notice the caution in the manual that says 
>that the old 
>catalog should not be used to access the VSAM data sets after the MERGECAT 
>operation.
>
>The result was that the VVDS entries for all of the VSAM data sets in the 
>catalogs had been 
>updated to point to the new catalog. The aliases were not changed, so the 
>system continued 
>to use the old catalogs. There were a lot of data sets in the same condition 
>that you describe.
>
>I don't remember what the problem was that this caused. Perhaps it had to do 
>with restoring a 
>data set from a backup. Art called me the following week to tell me about the 
>problem and ask 
>for suggestions as to what he should do to fix it.
>
>Maybe Art remembers what problems were caused by it. We both learned a lot 
>from the 
>experience.

I was hoping never to speak of this again =^O  I did learn more about ICF 
catalog structure that I ever thought I wanted to.

The problem was actually with REPRO NOMERGECAT, though similar results can 
likely be achieved with MERGECAT, if you work at it.  Neither of us noticed the 
caution, which, if memory serves, is now a more visible _warning_.  BTW, this 
was in DFP v1 (yes, MVS/SP).

As Tom stated, the VVRs were updated, however the datasests were still accessed 
via the original catalogs.  As long as the datasets didn't move, everything was 
fine.  We ran for days, maybe even a week or more, until application reorgs 
started to run.  The standard process at the time was to REPRO to a PS file, 
delete/define, then REPRO from the PS file into the VSAM file.  The REPRO ran 
without incident.  So did the DELETE, though it shouldn't have (IMHO).  Because 
the VVR back-pointer didn't match the catalog containing the BCS entry, AMS did 
not delete the VVR entry, though it did delete the BCS and VTOC entries.  Next, 
the VSAM dataset is defined anew in the standard search order, so AMS created a 
BCS entry, a duplicate VVR entry, which fell after the previously orphaned VVR 
entry, and a VTOC entry.  Still no consistency checking done or errors 
reported.  Finally, when the REPRO ran to repopulate the VSAM dataset, all hell 
broke loose, because AMS found and used the old VVR entry, pointing back to the 
wrong catalog, with information that did not match up with the VTOC entry.  At 
this point AMS decided at last to throw an error message and fail the 
operation.  The error message of course was obscure and obtuse, and it took a 
sev1 with IBM to figure out what was really going on.

It was then suggested we run DIAGNOSE to see how much trouble we were 
in...let's just say it took us 2-3 weeks to dig out, because, well, we didn't 
stop at a single alternate catalog...we had to create one for every catalog in 
the system.  Thankfully we had a Rexx wizard who wrote up a couple of programs 
to process DIAGNOSE output and generate AMS statemnts to EXPORT PERMANENT, 
DELETE VVR, and IMPORT for each afflicted dataset.  Otherwise, it might have 
taken 2-3 months.  There were a handful of datasets that had VTOC problems, 
too, but it's a little hazy - those could have been from failed attempts to 
repair the problem before we fully understood it.  We had to zap a few VTOC 
VSAM bits so to complete the cleanup.

Art Gutowski
General Motors, LLC

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

Re: Manipulating system symbols

[Art Gutowski]

On Sun, 31 Jan 2016 08:50:43 -0800, Skip Robinson <jo.skip.robin...@att.net> 
wrote:

>We run several CA products, which means CA90S (name?) early in IPL. I don't 
>know CAMASTER, but on a running system I can find no evidence of the symbols 
>you name. I'm not sure that the point of CA initialization would be early 
>enough for our needs.
>> -Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
>> On Behalf Of Bruce Hewson
>> Sent: Saturday, January 30, 2016 09:43 PM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: [Bulk] Re: Manipulating system symbols
>> 
>> one point, if you are running CA products, these days some extra symbols get
>> populated by CA code - one of which is LPARNAME.
>> 
>> at CAMASTER initialization these symbols get added.
>> 
>> VMUSER
>> LPARNAME
>> HRDWNAME
>> SMFID
>> OSLEVEL
>> 
>> been this way at least since 2013

Probably not, Skip.  It sounds like you need these symbols to determine other 
PARMLIB members and parameter values. CAMaster comes up during subsystem 
initialization...much too late.

We noticed CAMaster with our latest Common Services upgrades...either 14.0 or 
14.1...and the symbols Bruce describes do exist.  We came from 12.0, but now we 
see CAMaster is active on our sole 12.0 instance, but the symbols in question 
do not exist.  Looks like this started with 14.0?

I'm glad to see that this is conspicously documented...once we knew 
what to look for.  

It vexes me that the default is SYSSYM(YES).  I was at a shop that used 
 for its own purposes, and I can imagine the level of havoc wrought if 
CAMASTER changed the value of this symbol (the way the documentation is worded, 
I gather if left to default, this is the result).  Compound that with the 
complications of propagating symbol table updates in a JES3 MAS, and you've got 
a migraine brewing.  Thankfully, we don't have any of these symbols in use here 
(yet).

Bottom line:  not a big fan, and we will probably set up CAIMST00 with 
SYSSYM(NO) asap.  Who knows what new symbols will be added in 14.next.  I would 
rather see the symbols required (tho this seems a strong word in this case) by 
the product and let systems programmers define and document them to our 
standards in the symbol table.  We can then identify and resolve potential 
conflicts.  I don't like surprises, and this was a surprise to a couple of us 
here.

Art Gutowski
General Motors, LLC

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

Re: The Linklist

[Art Gutowski]

On Wed, 3 Feb 2016 09:08:35 -0500, Peter Relson <rel...@us.ibm.com> wrote:
>I would guess that the ISR stuff only works against the current LNKLST 
>set.

By current, it's the set that was active when you logged on, not necessarily 
the currently active set.

Side comment:  PARMLIB and APF are indeed also useful.  A PROCLIB pseudo-DD 
would be a nice addition, though the question might be:  Which one?

Art Gutowski
General Motors, LLC

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

Re: Cloning a Sysres and ZFS

[Art Gutowski]

On Tue, 19 Jan 2016 08:33:55 -0600, Bruce Hewson <bruce_hew...@hotmail.com> 
wrote:
>You do not need to use /Service to perform mainmtenance.
>
>You can mount your maintenance target HFS/ZFS files at ANY mountpoint, just so 
>long as your DDDEF PATH statements match.
>
>You could even create mount points as /IPLVOL  - same names as your IPL volume 
>VOLSER.

If you want to use Automount, as we do, /IPLVOL won't do.  I don't think you 
can automount-manage /.  Even if you could, would you really want to?  You can 
call it anything, but I recommend mounting a service fs off a subdirectory if 
you want to automount manage it.

Art Gutowski
General Motors, LLC

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

Re: Cloning a Sysres and ZFS

[Art Gutowski]

On Mon, 18 Jan 2016 16:03:39 +, Chambers, James 
<james.chamb...@permanenttsb.ie> wrote:
 
>We already include it like OMVS.RESPR1.ROOT but the DDDEF only has the path. 
>The below shows a DDDEF taken from the >apply, it still means I need to make 
>sure I got the mount right and the ZONEEDIT unlike the standard DDDEFs that 
>use the >volser to make sure the correct dataset is updated. 
> 
>DDDEF NFSCUTIL PATH'/Service/usr/lpp/NFS/IBM/ and PATHHFS OMVS.RESDD2.ROOT 
> 

Consider something along the lines of:
/Service/zos/RESDD2/usr/lpp/NFS/IBM/
in the DDDEFs.  As part of your cloning process, ZONEEDIT the path names so the 
new path names align with the new filesystem name.

Then, use UNIX automount to manage /Service/zos.  Map /Service/zos/ to 
OMVS..ROOT.  Provided the cloning process goes according to Hoyle, this 
will ensure consistency of maintenance between the MVS and UNIX environments.  

This approach was developed by another regular contributor of this list to 
handle a large number of target environments, but can be used in any sized 
shop.  It is proven and reliable.

Regards,
Art Gutowski
General Motors, LLC

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

Re: JES3 to JES2 Migration (was JES2 to JES3 Migration)

[Art Gutowski]

In a past life, a group of sysprogs entertained the idea of migrating as a cost 
savings measure.  The JECL and JOB CLASS changes were the least of our worries. 
 Exits could be written to translate and map.  As others have pointed out, 
8-character JES2 JOB classes may reduce the need for custom code, as can 
software tools that identify and perform conversion (no pun intended).

The bigger problem was JES3 functionality that systems and applications types 
alike exploited and the extent to which they did.  I don't recall any technical 
hurdles we couln't clear - between already licensed, or readily available 
vendor (including IBM) software, plus a little custom code, there wasn't any 
JES3 function we used that couldn't be "replaced".  It was the time to make the 
conversion and the cost of additional software that put the project on the 
shelf.  YMMV.

Migrating from JES3 DASD management to SMS (also mentioned to previously) 
helped, but, off the cuff, in no particular order, there are other features to 
consider, such as:
 - JES3 tape management
 - DEADLINE scheduling
 - DJC

These have have viable alternatives, if you can spend the time and/or money.  I 
agree a trip through the aforementioned Redbook(s), white papers, and a few 
SHARE presentations (the "bi-JESual" pitch comes to mind) will be well worth 
the investment in time.  

Regards,
Art Gutowski
General Motors, LLC

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

Re: Why doesn't "="option work in SMP/E panels?

[Art Gutowski]

>I also use  where appropriate and have added SCRNAME to most entries. 
>Very useful when using SWAPBAR. 
The introduction of SWAPBAR (combined with SCRNAME) was terrific.  

> You want SMPE, type SMP or SMPE, you want RACF, type RAC or RACF. SYSLOG? 
> Type SL.  Operlog?  Type OL. 
Neat!  Just FYI, some of these are also provided in ISPF, if by different names:

>ISRDDN? Type DDN. 
Or DDLIST. BTW, I use APF, LINK, and PARMLIB extensively (PROCLIB would be very 
useful, too), as well as MEMBER search, which is also available from...

>3.4 DSL
Or DSLIST (if you don't mind the extra keystrokes).  Without parms brings up 
your reflist, with a parm will bring up a dataset listing just as it would from 
the 3.4 panel.  But, alas, it only deals with cataloged datasets.
 
There's more... "Settings" stacks the Settings Panel into your active session.  
There's also UDLIST (3.17).  I haven't looked at "ISPF Hidden Treasures" in a 
while, so I'm sure there are others.
Regards,
Art Gutowski
General Motors, LLC

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

Re: Economics of Mainframe Technology

[Art Gutowski]

If my notes are accurate from Ross' Keynote address to SHARE attendees in 
Seattle, mainframes account for 68% of production workloads, but only 6% of IT 
spend (exclusive of aggregate labor costs across platforms).  Given the armies 
of sysadmins to support *nix and windoze platforms, I gotta believe labor costs 
on these platforms eclipse those of the mainframe.

I am passing the webinar info along to my senior management...

Thanks,
Art Gutowski
GM IT Senior Mainframe Specialist
arthur.gutow...@gm.com

On Tue, 10 Mar 2015 16:38:37 -0300, Lucas Rosalen rosalen.lu...@gmail.com 
wrote:

Wow, those are big numbers! Thank you, Tom.
This seems to be a good thing to be shared with techies, but specially with
management. I'm looking forward to it.

Thanks,

---
*Lucas Rosalen*
Emails: rosalen.lu...@gmail.com / *lrosa...@br.ibm.com
lrosa...@br.ibm.com*
LinkedIn: http://br.linkedin.com/in/lrosalen
Phone: +55 19 9-8146-7633

2015-03-10 15:47 GMT-03:00 Tom Marchant 
000a2a8c2020-dmarc-requ...@listserv.ua.edu:

 I just received word of this and thought others on the list might find it
 interesting.


 Compuware is hosting a webcast with renowned expert in technology
 economics,
 Dr. Howard Rubin. Dr. Rubin will be presenting his most recent findings on
 the
 growing consumption of technology and its impact on core infrastructure
 costs.
 His research compares the resulting costs for a mainframe-heavy
 organization to
 a server-heavy organization.

 Title: The Surprising Economics of Mainframe Technology
 Date: March 19
 Time: 11:00 a.m. ET
 Duration: 60 minutes

 [...]

 On the webcast, he will be speaking to the following findings:

 o   While computing power has doubled over the last five years,
 server-heavy organizations’ costs have gone up 63% more than
 mainframe-heavy organizations.
 o   For every $1 that’s spent on infrastructure costs, Mainframe
 organizations earn $10.55 while server-heavy organizations earn
 only $8.22.
 o   Analysis across 15 industries shows that the average IT cost of
 goods is 35% (on average) less for mainframe-heavy organizations,
 with the greatest differences in the financial sector.

 Dr. Rubin will be joined by two industry thought-leaders, Ross Mauri,
 General
 Manager, IBM z Systems and Chris O’Malley, CEO of Compuware. Ross will
 answer
 questions about mainframe misperceptions and the new capabilities of the
 z13,
 while Chris will discuss how increasing technical demand on the mainframe
 is
 impacting IT and the entire business.


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

Re: Local Page dataset sizing/quantity ROT?

[Art Gutowski]

On Mon, 6 Jan 2014 12:44:42 -0500, Rob Schramm rob.schr...@gmail.com wrote:

Does it really matter as much as it used to?  The amount of cache on a dasd
subsystem and overall i/o seems more relevant for paging spikes.  Not that
i am advocating a complete dismissal of all the normal considerations..
but since writes are done to cache..  isn't it the foremost attribute these
days?

Normal considerations including page-ins in parallel with VIO and perhaps SVC 
dump capture.  Cache will not relieve an I/O bottleneck even if you have 100GB 
of paging space, with 100GB of cache in front of it, with nothing else using 
that cache, if that 100GB is defined on 1 EAV.  IOSQ can be a problem if paging 
datasets or volumes are too large and too few.  Hence my emphasis on 
questioning page dataset and page volume counts, and follow up considerations 
for HiperPAV.  I was more interested in the software view of paging 
configuration, but I am learning some interesting things about hardware along 
the way.

Regards,
Art Gutowski
General Motors Corporation

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

Re: Local Page dataset sizing/quantity ROT?

[Art Gutowski]

I, too, have been watching this thread with interest.  I read much on overall 
sizing, but little on individual page dataset sizing or count (quantity).  I 
have perused past posts where those particulars have been discussed, but am 
curious as to whether any new experiences has lead folks to adjust the number 
and placement of their page datasets...

Regards,
Art Gutowski
General Motors Corporation

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

Re: LLA refreshed automatically with SETPROG ACTIVATE command

[Art Gutowski]

On Thu, 11 Jul 2013 01:31:26 -0500, Elardus Engelbrecht 
elardus.engelbre...@sita.co.za wrote:

But if I were you, I would do F LLA,REFRESH anyways and also SETPROG 
LNKLST,UPDATE,JOB=*

On a busy (with applications up and running), production system, I wouldn't.  
On a test system, or a system where applications have been quiesced, and hence 
an IPL would not cause the business owners heartburn, I might, and I have.

The books warn of the dangers of performing an UPDATE JOB=*, and I, for one, 
take that advice seriously.  I've never had an UPDATE=* crash a system, but 
then, I've not performed it during full-tilt-boogie production, nor have I 
tried to remove or relocate SYS1.LINKLIB, for example.  Even UPDATE JOB=jobname 
can impact that one job.  All it takes is one ill-timed fetch, and it's take 
two IPLs, call me in the morning...

But, as wise man (or is that wise guy) has said, It's not my dog.

Regards,
Art Gutowski
Compuware Corporation

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

Re: XCF / GRS

[Art Gutowski]

On Tue, 25 Jun 2013 15:47:09 -0500, Shane Ginnane ibm-m...@tpg.com.au wrote:

I'm was surprised to see GRS utilising XCF still on ESCON these days, but ring 
is still out there. In this town of less than a handful of sites, one recently 
had to do the ESCON to FICON in a hurry to get a couple of EC12s in the door, 
and another isn't in a position to take an outage to do the change at the 
moment.

If all goes according to Hoyle, no outage is necessary.  If the hardware or 
z/OS release does not support FICON, or they are not enabled for dynamic I/O 
reconfiguration (I haven't seen these conditions in a decade or more, but I can 
believe it's still out there), then clearly an outage (or three) will be 
needed.  If they are in a mixed GRS complex, the documentation provided by 
others in this thread will spell out the requirements.

Plan, then define the new CTC links to HCD and ACTIVATE the updated config.  
SETXCF START PATHIN/PATHOUT commands to allocate and start transmitting over 
the new devices.  SETXCF STOP PATHIN/PATHOUT commands to stop traffic on the 
old devices.  Unless I'm missing something obvious (been a few years since the 
migration at my last shop), and Bob's your uncle and Fanny's your aunt.  Oh, 
yeah...remember to update PARMLIB for the next IPL.

Migration to STAR is a little harder if you don't already have a CF for the 
Sysplex, or if you don't have enough storage to accommodate the ISGLOCK 
structure, otherwise, this too can be done dynamically (fallback sucks though).

Cheers,
Art

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

Re: XCF / GRS

[Art Gutowski]

On Tue, 18 Jun 2013 12:51:14 -0400, August Carideo august.cari...@avon.com 
wrote:

Has anyone converted XCF / GRS ( CNC / CTC ) from ESCON to FICON ?
we are looking into this because EC12 has no ESCON thanks to those
Einsteins at IBM
[...]
But this question is really geared towards GRS etc. so ignore rest of my
rant

It's not that bad.  I liked not having to track CTC/CNC pairs any more.  At a 
previous shop the migration was seamless, however...

- We moved from shared ESCON channels.  From experience, dedicated ESCON (or 
3088) migration to shared FICON CTCs are more involved.  If you are on 
dedicated paths, take the time and effort to understand and implement shared 
CTCs.  I took a page from a colleagues' playbook and drew a chart for the 
migrations.  Adding in devices later was much easier with established numbering 
conventions.  Pay particular attention to CUADD on your CTC control units.

- We had FICON directors to run the FCTC channels through.  If you have more 
than one CEC, especially if you are connecting across buildings, FICON 
directors are worth consideration for redundancy and bandwidth.  While 
directors also enable you to share FCTC channels with other devices, I wouldn't 
recommend piggy-backing XCF CTCs with other devices.

- Obtain and read the FICON Planning and Implementation Guide Redbook:
http://www.redbooks.ibm.com/abstracts/sg246497.html?Open

There is a FICON CTC RedPaper, but it's over 10 years old, and hopefully 
incorporated into the Redbook.

Good luck,
Art Gutowski

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

Re: SMP/E HOLDSYSTEM after REJECT

[Art Gutowski]

On Mon, 15 Apr 2013 18:31:55 -0500, Paul Gilmartin paulgboul...@aim.com wrote:

I have done a successful REJECT SELECT for a PTF which contained
internal HOLD data:

++ HOLD(%sysmod%)  SYSTEM  REASON(RESTART)  FMID(%fmid%)
DATE(13001)  COMMENT( Whatever. ) .
++ HOLD(%sysmod%)  SYSTEM  REASON(DOC)  FMID(%fmid%)
DATE(13001)  COMMENT(Test internal HOLD.).

[...]  

Is there any way to make that PTF and all its collateral damage go
away, really away, as if it never happened?

REJECT HOLDDATA SELECT(%sysmod%).  Or use the dialogs to generate the REJECT 
command and set REJECT HOLDDATA to YES.  It will reject the associated SYSTEM 
HOLD(s) even though the SYSMOD(s) have been previously rejected.  You will see 
the %sysmod% in the rejected report (again) when the HOLD DATA is deleted.

[...]  

If I restructure the PTF, removing the internal HOLDDATA, will they
still be present in the GLOBAL zone, and require a BYPASS to APPLY
or ACCEPT the restructured PTF?

IMHO, it is bad form to modify a PTF after its been received, even more so 
after apply, because yes, until you REJECT the HOLD DATA, you will need a 
BYPASS HOLDSYS to apply the SYSMOD, which seems counter to your intention.

Regards,
Art Gutowski
Compuware Corporation

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

Re: IGD17271I under ISPF but only sometimes

[Art Gutowski]

On Thu, 14 Feb 2013 18:31:40 -0600, Jim Mooney jmoo...@princesscruises.com 
wrote:

Can anyone explain why?  Does ispf suppress informational msgs, while the 
FileAid application does not?
(I know... next step call the vendor) but thx for any input,

Jim,

It is not that ISPF suppresses the informational (or any) messages, but the 
WTPMSG PROFILE setting (see TSO/E SYSHELP on PROFILE).  This can be overridden 
from a Clist (or EXEC) via CONTROL MSG/NOMSG, which sets SYSMSG (see the TSO/E 
Clist manual).

I do not work on File-AID, so I cannot speak to what it suppresses (or 
unsuppresses).  I recommend that you do indeed take the next step and contact 
our support center for assistance.  You may also want to search Frontline for 
any recent and related fixes or tech bulletins.

Regards,
Art Gutowski
Compuware Corporation

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

Re: Password (was: slightly O/T but interesting)

[Art Gutowski]

On Wed, 23 Jan 2013 13:31:31 -0600, John McKown john.archie.mck...@gmail.com 
wrote:

I can top that. On the Windows side a person called in because they
forgot their Windows login id (not password). At that time it was
first initial plus last name. How could they have forgotten who they
were, but remember where they worked?

http://www.youtube.com/watch?v=pvn-tBeLpCk

You forgot your name?
I been busy!

Regards,
Art Gutowski

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

Re: SMP/E GIM37904E vs. GIM24504E

[Art Gutowski]

On Fri, 7 Dec 2012 12:29:43 -0600, Paul Gilmartin paulgboul...@aim.com wrote:

It seems to me that it would be terribly easy to introduce inconsistencies
in a CSI with UCLIN.  For example, might my DEL SYSMOD have left
dangling RMID subentries or dangling PRErequisities?  Or does UCLIN
processing prevent or automatically repair those?  If not, is there anything
like a CSI health checker that would report any such inconsistencies?

This is precisely the risk with using UCLIN to update content entries.  Refer 
to:  
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/GIMCOM50/24.0

Be sure you understand the relationships between the various entries before 
making any UCLIN changes. This helps ensure that any UCLIN changes you make are 
complete and consistent with one another. When SMP/E processes UCLIN, it checks 
only the specified entry. It does not check how the changes might affect other 
entries.

I am not aware of any such health checker.  Short of dumping your CSI (with 
LIST or GIMAPI) and running through some RYO (perhaps CBT contains one) 
post-processor, subsequent maintenance is the only way I know of to find such 
problems lurking.

I assume my APPLY REDO; RESTORE has refreshed then obliterated any
subentries concerning my PTF.

In theory, yes, as long as you did not change the affected elements, 
particularly as long as you did not remove any elements from subsequent 
revision of the PTF.  My advice:  trust, but verify.

Regards,
Arthur Gutowski
Compuware Corporation

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

Re: SMP/E question

[Art Gutowski]

On Wed, 10 Oct 2012 08:36:42 -0700, Skip Robinson jo.skip.robin...@sce.com 
wrote:

I've said previously that a DOC record requiring action should be
(re)classified (or accompanied by) an ACTION hold. ENH in practice seems
to be a subset DOC: informative but not requiring immediate action.

Agreed, with the operative word being *should*... Not very often these days, 
one slips through, the offender is rightly castigated by an astute sysprog, and 
others are hopefully spared the (hopefully innocuous) oversight.  I tried to at 
least skim the DOC holds just in case there was anything obviously 
mis-classified.

Regards,
Art Gutowski
Compuware

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

Re: SMP/E question

[Art Gutowski]

On Wed, 10 Oct 2012 00:07:34 -0500, Shmuel Metz (Seymour J.) 
shmuel+...@patriot.net wrote:

There seems to be disagreement as to how to handle other types of
holds as well. In particular, I consider it risky to bypass action or
doc holds without first reading the comments in the hold or cover
letter.

Agreed.  How else would you identify and address pre-APPLY requirements?

Regards,
Art Gutowski
Compuware

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

Re: GIM39001E in SMP/E RECEIVE FROMNTS

[Art Gutowski]

On Tue, 25 Sep 2012 17:42:12 -0500, Paul Gilmartin paulgboul...@aim.com wrote:

Perhaps even more relevant is the ordering among PREs and SUPs of PTFs,
where order of SYSMODs in SMPPTFIN under a single APPLY command doesn't
matter.

SMPPTFIN is not read during APPLY.  That would be SMPPTS.  PREs and SUPs don't 
matter to RECEIVE, only VER SREL and FMID.

Regards,
Art Gutowski
Compuware

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

Re: GIM39001E in SMP/E RECEIVE FROMNTS

[Art Gutowski]

On Wed, 26 Sep 2012 08:56:21 -0500, Paul Gilmartin paulgboul...@aim.com wrote:
But still, if RECEIVE tolerates processing a SYSMOD prior to its PRErequisites 
on the assumption that
APPLY will sort things out, I might hope for the same flexibility with respect 
to FMID.

RECEIVE doesn't so much tolerate as it ignores PRErequisites (co-requisites, 
negative requisites, etc.).  That really has to be left up to APPLY/ACCEPT to 
figure out for the zone into which the SYSMODs are to be installed.  All 
RECEIVE validates is SREL and FMID for an incoming SYSMOD.  It would not be 
practical to sift through all of the combinations in all of the Target and 
Distribution zones to validate eligibility down to *requisites.  Complex enough 
if you have varied FUNCTIONs installed under an SREL from one D/T zone to the 
next, but at a small shop, many moons ago, I was weird enough to have multiple 
SRELs in a common Global (not in any common D/T zone, however).

In a prior post, I attempted to ask about such flexibility with FUNCTION 
SYSMODs akin to ASSIGN processing.  I'm hoping Kurt can shed some light.

Does the order in which SYSMOD names appear in a SELECT option matter, either 
to RECEIVE or to APPLY?

Not to RECEIVE, as far as I read from SMP/E Commands, and cetainly not to 
APPLY, neither from the book nor from my experience with it.  If SMP/E 
Reference says otherwise, I have not stumbled across a passage that says so.  
This was another question I tried to ask (albeit not clearly), again hoping 
Kurt will respond.

Also, I meant to ask about this statement your original post:

RECEIVE SELECT(
F1
F2
F3
) FROMNTS(SMPNTS-path)

Was this a typo or intentional?  The rest of what follows lists E2 and E3, 
which I am surprised RECEIVE would process since these are not part of the 
SELECT, unless F2/F3 are FMIDSETs?

Regards,
Art Gutowski
Compuware

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

Re: SMP/E RECEIVE FROMNETWORK vs. fchattr()

[Art Gutowski]

On Tue, 25 Sep 2012 11:19:38 -0400, Kurt Quackenbush ku...@us.ibm.com wrote:

 I've long wished that:

 o GIMZIP could build its product from non-catalogued data sets, perhaps
unloaded RELFILEs on tape, passed temporary DSNs, or MCS/JCLIN in
PDS members or UNIX files.  I'd like to be able to transform an SMP/E
installation tape to a GIMZIP archive without copying the parts to
transitory catalogued data sets.

 o The producer's local data set names could be redacted from the
GIMPAF file in order not to expose data set prefixes (which may
be TSO user IDs) to customers.

If the archid was used to store the archives in the package, and the name 
tag in the GIMPAF.XML was of the form SMPRELF/archid.pax.Z, Would that meet 
redaction requirements?  If archid=FMID.Fnn, for example, then name would be 
SMPRELF/FMID.Fnn.pax.Z (even name=SMPRELF/RFDSNPFX.FMID.Fnn.pax.Z would be 
passable)  Not to discourage DDNAME support, mind you... 

 Both these desiderata could be addressed if GIMZIP supported using
 DDNAMEs to identify its source data and used the data set names from
 its control file in the generated GIMPAF.

I understand your desires.  BTW, GIMZIP does support input UNIX files.

LLB, learned something new today.  Absolute pathnames only, though...similar 
redaction requirements may apply.

Regards,
Art Gutowski
Compuware

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

Re: GIM39001E in SMP/E RECEIVE FROMNTS

[Art Gutowski]

On Mon, 24 Sep 2012 09:18:09 -0400, Kurt Quackenbush ku...@us.ibm.com wrote:
Presumably the MCS for each SYSMOD is in a unique data set?  If so, then
yes, the order in which the archives for those data sets appear in the
GIMPAF.XML file determines the order in which they will be processed
during the RECEIVE.

Why does it matter whether each is in a unique dataset?  If FMIDs are selected 
from an alphabetical list and dropped into a common MCS during build, wouldn't 
this problem still manifest?  With IBM products its usually Hcc for base 
and Jcc for dependent, so GIMPAF order will be alpha order.  Apparently not 
everyone follows that convention.

Why does order matter?  Is it because the FMID list in the GZONE entry is not 
updated until RECEIVE processing for that SYSMOD is complete, only after which 
it moves on to the next?  Just curious and trying to contrast with ASSIGN 
statements in RECEIVE processing where order is unimportant.

Thanks,
Art Gutowski
Compuware

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

Another Mainframe Shuts Down

[Art Gutowski]

U of M Health Systems in Ann Arbor will be unplugging their mainframe.

http://umhsheadlines.org/07/mainframe-to-be-decommissioned-by-the-end-of-the-year/

Regards,
Art Gutowski
Compuware

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

Re: SMPE Question

[Art Gutowski]

On Tue, 21 Aug 2012 08:48:19 -0500, Richard Sandford rsandf...@healthplan.com 
wrote:

What would be the fastest, easiest way to rebuild a TARGET zone?
It appears a product (DB2 v9) was accepted early last year and now I need to 
put on some maintenance, but it looks like some *Merge operations have been 
done and now the target zone looks way out of wack.  
DLIB and DIST libraries appear to be OK, Target libraries look OK.
I'm hoping I don't have to re-receive DB2 v9 to put everyting back, although 
that would bring us up to current maintenance levels ...
Any help would be very much appreciated.

Backups fell off the end of retention?  Yikes.

If you're looking to unmerge, the closest thing I can suggest is BUILDMCS.  
Refer to the SMP/E Command Reference.  It will be tedious, but maybe no more so 
than re-ordering and re-installing from scratch (depending on how many hoops 
you typically jump through for order approval).

Good luck,
Art Gutowski
Compuware Corporation

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

Re: Parallel Sysplex Online Training

[Art Gutowski]

On Mon, 13 Aug 2012 15:00:38 +0530, saurabh khandelwal 
sourabhkhandelwal...@gmail.com wrote:
   I checked with interskill but they don't have
advanced course. for parallel sysplex they just have basic one, which
doesn't include any setup and system programmer stuff.
   Because of cost, we have issue in getting travel
approval. Can you please help me finding any virtual class session.

I'm sorry, but for online training, I haven't found anything beyond the basics, 
such as what Interskill provides.  

Perhaps as Lizette posted, SHARE (www.share.org) could set something up in the 
not-too-distant future.  Something along the lines of the Assembler Boot Camp - 
if only they had gotten a good recording of all five sessions :( - would be 
fantastic.  I should think zNextGen would be the best host for such a 
project.  If you're not a member, talk to your management about becoming one.  
I understand cost is an issue, but in my experience, the ROI is off the charts. 
 At least establish a non-member account so you have access to public content 
and forums.

Regards,
Art Gutowski
Compuware Corporation

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

Re: Parallel Sysplex Online Training

[Art Gutowski]

On Mon, 13 Aug 2012 06:52:57 -0500, Jim Marshall jim.marsh...@opm.gov wrote:
Not to plug Peter Enrico's new Parallel Sysplex available class, but if I was 
new to Sysplex, it would be worth the money to sit at the feet (as close as a 
Web session could get me) of the Master.   Here some info I got late last 
week. 

Not to take anything away from Peter Enrico (SHARE sessions and panel 
discussions he led helped me immensely at previous shops; in fact he was 
contracted to help optimize performance at a prior employer), but his focus is 
performance.  Saurabh is looking for more...

On Mon, 13 Aug 2012 15:00:38 +0530, saurabh khandelwal 
sourabhkhandelwal...@gmail.com wrote:
   I checked with interskill but they don't have
advanced course. for parallel sysplex they just have basic one, which
doesn't include any setup and system programmer stuff.

I have yet to find any virtual training that meets this need.

Regards,
Art Gutowski
Compuware Corporation

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

Re: Auditors Don't Know Squat!

[Art Gutowski]

On Thu, 2 Aug 2012 15:49:55 -0500, McKown, John john.mck...@healthmarkets.com 
wrote:


What is the most secure computer? The one that is powered off and locked in a 
vault!

...cast in concrete and scuttled to the ocean floor.  And even then, I'm not 
certain.

Art

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

Re: SMF volume - follow-up

[Art Gutowski]

On Fri, 22 Jun 2012 11:29:59 -0700, Edward Jaffe edja...@phoenixsoftware.com 
wrote:

On 6/22/2012 7:00 AM, Mark Zelden wrote:
 Reminds me of a joke in the recording studio when doing a mix and
 to make everything louder than everything else.  :-)

Or when on-stage and everyone keeps turning up their volume... :-)

That's why my amp goes to 11! :)

Art

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