Re: Old usercatalogs with IMBED and REPLICATE

2013-07-22 Thread John Eells 

Shameem .K .Shoukath wrote:

hi John,
snip>
Are you suggesting this parms has no performance implication? as documented in  
 IGGHC104E  message



Not exactly.  From what I'm told, the minor space savings and 
performance improvements to be had by "removing" these attributes are 
not, by themselves, worth making a catalog unavailable for the time 
required to do that.  (If you happen to reallocate the catalog for any 
other reason, this will of course take care of itself.)


There are always edge cases, of course.  A catalog on the cusp of 
needing to be split for performance-related reasons might be improved 
"just enough" if reallocated without IMBED and REPLICATE to buy you some 
time.


There are other reasons to proceed, too, which have been listed by other 
posters.  YMMV...


--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
ee...@us.ibm.com

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

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-20 Thread Ted MacNEIL 
>Are you suggesting this parms has no performance implication? as documented in 
>  IGGHC104E  message

He stated: No significant performance impact to justify an outage for removal.

There's a difference between significant and none.

I agree with the expert:
1. The 'impact' is more than mitigated by the performance of today's DASD.
2. The cost of space is so little compared to what it was when these parameters 
were introduced.
3. How do you justify the outage for something this insignificant?
4. Rather than listening to the scare tactics (and ridicule) of others on this 
list, cost it out for your shop (not others). If the numbers work, then do it 
(I'd be surprised if you manage to justify it).
-
Ted MacNEIL
eamacn...@yahoo.ca
Twitter: @TedMacNEIL

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

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-20 Thread Joel C. Ewing 
There is a small performance hit on current DASD with keeping the
obsolete IMBED REPLICATE structures , as John Eells has already implied
by use of "significant" in his statement that there is "no SIGNIFICANT
performance or space advantage".  The consensus in shops requiring 24x7
availability is the small, "no significant impact" is much preferred to
any outage or risk required to reorganize a catalog.

Now if you have any IMBED REPLICATE catalogs defined with
sub-cylinder-sized CA's, which would probably be unusual, then that
could increase the hit:  a catalog defined with a CA size of 3 tracks
would be throwing away 1/3 of its space on useless replicated INDEX CI
overhead, and a much higher percentage of its physical reads and writes
would be for redundant data. But that would be unusual, as typically
CYLINDER allocation was used for even small catalogs, which assured a
15-track CA size, precisely because even with old DASD that gave the
maximum benefit from IMBED REPLICATE at the minimum overhead cost.

If you are not constrained by 24x7 requirements, or have to take an
outage to move or resize a catalog anyway, then getting rid of the
obsolete structures at the same time is goodness.  We always went to a
new master catalog with a new release of z/OS, so for us only the
USERCATs were an issue, and over a period of years we eventually had to
resize or move all of them and took care of the issue at that point for
each.
JC Ewing

On 07/20/2013 06:17 AM, Shameem .K .Shoukath wrote:
> hi John,
> 
>   The Health checker points these parms as a performance affecting parms. 
> Also IGGHC104E in MVS System
> Messages Vol 9 for z/OS .13  Says
> The
> IMBED and REPLICATE attributes were intended as performance improvements but
> have proven to be otherwise. They have proven
> towaste
> DASD space and degrade performance. They have been obsoleted  by the
> newer, cached DASD devices. In some cases, unplanned
> outages have
> occured. No supported release of z/OS allows you to define a  user catalog
> or master catalog with either the IMBED or
> REPLICATE   attributes.
> IBM intends to drop support for these attributes in the
>  future.   
>  in our shop we have many catalogs (defined a long time back) has these parms 
> coded and Health checker warns about this. 
> 
> Are you suggesting this parms has no performance implication? as documented 
> in   IGGHC104E  message
>  
> 
> 
> 
> 
> Thanks and Regards
> Shameem K Shoukath
>  
>  
> 
> 
> 
>> ____________
>> From: John Eells 
>> To: IBM-MAIN@LISTSERV.UA.EDU 
>> Sent: Wednesday, July 17, 2013 6:01 PM
>> Subject: Re: Old usercatalogs with IMBED and REPLICATE
>>
>>
>> Richard Marchant wrote:
>>> Before you install Z/OS 1.13 do you need to remove the IMBED and REPLICATE 
>>> parameters from your old Usercatalogs or will they co-exist with  Z/OS 
>>> 1.13?  We are currently running Z/OS 1.11 and a number of the Usercatalogs 
>>> have the IMBED parameter with no obvious ill affect.
>>
>> As others have said, "No."  You need not do anything.  There are no 
>> current plans for removing this support, either.
>>
>> Also, I am reliably told that there is no significant performance or 
>> space advantage to be had that justifies making a catalog unavailable 
>> solely for the purpose of removing these attributes.
>>
>> -- 
>> John Eells
>> z/OS Technical Marketing
>> IBM Poughkeepsie
>> ee...@us.ibm.com
>>
...


-- 
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

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

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-20 Thread John Gilmore 
This post is a response to a question that was, I am all but certain,
addressed not to me but to another John, John Eells.

z/OS is a large, powerful, and complex operating system.  It is
heterogeneous too.  Some of it has been rearchitected (a barbarous but
now inescapable word) to reflect z/Architecture; some, much of it, is
yet to be updated; and some, we arfe told, may never be.

It is thus full of vermiform appendices, no longer relevant facilities
left behind as it evolved that are now perhaps dysfunctional but not
crippling.

IMBED and REPLICATE are excellent examples.  They are today without
function. They are indeed mildly dysfunctional.

IBM's efforts to shed such facilities always meet with a storm of
protest from customer management, which almost never has any very
clear idea of what it is protesting about but does know that it is
being asked to expend resources 'gratuitously'.  Why not let sleeping
dogs lie?

The real objection to old, usually very old, catalogs containing IMBED
and REPLICATE is not that they waste resources in a very small way.
It is that they should long since have been replaced by more modern
catalog structures and, in organizations dedicated to stasis, have not
been.

These organizations are reactionary, but they do not wish to be called
reactionary, and here some latin is actually useful: 'reactionary' can
be replaced by 'laudator temporis acti' or even by the acronym LTI,
which is much less offensive restated in what Gibbon called "the
decent obscurity of a learned language".

Problems of this kind are not of course new.  Many of the automobiles,
'horseless carriages', produced in the late nineteenth century in both
Europe and North America came equipped with buggy-whip holders.  It
was pointed out early on that these holders were now dispensable.
Internal combustion engines are at best unresponsive to flagellation.
Some nevertheless wished to retain them 1) for sentimental reasons or
2) because it would be costly and diversionary to remove them.

Topics of this kind arise with some frequency on IBM-MAIN; and they
often stir up more interest and participation than substantively
important ones, perhaps because they are easier to understand.   All
this is drôle.  What is less so is the spectacle of able men and women
crafting careful defenses of the indefensible.

John Gilmore, Ashland, MA 01721 - USA

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

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-20 Thread Shameem .K .Shoukath 
hi John,

  The Health checker points these parms as a performance affecting parms. Also 
IGGHC104E in MVS System
Messages Vol 9 for z/OS .13  Says
The
IMBED and REPLICATE attributes were intended as performance improvements but
have proven to be otherwise. They have proven
towaste
DASD space and degrade performance. They have been obsoleted  by the
newer, cached DASD devices. In some cases, unplanned
outages have
occured. No supported release of z/OS allows you to define a  user catalog
or master catalog with either the IMBED or
REPLICATE   attributes.
IBM intends to drop support for these attributes in the
 future.                                                               
 in our shop we have many catalogs (defined a long time back) has these parms 
coded and Health checker warns about this. 

Are you suggesting this parms has no performance implication? as documented in  
 IGGHC104E  message
 




Thanks and Regards
Shameem K Shoukath
 
 



>
> From: John Eells 
>To: IBM-MAIN@LISTSERV.UA.EDU 
>Sent: Wednesday, July 17, 2013 6:01 PM
>Subject: Re: Old usercatalogs with IMBED and REPLICATE
> 
>
>Richard Marchant wrote:
>> Before you install Z/OS 1.13 do you need to remove the IMBED and REPLICATE 
>> parameters from your old Usercatalogs or will they co-exist with  Z/OS 1.13? 
>>  We are currently running Z/OS 1.11 and a number of the Usercatalogs have 
>> the IMBED parameter with no obvious ill affect.
>
>As others have said, "No."  You need not do anything.  There are no 
>current plans for removing this support, either.
>
>Also, I am reliably told that there is no significant performance or 
>space advantage to be had that justifies making a catalog unavailable 
>solely for the purpose of removing these attributes.
>
>-- 
>John Eells
>z/OS Technical Marketing
>IBM Poughkeepsie
>ee...@us.ibm.com
>
>--
>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: Old usercatalogs with IMBED and REPLICATE

2013-07-18 Thread R.S. 

W dniu 2013-07-18 12:38, Scott Chapman pisze:

TDMF has worked fairly well for us for migrating between control units without 
taking an outage. Just did so within the last month matter of fact. I thought 
it was fun (and useful) that D IPLINFO shows both the original address you 
IPL'ed from as well as the current. I don't remember noticing that last time we 
did a TDMF migration (~4.5 years ago), but I may simply not have looked.

IEE254I  06.33.28 IPLINFO DISPLAY 326
  SYSTEM IPLED AT 11.20.21 ON 05/19/2013
  RELEASE z/OS 01.12.00LICENSE = z/OS
  USED LOAD0J IN SYS1.IPLPARM ON 04678
  ARCHLVL = 2   MTLSHARE = N
  IEASYM LIST = (MJ,L)
  IEASYS LIST = (MJ) (OP)
  IODF DEVICE: ORIGINAL(0624A) CURRENT(04678)
  IPL DEVICE: ORIGINAL(06252) CURRENT(04304) VOLUME(RES600)

Non-disruptive application releases take a little more work. I believe it's not 
necessarily impossible though, depending on how the application is architected 
and how much effort you want to put into it.



Scott,
I'm aware of TDMF and realize that application release could be 
non-disruptive - this is code (software) and data - as in microcode 
upgrades or z/OS migrations. However it wasn't my point. My point was 
that even if someone claims no planned outages, that usually means "no 
planned regular "tech windows", but does not include software releases 
or (sometimes) does not include hardware change. BTW: There is a *big* 
difference between preparatin of new software release and preparation 
new software release *and* non-disruptive rollout. That's at least 
opinion claimed by authors of i390 (CPC microcodes). Note they don't 
have multi-TB databases with possible data model changes.
Last, but not least: sometimes "binary approach" is not applicable, for 
example you can shut majority of software modules/functionality, but 
keep some 24x7 part alive during the process. Partial outage.


Regards

--
Radoslaw Skorupka
Lodz, Poland


P.S. What about people having maint windows and still using obsolete things?



--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. 


BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2013 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.555.904 złotych.



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

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-18 Thread Scott Chapman 
TDMF has worked fairly well for us for migrating between control units without 
taking an outage. Just did so within the last month matter of fact. I thought 
it was fun (and useful) that D IPLINFO shows both the original address you 
IPL'ed from as well as the current. I don't remember noticing that last time we 
did a TDMF migration (~4.5 years ago), but I may simply not have looked.

IEE254I  06.33.28 IPLINFO DISPLAY 326  
 SYSTEM IPLED AT 11.20.21 ON 05/19/2013
 RELEASE z/OS 01.12.00LICENSE = z/OS   
 USED LOAD0J IN SYS1.IPLPARM ON 04678  
 ARCHLVL = 2   MTLSHARE = N
 IEASYM LIST = (MJ,L)  
 IEASYS LIST = (MJ) (OP)   
 IODF DEVICE: ORIGINAL(0624A) CURRENT(04678)   
 IPL DEVICE: ORIGINAL(06252) CURRENT(04304) VOLUME(RES600) 

Non-disruptive application releases take a little more work. I believe it's not 
necessarily impossible though, depending on how the application is architected 
and how much effort you want to put into it. 

Scott Chapman

On Wed, 17 Jul 2013 20:59:57 +0200, R.S.  wrote:

>Q3. How do you move your datasets from old DASD to a new one?

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

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-17 Thread Shmuel Metz (Seymour J.) 
In
,
on 07/17/2013
   at 09:31 AM, John Gilmore  said:

>Using his own criterion Shmuel's '24x265' is just plain wrong too,
>but '2' and '3' are adjacent on all of the keyboards I am familiar
>with, and what we have here is all but certainly a typo.

One-off, transposed, dropped and duplicated letters seem to be my most
common typos.

>On the computer-technology time scale IMBED and REPLICATE, once
>chic, are now dysfunctional creatures of the remote past.  Their
>presence in

Agreed, and I sympathize with those whose management won't let them
migrate to new catalogs. It reminds me of the longevity of ISAM.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-17 Thread Ted MacNEIL 
That, in a nutshell, was the issue in the two places I worked that was 
considered unacceptable before IBM shelved it.
Totally unpalatable, afterwards.
-
Ted MacNEIL
eamacn...@yahoo.ca
Twitter: @TedMacNEIL

-Original Message-
From: Mark Zelden 
Sender:   IBM Mainframe Discussion List 
Date: Wed, 17 Jul 2013 14:56:44 
To: 
Reply-To: IBM Mainframe Discussion List 
Subject: Re: Old usercatalogs with IMBED and REPLICATE

On Wed, 17 Jul 2013 11:49:07 -0400, John Gilmore  wrote:

>.  As Mark's most recent post makes
>clear, change, any change, no matter how trivial, is viewed as the
>enemy bcause dangerous: Dragons be here!
>

You completely missed the main point of my post - availability.
The catalog must be offline during the time needed to "fix" this issue. 

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS   
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html 
Systems Programming expert at http://expertanswercenter.techtarget.com/

--
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: Old usercatalogs with IMBED and REPLICATE

2013-07-17 Thread Ted MacNEIL 
But, the tools cost money!
--Original Message--
From: Gibney, Dave
Sender: IBM Mainframe Discussion List
To: IBM-MAIN@LISTSERV.UA.EDU
ReplyTo: IBM Mainframe Discussion List
Subject: Re: Old usercatalogs with IMBED and REPLICATE
Sent: 17 Jul 2013 16:10

But, the tools available from either of the Catalog addon companies can shorten 
or almost entirely avoid this outage.
I did all my user catalogs during low activity periods. I did need to do my 
masters from a different lpar as I ipled the affected lpar.
Granted I am small, not sysplexed and don't do much catalog sharing.

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Mark Zelden
> Sent: Wednesday, July 17, 2013 12:57 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Old usercatalogs with IMBED and REPLICATE
> 
> On Wed, 17 Jul 2013 11:49:07 -0400, John Gilmore 
> wrote:
> 
> >.  As Mark's most recent post makes
> >clear, change, any change, no matter how trivial, is viewed as the
> >enemy bcause dangerous: Dragons be here!
> >
> 
> You completely missed the main point of my post - availability.
> The catalog must be offline during the time needed to "fix" this issue.
> 
> Mark
> --
> Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
> mailto:m...@mzelden.com
> Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
> Systems Programming expert at http://expertanswercenter.techtarget.com/
> 
> --
> 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

-
Ted MacNEIL
eamacn...@yahoo.ca
Twitter: @TedMacNEIL

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

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-17 Thread John Gilmore 
Allen Staller wrote:


Any currently processing jobs can wait for the completion of the event
(minutes), with no disturbance.


Agreed for batch jobs.  Online applications may require more planning,
but the problem of brief catalog unavailability is manageable, must
indeed be manageable for a host of other reasons.

It seems to me that Mark "completely missed the main point of my
post", which was that the energy devoted to finding reasons for not
doing things might better be devoted to doing them.

Misunderstanding of this sort, purported or real, may, however, be
inescapable.  They come with disagreements.  Almost exactly 60 years
ago Bertrand Russell wrote

"The most influential school of philosophy in Britain at the present
day maintains a certain linguistic doctrine to which I am unable to
subscribe.  I do not wish to misrepresent this school, but I suppose
any opponent of any doctrine is thought to misrepresent it by those
who hold it."

John Gilmore, Ashland, MA 01721 - USA

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

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-17 Thread Staller, Allan 
Having done this, it is a matter of minutes per catalog, unless your catalogs 
are huge!

Any currently processing jobs can wait for the completion of the event 
(minutes), with no disturbance.


You completely missed the main point of my post - availability.
The catalog must be offline during the time needed to "fix" this issue. 


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

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-17 Thread Gibney, Dave 
But, the tools available from either of the Catalog addon companies can shorten 
or almost entirely avoid this outage.
I did all my user catalogs during low activity periods. I did need to do my 
masters from a different lpar as I ipled the affected lpar.
Granted I am small, not sysplexed and don't do much catalog sharing.

Dave Gibney
Information Technology Services
Washington State University


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
> On Behalf Of Mark Zelden
> Sent: Wednesday, July 17, 2013 12:57 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: Old usercatalogs with IMBED and REPLICATE
> 
> On Wed, 17 Jul 2013 11:49:07 -0400, John Gilmore 
> wrote:
> 
> >.  As Mark's most recent post makes
> >clear, change, any change, no matter how trivial, is viewed as the
> >enemy bcause dangerous: Dragons be here!
> >
> 
> You completely missed the main point of my post - availability.
> The catalog must be offline during the time needed to "fix" this issue.
> 
> Mark
> --
> Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
> mailto:m...@mzelden.com
> Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
> Systems Programming expert at http://expertanswercenter.techtarget.com/
> 
> --
> 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: Old usercatalogs with IMBED and REPLICATE

2013-07-17 Thread Mark Zelden 
On Wed, 17 Jul 2013 12:01:50 -0400, John Eells  wrote:

>Also, I am reliably told that there is no significant performance or
>space advantage to be had that justifies making a catalog unavailable
>solely for the purpose of removing these attributes.
>

What a killjoy you are!  

--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS   
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html 
Systems Programming expert at http://expertanswercenter.techtarget.com/

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

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-17 Thread Mark Zelden 
On Wed, 17 Jul 2013 11:49:07 -0400, John Gilmore  wrote:

>.  As Mark's most recent post makes
>clear, change, any change, no matter how trivial, is viewed as the
>enemy bcause dangerous: Dragons be here!
>

You completely missed the main point of my post - availability.
The catalog must be offline during the time needed to "fix" this issue. 

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS   
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html 
Systems Programming expert at http://expertanswercenter.techtarget.com/

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

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-17 Thread R.S. 

W dniu 2013-07-17 18:00, Skip Robinson pisze:

My shop is 24 hours every day of the year, leap or otherwise. We never
close. Mainframe here is key to the customer support system, which is
obligated to take and manage customer calls. Any day. Any time.


Q1. (rhetorical IMHO) Do you have new releases of your application?
Q2. What happens at the time of rollout? Do you make all the changes 
in-flight, or maybe you switch off the application (part of it) to 
perform some changes?

Q3. How do you move your datasets from old DASD to a new one?


Side note: I do not urge anyone to remove IMBED from catalogs, I do not 
urge anyone to do any "modernization change" in their system. Why should I?
However I feel that many shops do not have so high availability 
requirements, so in many cases this isn't the reason. So, what the 
reason is?


--
Radoslaw Skorupka
Lodz, Poland


P.S. I predicted who will pick on "24x7x7x365" and I wasn't wrong. :-)
BTW: x is just a letter, I use * as multiplication sign. ;-)))
BTW2: If you really want to multiply the numbers above, please feel free to do 
so. You will get some result with no special meaning. It's legal. Pointless, 
but perfectly legal ;-)



--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. 


BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2013 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.555.904 zotych.



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

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-17 Thread Darth Keller 
I'm curious - has anyone ever used Dino Software's Teradon product?  IIRC, 
it allows you to move catalog entries from one catalog to another while 
datasets were open.
ddk



/
For those with 7x24 requirements, Catalog Recovery Plus allows for catalog 
re-orgs without an outage.
That's how got rid of my Imbed/Relpicate attributes. They advise 
performing the procedure during a 'slow' period but no outage is required 
per se.

Thank You,
Dave O'Brien
NIH Contracto

This e-mail message and all attachments transmitted with it may
contain legally privileged and/or confidential information intended
solely for the use of the addressee(s). If the reader of this
message is not the intended recipient, you are hereby notified that
any reading, dissemination, distribution, copying, forwarding or
other use of this message or its attachments is strictly
prohibited. If you have received this message in error, please
notify the sender immediately and delete this message and all
copies and backups thereof. Thank you.

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

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-17 Thread O'Brien, David W. (NIH/CIT) [C] 
For those with 7x24 requirements, Catalog Recovery Plus allows for catalog 
re-orgs without an outage.
That's how got rid of my Imbed/Relpicate attributes. They advise performing the 
procedure during a 'slow' period but no outage is required per se.

Thank You,
Dave O'Brien
NIH Contractor

From: Joel C. Ewing [jcew...@acm.org]
Sent: Wednesday, July 17, 2013 1:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Old usercatalogs with IMBED and REPLICATE

Not sure about rules in multi-system environment, but with one system I
believe it was possible to DIAGNOSE a catalog to be sure no serious
problems  existed, LOCK it, backup, redefine, restore/reorganize, UNLOCK
while system was running and datasets in the catalog were OPEN and in
use.  As long as you could tolerate short-term inability to OPEN/CLOSE
any datasets in the catalog, it was sometimes possible to move or
rebuild a catalog with in-use datasets without disrupting critical loads
- although admittedly this assumes you have enough control over or
knowledge about the loads and datasets involved to make that assessment.
 One just had to be sure the batch jobs doing the work and TSO user
controlling the process were designed to have no requirements for
OPEN/CLOSE of datasets in the catalog

Of course there is always some risk - errors in the process or unrelated
system failures in middle of process may end up requiring a viable
standalone z/OS.  But there is also a risk in continuing to use an
obsolete feature whose usage is increasingly rare.  Although IBM is
committed to maintain compatibility, I would suspect they may not be
able to test this support as thoroughly as some other system features
precisely because it is obsolete and rare. In every new release or RSU
level of z/OS there is the possibility IBM may unintentionally break
IMBED/REPLICATE logic in some subtle way that because of its rare usage
escapes initial detection during early testing.
JC Ewing

On 07/17/2013 11:00 AM, Skip Robinson wrote:
> My shop is 24 hours every day of the year, leap or otherwise. We never
> close. Mainframe here is key to the customer support system, which is
> obligated to take and manage customer calls. Any day. Any time.
>
> A few user catalogs are required as long as systems are active. So taking
> catalogs out of service means taking down all systems that share them.
> That means total outage, since rolling applications among sysplex members
> is precluded by loss of shared resources.
>
> Do we ever take all systems down? Sure, but that requires a business case
> presented to the Global Change Advisory Board and approval from top
> management. Here's my case: a few clunky old catalogs are causing me
> embarrassment among my professional peers, who are taking snide shots at
> me that make me feel like a high school schlub being dissed by the cool
> kids.
>
> Maybe not.
> .
> .
> JO.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 626-302-7535 Office
> 323-715-0595 Mobile
> jo.skip.robin...@sce.com
>
>
>
> From:   Ted MacNEIL 
> To: IBM-MAIN@LISTSERV.UA.EDU,
> Date:   07/17/2013 08:38 AM
> Subject:Re: Old usercatalogs with IMBED and REPLICATE
> Sent by:IBM Mainframe Discussion List 
>
>
>
> Not all of us are, though.
> If we wish to stay employed, we must follow their directives.
>
> -
> Ted MacNEIL
> eamacn...@yahoo.ca
> Twitter: @TedMacNEIL
>
> -Original Message-
> From: "R.S." 
> Sender:   IBM Mainframe Discussion List 
> Date: Wed, 17 Jul 2013 07:29:45
> To: 
> Reply-To: IBM Mainframe Discussion List 
> Subject: Re: Old usercatalogs with IMBED and REPLICATE
>
> W dniu 2013-07-16 21:19, Ted MacNEIL pisze:
>> Preach all you want.
>> It's management who sets priorities.
>>
> That's me.
>


--
Joel C. Ewing,Bentonville, AR   jcew...@acm.org

--
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: Old usercatalogs with IMBED and REPLICATE

2013-07-17 Thread Joel C. Ewing 
Not sure about rules in multi-system environment, but with one system I
believe it was possible to DIAGNOSE a catalog to be sure no serious
problems  existed, LOCK it, backup, redefine, restore/reorganize, UNLOCK
while system was running and datasets in the catalog were OPEN and in
use.  As long as you could tolerate short-term inability to OPEN/CLOSE
any datasets in the catalog, it was sometimes possible to move or
rebuild a catalog with in-use datasets without disrupting critical loads
- although admittedly this assumes you have enough control over or
knowledge about the loads and datasets involved to make that assessment.
 One just had to be sure the batch jobs doing the work and TSO user
controlling the process were designed to have no requirements for
OPEN/CLOSE of datasets in the catalog

Of course there is always some risk - errors in the process or unrelated
system failures in middle of process may end up requiring a viable
standalone z/OS.  But there is also a risk in continuing to use an
obsolete feature whose usage is increasingly rare.  Although IBM is
committed to maintain compatibility, I would suspect they may not be
able to test this support as thoroughly as some other system features
precisely because it is obsolete and rare. In every new release or RSU
level of z/OS there is the possibility IBM may unintentionally break
IMBED/REPLICATE logic in some subtle way that because of its rare usage
escapes initial detection during early testing.
JC Ewing

On 07/17/2013 11:00 AM, Skip Robinson wrote:
> My shop is 24 hours every day of the year, leap or otherwise. We never 
> close. Mainframe here is key to the customer support system, which is 
> obligated to take and manage customer calls. Any day. Any time. 
> 
> A few user catalogs are required as long as systems are active. So taking 
> catalogs out of service means taking down all systems that share them. 
> That means total outage, since rolling applications among sysplex members 
> is precluded by loss of shared resources. 
> 
> Do we ever take all systems down? Sure, but that requires a business case 
> presented to the Global Change Advisory Board and approval from top 
> management. Here's my case: a few clunky old catalogs are causing me 
> embarrassment among my professional peers, who are taking snide shots at 
> me that make me feel like a high school schlub being dissed by the cool 
> kids. 
> 
> Maybe not. 
> .
> .
> JO.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler 
> SHARE MVS Program Co-Manager
> 626-302-7535 Office
> 323-715-0595 Mobile
> jo.skip.robin...@sce.com
> 
> 
> 
> From:   Ted MacNEIL 
> To:     IBM-MAIN@LISTSERV.UA.EDU, 
> Date:   07/17/2013 08:38 AM
> Subject:Re: Old usercatalogs with IMBED and REPLICATE
> Sent by:IBM Mainframe Discussion List 
> 
> 
> 
> Not all of us are, though.
> If we wish to stay employed, we must follow their directives.
> 
> -
> Ted MacNEIL
> eamacn...@yahoo.ca
> Twitter: @TedMacNEIL
> 
> -Original Message-
> From: "R.S." 
> Sender:   IBM Mainframe Discussion List 
> Date: Wed, 17 Jul 2013 07:29:45 
> To: 
> Reply-To: IBM Mainframe Discussion List 
> Subject: Re: Old usercatalogs with IMBED and REPLICATE
> 
> W dniu 2013-07-16 21:19, Ted MacNEIL pisze:
>> Preach all you want.
>> It's management who sets priorities.
>>
> That's me.
> 


-- 
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

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

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-17 Thread Ted MacNEIL 
The last shop I worked at shelved all plans as soon as IBM changed direction.
-
Ted MacNEIL
eamacn...@yahoo.ca
Twitter: @TedMacNEIL

-Original Message-
From: Skip Robinson 
Sender:   IBM Mainframe Discussion List 
Date: Wed, 17 Jul 2013 09:00:22 
To: 
Reply-To: IBM Mainframe Discussion List 
Subject: Re: Old usercatalogs with IMBED and REPLICATE

My shop is 24 hours every day of the year, leap or otherwise. We never 
close. Mainframe here is key to the customer support system, which is 
obligated to take and manage customer calls. Any day. Any time. 

A few user catalogs are required as long as systems are active. So taking 
catalogs out of service means taking down all systems that share them. 
That means total outage, since rolling applications among sysplex members 
is precluded by loss of shared resources. 

Do we ever take all systems down? Sure, but that requires a business case 
presented to the Global Change Advisory Board and approval from top 
management. Here's my case: a few clunky old catalogs are causing me 
embarrassment among my professional peers, who are taking snide shots at 
me that make me feel like a high school schlub being dissed by the cool 
kids. 

Maybe not. 
.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com



From:   Ted MacNEIL 
To: IBM-MAIN@LISTSERV.UA.EDU, 
Date:   07/17/2013 08:38 AM
Subject:    Re: Old usercatalogs with IMBED and REPLICATE
Sent by:IBM Mainframe Discussion List 



Not all of us are, though.
If we wish to stay employed, we must follow their directives.

-
Ted MacNEIL
eamacn...@yahoo.ca
Twitter: @TedMacNEIL

-Original Message-
From: "R.S." 
Sender:   IBM Mainframe Discussion List 
Date: Wed, 17 Jul 2013 07:29:45 
To: 
Reply-To: IBM Mainframe Discussion List 
Subject: Re: Old usercatalogs with IMBED and REPLICATE

W dniu 2013-07-16 21:19, Ted MacNEIL pisze:
> Preach all you want.
> It's management who sets priorities.
>
That's me.

-- 
Radoslaw Skorupka
Lodz, Poland


--
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: Old usercatalogs with IMBED and REPLICATE

2013-07-17 Thread John Eells 

Richard Marchant wrote:

Before you install Z/OS 1.13 do you need to remove the IMBED and REPLICATE 
parameters from your old Usercatalogs or will they co-exist with  Z/OS 1.13?  
We are currently running Z/OS 1.11 and a number of the Usercatalogs have the 
IMBED parameter with no obvious ill affect.


As others have said, "No."  You need not do anything.  There are no 
current plans for removing this support, either.


Also, I am reliably told that there is no significant performance or 
space advantage to be had that justifies making a catalog unavailable 
solely for the purpose of removing these attributes.


--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
ee...@us.ibm.com

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

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-17 Thread Gerhard Postpischil 

On 7/17/2013 9:31 AM, John Gilmore wrote:

Using his own criterion Shmuel's '24x265' is just plain wrong too, but
'2' and '3' are adjacent on all of the keyboards I am familiar with,
and what we have here is all but certainly a typo.


And here I thought he was advocating for CPU vacation time 

Judging from some installations I've visited, 24*7 means 24 days per 
month, 7 hours per day <>


Gerhard Postpischil
Bradford, Vermont

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

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-17 Thread Skip Robinson 
My shop is 24 hours every day of the year, leap or otherwise. We never 
close. Mainframe here is key to the customer support system, which is 
obligated to take and manage customer calls. Any day. Any time. 

A few user catalogs are required as long as systems are active. So taking 
catalogs out of service means taking down all systems that share them. 
That means total outage, since rolling applications among sysplex members 
is precluded by loss of shared resources. 

Do we ever take all systems down? Sure, but that requires a business case 
presented to the Global Change Advisory Board and approval from top 
management. Here's my case: a few clunky old catalogs are causing me 
embarrassment among my professional peers, who are taking snide shots at 
me that make me feel like a high school schlub being dissed by the cool 
kids. 

Maybe not. 
.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com



From:   Ted MacNEIL 
To: IBM-MAIN@LISTSERV.UA.EDU, 
Date:   07/17/2013 08:38 AM
Subject:    Re: Old usercatalogs with IMBED and REPLICATE
Sent by:IBM Mainframe Discussion List 



Not all of us are, though.
If we wish to stay employed, we must follow their directives.

-
Ted MacNEIL
eamacn...@yahoo.ca
Twitter: @TedMacNEIL

-Original Message-
From: "R.S." 
Sender:   IBM Mainframe Discussion List 
Date: Wed, 17 Jul 2013 07:29:45 
To: 
Reply-To: IBM Mainframe Discussion List 
Subject: Re: Old usercatalogs with IMBED and REPLICATE

W dniu 2013-07-16 21:19, Ted MacNEIL pisze:
> Preach all you want.
> It's management who sets priorities.
>
That's me.

-- 
Radoslaw Skorupka
Lodz, Poland


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

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-17 Thread Ed Gould 

John,

Just think (in a few years hopefully) that your replacement will come  
in and not think of you as a do nothing.


Ed

On Jul 17, 2013, at 10:49 AM, John Gilmore wrote:


Opinions about the urgency and desirability of any maintenance can of
course differ, and the right decision for one shop may not be the
right one for another.

So much is platitudinous.  If these were the issues there would be
little to be said.  They are not.  As Mark's most recent post makes
clear, change, any change, no matter how trivial, is viewed as the
enemy bcause dangerous: Dragons be here!

Stasis is prized because on this view it is risk free.  Well, "The
grave's a fine and private place, but none I think do there embrace".

John Gilmore, Ashland, MA 01721 - USA

--
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: Old usercatalogs with IMBED and REPLICATE

2013-07-17 Thread John Gilmore 
Opinions about the urgency and desirability of any maintenance can of
course differ, and the right decision for one shop may not be the
right one for another.

So much is platitudinous.  If these were the issues there would be
little to be said.  They are not.  As Mark's most recent post makes
clear, change, any change, no matter how trivial, is viewed as the
enemy bcause dangerous: Dragons be here!

Stasis is prized because on this view it is risk free.  Well, "The
grave's a fine and private place, but none I think do there embrace".

John Gilmore, Ashland, MA 01721 - USA

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

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-17 Thread John Gilmore 
Mark's response was wholly predictable.  I could have written it for him.

Still, it was nice to have my surmises about risk aversion and
suspicious unanimity confirmed yet again.

John Gilmore, Ashland, MA 01721 - USA

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

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-17 Thread Ted MacNEIL 
Not all of us are, though.
If we wish to stay employed, we must follow their directives.

-
Ted MacNEIL
eamacn...@yahoo.ca
Twitter: @TedMacNEIL

-Original Message-
From: "R.S." 
Sender:   IBM Mainframe Discussion List 
Date: Wed, 17 Jul 2013 07:29:45 
To: 
Reply-To: IBM Mainframe Discussion List 
Subject: Re: Old usercatalogs with IMBED and REPLICATE

W dniu 2013-07-16 21:19, Ted MacNEIL pisze:
> Preach all you want.
> It's management who sets priorities.
>
That's me.

-- 
Radoslaw Skorupka
Lodz, Poland






--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorised to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive. 

BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru 
Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2013 r. kapita zakadowy BRE Banku SA (w caoci 
wpacony) wynosi 168.555.904 zotych.


--
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: Old usercatalogs with IMBED and REPLICATE

2013-07-17 Thread Ed Jaffe 

On 7/16/2013 11:15 AM, R.S. wrote:

W dniu 2013-07-16 19:22, John Gilmore pisze:

R S is right.   Constantly accumulating detritus of this sort 1) makes
the mainframe look bad, 2) provokes repeated discussions of this sort,
3) impairs performance marginally on a case-by-case basis but
cumulatively, and 4) is ugly.


And 5. IMHO very important: some day you will HAVE TO DO IT.


I seriously doubt that's true!

There are many installations with IMBED/REPLICATE in their catalogs. 
Some of the larger ones asked IBM to explain why they had abandoned 
their commitment to upward compatibility and platform investment 
protection i.e., what was the _business case_ for customers to expend 
time, effort and $ to redefine these catalogs?


[Aside: my unofficial understanding is that IBM wanted these attributes 
removed primarily so they could clean up their code to make future 
development easier.]


Whatever the "official" justification turned out to be, it was deemed 
insufficient by customers and IBM executives alike, and this led to the 
"retrenchment" to which Skip referred in an earlier post.


Since then, IBM catalog development has implemented *numerous* 
substantive enhancements e.g., RLS catalogs. Would those enhancements 
have been implemented sooner if every customer in the world had been 
forced to remove IBMED/REPLICATE from every such catalog in the world? 
Perhaps. But, we will never know...


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

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

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-17 Thread Greg Dorner 
Funny all the hoopla about doing an EXPORT TEMP followed by an IMPORT.  Not 
laying criticisism on anyone, but I consider it my job to keep the structures 
and constructs as clean as possible at all times. But, that's just me, I guess.

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

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-17 Thread Mark Zelden 
On Wed, 17 Jul 2013 09:31:33 -0400, John Gilmore  wrote:

>Things might have been different, but these shops deserve to die, and
>they will be picked off one after another.

Laughable.Although I have no proof / evidence to back me up, 
I would guess that it is some of the largest mainframe shops that 
still have catalogs with IMBED/REPLICATE and IBM's retraction of
removing support was based on their largest clients ($$$) objections,
not by majority numbers.   I know of some shops that don't even want
a once a year outage and depending on what data is in the catalog
that needs to be worked on, making this change just might not
be acceptable or worth the benefit / risk.  Five 9's baby!   

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS   
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html 
Systems Programming expert at http://expertanswercenter.techtarget.com/

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

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-17 Thread Joel C. Ewing 
The end user-impact is minor, but the catalog like any VSAM dataset with
IMBED/REPLICATE takes up slightly more space than it would otherwise, as
the replicated index CI requires one track in each DATA space CA and
reduces the amount of usable space per DATA CA (especially significant
if the CA is less than 1 cylinder).  The redundant replicated INDEX CI's
in that track no doubt "wastes" some cache in the DASD subsystem when
the dataset is processed, and there would be additional overhead in
maintaining the replicated INDEX CI's when changed.

Before massive DASD subsystem cache and smart DASD subsystems,
IMBED/REPLICATE improved speed of DASD access by eliminating a physical
seek and the rotational delay to read the INDEX CI associated with a
DATA CA.  Now it actually degrades performance slightly since the
physical read of a CA contains fewer useful CI's and a highly used INDEX
CI would already be in DASD cache or cached in the application address
space (the CATALOG address space in the case of MVS catalogs).

Note that removing these attributes is not just a matter of rebuilding
the INDEX component but requires a complete reorganizing of the dataset
to rebuild both DATA and INDEX components, as IMBED/REPLICATE causes
INDEX sequence set CIs to be stored inside each DATA component CA.
Joel C EWing

On 07/16/2013 08:17 PM, Mike Schwab wrote:
> Here is an idea.  Add to IDCAMS ALTER parameter REBUILDINDEX.
> Creates a new index component for an existing dataset (in case of an
> index error, reorg just the index, or getting rid of the IMBED /
> REPLICATE index).
> Leaves the old index for backup.  Would not be good after an update.
> 
> Add to IDCAMS ALTER parameter DELOLDINDEX.
> Deletes old index component for an existing dataset left by REBUILDINDEX.
> Reformats IMBEDED INDEXES tracks as empty DATA control intervals.
> Resets RBAs in all records to reflect bigger CAs (IMBED REPLICATE
> would be 1 track per cylinder, IMBED REPLICATE might be smaller).
> 
> On Tue, Jul 16, 2013 at 5:37 PM, Skip Robinson  
> wrote:
>> AFAIK customer retention of obsolete attributes is mostly IBM's problem,
>> not the customer's. They stopped honoring those attributes on new
>> allocations years ago, but as long any customers retain them, DFP code
>> still has to account for them. That means additional regression testing
>> for pretty much nothing. I sympathize with the change team, but I don't
>> think there's an end user performance hit.
>>
>> .
>> .
>> JO.Skip Robinson
>> Southern California Edison Company
>> Electric Dragon Team Paddler
>> SHARE MVS Program Co-Manager
>> 626-302-7535 Office
>> 323-715-0595 Mobile
>> jo.skip.robin...@sce.com
>>
>>
>>
>> From:   Mike Schwab 
>> To: IBM-MAIN@LISTSERV.UA.EDU,
>> Date:   07/16/2013 02:48 PM
>> Subject:Re: Old usercatalogs with IMBED and REPLICATE
>> Sent by:IBM Mainframe Discussion List 
>>
>>
>>
>> Another option would be to move various Aliases (HLQs) to new
>> usercatalogs.  Perhaps splitting them into more, smaller user
>> catalogs.
>>
>> On Tue, Jul 16, 2013 at 2:26 PM, John McKown
>>  wrote:
>>> OK, OK, all ya'all have worn me out!  I scan to see how many
>> catalog
>>> I'm talking about and which ones they are. Then mention it to my boss.
>>> Upper IT management basically won't care, so long as nothing goes wrong.
>>> 
> 


-- 
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

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

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-17 Thread David Devine 
Hiya,
Just out of interest, how many extents are these catalogs in?  if they havent 
been reorged in 10 years they are probably due for some attention, not just for 
a straight "tidyup" reorg (which will also remove the imbed & replicate) but 
also give you the opportunity to make changes for performance enhancements.
Run some catalog address space displays and see how they are performing
regards,
 Dave



 





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

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-17 Thread John Gilmore 
Using his own criterion Shmuel's '24x265' is just plain wrong too, but
'2' and '3' are adjacent on all of the keyboards I am familiar with,
and what we have here is all but certainly a typo.

Now that it has exhausted itself in trivia, it may be useful to draw a
portentous moral from this thread.

On the computer-technology time scale IMBED and REPLICATE, once chic,
are now dysfunctional creatures of the remote past.  Their presence in
user catalogs means, in effect, that the design of these catalogs has
not been reconsidered or even trivially revised in a very long time.

One eminent contributor here judges this and its like positively, as
establishing the robust immortality of the mainframe.  I see it
differently, as evidence that  the vierws and practices of those who
manage many (and in particular many American) mainframe shops are ". .
. insular, suspiciously unanimous, risk-averse, and mediocre".

Things might have been different, but these shops deserve to die, and
they will be picked off one after another.  What is unfortunate about
this is that, as usual, the wrong people will suffer the consequences
of this crackpot realism.

John Gilmore, Ashland, MA 01721 - USA

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

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-17 Thread Shmuel Metz (Seymour J.) 
In <51e58dc6.6010...@bremultibank.com.pl>, on 07/16/2013
   at 08:15 PM, "R.S."  said:

>My shop is open 24x7x365 (*),

I doubt it.

>(*) Everyone knows the meaning of the above, 

Yes, innumeracy. I might believe 24x265 or 24x7x52 as approximations,
but 24x7x365 is just plain wrong.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 Atid/2
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-16 Thread R.S. 

W dniu 2013-07-16 21:19, Ted MacNEIL pisze:

Preach all you want.
It's management who sets priorities.


That's me.

--
Radoslaw Skorupka
Lodz, Poland






--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. 


BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2013 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.555.904 zotych.



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

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-16 Thread Mike Schwab 
Here is an idea.  Add to IDCAMS ALTER parameter REBUILDINDEX.
Creates a new index component for an existing dataset (in case of an
index error, reorg just the index, or getting rid of the IMBED /
REPLICATE index).
Leaves the old index for backup.  Would not be good after an update.

Add to IDCAMS ALTER parameter DELOLDINDEX.
Deletes old index component for an existing dataset left by REBUILDINDEX.
Reformats IMBEDED INDEXES tracks as empty DATA control intervals.
Resets RBAs in all records to reflect bigger CAs (IMBED REPLICATE
would be 1 track per cylinder, IMBED REPLICATE might be smaller).

On Tue, Jul 16, 2013 at 5:37 PM, Skip Robinson  wrote:
> AFAIK customer retention of obsolete attributes is mostly IBM's problem,
> not the customer's. They stopped honoring those attributes on new
> allocations years ago, but as long any customers retain them, DFP code
> still has to account for them. That means additional regression testing
> for pretty much nothing. I sympathize with the change team, but I don't
> think there's an end user performance hit.
>
> .
> .
> JO.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 626-302-7535 Office
> 323-715-0595 Mobile
> jo.skip.robin...@sce.com
>
>
>
> From:   Mike Schwab 
> To:     IBM-MAIN@LISTSERV.UA.EDU,
> Date:   07/16/2013 02:48 PM
> Subject:Re: Old usercatalogs with IMBED and REPLICATE
> Sent by:IBM Mainframe Discussion List 
>
>
>
> Another option would be to move various Aliases (HLQs) to new
> usercatalogs.  Perhaps splitting them into more, smaller user
> catalogs.
>
> On Tue, Jul 16, 2013 at 2:26 PM, John McKown
>  wrote:
>> OK, OK, all ya'all have worn me out!  I scan to see how many
> catalog
>> I'm talking about and which ones they are. Then mention it to my boss.
>> Upper IT management basically won't care, so long as nothing goes wrong.
>> 

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

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

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-16 Thread Skip Robinson 
AFAIK customer retention of obsolete attributes is mostly IBM's problem, 
not the customer's. They stopped honoring those attributes on new 
allocations years ago, but as long any customers retain them, DFP code 
still has to account for them. That means additional regression testing 
for pretty much nothing. I sympathize with the change team, but I don't 
think there's an end user performance hit. 

.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com



From:   Mike Schwab 
To: IBM-MAIN@LISTSERV.UA.EDU, 
Date:   07/16/2013 02:48 PM
Subject:Re: Old usercatalogs with IMBED and REPLICATE
Sent by:IBM Mainframe Discussion List 



Another option would be to move various Aliases (HLQs) to new
usercatalogs.  Perhaps splitting them into more, smaller user
catalogs.

On Tue, Jul 16, 2013 at 2:26 PM, John McKown
 wrote:
> OK, OK, all ya'all have worn me out!  I scan to see how many 
catalog
> I'm talking about and which ones they are. Then mention it to my boss.
> Upper IT management basically won't care, so long as nothing goes wrong.
> 
>

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




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

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-16 Thread Mike Schwab 
Another option would be to move various Aliases (HLQs) to new
usercatalogs.  Perhaps splitting them into more, smaller user
catalogs.

On Tue, Jul 16, 2013 at 2:26 PM, John McKown
 wrote:
> OK, OK, all ya'all have worn me out!  I scan to see how many catalog
> I'm talking about and which ones they are. Then mention it to my boss.
> Upper IT management basically won't care, so long as nothing goes wrong.
> 
>

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

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

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-16 Thread John McKown 
Thanks. I have T-REX and so have all that I need to take care of it. I just
don't want to give up the Sunday afternoon. I'd rather sleep, assuming the
dog will let me.

On Tue, Jul 16, 2013 at 3:22 PM, Patrick Lyon wrote:

> If needed IBM wrote a tool years ago to find IMBED and REPLICATE
> datasets/catalogs.
>
> http://www-01.ibm.com/support/docview.wss?uid=isg1II13894
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
This is a test of the Emergency Broadcast System. If this had been an
actual emergency, do you really think we'd stick around to tell you?

Maranatha! <><
John McKown

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

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-16 Thread Patrick Lyon 
If needed IBM wrote a tool years ago to find IMBED and REPLICATE 
datasets/catalogs.

http://www-01.ibm.com/support/docview.wss?uid=isg1II13894

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

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-16 Thread John McKown 
No.

Will we ever? Not likely. Why? "Does it cost CPU cycles?" If so, then only
do it if it is absolutely _required_ to run the business. My manager is
always reporting on MSU usage. It is a major thing. So much so that I have
stopped doing much UNIX work because each UNIX command shows up as a "job"
and I get questioned on it.

On Tue, Jul 16, 2013 at 2:35 PM, Mark Zelden  wrote:

> On Tue, 16 Jul 2013 14:26:07 -0500, John McKown <
> john.archie.mck...@gmail.com> wrote:
>
> >OK, OK, all ya'all have worn me out!  I scan to see how many
> catalog
> >I'm talking about and which ones they are. Then mention it to my boss.
> >Upper IT management basically won't care, so long as nothing goes wrong.
> >
> >
>
>
> Don't you run the system health checker by now?  While it hasn't been
> around
> as long as IBM has been telling you to get rid of imbed/replicate, it has
> been a while and has enough good checks in it to make it worth while to
> spend
> the small amount of effort to get it set up.
>
> I don't disable the imbed/replicate catalog check just for this reason.  A
> handy list
> of what someday may have to be "fixed" (but I doubt it at this point).
>
> Check name is "CATALOG_IMBED_REPLICATE"
>
> Mark
> --
> Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
> mailto:m...@mzelden.com
> Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
> Systems Programming expert at http://expertanswercenter.techtarget.com/
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
This is a test of the Emergency Broadcast System. If this had been an
actual emergency, do you really think we'd stick around to tell you?

Maranatha! <><
John McKown

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

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-16 Thread Mark Zelden 
On Tue, 16 Jul 2013 14:26:07 -0500, John McKown  
wrote:

>OK, OK, all ya'all have worn me out!  I scan to see how many catalog
>I'm talking about and which ones they are. Then mention it to my boss.
>Upper IT management basically won't care, so long as nothing goes wrong.
>
>


Don't you run the system health checker by now?  While it hasn't been around
as long as IBM has been telling you to get rid of imbed/replicate, it has
been a while and has enough good checks in it to make it worth while to spend
the small amount of effort to get it set up. 

I don't disable the imbed/replicate catalog check just for this reason.  A 
handy list
of what someday may have to be "fixed" (but I doubt it at this point). 

Check name is "CATALOG_IMBED_REPLICATE"

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS   
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html 
Systems Programming expert at http://expertanswercenter.techtarget.com/

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

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-16 Thread John McKown 
OK, OK, all ya'all have worn me out!  I scan to see how many catalog
I'm talking about and which ones they are. Then mention it to my boss.
Upper IT management basically won't care, so long as nothing goes wrong.


On Tue, Jul 16, 2013 at 2:19 PM, Ted MacNEIL  wrote:

> Preach all you want.
> It's management who sets priorities.
>
> -
> Ted MacNEIL
> eamacn...@yahoo.ca
> Twitter: @TedMacNEIL
>
> -Original Message-
> From: "R.S." 
> Sender:   IBM Mainframe Discussion List 
> Date: Tue, 16 Jul 2013 20:15:34
> To: 
> Reply-To: IBM Mainframe Discussion List 
> Subject: Re: Old usercatalogs with IMBED and REPLICATE
>
> W dniu 2013-07-16 19:22, John Gilmore pisze:
> > That would a persuasive argument against, say, devoting next Sunday
> > between 1500 and 2100 to such scut work when you perhaps have more
> > important or urgent things to do.  After 10 years, though, it should
> > have been done by someone.
> >
> > R S is right.   Constantly accumulating detritus of this sort 1) makes
> > the mainframe look bad, 2) provokes repeated discussions of this sort,
> > 3) impairs performance marginally on a case-by-case basis but
> > cumulatively, and 4) is ugly.
> >
> And 5. IMHO very important: some day you will HAVE TO DO IT. I can be
> IMBED in ICF BCS, it can be TN3270 address space, it can be VSAM
> password, or :variable without semicolon in SQL statement. In every case
> it is very big pain when you HAVE to do it NOW and usually it is
> surprise - no plans, no preparation, no knowledge, no test, no resources
> to test...
> That's why I sustain that some Sunday is worth to do it.
> BTW: John have Sundays. My shop is open 24x7x365 (*), I have to use
> other service time slots or wait. And it's always Sat/Sun night.
>
> (*) Everyone knows the meaning of the above, actually it's not
> multiplication.
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
>
> --
> Tre   tej wiadomo ci mo e zawiera  informacje prawnie chronione Banku
> przeznaczone wy  cznie do u ytku s u bowego adresata. Odbiorc  mo e by
>  jedynie jej adresat z wy  czeniem dost pu osób trzecich. Je eli nie jeste
>  adresatem niniejszej wiadomo ci lub pracownikiem upowa nionym do jej
> przekazania adresatowi, informujemy,  e jej rozpowszechnianie, kopiowanie,
> rozprowadzanie lub inne dzia anie o podobnym charakterze jest prawnie
> zabronione i mo e by  karalne. Je eli otrzyma e  t  wiadomo   omy kowo,
> prosimy niezw ocznie zawiadomi  nadawc  wysy aj c odpowied  oraz trwale
> usun   t  wiadomo   w  czaj c w to wszelkie jej kopie wydrukowane lub
> zapisane na dysku.
>
> This e-mail may contain legally privileged information of the Bank and is
> intended solely for business use of the addressee. This e-mail may only be
> received by the addressee and may not be disclosed to any third parties. If
> you are not the intended addressee of this e-mail or the employee
> authorised to forward it to the addressee, be advised that any
> dissemination, copying, distribution or any other similar activity is
> legally prohibited and may be punishable. If you received this e-mail by
> mistake please advise the sender immediately by using the reply facility in
> your e-mail software and delete permanently this e-mail including any
> copies of it either printed or saved to hard drive.
>
> BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00,
> fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
> S d Rejonowy dla m. st. Warszawy XII Wydzia  Gospodarczy Krajowego
> Rejestru S dowego, nr rejestru przedsi biorców KRS 025237, NIP:
> 526-021-50-88.
> Wed ug stanu na dzie  01.01.2013 r. kapita  zak adowy BRE Banku SA (w ca o
> ci wp acony) wynosi 168.555.904 z otych.
>
>
> --
> 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
>



-- 
This is a test of the Emergency Broadcast System. If this had been an
actual emergency, do you really think we'd stick around to tell you?

Maranatha! <><
John McKown

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

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-16 Thread Ted MacNEIL 
Preach all you want.
It's management who sets priorities.

-
Ted MacNEIL
eamacn...@yahoo.ca
Twitter: @TedMacNEIL

-Original Message-
From: "R.S." 
Sender:   IBM Mainframe Discussion List 
Date: Tue, 16 Jul 2013 20:15:34 
To: 
Reply-To: IBM Mainframe Discussion List 
Subject: Re: Old usercatalogs with IMBED and REPLICATE

W dniu 2013-07-16 19:22, John Gilmore pisze:
> That would a persuasive argument against, say, devoting next Sunday
> between 1500 and 2100 to such scut work when you perhaps have more
> important or urgent things to do.  After 10 years, though, it should
> have been done by someone.
>
> R S is right.   Constantly accumulating detritus of this sort 1) makes
> the mainframe look bad, 2) provokes repeated discussions of this sort,
> 3) impairs performance marginally on a case-by-case basis but
> cumulatively, and 4) is ugly.
>
And 5. IMHO very important: some day you will HAVE TO DO IT. I can be 
IMBED in ICF BCS, it can be TN3270 address space, it can be VSAM 
password, or :variable without semicolon in SQL statement. In every case 
it is very big pain when you HAVE to do it NOW and usually it is 
surprise - no plans, no preparation, no knowledge, no test, no resources 
to test...
That's why I sustain that some Sunday is worth to do it.
BTW: John have Sundays. My shop is open 24x7x365 (*), I have to use 
other service time slots or wait. And it's always Sat/Sun night.

(*) Everyone knows the meaning of the above, actually it's not 
multiplication.

-- 
Radoslaw Skorupka
Lodz, Poland






--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorised to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive. 

BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru 
Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2013 r. kapita zakadowy BRE Banku SA (w caoci 
wpacony) wynosi 168.555.904 zotych.


--
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: Old usercatalogs with IMBED and REPLICATE

2013-07-16 Thread Gerhard Postpischil 

On 7/16/2013 2:15 PM, R.S. wrote:

And 5. IMHO very important: some day you will HAVE TO DO IT. I can be
IMBED in ICF BCS, it can be TN3270 address space, it can be VSAM
password, or :variable without semicolon in SQL statement. In every case
it is very big pain when you HAVE to do it NOW and usually it is
surprise - no plans, no preparation, no knowledge, no test, no resources
to test...


While it may be true that a change must be done at some time, it is 
rarely the case that there is insufficient lead time. All the shops I've 
worked in (mostly service bureaus and ISVs) are very conservative, and 
make new products and features available only after thorough testing 
(these days most shops have a "sandbox" machine). While testing 
occasionally misses something, resulting in a scrabble to fix, bypass, 
or back off the change, that tends to be rare.


Gerhard Postpischil
Bradford, Vermont

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

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-16 Thread R.S. 

W dniu 2013-07-16 19:22, John Gilmore pisze:

That would a persuasive argument against, say, devoting next Sunday
between 1500 and 2100 to such scut work when you perhaps have more
important or urgent things to do.  After 10 years, though, it should
have been done by someone.

R S is right.   Constantly accumulating detritus of this sort 1) makes
the mainframe look bad, 2) provokes repeated discussions of this sort,
3) impairs performance marginally on a case-by-case basis but
cumulatively, and 4) is ugly.

And 5. IMHO very important: some day you will HAVE TO DO IT. I can be 
IMBED in ICF BCS, it can be TN3270 address space, it can be VSAM 
password, or :variable without semicolon in SQL statement. In every case 
it is very big pain when you HAVE to do it NOW and usually it is 
surprise - no plans, no preparation, no knowledge, no test, no resources 
to test...

That's why I sustain that some Sunday is worth to do it.
BTW: John have Sundays. My shop is open 24x7x365 (*), I have to use 
other service time slots or wait. And it's always Sat/Sun night.


(*) Everyone knows the meaning of the above, actually it's not 
multiplication.


--
Radoslaw Skorupka
Lodz, Poland






--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. 


BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2013 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.555.904 zotych.



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

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-16 Thread efinnell15 
Was talking to one of my friends and he's doing a booming business in Cloud 
conversions.
Each node is 40 by  8way with 2.5 petabytes of storage. They have hundreds of 
nodes and planning for more. They believe they can do more for a fraction of 
the cost in support and environment. That's the kind of stuff that gets 
conversions moving pretty rapidly.

The danger in sitting on your thumbs too long is they become attached.  



In a message dated 07/16/13 12:31:54 Central Daylight Time, ba...@mxg.com 
writes:
PRECISELY BECAUSE YOU ARE NOT REQUIRED TO CHANGE ANYTHING, 
THE MAINFRAME WILL NEVER BE OBSOLETE.

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

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-16 Thread Ted MacNEIL 
Two places I worked at, since the whole overblown issue came up had the same 
response by management: "If it ain't broke ...".
Plus, there are always other things to do.
Now, that IBM has backed off ...
-
Ted MacNEIL
eamacn...@yahoo.ca
Twitter: @TedMacNEIL

-Original Message-
From: John McKown 
Sender:   IBM Mainframe Discussion List 
Date: Tue, 16 Jul 2013 11:54:17 
To: 
Reply-To: IBM Mainframe Discussion List 
Subject: Re: Old usercatalogs with IMBED and REPLICATE

I still have a few, very old, catalogs with IMBED and REPLICATE. Why?
That's what was "in vogue" when they were created. Why not recreate them?
Reverse it, why should I? If I do, then I have to make sure that I don't
mess up. And I must do it between 3 and 9 p.m. on a Sunday because that is
the only possible "gap" that I can use. And if I use too much time, people
will complain because they normally have that time to do things that they
want to do.  So I leave them alone because by converting the correctly buys
me _nothing_ and uses up my time. But make a mistake and it is Atlantis
submerging under the waves or Santorini exploding. Not worth the pain.

On Tue, Jul 16, 2013 at 11:39 AM, R.S. wrote:

> W dniu 2013-07-16 11:42, Richard Marchant pisze:
>
>> Before you install Z/OS 1.13 do you need to remove the IMBED and
>> REPLICATE parameters from your old Usercatalogs or will they co-exist with
>>  Z/OS 1.13?  We are currently running Z/OS 1.11 and a number of the
>> Usercatalogs have the IMBED parameter with no obvious ill affect.
>>
>>
>>  Just curious: why??? Why do you still have IMBED? It's been 10+ years
> since IBM started asking GET RID OFF IT. Note it is not recommended since
> times of OS/390 (2.6?) and AFAIK removed form "DEF CL" support at z/OS 1.3.
> I don't believe you were to busy last 10 years. So - in general  - why
> people insist to keep obsolete things?
>
>
> Caution: nothing personal, even if it looks so (my English is poor) , I'm
> trying to express my questions in general - why people do this. It's
> important, this is one of the reasons why mainframe is considered obsolete.
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
>
> --
> Tre   tej wiadomo ci mo e zawiera  informacje prawnie chronione Banku
> przeznaczone wy  cznie do u ytku s u bowego adresata. Odbiorc  mo e by
>  jedynie jej adresat z wy  czeniem dost pu osób trzecich. Je eli nie jeste
>  adresatem niniejszej wiadomo ci lub pracownikiem upowa nionym do jej
> przekazania adresatowi, informujemy,  e jej rozpowszechnianie, kopiowanie,
> rozprowadzanie lub inne dzia anie o podobnym charakterze jest prawnie
> zabronione i mo e by  karalne. Je eli otrzyma e  t  wiadomo   omy kowo,
> prosimy niezw ocznie zawiadomi  nadawc  wysy aj c odpowied  oraz trwale
> usun   t  wiadomo   w  czaj c w to wszelkie jej kopie wydrukowane lub
> zapisane na dysku.
>
> This e-mail may contain legally privileged information of the Bank and is
> intended solely for business use of the addressee. This e-mail may only be
> received by the addressee and may not be disclosed to any third parties. If
> you are not the intended addressee of this e-mail or the employee
> authorised to forward it to the addressee, be advised that any
> dissemination, copying, distribution or any other similar activity is
> legally prohibited and may be punishable. If you received this e-mail by
> mistake please advise the sender immediately by using the reply facility in
> your e-mail software and delete permanently this e-mail including any
> copies of it either printed or saved to hard drive.
> BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00,
> fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
> S d Rejonowy dla m. st. Warszawy XII Wydzia  Gospodarczy Krajowego
> Rejestru S dowego, nr rejestru przedsi biorców KRS 025237, NIP:
> 526-021-50-88. Wed ug stanu na dzie  01.01.2013 r. kapita  zak adowy BRE
> Banku SA (w ca o ci wp acony) wynosi 168.555.904 z otych.
>
>
> --**--**--
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
This is a test of the Emergency Broadcast System. If this had been an
actual emergency, do you really think we'd stick around to tell you?

Maranatha! <><
John McKown

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

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

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-16 Thread Barry Merrill 
"It's important, this is one of the reasons why mainframe is considered 
obsolete."

I'd argue just the opposite:  

 PRECISELY BECAUSE YOU ARE NOT REQUIRED TO CHANGE ANYTHING,
 THE MAINFRAME WILL NEVER BE OBSOLETE.

Barry

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of John McKown
Sent: Tuesday, July 16, 2013 11:54 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Old usercatalogs with IMBED and REPLICATE

I still have a few, very old, catalogs with IMBED and REPLICATE. Why?
That's what was "in vogue" when they were created. Why not recreate them?
Reverse it, why should I? If I do, then I have to make sure that I don't mess 
up. And I must do it between 3 and 9 p.m. on a Sunday because that is the only 
possible "gap" that I can use. And if I use too much time, people will complain 
because they normally have that time to do things that they want to do.  So I 
leave them alone because by converting the correctly buys me _nothing_ and uses 
up my time. But make a mistake and it is Atlantis submerging under the waves or 
Santorini exploding. Not worth the pain.

On Tue, Jul 16, 2013 at 11:39 AM, R.S. wrote:

> W dniu 2013-07-16 11:42, Richard Marchant pisze:
>
>> Before you install Z/OS 1.13 do you need to remove the IMBED and 
>> REPLICATE parameters from your old Usercatalogs or will they co-exist 
>> with  Z/OS 1.13?  We are currently running Z/OS 1.11 and a number of 
>> the Usercatalogs have the IMBED parameter with no obvious ill affect.
>>
>>
>>  Just curious: why??? Why do you still have IMBED? It's been 10+ 
>> years
> since IBM started asking GET RID OFF IT. Note it is not recommended 
> since times of OS/390 (2.6?) and AFAIK removed form "DEF CL" support at z/OS 
> 1.3.
> I don't believe you were to busy last 10 years. So - in general  - why 
> people insist to keep obsolete things?
>
>
> Caution: nothing personal, even if it looks so (my English is poor) , 
> I'm trying to express my questions in general - why people do this. 
> It's important, this is one of the reasons why mainframe is considered 
> obsolete.
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
>
> --
> Tre   tej wiadomo ci mo e zawiera  informacje prawnie chronione Banku
> przeznaczone wy  cznie do u ytku s u bowego adresata. Odbiorc  mo e by  
> jedynie jej adresat z wy  czeniem dost pu osób trzecich. Je eli nie 
> jeste  adresatem niniejszej wiadomo ci lub pracownikiem upowa nionym 
> do jej przekazania adresatowi, informujemy,  e jej rozpowszechnianie, 
> kopiowanie, rozprowadzanie lub inne dzia anie o podobnym charakterze jest 
> prawnie
> zabronione i mo e by  karalne. Je eli otrzyma e  t  wiadomo   omy kowo,
> prosimy niezw ocznie zawiadomi  nadawc  wysy aj c odpowied  oraz trwale
> usun   t  wiadomo   w  czaj c w to wszelkie jej kopie wydrukowane lub
> zapisane na dysku.
>
> This e-mail may contain legally privileged information of the Bank and 
> is intended solely for business use of the addressee. This e-mail may 
> only be received by the addressee and may not be disclosed to any 
> third parties. If you are not the intended addressee of this e-mail or 
> the employee authorised to forward it to the addressee, be advised 
> that any dissemination, copying, distribution or any other similar 
> activity is legally prohibited and may be punishable. If you received 
> this e-mail by mistake please advise the sender immediately by using 
> the reply facility in your e-mail software and delete permanently this 
> e-mail including any copies of it either printed or saved to hard drive.
> BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 
> 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl S 
> d Rejonowy dla m. st. Warszawy XII Wydzia  Gospodarczy Krajowego 
> Rejestru S dowego, nr rejestru przedsi biorców KRS 025237, NIP:
> 526-021-50-88. Wed ug stanu na dzie  01.01.2013 r. kapita  zak adowy 
> BRE Banku SA (w ca o ci wp acony) wynosi 168.555.904 z otych.
>
>
> --**--**--
>  For IBM-MAIN subscribe / signoff / archive access instructions, 
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



--
This is a test of the Emergency Broadcast System. If this had been an actual 
emergency, do you really think we'd stick around to tell you?

Maranatha! <><
John McKown

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

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

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-16 Thread John Gilmore 
That would a persuasive argument against, say, devoting next Sunday
between 1500 and 2100 to such scut work when you perhaps have more
important or urgent things to do.  After 10 years, though, it should
have been done by someone.

R S is right.   Constantly accumulating detritus of this sort 1) makes
the mainframe look bad, 2) provokes repeated discussions of this sort,
3) impairs performance marginally on a case-by-case basis but
cumulatively, and 4) is ugly.

Again, John, I mean nothing personal by this.  It is clear that you do
what you can in a hostile environment, and no one can reasonably
accuse you of sloth.   Arguments of this sort are, however, too
facile.

John Gilmore, Ashland, MA 01721 - USA

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

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-16 Thread Mark Zelden 
Can't say I blame you.   I got rid of IMBED/REPLICATE many years ago from
all the master catalogs that had them, as "I" own them.   But the storage team
manages user catalogs and they just kept putting it off when I warned them,
then IBM finally retracted their statement of direction.I can understand
their (and your) hesitation with tens if not hundreds of thousands of data sets
in some of the user catalogs in question.

Interestingly (or not) the health check still hasn't changed its tune in the 
exception text (which I let trip still as a low severity exception):  

"IBM intends to drop support for these attributes in the future."   


Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS   
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html 
Systems Programming expert at http://expertanswercenter.techtarget.com/


On Tue, 16 Jul 2013 11:54:17 -0500, John McKown  
wrote:

>I still have a few, very old, catalogs with IMBED and REPLICATE. Why?
>That's what was "in vogue" when they were created. Why not recreate them?
>Reverse it, why should I? If I do, then I have to make sure that I don't
>mess up. And I must do it between 3 and 9 p.m. on a Sunday because that is
>the only possible "gap" that I can use. And if I use too much time, people
>will complain because they normally have that time to do things that they
>want to do.  So I leave them alone because by converting the correctly buys
>me _nothing_ and uses up my time. But make a mistake and it is Atlantis
>submerging under the waves or Santorini exploding. Not worth the pain.
>
>On Tue, Jul 16, 2013 at 11:39 AM, R.S. wrote:
>
>> W dniu 2013-07-16 11:42, Richard Marchant pisze:
>>
>>> Before you install Z/OS 1.13 do you need to remove the IMBED and
>>> REPLICATE parameters from your old Usercatalogs or will they co-exist with
>>>  Z/OS 1.13?  We are currently running Z/OS 1.11 and a number of the
>>> Usercatalogs have the IMBED parameter with no obvious ill affect.
>>>
>>>
>>>  Just curious: why??? Why do you still have IMBED? It's been 10+ years
>> since IBM started asking GET RID OFF IT. Note it is not recommended since
>> times of OS/390 (2.6?) and AFAIK removed form "DEF CL" support at z/OS 1.3.
>> I don't believe you were to busy last 10 years. So - in general  - why
>> people insist to keep obsolete things?
>>
>>
>> Caution: nothing personal, even if it looks so (my English is poor) , I'm
>> trying to express my questions in general - why people do this. It's
>> important, this is one of the reasons why mainframe is considered obsolete.
>>
>> --
>> Radoslaw Skorupka
>> Lodz, Poland
>>
>>
>>
>>
>>
>>
>> --
>> Tre   tej wiadomo ci mo e zawiera  informacje prawnie chronione Banku
>> przeznaczone wy  cznie do u ytku s u bowego adresata. Odbiorc  mo e by
>>  jedynie jej adresat z wy  czeniem dost pu os�b trzecich. Je eli nie jeste
>>  adresatem niniejszej wiadomo ci lub pracownikiem upowa nionym do jej
>> przekazania adresatowi, informujemy,  e jej rozpowszechnianie, kopiowanie,
>> rozprowadzanie lub inne dzia anie o podobnym charakterze jest prawnie
>> zabronione i mo e by  karalne. Je eli otrzyma e  t  wiadomo   omy kowo,
>> prosimy niezw ocznie zawiadomi  nadawc  wysy aj c odpowied  oraz trwale
>> usun   t  wiadomo   w  czaj c w to wszelkie jej kopie wydrukowane lub
>> zapisane na dysku.
>>
>> This e-mail may contain legally privileged information of the Bank and is
>> intended solely for business use of the addressee. This e-mail may only be
>> received by the addressee and may not be disclosed to any third parties. If
>> you are not the intended addressee of this e-mail or the employee
>> authorised to forward it to the addressee, be advised that any
>> dissemination, copying, distribution or any other similar activity is
>> legally prohibited and may be punishable. If you received this e-mail by
>> mistake please advise the sender immediately by using the reply facility in
>> your e-mail software and delete permanently this e-mail including any
>> copies of it either printed or saved to hard drive.
>> BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00,
>> fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
>> S d Rejonowy dla m. st. Warszawy XII Wydzia  Gospodarczy Krajowego
>> Rejestru S dowego, nr rejestru przedsi biorc�w KRS 025237, NIP:
>> 526-021-50-88. Wed ug stanu na dzie  01.01.2013 r. kapita  zak adowy BRE
>> Banku SA (w ca o ci wp acony) wynosi 168.555.904 z otych.
>>
>>
>> --**--**--
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>
>
>
>-- 
>This is a test of the Emergency Broadcast System. If this had been an
>actual emergency, do you really think we'd stick around to tell you?
>
>Mara

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-16 Thread John McKown 
I still have a few, very old, catalogs with IMBED and REPLICATE. Why?
That's what was "in vogue" when they were created. Why not recreate them?
Reverse it, why should I? If I do, then I have to make sure that I don't
mess up. And I must do it between 3 and 9 p.m. on a Sunday because that is
the only possible "gap" that I can use. And if I use too much time, people
will complain because they normally have that time to do things that they
want to do.  So I leave them alone because by converting the correctly buys
me _nothing_ and uses up my time. But make a mistake and it is Atlantis
submerging under the waves or Santorini exploding. Not worth the pain.

On Tue, Jul 16, 2013 at 11:39 AM, R.S. wrote:

> W dniu 2013-07-16 11:42, Richard Marchant pisze:
>
>> Before you install Z/OS 1.13 do you need to remove the IMBED and
>> REPLICATE parameters from your old Usercatalogs or will they co-exist with
>>  Z/OS 1.13?  We are currently running Z/OS 1.11 and a number of the
>> Usercatalogs have the IMBED parameter with no obvious ill affect.
>>
>>
>>  Just curious: why??? Why do you still have IMBED? It's been 10+ years
> since IBM started asking GET RID OFF IT. Note it is not recommended since
> times of OS/390 (2.6?) and AFAIK removed form "DEF CL" support at z/OS 1.3.
> I don't believe you were to busy last 10 years. So - in general  - why
> people insist to keep obsolete things?
>
>
> Caution: nothing personal, even if it looks so (my English is poor) , I'm
> trying to express my questions in general - why people do this. It's
> important, this is one of the reasons why mainframe is considered obsolete.
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
>
>
>
>
>
> --
> Tre   tej wiadomo ci mo e zawiera  informacje prawnie chronione Banku
> przeznaczone wy  cznie do u ytku s u bowego adresata. Odbiorc  mo e by
>  jedynie jej adresat z wy  czeniem dost pu osób trzecich. Je eli nie jeste
>  adresatem niniejszej wiadomo ci lub pracownikiem upowa nionym do jej
> przekazania adresatowi, informujemy,  e jej rozpowszechnianie, kopiowanie,
> rozprowadzanie lub inne dzia anie o podobnym charakterze jest prawnie
> zabronione i mo e by  karalne. Je eli otrzyma e  t  wiadomo   omy kowo,
> prosimy niezw ocznie zawiadomi  nadawc  wysy aj c odpowied  oraz trwale
> usun   t  wiadomo   w  czaj c w to wszelkie jej kopie wydrukowane lub
> zapisane na dysku.
>
> This e-mail may contain legally privileged information of the Bank and is
> intended solely for business use of the addressee. This e-mail may only be
> received by the addressee and may not be disclosed to any third parties. If
> you are not the intended addressee of this e-mail or the employee
> authorised to forward it to the addressee, be advised that any
> dissemination, copying, distribution or any other similar activity is
> legally prohibited and may be punishable. If you received this e-mail by
> mistake please advise the sender immediately by using the reply facility in
> your e-mail software and delete permanently this e-mail including any
> copies of it either printed or saved to hard drive.
> BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00,
> fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
> S d Rejonowy dla m. st. Warszawy XII Wydzia  Gospodarczy Krajowego
> Rejestru S dowego, nr rejestru przedsi biorców KRS 025237, NIP:
> 526-021-50-88. Wed ug stanu na dzie  01.01.2013 r. kapita  zak adowy BRE
> Banku SA (w ca o ci wp acony) wynosi 168.555.904 z otych.
>
>
> --**--**--
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
This is a test of the Emergency Broadcast System. If this had been an
actual emergency, do you really think we'd stick around to tell you?

Maranatha! <><
John McKown

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

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-16 Thread R.S. 

W dniu 2013-07-16 11:42, Richard Marchant pisze:

Before you install Z/OS 1.13 do you need to remove the IMBED and REPLICATE 
parameters from your old Usercatalogs or will they co-exist with  Z/OS 1.13?  
We are currently running Z/OS 1.11 and a number of the Usercatalogs have the 
IMBED parameter with no obvious ill affect.


Just curious: why??? Why do you still have IMBED? It's been 10+ years 
since IBM started asking GET RID OFF IT. Note it is not recommended 
since times of OS/390 (2.6?) and AFAIK removed form "DEF CL" support at 
z/OS 1.3.
I don't believe you were to busy last 10 years. So - in general  - why 
people insist to keep obsolete things?



Caution: nothing personal, even if it looks so (my English is poor) , 
I'm trying to express my questions in general - why people do this. It's 
important, this is one of the reasons why mainframe is considered obsolete.


--
Radoslaw Skorupka
Lodz, Poland






--
Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku 
przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie 
jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem 
niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania 
adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by 
karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie 
zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo 
wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. 


BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax 
+48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl
Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. 
Wedug stanu na dzie 01.01.2013 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.555.904 zotych.



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

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-16 Thread Staller, Allan 
The old attributes will be supported (ignored) indefinitely. However, this 
might be a good time to bite the bullet.
The process of redefining the catalog, should take a matter of minutes (for 
each catalog), during which time the catalog would be locked.

A small variation of the info in APAR II13354 should accomplish this.

http://www-01.ibm.com/support/docview.wss?uid=isg1II13354

HTH,


Before you install Z/OS 1.13 do you need to remove the IMBED and REPLICATE 
parameters from your old Usercatalogs or will they co-exist with  Z/OS 1.13?  
We are currently running Z/OS 1.11 and a number of the Usercatalogs have the 
IMBED parameter with no obvious ill affect.


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

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-16 Thread Skip Robinson 
At one time, IBM issued a dire warning that at some point the near-ish but 
indefinite future, catalogs with such obsolete attributes would cease to 
work. IBM has since retrenched. The attributes are still deprecated and 
will not be honored on DEF CL, but the threat of outright failure is no 
longer in the air. 
.
.
JO.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com



From:   Mark Jacobs 
To: IBM-MAIN@LISTSERV.UA.EDU, 
Date:   07/16/2013 04:51 AM
Subject:Re: Old usercatalogs with IMBED and REPLICATE
Sent by:IBM Mainframe Discussion List 



On 07/16/13 05:42, Richard Marchant wrote:
> Before you install Z/OS 1.13 do you need to remove the IMBED and 
REPLICATE parameters from your old Usercatalogs or will they co-exist with 
 Z/OS 1.13?  We are currently running Z/OS 1.11 and a number of the 
Usercatalogs have the IMBED parameter with no obvious ill affect.
>
> Richard
>

No. We're currently running zOS 1.13 with one of our catalogs in the 
same state without any problems.

-- 
Mark Jacobs
Time Customer Service
Tampa, FL


The quiet ones are the ones that change the universe...
The loud ones only take the credit.

Londo Mollari - Babylon 5


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

Re: Old usercatalogs with IMBED and REPLICATE

2013-07-16 Thread Mark Jacobs 

On 07/16/13 05:42, Richard Marchant wrote:

Before you install Z/OS 1.13 do you need to remove the IMBED and REPLICATE 
parameters from your old Usercatalogs or will they co-exist with  Z/OS 1.13?  
We are currently running Z/OS 1.11 and a number of the Usercatalogs have the 
IMBED parameter with no obvious ill affect.

Richard



No. We're currently running zOS 1.13 with one of our catalogs in the 
same state without any problems.


--
Mark Jacobs
Time Customer Service
Tampa, FL


The quiet ones are the ones that change the universe...
The loud ones only take the credit.

Londo Mollari - Babylon 5

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

Old usercatalogs with IMBED and REPLICATE

2013-07-16 Thread Richard Marchant 
Before you install Z/OS 1.13 do you need to remove the IMBED and REPLICATE 
parameters from your old Usercatalogs or will they co-exist with  Z/OS 1.13?  
We are currently running Z/OS 1.11 and a number of the Usercatalogs have the 
IMBED parameter with no obvious ill affect.

Richard

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