Make sure you have the RACFVARS class active and SETR RACLISTed, and that you
have your JES node name defined as a member of RACFVARS &RACLNDE. Otherwise
you'll lose all the security info associated with the data when you do the
reload.
--
Walt
Change them dynamically via commands. Then update JES2PARm to match.
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of R.S.
> Sent: Monday, May 28, 2012 11:24 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Spool offloa
W dniu 2012-05-28 18:03, Skip Robinson pisze:
OK, I'll bite. Which parameters cannot be changed dynamically? I think you
mentioned in another thread about having to resolve name conflicts. There
ways to juggle things around via multiple incremental changes to achieve
the desired result. I have sy
1995.
.
.
JO.Skip Robinson
SCE Infrastructure Technology Services
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
626-302-7535 Office
323-715-0595 Mobile
jo.skip.robin...@sce.com
From: "R.S."
To: IBM-MAIN@bama.ua.edu
Date: 05/28/2012 08:35 AM
Subject: Re: Spool
W dniu 2012-05-28 17:10, Mark Zelden pisze:
[...]
I assume you are asking if they are correct prior to starting the offload. If
so,
it looks okay. If not, then of course you need to start offload1.
Good assumption!
My explanations weren't good enough. :-)
Are you sure you disk o
On Mon, 28 May 2012 15:56:24 +0200, R.S. wrote:
>I'm going to cold start JES2. I would like to preserve my spool content
>by using spool offload.
>
>I changed parameters of OFF* devices to the following values:
>
>OFFLOAD1 DSN=SYS1.OFFLOAD,STATUS=DRAINED,ARCHIVE=ONE,
&
I'm going to cold start JES2. I would like to preserve my spool content
by using spool offload.
I changed parameters of OFF* devices to the following values:
OFFLOAD1 DSN=SYS1.OFFLOAD,STATUS=DRAINED,ARCHIVE=ONE,
CRTIME=RESET,LABEL=SL,PROTECT=NO,RETPD=0,
TRACE=NO
Bruce,
We do a "disk to disk" offload every night, issuing the following commands at
23:00:
$T OFFLOAD1,DSN=SYS3.JES2.OFFLOAD
$TOFF1.ST,Q=US
$S OFFLOAD1,TYPE=TRANSMIT
At 24:00, we issue:
$P OFFLOAD1
SYS3.JES2.OFFLOAD is a permanent data set on a 3390
On 25 February 2012 22:17, Robert A. Rosenberg wrote:
> At 15:55 -0500 on 02/23/2012, Tony Harminc wrote about Re: JES2 OFFLOAD -
> requesting help, ideas, etc.:
>
>
>> The latter is what would result from using my catalogued tape dataset
>> suggestion, if it works at all.
At 15:55 -0500 on 02/23/2012, Tony Harminc wrote about Re: JES2
OFFLOAD - requesting help, ideas, etc.:
The latter is what would result from using my catalogued tape dataset
suggestion, if it works at all. There would be multiple, unrelated
offload datasets that just happen to be on the same
On 23 February 2012 13:52, Bruce Richardson
wrote:
> Hello IBM-MAIN people,
Hi Bruce - long time, etc...
> One of our difficult processes is the JES2 OFFLOAD. Every weekday night
> (at 18:30) we start the offload of production output to tape (with PURGE).
> Before the new
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Bruce Richardson
Sent: Thursday, February 23, 2012 10:52 AM
To: IBM-MAIN@bama.ua.edu
Subject: JES2 OFFLOAD - requesting help, ideas, etc.
Hello IBM-MAIN people,
We recently have installed a
asy!
> One of our difficult processes is the JES2 OFFLOAD. Every weekday
night (at 18:30)
> we start the offload of production output to tape (with PURGE). Before the
new tape
> library, this would take less than a full 3490 cartridge (and it still
takes less than a full
> 3590 cartr
rocesses is the JES2 OFFLOAD. Every weekday night (at
18:30) we start the offload of production output to tape (with PURGE). Before
the new tape library, this would take less than a full 3490 cartridge (and it
still takes less than a full 3590 cartridge - a very small fraction of a
cartridge and a lo
Are you (also) asking how to identify candidate workloads that could be
re-engineered, hopefully with little effort, to exploit zIIPs and/or zAAPs?
If that's the question, here are a couple ideas:
1. Look for any Java code that may be executing, and classify those
workloads according to the Java r
: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of
Henke, George
Sent: Thursday, January 05, 2012 6:32 PM
To: MVS List Server 1
Subject: Identifying SOA Workloads for zIIP zAAP Offload
Does anyone know how best to identify Service Oriented Architecture (SOA)
workloads (XML) tha
RMF TYPE72's will give a good indication of what service classes/report
classes contain zAAP & zIIP eligible workloads.
What you should however be aware of, is that some vendor code does not
necessarily create enclaves (which are often [but not always] used as the
container bestowing the zIIP/zAAP
Does anyone know how best to identify Service Oriented Architecture (SOA)
workloads (XML) that are processing on the MF using GPPs.
Being eligible for zIIP zAAP, they are good candidates for offloading.
I just don't know a good way to identify them on an existing mainframe.
Maybe SMF, RMF, Enc
David O'Brien posts:
>The following has been posed by one of our mainframe users.
>QUESTION: What options (if any) are available for migrating
>these old study files and contents of accounts to storage media
>such as DVDs and external hard drives that could be securely
>held (off-line) by the age
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ed Gould
> Sent: Wednesday, October 19, 2011 5:34 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Data offload to DVDs or external drives
>
> John,
>
> Com
a.sch...@gmail.com]
Sent: Wednesday, October 19, 2011 8:21 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Data offload to DVDs or external drives
You can also specify volsers. Very useful if one is damaged.
On Wed, Oct 19, 2011 at 5:27 PM, Ed Gould wrote:
> David,
>
> Great reply. Thank yo
Backing up to paper (and restoring from it) is already possible...
http://www.ollydbg.de/Paperbak/
The author claims about 3 MB per A4 page, so 1 TB could be backed up to about
700 reams.
I think the paper would last longer than the ink though.
--
John.
I know you are kidding, right?
Have you seen some pictures f the scrolls? They are not easily readable cracked
with age and the only thing that helped save them was the lack of humidity in
the desert. Now I realize. There are people that have partially that deciphered
them but we are tal
You can also specify volsers. Very useful if one is damaged.
On Wed, Oct 19, 2011 at 5:27 PM, Ed Gould wrote:
> David,
>
> Great reply. Thank you for pointing this out.
> As a small side question (I have never had to do this) how does one identify
> tapes that need recycling?
> I have just do
Why not print it all out? Then get an army of Monks to transcribe to archival
parchment scrolls using quill pens and an ink formula from about 2000 years
ago. Seal the results into ceramic pottery vessels and place in a cave,
somewhere near the Dead Sea. Roll a big rock in front of the cave an
John,
Come on egypt tech??? And certain types of paper can last with the proper
conditions can last a few hundred years but when we are talking IT we are
talking machine readable.
Ed
Ps OCR is not an option.
--
For IBM-MAIN s
David,
Great reply. Thank you for pointing this out.
As a small side question (I have never had to do this) how does one identify
tapes that need recycling?
I have just done recycles on percent valid and was never worried about doing
it based on device type.
Ed
-
With the reference to moving data files from z/OS to an ASCII platform
and intending to read that archived data, for any "binary" file, that
is, a file that can contain non-pure-text data, the PGM=FTP on z/OS will
delete ALL of the BDWs and RDWs from any dataset with RECFM=V or VB or VBS,
and you e
>> The life expectancy (readability) is at most 10 years for DVD and CD's .
Whenever you are archiving data, you need to ask the question: what is the
expected "Standard of Care".
IMO, data archival is often a CYA proposition. You may think that the data is
a bunch of old junk, but you are uns
On Wed, 19 Oct 2011 13:21:14 -0500, Tom Marchant wrote:
>IBM DVD media is not very reliable.
I meant to write IMO DVD media is not very reliable. I don't
know how my fingers wrote IBM or why my eyes didn't catch
the error.
And when I say that it is not very reliable, I'm not just talking
abo
cKown, John [mailto:john.mck...@healthmarkets.com]
Sent: Wednesday, October 19, 2011 2:55 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Data offload to DVDs or external drives
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of E
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ed Gould
> Sent: Wednesday, October 19, 2011 1:44 PM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Data offload to DVDs or external drives
>
> Tom:
>
>
be iffy at 10 years as well.
Technology changes so fast that there isn't a really great long term storage
option.
Ed'
- Original Message -
From: Tom Marchant
To: IBM-MAIN@bama.ua.edu
Cc:
Sent: Wednesday, October 19, 2011 1:21 PM
Subject: Re: Data offload to DVDs or external dr
On Wed, 19 Oct 2011 11:08:09 -0400, O'Brien, David W. wrote:
>What options (if any) are available for migrating these old study
files and contents of accounts to storage media such as DVDs and
external hard drives that could be securely held (off-line) by the
agencies?
If you really mean DVD,
John [mailto:john.mck...@healthmarkets.com]
Sent: Wednesday, October 19, 2011 1:57 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Data offload to DVDs or external drives
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of O'Brien, David
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of O'Brien, David W.
> (NIH/CIT) [C]
> Sent: Wednesday, October 19, 2011 10:08 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Data offload to DVDs or external drives
&
Dave,
In 2006 I did a project in Ohio to offload a bunch of data files to MS SQL.
They had completed a SAP implementation, but had not bothered to deal with all
the historical data left behind on the old mainframe. They had VSAM files,
QSAM disk files, thousands of tapes, and even a few IMS
Dave,
This is a data migration problem, something very common in mainframe
migration/modernization projects. There are ETL tools (Extract-Transform-Load)
to help with doing such projects.
But first you need to establish the goal of migrating the data. From what you
describe, I could see two
W dniu 2011-10-19 17:08, O'Brien, David W. (NIH/CIT) [C] pisze:
The following has been posed by one of our mainframe users.
QUESTION: What options (if any) are available for migrating these old study
files and contents of accounts to storage media such as DVDs and external hard
drives that c
The following has been posed by one of our mainframe users.
QUESTION: What options (if any) are available for migrating these old study
files and contents of accounts to storage media such as DVDs and external hard
drives that could be securely held (off-line) by the agencies?
Looking at the
And it worked beautifully.
Jim Horne
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of
Richards, Robert B.
Sent: Monday, August 01, 2011 10:52 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Orphaned SMF Logger offload dataset
Sent Jim some JCL
AM
To: IBM-MAIN@bama.ua.edu
Subject: Orphaned SMF Logger offload dataset
All,
We had SMF an SMF logstream get disconnected during an IPL and are trying to
figure out how to get the data from the old logstream back. We have renamed it
and rebuilt so that our logstreams are working again but I ca
All,
We had SMF an SMF logstream get disconnected during an IPL and are trying to
figure out how to get the data from the old logstream back. We have renamed it
and rebuilt so that our logstreams are working again but I can't see an example
of JCL to read the data in the old offload dat
Hello List,
We open a PMR with IBM here, and now, our OFFLOAD run ok.
Below the Output from SYSLOG (Part) ..
$S OFFLOAD1,TYPE=TRANSMIT
$HASP000 OK
IEF234E D 0671,012613,,JES2,JES2
IEF196I IEF237I 0671 ALLOCATED TO SYS4
IEC501A M 0671,123456,SL,COMP,JES2,JES2,GRV.PROD.G123456
IEC507D E
In
,
on 06/30/2011
at 07:57 AM, Sérgio Lima Costa said:
>However it seems that someone wants to be the list owner.
The people who demand that others do their research for them?
Assistance on this list is on a volunteer basis. If you want someone
to help you and he asks you to do something fi
JES2 OFFLOAD Question
Hi Sergio,
This looks like the default coding from sys1.parmlib, so it appears that you
have not customized this at all yet. Please get in the habit now of using the
documentation as it contains many examples. Most of us here on the forum are
very willing to help, but only
Enviada em: terça-feira, 28 de junho de 2011 23:14
Para: IBM-MAIN@bama.ua.edu
Assunto: Re: RES: JES2 OFFLOAD Question
Ted,
It's been ages since I have tried to figure out the offload command. My vague
memory was that the WS option was not well explained at the time. I remember
being
---
I've always believed:
Give a man a fish, he'll eat for a day.
Teach a man to fish, he'll eat for a lifetime.
---
That last line should be:
"Teach a man to fish and he'll sit in the
--
I would encourage you to really read through all of the explanations and
documentation for the JES2 offload. There are many settings and each
shop needs to set this up according to the shop's specific needs. Just
rem
Ted,
It's been ages since I have tried to figure out the offload command. My vague
memory was that the WS option was not well explained at the time. I remember
being under pressure at the time but I do remember being confused (and harried)
while I was trying to empty a spool volume. I rem
te: Tue, 28 Jun 2011 22:11:39
To:
Reply-To: IBM Mainframe Discussion List
Subject: Re: RES: JES2 OFFLOAD Question
Hi Ted,
Too true. None of us get it right all of the time, but the more often we do,
the more often (hopefully) we will be forgiven when we don't ;-)
Lin
:20 PM
Subject: Re: RES: JES2 OFFLOAD Question
>Please get in the habit now of using the documentation as it contains many
>examples. Most of us here on the forum are very willing to help, but only if
>do your part too.
Nobody seems to have that (required) habit!
I may be a dor
>Please get in the habit now of using the documentation as it contains many
>examples. Most of us here on the forum are very willing to help, but only if
>do your part too.
Nobody seems to have that (required) habit!
I may be a dork, but I've always asked where's the doc?
-
Ted MacNEIL
eamac
too.
I would encourage you to really read through all of the explanations and
documentation for the JES2 offload. There are many settings and each shop
needs to set this up according to the shop's specific needs. Just remember,
set what you want, and set the work selection criteri
Linda,
Here, is the definition off JES2PARM :
*/
OFFLOAD1 DSN=SYS1.OFFLOAD/* DATA SET NAME DSN ohwnc*/
/* No. of Devices (units) UNITCT ohwnc
: terça-feira, 28 de junho de 2011 15:43
Para: IBM-MAIN@bama.ua.edu
Assunto: Re: JES2 OFFLOAD Question
Sergio,
Issue the following command and post the results, please.
$DOFF1.ST
Greg Shirey
Ben E. Keith Company
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Sérgio Lima
Hi Sergio,
The setup is different, the start and drain commands are the same. Init and
Tuning has a full explanation of each parameter.
If you want further info/help, please post your offload definitions from your
parmlib and the results of $DU,OFFLOADn (where n is the number for each
Hello Linda,
Thanks very much for your help.
Suppose that I Will want write in the tape, not on DASD.
What are the way ?
The command for OFFLOAD is the same?
Thanks again,
Sergio
-Mensagem original-
De: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] Em nome de
Linda
Sergio,
Issue the following command and post the results, please.
$DOFF1.ST
Greg Shirey
Ben E. Keith Company
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Sérgio Lima Costa
Sent: Tuesday, June 28, 2011 11:30 AM
To: IBM-MAIN@bama.ua.edu
Subject: JES2 OFFLOAD
) and LABEL=SL coded, which are used
for tape, not for a catlogued DASD dataset. Additionally, have a look at how
to code the start up settings for how you want this offload device (and any
additional offload devices) set up in your JES2PARM member in your parmlib .
I have 3 offloads
Hello List,
We are tried execute a JES OFFLOAD here, and this don't work.
We made what is wrote in JES2 Initialization and tunning Guide.
$D SPL
$HASP893 VOLUME(Z2SPL1) STATUS=ACTIVE,PERCENT=99
$HASP893 VOLUME(Z2SPL2) STATUS=ACTIVE,PERCENT=72
$HASP646 81.1087 PERCENT SPOOL UTILIZATIO
is not an option
> in my shop.
> Dennis
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
> Behalf Of Nick Jones
> Sent: Wednesday, March 23, 2011 10:22 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: Re: Logstream Offload
>
Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of Nick Jones
Sent: Wednesday, March 23, 2011 10:22 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Logstream Offload
Hi Sam, Dennis,
Unfortunately simply issuing an IXGOFFLD, from the S IXGOFLDS proc or
another program, may not cause logger to deal
Hi Sam, Dennis,
Unfortunately simply issuing an IXGOFFLD, from the S IXGOFLDS proc or
another program, may not cause logger to deallocate the current offload data
set. Logger keeps the current offload data set allocated until it switches
to a new one (because it fills, or there is an io error
Sam,
Thanks for the suggestion. IBM actually contacted me again and
suggested using the sample IXGOFLDS PROC for LOGGER offload. They even
opened a DCR for an enhancement to "provide a command to unallocate the
offload data set, or switch to the next offload data set" in a future
relea
Take a look at IBM program IEAMDBLG assembler source and the
documentation for IXGOFFLD.You can alter IEAMDBLG pretty quickly to
invoke IXGOFFLD against the logstream you want without doing anything
else.
You only need to connect, offload, disconnect.
CA-SYSIVEW includes command LGOFFLOD to
I've got a logstream dataset from RRS allocated on a volume that I want
to take offline. IBM tells me the only way to release the allocation is
to stop RRS or write a program to issue the IXGOFFLD to force a switch
to a new dataset. Since I sure can't stop RRS in a 24*7 production
environment does
Thanks for all the replies, I think I have a better idea of the problem
here. It seems that Logger may inadvertently be the weak link when dasd is
separated within a sysplex. I think the offloads happening on any
connection was designed to increase availability if one system lost
connections to D
On Wed, 14 Apr 2010 17:39:53 -0500, Arthur Gutowski wrote:
>In keeping with the consolidated response (if I'm not losing too much context):
>
>Mark,
>
>Yes, I recall the striping issue you had. I think we can avoid that.
>Yes, the allocate/delete job is what I referred to. Glad to hear that's n
>Don't forget ULC.
>PSCL plus ULC is still the most advantageous option for us.
I've forgotten what ULC is (if I ever knew).
There are so many pricing options around, and if you have knowledgable
negotiators, you can get a deal so many different ways.
It's almost as if each shop has its own cust
"Ted MacNEIL" wrote in message
news:<325749814-1271266055-cardhu_decombobulator_blackberry.rim.net-2135
6707...@bda026.bisx.prod.on.blackberry>...
> >>> PSLC is pretty simple. Your qualifying sysplex (biggest one) has
to
> > be 50%
> >> or more of the used capacity on each box.
> >
> >> 80% is th
>I think the marketing solution would either be more restrictive
>or more costly.
Not sure how it would be more restrictive than I would want it. Would the
overhead for offload system selection really be that bad? There might be
opportunity
>>> PSLC is pretty simple. Your qualifying sysplex (biggest one) has to
> be 50%
>> or more of the used capacity on each box.
>
>> 80% is the value I heard.
>HEARD? Is it documented anyhwhere?
It was in 1998.
We got PSLC by running SYSLOGR and Batch on the CEC.
I don't know if it's more complex
On Wed, 14 Apr 2010 19:06:07 +0200, R.S. wrote:
>W dniu 2010-04-14 15:59, Vernooij, CP - SPLXM pisze:
>[...]
>>> PSLC is pretty simple. Your qualifying sysplex (biggest one) has to
>> be 50%
>>> or more of the used capacity on each box.
>>
>> 80% is the value I heard.
>
>HEARD? Is it documented
W dniu 2010-04-14 15:59, Vernooij, CP - SPLXM pisze:
[...]
PSLC is pretty simple. Your qualifying sysplex (biggest one) has to
be 50%
or more of the used capacity on each box.
80% is the value I heard.
HEARD? Is it documented anyhwhere? I have SEEN IBM documents describing
Terms and Condi
I went through all this in a previous employer. Due to acquisitions, we merged
4 plexes into one site, into one shamplex. Only one small system was able to
be combined with another, wound up with 3 MAS'es, 3 RACFDB's, 3
SMSplexes, etc. Chose to send LOGREC data to LOGR for the contractual
"Mark Zelden" wrote in message
news:...
> On Wed, 14 Apr 2010 02:24:21 -0500, Barbara Nitz
wrote:
>
> >>Are you sure you *have* to pay more if you don't merge Test and
Prod?
> >
> >Having repeatedly asked my managers about just that (and my feelings
about
> >this idea are certainly known here -
On Wed, 14 Apr 2010 02:24:21 -0500, Barbara Nitz wrote:
>>Are you sure you *have* to pay more if you don't merge Test and Prod?
>
>Having repeatedly asked my managers about just that (and my feelings about
>this idea are certainly known here - I have made enemies in the past because
>of it), I ha
On Wed, 14 Apr 2010 00:39:34 -0500, Barbara Nitz wrote:
>Answering all of last nights post in one:
>
>Mark,
>>Anyway, I am commenting on it because the reason I had to use group name
>>was due to 2 different DB2 subsystems on different systems in the same
>>sysplex that had the same name. This p
: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of
Barbara Nitz
Sent: Wednesday, April 14, 2010 3:24 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Non-SMS-managed LOGR offload data sets
>Are you sure you *have* to pay more if you don't merge Test and Prod?
Having repeated
>Are you sure you *have* to pay more if you don't merge Test and Prod?
Having repeatedly asked my managers about just that (and my feelings about
this idea are certainly known here - I have made enemies in the past because
of it), I have to *believe* what they tell me. I am not privy to the cont
"Barbara Nitz" wrote in message
news:...
> Answering all of last nights post in one:
>
Big snip ...
> That 'foreign' subplex will be decommisioned soon. At this time we are
again
> prone to paying more money if we keep TEST separate from PROD.
Barbara,
Are you sure you *have* to pay more i
way to make LOGR
connect on the wrong subplex? Probably under some 'helpful' guise?
Nick,
>Usually the system that does the offload for a log stream is the system that
>does the write causing the HIGHOFFLOAD threshold to be exceeded. So if
>your utility program ran on your TEST sid
given a subset of that DASD to manage. So each disk
volume has only one SMS owner.
Set up common User Catalog, connected to each system MastCat.
It doesn't matter which LOGR does the OFFLOAD.....because the SMS
managed offload dataset is placed onto the shared disk, and cataloged in
common
gues, too! Mostly because they don't really
> understand how offload works.
Barbara,
Yes i'm in logger development.
> Also, keep in mind that I am not saying that we already *had* a corrupted
> RRS log stream, I just see a big timing window (that we will probably hit
at the
&
On Tue, 13 Apr 2010 10:14:24 -0500, Arthur Gutowski wrote:
>On Mon, 12 Apr 2010 08:08:22 -0500, Mark Zelden
>wrote:
>
>>BTW, I'm not sure if I mentioned this last year, but they way we shared
>>these pools between SMSplexes usually was by having the SMS status
>>in the "owning" SMSplex as "ENAB
to save $$. "Shamplex" has
become part of the nomenclature...
As for "where" support to restrict offload locations, this too was proposed by
a poster last year, and so well-written that some of us ran to the books to
read what we thought we missed! I would definitely make u
On Mon, 12 Apr 2010 23:56:56 -0500, Barbara Nitz wrote:
>
>Yes. Mark, look at group name in RRS to separate logging groups - I think this
>was intended to separate test and prod, and then look at the RRS panels
>where you can freely choose the group name; the rest is simple logstream
>definition
Nick,
from your email I figured you're somewhere in LOGR development :-) And I am
absolutely glad someone finally 'gets' my paranoia. I have a hard time getting
the problem across to my colleagues, too! Mostly because they don't really
understand how offload works.
>Ah
configurably sysplex scope.
>
>LOGR is a problem is such a setup, and no amount of naming conventions for
>offload datasets will help, when the logstream definition is truly sysplex
scope
>(as in operlog). As there is only one logr policy, so there is no way to define
>two different
e volumes.
>Last year we've discussed this, and a suggestion was made to define in the
>LOGR policy via keyword *where* offload might occur. That would take care of
>our problem (and I don't think we are the only customer to have such an
>artificially separated sysplex - I
"Barbara Nitz" wrote in message
news:...
> Nick,
>
> >My only advice, if such a thing works, is that you should consider
> >separate HLQ or EHLQ values for each log stream that has the same
name
> >in both sysplexes. That would avoid thrashing when allocati
Nick,
>My only advice, if such a thing works, is that you should consider
>separate HLQ or EHLQ values for each log stream that has the same name
>in both sysplexes. That would avoid thrashing when allocating offload
>data sets, where the sysplexes would be competing for the same dat
On Wed, 7 Apr 2010 04:27:41 -0500, Barbara Nitz wrote:
>What I need to have accessible from all systems in the sysplex (share) is a
>number of volumes that can contain LOGR offload data sets from two
>subplexes that otherwise know nothing about it each other (in theory). I am
>also
On Wed, 7 Apr 2
>What I need to have accessible from all systems in the sysplex (share) is a
>number of volumes that can contain LOGR offload data sets from two
>subplexes that otherwise know nothing about it each other (in theory). I am
>also told that it is 'too much work&#x
On Wed, 7 Apr 2010 03:48:32 -0500, Barbara Nitz
wrote:
>Unscientific survey:
>
>How many of you use truly non-SMS-managed LOGR datasets? As in: Using
>the two model data sets and an IEFDB401 exit that specifies the DALLIKE text
>unit?
All SMS-managed, AFAIK. No IEFDB401 exit.
>How many of you
On Wed, 7 Apr 2010 03:48:32 -0500, Barbara Nitz wrote:
>Unscientific survey:
>
>How many of you use truly non-SMS-managed LOGR datasets?
We still have some. I "discovered" them in one of our sysplexes a
couple of years ago after a space problem (they go to storage volumes).
Most of that has b
naged DASD *can* be shared between
> two SMSs. Not recommended, probably not really supported, but there we
go.
>
> What I need to have accessible from all systems in the sysplex (share)
is a
> number of volumes that can contain LOGR offload data sets from two
> subplexes that oth
accessible from all systems in the sysplex (share) is a
number of volumes that can contain LOGR offload data sets from two
subplexes that otherwise know nothing about it each other (in theory). I am
also told that it is 'too much work' to make it one SMS config for the full
sysplex.
1. No.
2. No. What configuration do you have in mind here? You can't have SMS
dasd in 2 SMS's, non-SMS dasd is in no SMS at all. What is being
'shared' then? We now have truly split our sysplexes, but we had issues
with LOGR datasets when our 2 sysplexes shared the same Dasd with 1 SMS
configuratio
1 - 100 of 341 matches
Mail list logo
