Tom,
>The way I read this is that the PARMLIB member does not agree with the
>ICHRDSNT already in use by the RACF sharing group. Are you absolutely
>sure that the PARMLIB member is correct and agrees with your current
>ICHRDSNT in every respect? If so, then I would open a PMR for this issue.
>I think that there are two sets of "environment variables" in this
situation. There are the UNIX shell environment variables, which is what I
think you are asking about. And there are the Language Environment
environment variables.
I have not done an in-depth analysis on this but I don't
You would need to follow the CAA chain. For a standard LE task you would find
the anchor in the TCB. CICS would have it in its control blocks.
If you need it to be super clean, i.e., avoiding walking control blocks, you
could probably fake a call to your routine with NAB=NO and then use the
>>Set MANx CISIZE to half track (26624).
> Interesting. Why half track? Is it documented that it will help? Just curious
> if you don't mind, please.
Short answer ... 26K (or even 16K) of data written per I/O is much better
than the default of 4K (CI Size).
It really speeds up the writes
Tim Hare wrote:
>Set MANx CISIZE to half track (26624).
Interesting. Why half track? Is it documented that it will help? Just curious
if you don't mind, please.
>//AMP='BUFND=60',
>60 buffers = 2 cylinders if you are using half track CI sizes.
That is a good one. I really need
Let me add to my post - if you read abut SMF CI Size in member ACHAP03 of the
MXG source/documentation library, you will see a very good discussion of the
trade-off between DASD space and CISIZE in MANx datasets. Apparently SMF
doesn't do VBS in the MANx datasets in the same way "regular" VBS
Hello List,
I'm having a problem where one of my developers is getting "INSUFFICIENT ACCESS
AUTHORITY" on a dataset that I have defined in RACF and the issue is that it is
reporting on the generic definition.
I have defined in RACF a generic dataset definition of MAC.* (this definition
has a
What I understand if you use one star MAC.* that cover 2 nodes A.B
If you have a longer dataset name I think you would use a double star MAC.**
We have a standard that the dataset profile should be coded A.*.**
Lizette
> -Original Message-
> From: IBM Mainframe Discussion
FDRMOVE from Innovation is an OUTSTANDING product; several years ago our agency
moved eleven (11) DASD Storage Subsystem from five (5) different MAINFRAME
Storage Vendors IBM; EMC HITACHI; STK and Amdahl to two IBM SHARKs with NO
down time.
There products FDRABR as far as a customer is the
Also, if you were not aware, there is a RACF List that can help with these types
of questions
To join, if you have not already done so, use this URL
RACFhttp://www.listserv.uga.edu/archives/racf-l.html
Lizette
> -Original Message-
> From: IBM Mainframe Discussion List
On 3/14/2018 3:31 AM, Barbara Nitz wrote:
Tom,
The way I read this is that the PARMLIB member does not agree with the
ICHRDSNT already in use by the RACF sharing group. Are you absolutely
sure that the PARMLIB member is correct and agrees with your current
ICHRDSNT in every respect? If so,
Yes, we have several times. According to the doc, the only parts that cannot
be moved are the JES checkpoint datasets, active local page datasets, and
volumes with couple datasets. We have moved spool volumes several times for
different DASD migrations with no problems. Checkpoint, local
One thing to consider is the number, type and complexity of the control cards
being used in the dump utility request itself;
if you are using a "lot" of output targets you might consider using a "SORT"
type program instead of the IFASMFDP utility itself for the dump process (you
still need it
Hello,
One possible action is to enhance BUFSPACE of SYS1.MAN* to 90112.
I think it can be done via ALTER command.
Atenciosamente / Regards / Saludos
Ituriel do Nascimento Neto
BANCO BRADESCO S.A.
4250 / DITI Engenharia de Software
Sistemas Operacionais Mainframes
Tel: +55 11 3684-9602 R:
Any one used TDMF to move active/live/in-use JES2 Spool volumes?
If yes, any considerations?
Lizette Koehler
statistics: A precise and logical method for stating a half-truth inaccurately
--
For IBM-MAIN subscribe / signoff /
Yes, at a former location we used TDMF to move all volumes, spool volumes
included with the exception of one CKPT volume (CKPT1 was in the CF), and I
believe the LOGR couple data sets could not be copied/moved using TDMF IIRC.
Carmen Vitullo
- Original Message -
From: "Lizette
Hi All,
In a new set-up MF environment , it has been decided to go ahead with the
new proactive maintenance strategy . As a part of which we need to review
the HIPERs which the z/OS sysprog have generated(in text pad). These
include for DB2 , CICS, MQ ,z WAS etc.
The HIPERs need to be classified
Do you have MXG? They have a program, ANALSMF, which will analyze your current
SMF. In general, what I've done and which seemed to help:
Set MANx CISIZE to half track (26624).
In your IFASMFDP JCL to dump a full MANx dataset (we use IEFU29 to issue a
start for SMFDUMP JCL to dump one
Agreed. If you have a large MASDEF and you try to list volume stats
from a different system, it can take quite a while for the info to
come back. Suggestion is shared checkpoint volumes be at 100 at all
times, or gen the checkpoint volume to just the systems that use it.
for MASDEF=.
I have used TDMF many times in the past to move JES2 Spool and Ckpt volumes.
For Spool and ckpt volumes try to move them one at a time as "special"
volumes. It used to be a planning consideration in the docs but in recent
releases it doesn't seem to be an issue. I try not to tempt Mr. Murphy
20 matches
Mail list logo
