Changing DRCT size

2009-02-27 Thread Jim Bohnsack
I think a statement in a recent topic thread said that CP allocations 
are read at ipl time only.  Do I remember that correctly?  I got the 
following DIRMAINT messages adding a user:


DVHDRC3457I DVHUPDIR is unable to update object directory because  
DVHDRC3457I directory requires more than half of available space.  
DVHDRC3458I Directory updates will be brought online running DIRECTXA  
DVHDRC3458I against full source directory.
  
Can I change the DRCT allocation and have the change be recognized by CP 
without doing an ipl?  I'll be putting the new DRCT space on the same 
volume as the exiting allocation.


If there is not space to write the object directory in the existing DRCT 
space, where is it being held?  In memory?  Is everything that is 
changed or added after that message lost in an ipl?


Jim

--
Jim Bohnsack
Cornell University
(972) 596-6377 home/office
(972) 342-5823 cell
jab...@cornell.edu


Re: Changing DRCT size

2009-02-27 Thread Mark Wheeler

Jim,

 

Yes, you can. My experience is with VM:Secure, not DIRMAINT. I had to create a 
USER DIRECT file, take VMSECURE down, change the allocation, run DIRECTXA 
against USER DIRECT, and bring VMSECURE back up. 

 

Best regards,

Mark Wheeler
 
 Date: Fri, 27 Feb 2009 09:53:35 -0500
 From: jab...@cornell.edu
 Subject: Changing DRCT size
 To: IBMVM@LISTSERV.UARK.EDU
 
 I think a statement in a recent topic thread said that CP allocations 
 are read at ipl time only. Do I remember that correctly? I got the 
 following DIRMAINT messages adding a user:
 
 DVHDRC3457I DVHUPDIR is unable to update object directory because 
 DVHDRC3457I directory requires more than half of available space. 
 DVHDRC3458I Directory updates will be brought online running DIRECTXA 
 DVHDRC3458I against full source directory.
 
 Can I change the DRCT allocation and have the change be recognized by CP 
 without doing an ipl? I'll be putting the new DRCT space on the same 
 volume as the exiting allocation.
 
 If there is not space to write the object directory in the existing DRCT 
 space, where is it being held? In memory? Is everything that is 
 changed or added after that message lost in an ipl?
 
 Jim
 
 -- 
 Jim Bohnsack
 Cornell University
 (972) 596-6377 home/office
 (972) 342-5823 cell
 jab...@cornell.edu

_
Windows Live™: Discover 10 secrets about the new Windows Live.  
http://windowslive.com/connect/post/jamiethomson.spaces.live.com-Blog-cns!550F681DAD532637!7540.entry?ocid=TXT_TAGLM_WL_t2_ugc_post_022009

Re: Changing DRCT size

2009-02-27 Thread Kris Buelens
You can dynamically add extra DRCT areas on any CP owned pack.  There is no
need to keep DRCT area in one extend either, I never encountered CP problems
wit a DRCT area split in two pieces.

You are right that Q ALLOC DRCT will not display the added/enlarged area's
until you IPL (or ar eable to DETACHATTACH that pack to SYSTEM.

If tjhe DRCT area is too small (like now), CP directory updates are simply
impossible

2009/2/27 Jim Bohnsack jab...@cornell.edu

 I think a statement in a recent topic thread said that CP allocations are
 read at ipl time only.  Do I remember that correctly?  I got the following
 DIRMAINT messages adding a user:

 DVHDRC3457I DVHUPDIR is unable to update object directory because
  DVHDRC3457I directory requires more than half of available space.
  DVHDRC3458I Directory updates will be brought online running DIRECTXA
  DVHDRC3458I against full source directory.
  Can I change the DRCT allocation and have the
 change be recognized by CP without doing an ipl?  I'll be putting the new
 DRCT space on the same volume as the exiting allocation.

 If there is not space to write the object directory in the existing DRCT
 space, where is it being held?  In memory?  Is everything that is changed or
 added after that message lost in an ipl?

 Jim

 --
 Jim Bohnsack
 Cornell University
 (972) 596-6377 home/office
 (972) 342-5823 cell
 jab...@cornell.edu




-- 
Kris Buelens,
IBM Belgium, VM customer support


Re: Changing DRCT size

2009-02-27 Thread Kris Buelens
Oh yes: with DIRMAINT there is no problem as with VM:Secure.  It doesn't
need to be brought down.

2009/2/27 Mark Wheeler mwheele...@hotmail.com

  Jim,

 Yes, you can. My experience is with VM:Secure, not DIRMAINT. I had to
 create a USER DIRECT file, take VMSECURE down, change the allocation, run
 DIRECTXA against USER DIRECT, and bring VMSECURE back up.

 Best regards,
 Mark Wheeler

  Date: Fri, 27 Feb 2009 09:53:35 -0500
  From: jab...@cornell.edu
  Subject: Changing DRCT size
  To: IBMVM@LISTSERV.UARK.EDU

 
  I think a statement in a recent topic thread said that CP allocations
  are read at ipl time only. Do I remember that correctly? I got the
  following DIRMAINT messages adding a user:
 
  DVHDRC3457I DVHUPDIR is unable to update object directory because
  DVHDRC3457I directory requires more than half of available space.
  DVHDRC3458I Directory updates will be brought online running DIRECTXA
  DVHDRC3458I against full source directory.
 
  Can I change the DRCT allocation and have the change be recognized by CP
  without doing an ipl? I'll be putting the new DRCT space on the same
  volume as the exiting allocation.
 
  If there is not space to write the object directory in the existing DRCT
  space, where is it being held? In memory? Is everything that is
  changed or added after that message lost in an ipl?
 
  Jim
 
  --
  Jim Bohnsack
  Cornell University
  (972) 596-6377 home/office
  (972) 342-5823 cell
  jab...@cornell.edu

 --
 Windows Live™: Discover 10 secrets about the new Windows Live. View 
 post.http://windowslive.com/connect/post/jamiethomson.spaces.live.com-Blog-cns%21550F681DAD532637%217540.entry?ocid=TXT_TAGLM_WL_t2_ugc_post_022009




-- 
Kris Buelens,
IBM Belgium, VM customer support


Re: Changing DRCT size

2009-02-27 Thread Bob Bolch
Oh yes: with DIRMAINT there is no problem as with VM:Secure.  It doesn't need 
to be brought down.

Starting with r2.8 Service Pack 1, VM:Secure provides a new CPFMTXA command 
which allows you to change
the allocation map on a volume containing the DRCT area, without taking 
VM:Secure down. It can be used to
add new directory cylinders or to modify any non-directory cylinders. To remove 
directory cylinders, we suggest
taking VM:Secure down as in previous releases.

The VM:Secure CPFMTXA command works by locking out changes to the directory 
area, running the IBM
CPFMTXA command, and then refreshing its own in-memory cache of the allocation 
map. 

Bob Bolch




Re: Changing DRCT size

2009-02-27 Thread Ivan Warren

Bob Bolch wrote:
 
The VM:Secure CPFMTXA command works by locking out changes to the 
directory area, running the IBM
CPFMTXA command, and then refreshing its own in-memory cache of the 
allocation map.
 
I do hope the implementation *DOES* run DIRECTXA after changing the 
allocation map..


Because changing the allocation map has a nasty tendency of clearing the 
'active' directory flag...


That means there is a window of opportunity in which you may find 
yourself unable to IPL your system.


(between the time you CPFMTXA  the time you DIRECTXA.. which is why I 
like to do this manually !)


--Ivan


Re: Changing DRCT size

2009-02-27 Thread Bob Bolch
I do hope the implementation *DOES* run DIRECTXA after changing the 
allocation map..


No, but it does issue a Diagnose 3C to bring the changed allocation online 
properly.
Bob Bolch 


Re: Changing DRCT size

2009-02-27 Thread Ivan Warren

Bob Bolch wrote:
I do hope the implementation *DOES* run DIRECTXA after changing the 
allocation map..


No, but it does issue a Diagnose 3C to bring the changed allocation 
online properly.
Bob Bolch 
If the flag is cleared in the allocation map, using Diag 3C isn't going 
to help !


You'd use Diag 3C to indicate you actually DID change the flag to 
another area so that CP can pick it up !


That's what DIRECTXA does anyway !

And even then, you still have a window of opportunity for disaster.. 
(albeit a short one)


--Ivan


Re: Changing DRCT size

2009-02-27 Thread Schuh, Richard
That is a welcome change from the former action. Having a new allocation
map wiped out at shutdown time was the source of a considerable amount
of head scratching. In my case, it was new PARM disk allocations that
got hammered. Thank you Bob or whoever wrote the code. 

Regards, 
Richard Schuh 

 

 




From: The IBM z/VM Operating System
[mailto:ib...@listserv.uark.edu] On Behalf Of Bob Bolch
Sent: Friday, February 27, 2009 7:39 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Changing DRCT size


Oh yes: with DIRMAINT there is no problem as with VM:Secure.
It doesn't need to be brought down.
 
Starting with r2.8 Service Pack 1, VM:Secure provides a new
CPFMTXA command which allows you to change
the allocation map on a volume containing the DRCT area, without
taking VM:Secure down. It can be used to
add new directory cylinders or to modify any non-directory
cylinders. To remove directory cylinders, we suggest
taking VM:Secure down as in previous releases.
 
The VM:Secure CPFMTXA command works by locking out changes to
the directory area, running the IBM
CPFMTXA command, and then refreshing its own in-memory cache of
the allocation map. 
 
Bob Bolch





Re: Changing DRCT size

2009-02-27 Thread Kris Buelens
When you do not include the current DRCT cylinders in the ALLOCATE
request, the active directory should not be wiped out.
There are two hex codes used for DRCT in the allocation map.  If
memory servers me well:
X'40' is inactive DCRT cylinder
X'C0' is active DRCT cylinder
- DIRECTXA looks for x'40' chars to find free space for the new
directory it wants to write.
- CP looks for X'C0' when it wants to read the object directory
When you issue ICKDSF (or CPFMTXA) ALLOCATE, it will write X'40' in
the alloc map for the entered DRCT cylinder range.  Example:
- you run with cylinders 100-103 as DRCT.  suppose 100-101 is active (X'C0')
- Issue ICKDSF ALLOCATE TYPE(DRCT,104,105)
  -- no harm done, only cyls 104  105 are set to X'40'
- Issue ICKDSF ALLOCATE TYPE(DRCT,100,105)
   -- cyl range 100-105 is set to X'40', no active directory anymore
until DIRECTXA is run.


2009/2/27 Schuh, Richard rsc...@visa.com


 That is a welcome change from the former action.  Having a new allocation map 
 wiped out at shutdown time was the source of a  considerable amount of head 
 scratching. In my case, it was new PARM disk  allocations that got hammered. 
 Thank you Bob or whoever wrote the code.


 Regards,
 Richard Schuh






   From: The IBM z/VM Operating System
[mailto:ib...@listserv.uark.edu] On Behalf Of Bob Bolch
 Sent:Friday, February 27, 2009 7:39 AM
 To:IBMVM@LISTSERV.UARK.EDU
 Subject: Re: Changing DRCTsize



 Oh yes: with DIRMAINT there is no problem as with VM:Secure.  Itdoesn't 
 need to be brought down.

 Starting with r2.8 Service Pack 1, VM:Secure providesa new CPFMTXA 
 command which allows you to change
 the allocation map on a volume containing the DRCTarea, without taking 
 VM:Secure down. It can be used to
 add new directory cylinders or to modify anynon-directory cylinders. To 
 remove directory cylinders, we  suggest
 taking VM:Secure down as in previousreleases.

 The VM:Secure CPFMTXA command works by locking outchanges to the 
 directory area, running the IBM
 CPFMTXA command, and thenrefreshing its own in-memory cache of the 
 allocation map.

 Bob Bolch






-- 
Kris Buelens,
IBM Belgium, VM customer support


Re: Changing DRCT size

2009-02-27 Thread Jim Bohnsack
I really appreciate all of the replies. 

What I have gotten out of them is that I can add additional DRCT space 
on a CPOWNed volume and it will be put into use immediately.  Of course, 
by adding DRCT space, I'm referring to doing a CPVOL FORMAT of the 
space, specifying in the TYPE operand, DRCT.  I should be able to follow 
that with a DIRM DIRECT or DIRECTXA.  I understand that a subsequent CP 
Q ALLOC command will not show the additional space until an ipl is done.


Is my understanding correct?

Jim

Schuh, Richard wrote:

This is a multi-part message in MIME format.

--_=_NextPart_001_01C998F9.B0ECC7BF
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: quoted-printable

That is a welcome change from the former action. Having a new allocation
map wiped out at shutdown time was the source of a considerable amount
of head scratching. In my case, it was new PARM disk allocations that
got hammered. Thank you Bob or whoever wrote the code.=20

Regards,=20
Richard Schuh=20

  

--
Jim Bohnsack
Cornell University
(972) 596-6377 home/office
(972) 342-5823 cell
jab...@cornell.edu


Re: Changing DRCT size

2009-02-27 Thread Kris Buelens
You've got it 100%

2009/2/27, Jim Bohnsack jab...@cornell.edu:
 I really appreciate all of the replies.
  What I have gotten out of them is that I can add additional DRCT space on a
 CPOWNed volume and it will be put into use immediately.  Of course, by
 adding DRCT space, I'm referring to doing a CPVOL FORMAT of the space,
 specifying in the TYPE operand, DRCT.  I should be able to follow that with
 a DIRM DIRECT or DIRECTXA.  I understand that a subsequent CP Q ALLOC
 command will not show the additional space until an ipl is done.

  Is my understanding correct?

  Jim

  Schuh, Richard wrote:

  This is a multi-part message in MIME format.
 
  --_=_NextPart_001_01C998F9.B0ECC7BF
  Content-Type: text/plain;
 charset=us-ascii
  Content-Transfer-Encoding: quoted-printable
 
  That is a welcome change from the former action. Having a new allocation
  map wiped out at shutdown time was the source of a considerable amount
  of head scratching. In my case, it was new PARM disk allocations that
  got hammered. Thank you Bob or whoever wrote the code.=20
 
  Regards,=20
  Richard Schuh=20
 
 
 
  --
  Jim Bohnsack
  Cornell University
  (972) 596-6377 home/office
  (972) 342-5823 cell
  jab...@cornell.edu



-- 
Kris Buelens,
IBM Belgium, VM customer support


Re: Changing DRCT size

2009-02-27 Thread Mark Wheeler

Ivan Warren wrote:
 

 Because changing the allocation map has a nasty tendency of clearing the 
 'active' directory flag...
 
 That means there is a window of opportunity in which you may find 
 yourself unable to IPL your system.

 

If that's the only problem, one can still IPL with the NODIRECT option. 
OPERATOR will come up, but with no minidisks or CMS. Hopefully this will never 
happen to you, but what to do if it does?

 

1) Create a USER DIRECT file, and a map (I use DIRMAP for this) on a *secure* 
local CMS minidisk every day! VMSECURE users typically do this. Don't know 
about DIRMAINT

 

2) Squirrel away a copy of the minidisk map on some *secure* external system, 
if for no other reason than for disaster (natural or manmade) recovery 
purposes. You can do same for USER DIRECT, if the location is triple secret 
secure.

 

In the map from 2),

3) find the location of MAINT 190 (or 490) and issue 

DEFINE MDISK 190 start count volid   

4) find the location of the mdisk with the USER DIRECT file and issue 

DEFINE MDISK 191 start count volid 

5) DEFINE STOR 20M (at least)

6) IPL 190 CLEAR PARM NOSPROF

7) XEDIT, BROWSE, or TYPE USER DIRECT and note the vdev and volid in the 
DIRECTORY statement 

8) DEFINE MDISK vdev 0 END volid

9) DIRECTXA USER DIRECT A (twice) 

 

Hopefully, DIRECTXA completes with rc=0!

 

SHUTDOWN REIPL and you should be back on your way.

 

Mark Wheeler 

 

 


 

 

_
Access your email online and on the go with Windows Live Hotmail.
http://windowslive.com/online/hotmail?ocid=TXT_TAGLM_WL_HM_AE_Access_022009