Re: Applying Maintenance - Best Practice

[Kris Buelens]

One side remark (David surely knows, but his text below may not be explicit
enough)
when you'd need a real IPL with disks starting at cylinder 1, just copying
cylinder 1 to 0 will not be sufficient.  One needs to "move" the whole disk
up one cylinder.  So DDR: COPY 1 END REORDER 0
And this for all packs that the system to IPL will use.  Failure to do so
may even cause data loss.

2010/10/1 David Boyes 

>
> ty for this information, but I do not follow how the last cylinder of any
> pack on the IIS being unused allows you to name the real packs anything you
> want while still retaining the default names for the 2nd Level system.
> Could you explain in a little more detail?
>
>  Think of it this way: by making the IIS systems deliberately short 1 cyl
> for each pack, you can do the following:
>
> On level 1, each disk has a unique label in real cyl 0, always, no excuses.
> Defining a minidisk from 1 to END on that pack gives you a virtual cyl 0 for
> your guest that can be the default IBM label set (eg 540RES or the like)
> without ever interfering with the real system or risking the possibility
> that the 1st level system will accidentally pick up a duplicate volser and
> use the wrong one. You can just restore the IIS to the minidisk, and it’ll
> Just Work.
>
> You can have as many second level systems as you want in this
> configuration, and they can ALL have the default labels. You just can’t
> directly IPL from them because the boot loader is in cyl 1 instead of 0. I
> solve that problem by having a process for DDR (or flashcopy) of cyl 1 to
> real cyl 0 from test to my “boot set”  of volumes (I have one set for
> current, one set for pending IPL that I alternate between, so backout is
> just IPL from the other set if something goes totally casters up). It’s less
> confusing for IBM if the standard label set is there, and less confusing if
> you have to maintain a lot of similar systems.
>
> 6.2 is probably going to change a lot of that methodology – lots of new
> things coming, and we’ll have to see what still works and doesn’t work at
> that point.
>
>
>
> -- db
>



-- 
Kris Buelens,
IBM Belgium, VM customer support

Re: z/VM ISFC links

[Alan Ackerman]

Photons don't carry a charge, Mike. (It's still Friday here for 7 more mi
nutes.)

Alan Ackerman

On Thu, 30 Sep 2010 16:16:13 -0500, Mike Walter  
wrote:

>TCP/IP is old technology?  What about the bits and bytes it relies on -
>why can't IBM replace those with negatively and positively charged
>photons?  They'd be a lot faster!  Gee, I hope I'm hinting at some secre
t
>announcement  letter pending for the z/NT, which would naturally be
>followed by the z/XP, and then (skipping some more nightmares) eventuall
y
>the z/7, right!?  %-}~
>
>But then.. light does go wy back to the very beginning.  ;-)
>
>Mike Walter
>Hewitt Associates
>The opinions expressed herein are mine alone, not my employer's.
>

Re: Maximum Virtual Storage

[Rob van der Heij]

On Sat, Oct 2, 2010 at 1:11 AM, Gary M. Dennis  wrote:

> If the volume limit for a z/VM page volumes is 240+, how does this relate to
> maximum defined virtual storage for all active guests under a z/VM image?

The total amount of virtual storage in the universe is limited by the
amount segment and page tables in PTRM address spaces that we'd need
to span that virtual memory. Some of that is resident, some is paged
out, and some is just not there. The amount resident is limited by
your real memory, paged out is limited by the amount of paging space,
etc. Paging volumes is due cpowned maximum and number of spool packs,
plus size of a device, etc.

The way I remember the presentation is that Bit points at the various
restrictions independent of each other. So you know that once this
restriction is gone, the next barrier in space would be that one. Or
the other way around: don't start bugging us about this limit because
the other one is hitting you first.

We don't want the car manufacturers to list all cars maximum speed at
55 mph because that's the local limit in your area. But looking at the
glossies, it does make sense to realize whether a listed 110 mph does
you any good...

| Rob

Re: How DIRMAINT Work ?

[Alan Altmark]

On Friday, 10/01/2010 at 07:47 EDT, gclo...@br.ibm.com wrote:

> Question to Alan (Altmark): can the developers imbed this model on 
Program 
> Directories? As a new topic: "For Dirmaint users:"?

I think that is an excellent idea.  The best way to suggest it is to get 
David Boyes to open a Requirement for you or you can contact the Support 
Center and ask to open a requirement.

Let me go one step further and suggest that those files actually be ON 
DISK.

Alan Altmark

z/VM and Linux on System z Consultant
IBM System Lab Services and Training 
ibm.com/systems/services/labservices 
office: 607.429.3323
alan_altm...@us.ibm.com
IBM Endicott

Re: Maximum Virtual Storage

[Scott Rohling]

There is also that intangible factor of how each of those 4GB guests make
use of memory..  combine that with use of VDISK for things like Linux
swapping ...  another unpredictable.

That's why 'how many xxGB guests can I run within the maximum architectural
limits' isn't really answerable..  all you can really do is come up with a
worst case value and estimate.

Yet another factor is your willingness to suffer poor performance ..
overcommit to 5x and if response times are acceptable -- than you can have
twice as many guests running than with an overcommit of 2.5x.   (and yes -
you need the paging space available to support those overcommit levels)

Anyway - unless all those 4GB guests are doing exactly the same thing, and
accepting work at exactly the same rate -  the number you can support isn't
really predictable except within some broad ranges.  Cost effective
virtualization sort of depends on the hypothesis that there is usually a
natural disparity of work between guests moment to moment.   Ideally - the
peaks and valleys of activity all average into that 'sweet spot' plateau we
are all searching for.

So - 4 paragraphs to say 'it depends' again.  :-)Friday night and time
for a nightcap and some sleep.. dreaming of dolphins and swimming after
imaginary numbers.

Good discussion, I think --   nite all -

Scott Rohling


On Fri, Oct 1, 2010 at 7:06 PM, Phil Smith  wrote:

> Gary M. Dennis asked:
> >If the volume limit for a z/VM page volumes is 240+, how does this relate
> to
> >maximum defined virtual storage for all active guests under a z/VM image?
>
> Well, in theory, I guess it's
>(real storage)+(page space)-(real system requirements)
> but that's cutting it close to the line. So it's more like
>(real storage)*n
> where n is the overcommit ratio, as Scott Rohling indicated -- likely no
> more than 3x in production, probably closer to 2x.
>
> If you're thinking "Ginormous zEnterprise with 3TB of real and one z/VM
> system", do the math:
> 240 x 48GB* = 11TB, if I'm doing it right. So you're "OK", FSVO "OK".
>
> Let us know how that baby runs, eh?
>
> ...phsiii
>
> * 48GB = 65530*180*4096
>

Re: Maximum Virtual Storage

[Phil Smith]

Gary M. Dennis asked:
>If the volume limit for a z/VM page volumes is 240+, how does this relate to
>maximum defined virtual storage for all active guests under a z/VM image?

Well, in theory, I guess it's 
(real storage)+(page space)-(real system requirements)
but that's cutting it close to the line. So it's more like 
(real storage)*n
where n is the overcommit ratio, as Scott Rohling indicated -- likely no more 
than 3x in production, probably closer to 2x.

If you're thinking "Ginormous zEnterprise with 3TB of real and one z/VM 
system", do the math:
240 x 48GB* = 11TB, if I'm doing it right. So you're "OK", FSVO "OK".

Let us know how that baby runs, eh?

...phsiii

* 48GB = 65530*180*4096

AUTO: Lionel Dyck is out of the office - vacation (returning 10/08/2010)

[Lionel Dyck]

I am out of the office until 10/08/2010.

I am out of the office.  Call my cell if this is an emergency.


Note: This is an automated response to your message  "Re: How DIRMAINT
Work ?" sent on 10/1/10 13:04:40.

This is the only notification you will receive while this person is away.

Re: How DIRMAINT Work ?

[gclovis]

Hi,
I am an old user of Dirmaint (more than 20 years). Few times I need to stop
Dirmaint and make manual changes into monolithic USER DIRECT.
So, what was my surprise when I see this text in Dirmaint manual (Directory
Maintenance Facility, Tailoring and Administration Guide, version 6 release
1 - SC24-6190-00).

Appendix F. Making Multiple Updates to a Directory

Once a directory has been initialized, it should not be edited directly.
Direct editing invariably introduces checksum errors, possibly for every
entry if default serialization
is allowed to take place. An editor may only be used as part of the cycle
of transactions (DIRM FOR userid GET, RECEIVE, XEDIT userid DIRECT A, DIRM
FOR userid REPLACE), when applied to a single directory entry at a time.
To make multiple updates to the entire directory (updates that may affect
multiple users) the following procedure is recommended:
1. Disable updates to the source directory (DIRM DISABLE)
2. Ensure you have the latest copy of the directory (DIRM USER BACKUP)
3. Receive the monolithic backup (DIRM SEND USER BACKUP G)
Note: You can optionally combine these three commands into a batch job file
(called BULKUPDT PART1 A for this example), containing the following
commands:
DISABLE
USER BACKUP
SEND USER BACKUP G
and then submit this batch job file the DIRMAINT server using a DIRM BATCH
BLKUPDT PART1 command.
4. Receive the file to your A-minidisk and use your editor to make the
changes.
5. Replace the user input file (DIRM FILE USER BACKUP A USER INPUT E) on
the DIRMAINT server.
6. Create a batch job file (called BULKUPDT PART2 A for this example),
containing the following commands:
CMS ERASE USER DIRECT E
RLDDATA
ENABLE
and submit this batch job file to the DIRMAINT server using a DIRM BATCH
BULKUPDT PART2 command.
Note: This is required. Otherwise, authentication of the DIRM RLDDATA
command will fail once the USER DIRECT E file has been erased. (If you’ve
inadvertently done this, you can correct it by logging on to the DIRMAINT
server and issuing the RLDDATA and ENABLE commands from the console, then
CP DISC.) If you wish, the DIRM ENABLE command can be issued separately.
__
Clovis Pereira



 
  From:   Michael MacIsaac  
 

 
  To: IBMVM@LISTSERV.UARK.EDU   
 

 
  Date:   01/10/2010 11:26  
 

 
  Subject:Re: How DIRMAINT Work ?   
 

 
  Sent by:The IBM z/VM Operating System
 

 






>> We never more can edit our VMUSERS DIRECT
> That is correct, Sergio.

But "never" is a strong word.  I believe you can "reprime" the DirMaint
pump by copying a USER DIRECT file to USER INPUT on the (I believe it is)
DIRMAINT 1DF disk.  Then when DirMaint is started again, it loads that new
directory.

I agree Rich, in general you don't do that with DirMaint, but you can in a
pinch.

There have been times that I've gotten DirMaint royally mucked up so I
can't delete a user ID. I did a DIRM USER WIHTPASS, pulled the file from
the reader, changed a couple of settings, copied it as USER INPUT and
started fresh. Not recommended, I know, but sometimes a useful tool.



P.S. I see Dave Jones posted another method as I was putting this reply
together.  That makes it look even easier.  Just one question - using that
model, if DirMaint is restarted, will it have the correct USER DIRECT
file/directory?

"Mike MacIsaac"(845) 433-7061

Re: How DIRMAINT Work ?

[gclovis]

Hi, Friends.
There are more vantages to use Dirmaint. My preferred are the commands
BATCH, CLONED, ADD LIKE (using prototypes), etc.
About the BATCH, we can send a lot of commands to be executed, putting all
on one file and submitting using only one command.
By example, to install the Operator Manager product, I create the machines
without any mdisk and create a file: ADDMDOPM BATCH, with these commands:

FOR 5697J10C AMDISK 02B2 3390 GBLK4096   900 ZVM540 LABEL OPM2B2
FOR 5697J10C AMDISK 02C2 3390 GBLK4096   360 ZVM540 LABEL OPM2C2
FOR 5697J10C AMDISK 02C4 3390 GBLK4096   360 ZVM540 LABEL OPM2C4
FOR 5697J10C AMDISK 02A6 3390 GBLK4096   360 ZVM540 LABEL OPM2A6
FOR 5697J10C AMDISK 02A2 3390 GBLK4096   360 ZVM540 LABEL OPM2A2
FOR 5697J10C AMDISK 02D2 3390 GBLK4096  5400 ZVM540 LABEL OPM2D2
FOR 5697J10C AMDISK 0300 3390 GBLK4096   900 ZVM540 LABEL OPM300
FOR 5697J10C AMDISK 0400 3390 GBLK4096   900 ZVM540 LABEL OPM400
FOR 5697J10C AMDISK 0310 3390 GBLK4096   900 ZVM540 LABEL OPM310
FOR 5697J10C AMDISK 0410 3390 GBLK4096   900 ZVM540 LABEL OPM410
FOR 5697J10C AMDISK 0191 3390 GBLK4096  1800 ZVM540 LABEL OPM191
FOR OPMGRM1  AMDISK 0191 3390 GBLK4096   900 ZVM540 LABEL OPM191
FOR OPMGRM1  AMDISK 0194 3390 GBLK4096  9000 ZVM540 LABEL OPM194
FOR OPMGRM1  AMDISK 0198 3390 GBLK4096   900 ZVM540 LABEL OPM198
FOR OPMGRS1  AMDISK 0191 3390 GBLK4096   900 ZVM540 LABEL OPM191
FOR OPMGRS2  AMDISK 0191 3390 GBLK4096   900 ZVM540 LABEL OPM191
FOR OPMGRS3  AMDISK 0191 3390 GBLK4096   900 ZVM540 LABEL OPM191
FOR OPMGRS4  AMDISK 0191 3390 GBLK4096   900 ZVM540 LABEL OPM191

To execute all these commands: DIRM BATCH ADDMDOPM BATCH

Some effects:
   AMDISK  adds mdisk according to Program Directory, to all machines. No
   need to manual conversions, search for gaps, find dasds...
   GBLK4096 allocs blocks of 4096 bytes  on any dasd defined in Group
   ZVM540. It automatically converts to Cylinders... I didn't test, but I
   think that "3390" are changed to every model coded on respective REGION
   into EXTENT CONTROL, including FBA dasds. We can use "*" also...
   LABEL instruct Dirmaint (using DATAMOVE) to CMS format these mdisks...
   Pre-req for installation...
   All done in few minutes.

Question to Alan (Altmark): can the developers imbed this model on Program
Directories? As a new topic: "For Dirmaint users:"?
Thanks a lot,
__
Clovis Pereira




 
  From:   Scott Rohling
 

 
  To: IBMVM@LISTSERV.UARK.EDU   
 

 
  Date:   01/10/2010 11:50  
 

 
  Subject:Re: How DIRMAINT Work ?   
 

 
  Sent by:The IBM z/VM Operating System
 

 





There are many pros -- including attempting to keep you from shooting
yourself in the foot - allowing administrative control over who can do what
with the directory - allowing users to make their own changes (like
changing their password -- if you don't use an ESM) - etc.   It also allow
you to assign volumes in groups and DIRMAINT will automatically find free
space and create minidisks out of those groups.  It attempts to prevent
minidisk overlays, etc.   It cleans mindisks when they are deleted.   It
gives you a one command way to increase a minidisk.   I could go on for
awhile

To me -  one of the biggest advantages of DIRMAINT is that you now have an
automated way to create guests.   You can use DIRMSAPI from an EXEC -- get
synchronous responses from DIRMAINT -- and voila - you can manipulate the
directory with an EXEC.   Imagine:   Create guest from template directory,
do a DIRM ADD,  clone the disks, autolog the new guest - with one script.
Just ensure you have free space in your DASD pools 

Re: Maximum Virtual Storage

[Scott Rohling]

Well - this probably seems circular .. but it depends on the level of
overcommitment of virtual to real you define and on what size your paging
volumes are.   Or maybe I'm misunderstanding (frequently the case)..

Scott Rohling

On Fri, Oct 1, 2010 at 5:11 PM, Gary M. Dennis wrote:

> The thread on mixed paging volumes caused me to ask the question. I should
> have been more specific.
>
> If the volume limit for a z/VM page volumes is 240+, how does this relate
> to
> maximum defined virtual storage for all active guests under a z/VM image?
>
> For example, in an environment where each guest requires 4BG virtual, how
> many such guests could a single z/VM system manage?
>
>
>
> On 10/1/10 3:07 PM, "Mike Walter"  wrote:
>
> > Do you mean REAL virtual storage, to which answers have already been
> > supplied?
> > Or do you mean VIRTUAL virtual storage, as documented as the "Maximum
> > Input Values for Storage Units" in the CP Planning and Administration
> > manual?
> >
> > For z/VM 5.4 and 6.1 the maximum "stor" size for any virtual machine is
> > 16E (exabytes).
> >
> > I'd venture a guess that IBM would be pleased to sell you sufficient real
> > storage and DASD to support a few of those VMs, their paging and dump
> > space requirements.  :-)
> >
> >
> 11010100100010011001001011010100111001101001100100111010001111
> > 0110011001
> >
> > Mike Walter
> > Hewitt Associates
> > The opinions expressed herein are mine alone, not my employer's.
> >
> >
> >
> >
> > "Gary M. Dennis" 
> >
> > Sent by: "The IBM z/VM Operating System" 
> > 10/01/2010 02:47 PM
> > Please respond to
> > "The IBM z/VM Operating System" 
> >
> >
> >
> > To
> > IBMVM@LISTSERV.UARK.EDU
> > cc
> >
> > Subject
> > Maximum Virtual Storage
> >
> >
> >
> >
> >
> >
> > What is the maximum guest virtual storage supported by z/VM?
> >
> > --.  .-  .-.  -.--
> >
> > Gary Dennis
> > Mantissa Corporation
> >
> >
> >
> >
> >
> > The information contained in this e-mail and any accompanying documents
> may
> > contain information that is confidential or otherwise protected from
> > disclosure. If you are not the intended recipient of this message, or if
> this
> > message has been addressed to you in error, please immediately alert the
> > sender by reply e-mail and then delete this message, including any
> > attachments. Any dissemination, distribution or other use of the contents
> of
> > this message by anyone other than the intended recipient is strictly
> > prohibited. All messages sent to and from this e-mail address may be
> monitored
> > as permitted by applicable law and regulations to ensure compliance with
> our
> > internal policies and to protect our business. E-mails are not secure and
> > cannot be guaranteed to be error free as they can be intercepted,
> amended,
> > lost or destroyed, or contain viruses. You are deemed to have accepted
> these
> > risks if you communicate with us by e-mail.
> >
>
> --.  .-  .-.  -.--
>
> Gary Dennis
> Mantissa Corporation
> 1121 Edenton Street
> Birmingham, Alabama 35242-9257
>
> 0 ... living between the zeros... 0
>
> p: 205.968-3942
> m: 205.218-3937
> f: 205.968.3932
>
> gary.den...@mantissa.com
> http://www.mantissa.com
> http://www.idovos.com
>

Re: Maximum Virtual Storage

[Gary M. Dennis]

The thread on mixed paging volumes caused me to ask the question. I should
have been more specific.

If the volume limit for a z/VM page volumes is 240+, how does this relate to
maximum defined virtual storage for all active guests under a z/VM image?

For example, in an environment where each guest requires 4BG virtual, how
many such guests could a single z/VM system manage?



On 10/1/10 3:07 PM, "Mike Walter"  wrote:

> Do you mean REAL virtual storage, to which answers have already been
> supplied?
> Or do you mean VIRTUAL virtual storage, as documented as the "Maximum
> Input Values for Storage Units" in the CP Planning and Administration
> manual?
> 
> For z/VM 5.4 and 6.1 the maximum "stor" size for any virtual machine is
> 16E (exabytes).
> 
> I'd venture a guess that IBM would be pleased to sell you sufficient real
> storage and DASD to support a few of those VMs, their paging and dump
> space requirements.  :-)
> 
> 11010100100010011001001011010100111001101001100100111010001111
> 0110011001
> 
> Mike Walter
> Hewitt Associates
> The opinions expressed herein are mine alone, not my employer's.
> 
> 
> 
> 
> "Gary M. Dennis" 
> 
> Sent by: "The IBM z/VM Operating System" 
> 10/01/2010 02:47 PM
> Please respond to
> "The IBM z/VM Operating System" 
> 
> 
> 
> To
> IBMVM@LISTSERV.UARK.EDU
> cc
> 
> Subject
> Maximum Virtual Storage
> 
> 
> 
> 
> 
> 
> What is the maximum guest virtual storage supported by z/VM?
> 
> --.  .-  .-.  -.--
> 
> Gary Dennis
> Mantissa Corporation
> 
> 
> 
> 
> 
> The information contained in this e-mail and any accompanying documents may
> contain information that is confidential or otherwise protected from
> disclosure. If you are not the intended recipient of this message, or if this
> message has been addressed to you in error, please immediately alert the
> sender by reply e-mail and then delete this message, including any
> attachments. Any dissemination, distribution or other use of the contents of
> this message by anyone other than the intended recipient is strictly
> prohibited. All messages sent to and from this e-mail address may be monitored
> as permitted by applicable law and regulations to ensure compliance with our
> internal policies and to protect our business. E-mails are not secure and
> cannot be guaranteed to be error free as they can be intercepted, amended,
> lost or destroyed, or contain viruses. You are deemed to have accepted these
> risks if you communicate with us by e-mail.
> 

--.  .-  .-.  -.--

Gary Dennis
Mantissa Corporation
1121 Edenton Street
Birmingham, Alabama 35242-9257

0 ... living between the zeros... 0

p: 205.968-3942
m: 205.218-3937
f: 205.968.3932

gary.den...@mantissa.com
http://www.mantissa.com
http://www.idovos.com

Mixed LPARs

[Schuh, Richard]

Friday's question:

If an LPAR contains
*   both IFLs and regular CPs
*   2 or 3 Linux guests where the processors are defined as TYPE IFL
*   a lot of non-IFL VMs
.
Would CP run
*   only on regular CPs
*   only on IFLs, or
*   on both indiscriminately?


Regards,
Richard Schuh

Re: A confused CCW question.

[Rob van der Heij]

On Fri, Oct 1, 2010 at 11:51 PM, Alan Altmark  wrote:

> According to documents on the web, timestamps are part of the PREFIX and
> DEFINE EXTENT CCWs.  However,  you will not find any documentation of
> PREFIX, nor of the extensions to DEFINE EXTENT (no pun intended).  Another
> case of RTFC, as LINUX will use them.
>
> I think you need to move your tracing out of the realm of CCWs and
> consider whether Linux can trace the timestamps it is using in its I/O.

Browsing a few Linux source files suggests that you should be able to
recognize it by the data length in your Define Extent CCW. We used to
do 16 byte, from what dasd_eckd.h tells me XRC adds another 16 (and
uses some of the reserved bytes). An I/O trace with CCW option should
reveal it...

And since someone asked that a while ago; once RDC shows the device
can, Linux appears to include the time stamps.

| Rob

Re: How DIRMAINT Work ?

[Scott Rohling]

Or hey - maybe DIRM DASD CHANGE VOLUME  oldid newid   (followed I suppose by
DIRM DASD CHANGE REGION oldid newid?)

I just discovered DIRM DASD recently..  which helps you manage the EXTENT
CONTROL file --   and only recently mostly because (at least on my system)
the DIRMAINT HELP menu doesn't list it.   But DIRM HELP DASD will show you
this neat command...

It would be great if the EXTENT CONTROL file got updated - as well as the
directory..   But since the design seems to be that DIRM DASD only
manipulates the EXTENT CONTROL file  - then maybe a separate DIRM RELABEL
which updates the directory is warranted.   Something like:

DIRM DASD CHANGE VOLUME OLDVM1 NEWVM1
DIRM DASD CHANGE REGION OLDVM1 NEWVM1
DIRM RELABEL OLDVM1 NEWVM1
DIRM RLDE (put the extent control changes 'online')

Scott Rohling


On Fri, Oct 1, 2010 at 3:31 PM, Alan Altmark wrote:

> On Friday, 10/01/2010 at 05:08 EDT, Scott Rohling
>  wrote:
> > There are times when using DIRMAINT commands isn't practical..   for
> example -
> > doing DASD volume relabelling.   I suppose you could do a bunch of
> GET/REP
> > commands -- or maybe DMDISK NOCLEAN and AMDISK using the same extents
> and the
> > new volid?   But I have found the best thing to do is update the
> monolithic
> > directory with some simple plumbing and then give it back to DIRMAINT.
> I
> > concede the loss of an audit trail, but for most customers that can be
> resolved
> > by having a change record indicating what was done.
>
> I had thought of that case and would allow it with proper oversight and
> change management as you suggest.  Of course, I would turn around and
> demand (nay, politely request with a tug on my forelock) a DIRM RELABEL
> command.
>
> And I would probably remove class H from DIRM USER, or maybe even give it
> its own class.  It should be HARD to use that command, just as folks with
> RACF should make it hard for a sysprog to issue the CP STORE HOST command.
>
> Alan Altmark
>
> z/VM and Linux on System z Consultant
> IBM System Lab Services and Training
> ibm.com/systems/services/labservices
> office: 607.429.3323
> alan_altm...@us.ibm.com
> IBM Endicott
>

Re: A confused CCW question.

[Alan Altmark]

On Friday, 10/01/2010 at 09:54 EDT, Tom Huegel  wrote:
> Someone from our LINUX LAB asked me to trace 'TIMESTAMP' CCW's to 
mini-disks. 
> I never heard of a 'TIMESTAMP' CCW, but since most of my channel 
programming 
> knowledge dates back to preXA hardware I thought I would try to look it 
up in 
> the manuals.
> After searching I could find nothing even suggesting there is a CCW 
command 
> that instructs the control unit to timestamp something. 
> Has anyone ever heard of such a thing? or be able to point me to some 
doc that 
> explains it.  
> If I sound vague it is because I am. This request has been translated 
through 
> no less that 3 languages (all "English"). 

According to documents on the web, timestamps are part of the PREFIX and 
DEFINE EXTENT CCWs.  However,  you will not find any documentation of 
PREFIX, nor of the extensions to DEFINE EXTENT (no pun intended).  Another 
case of RTFC, as LINUX will use them.

I think you need to move your tracing out of the realm of CCWs and 
consider whether Linux can trace the timestamps it is using in its I/O.

Alan Altmark

z/VM and Linux on System z Consultant
IBM System Lab Services and Training 
ibm.com/systems/services/labservices 
office: 607.429.3323
alan_altm...@us.ibm.com
IBM Endicott

Re: How DIRMAINT Work ?

[Alan Altmark]

On Friday, 10/01/2010 at 05:08 EDT, Scott Rohling 
 wrote:
> There are times when using DIRMAINT commands isn't practical..   for 
example - 
> doing DASD volume relabelling.   I suppose you could do a bunch of 
GET/REP 
> commands -- or maybe DMDISK NOCLEAN and AMDISK using the same extents 
and the 
> new volid?   But I have found the best thing to do is update the 
monolithic 
> directory with some simple plumbing and then give it back to DIRMAINT.   
I 
> concede the loss of an audit trail, but for most customers that can be 
resolved 
> by having a change record indicating what was done.

I had thought of that case and would allow it with proper oversight and 
change management as you suggest.  Of course, I would turn around and 
demand (nay, politely request with a tug on my forelock) a DIRM RELABEL 
command.

And I would probably remove class H from DIRM USER, or maybe even give it 
its own class.  It should be HARD to use that command, just as folks with 
RACF should make it hard for a sysprog to issue the CP STORE HOST command.

Alan Altmark

z/VM and Linux on System z Consultant
IBM System Lab Services and Training 
ibm.com/systems/services/labservices 
office: 607.429.3323
alan_altm...@us.ibm.com
IBM Endicott

Re: How DIRMAINT Work ?

[David Boyes]

DIRM NODIRECT is your friend there, but I would contend that a mass relabel is 
not an everyday function, and would probably merit a mass reload.





On Oct 1, 2010, at 5:09 PM, "Scott Rohling" 
mailto:scott.rohl...@gmail.com>> wrote:

There are times when using DIRMAINT commands isn't practical..   for example - 
doing DASD volume relabelling.   I suppose you could do a bunch of GET/REP 
commands -- or maybe DMDISK NOCLEAN and AMDISK using the same extents and the 
new volid?   But I have found the best thing to do is update the monolithic 
directory with some simple plumbing and then give it back to DIRMAINT.   I 
concede the loss of an audit trail, but for most customers that can be resolved 
by having a change record indicating what was done.

Scott Rohling

On Fri, Oct 1, 2010 at 2:50 PM, Alan Altmark 
<alan_altm...@us.ibm.com>
 wrote:
On Friday, 10/01/2010 at 10:24 EDT, Ray Waters
<ray.wat...@opensolutions.com>
 wrote:
> We use all the ?DIRMAINT ? or ?DIRM?  commands and also are able to use
XEDIT
> to make our major directory changes. I wrote an EXEC to ?DIRMAINT
OFFLINE?,
> ?DIRMAINT BACKUP?, DIRMAINT SHUTDOWN?, then ?COPY USER BACKUP B &DIRNAME
DIRECT
> A (OLDD ? , followed by ?XEDIT &DIRNAME DIRECT A?.
>
> Once my EXDIT changes are made and I ?FILE?, I ?COPY &DIRNAME DIRECT A
USER
> INPUT C (OLDD? to the DIRMAINT 1DF mdisk,? CP XAUTOLOG DIRMAINT?, ?EXEC
> DIRMAINT ONLINE?.
>
> Anyway you get the idea. There are precautions  and sleeps and performed
by the
> EXEC, but that is the general idea.

Any procedure that has you editing the monolithic directory and replacing
it as a whole means you have no audit trail (except for "directory
replaced") and the holodeck safeties are turned off.  All major directory
changes should be made with DIRM commands.  If you're making a bunch of
changes at the same time, use DIRM NODIRECT   to suppress the
DIRECTXA, and then when you're done use DIRM DIRECT to bring all the
changes online at the same time.

Alan Altmark

z/VM and Linux on System z Consultant
IBM System Lab Services and Training
ibm.com/systems/services/labservices
office: 607.429.3323
alan_altm...@us.ibm.com
IBM Endicott

Re: How DIRMAINT Work ?

[Scott Rohling]

There are times when using DIRMAINT commands isn't practical..   for example
- doing DASD volume relabelling.   I suppose you could do a bunch of GET/REP
commands -- or maybe DMDISK NOCLEAN and AMDISK using the same extents and
the new volid?   But I have found the best thing to do is update the
monolithic directory with some simple plumbing and then give it back to
DIRMAINT.   I concede the loss of an audit trail, but for most customers
that can be resolved by having a change record indicating what was done.

Scott Rohling

On Fri, Oct 1, 2010 at 2:50 PM, Alan Altmark wrote:

> On Friday, 10/01/2010 at 10:24 EDT, Ray Waters
>  wrote:
> > We use all the ?DIRMAINT ? or ?DIRM?  commands and also are able to use
> XEDIT
> > to make our major directory changes. I wrote an EXEC to ?DIRMAINT
> OFFLINE?,
> > ?DIRMAINT BACKUP?, DIRMAINT SHUTDOWN?, then ?COPY USER BACKUP B &DIRNAME
> DIRECT
> > A (OLDD ? , followed by ?XEDIT &DIRNAME DIRECT A?.
> >
> > Once my EXDIT changes are made and I ?FILE?, I ?COPY &DIRNAME DIRECT A
> USER
> > INPUT C (OLDD? to the DIRMAINT 1DF mdisk,? CP XAUTOLOG DIRMAINT?, ?EXEC
> > DIRMAINT ONLINE?.
> >
> > Anyway you get the idea. There are precautions  and sleeps and performed
> by the
> > EXEC, but that is the general idea.
>
> Any procedure that has you editing the monolithic directory and replacing
> it as a whole means you have no audit trail (except for "directory
> replaced") and the holodeck safeties are turned off.  All major directory
> changes should be made with DIRM commands.  If you're making a bunch of
> changes at the same time, use DIRM NODIRECT   to suppress the
> DIRECTXA, and then when you're done use DIRM DIRECT to bring all the
> changes online at the same time.
>
> Alan Altmark
>
> z/VM and Linux on System z Consultant
> IBM System Lab Services and Training
> ibm.com/systems/services/labservices
> office: 607.429.3323
> alan_altm...@us.ibm.com
> IBM Endicott
>

Re: How DIRMAINT Work ?

[Alan Altmark]

On Friday, 10/01/2010 at 10:24 EDT, Ray Waters 
 wrote:
> We use all the ?DIRMAINT ? or ?DIRM?  commands and also are able to use 
XEDIT 
> to make our major directory changes. I wrote an EXEC to ?DIRMAINT 
OFFLINE?, 
> ?DIRMAINT BACKUP?, DIRMAINT SHUTDOWN?, then ?COPY USER BACKUP B &DIRNAME 
DIRECT 
> A (OLDD ? , followed by ?XEDIT &DIRNAME DIRECT A?.
> 
> Once my EXDIT changes are made and I ?FILE?, I ?COPY &DIRNAME DIRECT A 
USER 
> INPUT C (OLDD? to the DIRMAINT 1DF mdisk,? CP XAUTOLOG DIRMAINT?, ?EXEC 
> DIRMAINT ONLINE?.
> 
> Anyway you get the idea. There are precautions  and sleeps and performed 
by the 
> EXEC, but that is the general idea.

Any procedure that has you editing the monolithic directory and replacing 
it as a whole means you have no audit trail (except for "directory 
replaced") and the holodeck safeties are turned off.  All major directory 
changes should be made with DIRM commands.  If you're making a bunch of 
changes at the same time, use DIRM NODIRECT   to suppress the 
DIRECTXA, and then when you're done use DIRM DIRECT to bring all the 
changes online at the same time. 

Alan Altmark

z/VM and Linux on System z Consultant
IBM System Lab Services and Training 
ibm.com/systems/services/labservices 
office: 607.429.3323
alan_altm...@us.ibm.com
IBM Endicott

Re: Maximum Virtual Storage

[Ivan Warren]

On 10/1/2010 10:07 PM, Mike Walter wrote:


I'd venture a guess that IBM would be pleased to sell you sufficient real
storage and DASD to support a few of those VMs, their paging and dump
space requirements.  :-)

110101001000100110010010110101001110011010011001001110100011110110011001



Ah.. IBM & Storage..

I was a bit appalled by the ad I was (and still am) seeing here locally 
(I don't know if you all get that kind)..


Basically, the poster was saying : Storage requirements double every 18 
hours (!!??)


And since I've been seeing this one for about a couple of years, I 
figured that by now, the 'storage requirement' would have, by far, 
exceed the number of electrons in the whole universe by several orders 
of magnitude.. Of course, I may be a bit conservative by assigning 1 bit 
per electron.


But sure - they'll sell it !

(Hey - it's Friday !)

--Ivan

Re: Applying Maintenance - Best Practice

[George Henke/NYLIC]

ty, David for this fine explanation.

It's a nice "trick of the trade".





David Boyes  
Sent by: The IBM z/VM Operating System 
10/01/2010 04:02 PM
Please respond to
The IBM z/VM Operating System 


To
IBMVM@LISTSERV.UARK.EDU
cc

Subject
Re: Applying Maintenance - Best Practice







ty for this information, but I do not follow how the last cylinder of any 
pack on the IIS being unused allows you to name the real packs anything 
you want while still retaining the default names for the 2nd Level system. 

Could you explain in a little more detail? 

Think of it this way: by making the IIS systems deliberately short 1 cyl 
for each pack, you can do the following:
On level 1, each disk has a unique label in real cyl 0, always, no 
excuses. Defining a minidisk from 1 to END on that pack gives you a 
virtual cyl 0 for your guest that can be the default IBM label set (eg 
540RES or the like) without ever interfering with the real system or 
risking the possibility that the 1st level system will accidentally pick 
up a duplicate volser and use the wrong one. You can just restore the IIS 
to the minidisk, and it’ll Just Work. 
You can have as many second level systems as you want in this 
configuration, and they can ALL have the default labels. You just can’t 
directly IPL from them because the boot loader is in cyl 1 instead of 0. I 
solve that problem by having a process for DDR (or flashcopy) of cyl 1 to 
real cyl 0 from test to my “boot set”  of volumes (I have one set for 
current, one set for pending IPL that I alternate between, so backout is 
just IPL from the other set if something goes totally casters up). It’s 
less confusing for IBM if the standard label set is there, and less 
confusing if you have to maintain a lot of similar systems. 
6.2 is probably going to change a lot of that methodology – lots of new 
things coming, and we’ll have to see what still works and doesn’t work at 
that point. 
 
-- db

Re: Applying Maintenance - Best Practice

[George Henke/NYLIC]

tyvm, really sweet.

So we can "have our cake and eat it too".

If I understand what you are saying.

The real volser is on cylinder 0.
But since we define minidisks from cylinder 1 to whatever, the minidisk, 
virtual disk, volser is defined on cylinder 1.

Since DDR never really cares about or writes the last cylinder, though it 
complains, we can DDR to the minidisk, virtual disk, just as we would a to 
real disk and all is copacetic, at least as long as IBM does not mess with 
this.  (Hope Alan is not listening).

And so we can indeed have duplicate volsers,  in name only, at 2nd Level, 
that are not really duplicate.

Not bad.

Not bad at all . . .




peter.w...@ttc.ca 
Sent by: The IBM z/VM Operating System 
10/01/2010 03:58 PM
Please respond to
The IBM z/VM Operating System 


To
IBMVM@LISTSERV.UARK.EDU
cc

Subject
Re: Applying Maintenance - Best Practice






With the disks for your second level system defined like this:
 
MDISK 0100 3390 1 END TVM001 MR
MDISK 0101 3390 1 END TVM002 MR
MDISK 0102 3390 1 END TVM003 MR
MDISK 0103 3390 1 END TVM004 MR
MDISK 0104 3390 1 END TVM005 MR
MDISK 0105 3390 1 END TVM006 MR
MDISK 0106 3390 1 END TVM007 MR
MDISK 0107 3390 1 END TVM008 MR
 
The real labels are TVM001 to TVM008, while the ‘virtual’ labels starting 
on cylinder one can be anything your like, even duplicates of production 
volume labels.
 
Just do a DDR restore to device 100 while logged on to the second level 
user. DDR will complain about the volume being too small, but will restore 
from the beginning of the backup. Since the last cylinder on the backup is 
empty, it doesn’t matter that volume 100 is one cylinder short.
 
Peter
 
-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On 
Behalf Of George Henke/NYLIC
Sent: October 1, 2010 15:51
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Applying Maintenance - Best Practice
 

ty for this information, but I do not follow how the last cylinder of any 
pack on the IIS being unused allows you to name the real packs anything 
you want while still retaining the default names for the 2nd Level system. 


Could you explain in a little more detail? 




Jeff Gribbin  
Sent by: The IBM z/VM Operating System  
10/01/2010 01:35 PM 


Please respond to
The IBM z/VM Operating System 



To
IBMVM@LISTSERV.UARK.EDU 
cc
 
Subject
Re: Applying Maintenance - Best Practice
 


 
 




Just in case this helps ...

If your test system will never be IPLed 1st-level, are you aware that IBM

deliberately does not allocate the last cylinder of any pack (3390-3 or
3390-9) that is part of an Initial Installation System? (That is, 540RES,
etc.)

because the last cylinder is not used, these packs can all be accommodate
d
using minidisks that begin at real cylinder 1 - allowing you to name the
real packs whatever you wish and still retain the default names for your
virtual second-level packs.

I am trying to encourage IBM to make this information more obvious and
well-known but for some reason they feel reluctant so to do.  However, I
have had a clear indication (in reply to a Reader's Comment) that they
intend to continue to do this so I think it's fairly safe to go ahead on 
the
assumption that the last cylinder of a, 'default installation' volume wil
l
not be referenced.

In my view this approach makes much more sense than fiddling around with
real volsers - I am a great believer in keeping all guests away from real

cylinder zero except when this is absolutely unavoidable.

Regards
Jeff
The information transmitted is intended only for the person or entity to 
which it is addressed and may contain confidential and/or privileged 
material. Any review retransmission dissemination or other use of or 
taking any action in reliance upon this information by persons or entities 
other than the intended recipient or delegate is strictly prohibited. If 
you received this in error please contact the sender and delete the 
material from any computer. The integrity and security of this message 
cannot be guaranteed on the Internet. The sender accepts no liability for 
the content of this e-mail or for the consequences of any actions taken on 
the basis of information provided. The recipient should check this e-mail 
and any attachments for the presence of viruses. The sender accepts no 
liability for any damage caused by any virus transmitted by this e-mail. 
This disclaimer is property of the TTC and must not be altered or 
circumvented in any manner. 

Re: Maximum Virtual Storage

[Mike Walter]

Do you mean REAL virtual storage, to which answers have already been 
supplied?
Or do you mean VIRTUAL virtual storage, as documented as the "Maximum 
Input Values for Storage Units" in the CP Planning and Administration 
manual?

For z/VM 5.4 and 6.1 the maximum "stor" size for any virtual machine is 
16E (exabytes).

I'd venture a guess that IBM would be pleased to sell you sufficient real 
storage and DASD to support a few of those VMs, their paging and dump 
space requirements.  :-)

110101001000100110010010110101001110011010011001001110100011110110011001

Mike Walter
Hewitt Associates
The opinions expressed herein are mine alone, not my employer's.




"Gary M. Dennis"  

Sent by: "The IBM z/VM Operating System" 
10/01/2010 02:47 PM
Please respond to
"The IBM z/VM Operating System" 



To
IBMVM@LISTSERV.UARK.EDU
cc

Subject
Maximum Virtual Storage






What is the maximum guest virtual storage supported by z/VM?

--.  .-  .-.  -.--

Gary Dennis
Mantissa Corporation





The information contained in this e-mail and any accompanying documents may 
contain information that is confidential or otherwise protected from 
disclosure. If you are not the intended recipient of this message, or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message, including any attachments. Any 
dissemination, distribution or other use of the contents of this message by 
anyone other than the intended recipient is strictly prohibited. All messages 
sent to and from this e-mail address may be monitored as permitted by 
applicable law and regulations to ensure compliance with our internal policies 
and to protect our business. E-mails are not secure and cannot be guaranteed to 
be error free as they can be intercepted, amended, lost or destroyed, or 
contain viruses. You are deemed to have accepted these risks if you communicate 
with us by e-mail. 

Re: Applying Maintenance - Best Practice

[David Boyes]

ty for this information, but I do not follow how the last cylinder of any pack 
on the IIS being unused allows you to name the real packs anything you want 
while still retaining the default names for the 2nd Level system.
Could you explain in a little more detail?

Think of it this way: by making the IIS systems deliberately short 1 cyl for 
each pack, you can do the following:
On level 1, each disk has a unique label in real cyl 0, always, no excuses. 
Defining a minidisk from 1 to END on that pack gives you a virtual cyl 0 for 
your guest that can be the default IBM label set (eg 540RES or the like) 
without ever interfering with the real system or risking the possibility that 
the 1st level system will accidentally pick up a duplicate volser and use the 
wrong one. You can just restore the IIS to the minidisk, and it'll Just Work.
You can have as many second level systems as you want in this configuration, 
and they can ALL have the default labels. You just can't directly IPL from them 
because the boot loader is in cyl 1 instead of 0. I solve that problem by 
having a process for DDR (or flashcopy) of cyl 1 to real cyl 0 from test to my 
"boot set"  of volumes (I have one set for current, one set for pending IPL 
that I alternate between, so backout is just IPL from the other set if 
something goes totally casters up). It's less confusing for IBM if the standard 
label set is there, and less confusing if you have to maintain a lot of similar 
systems.
6.2 is probably going to change a lot of that methodology - lots of new things 
coming, and we'll have to see what still works and doesn't work at that point.

-- db

Re: Applying Maintenance - Best Practice

[Peter . Webb]

With the disks for your second level system defined like this:

 

MDISK 0100 3390 1 END TVM001 MR

MDISK 0101 3390 1 END TVM002 MR

MDISK 0102 3390 1 END TVM003 MR

MDISK 0103 3390 1 END TVM004 MR

MDISK 0104 3390 1 END TVM005 MR

MDISK 0105 3390 1 END TVM006 MR

MDISK 0106 3390 1 END TVM007 MR

MDISK 0107 3390 1 END TVM008 MR

 

The real labels are TVM001 to TVM008, while the 'virtual' labels
starting on cylinder one can be anything your like, even duplicates of
production volume labels.

 

Just do a DDR restore to device 100 while logged on to the second level
user. DDR will complain about the volume being too small, but will
restore from the beginning of the backup. Since the last cylinder on the
backup is empty, it doesn't matter that volume 100 is one cylinder
short.

 

Peter

 

-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of George Henke/NYLIC
Sent: October 1, 2010 15:51
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Applying Maintenance - Best Practice

 


ty for this information, but I do not follow how the last cylinder of
any pack on the IIS being unused allows you to name the real packs
anything you want while still retaining the default names for the 2nd
Level system. 

Could you explain in a little more detail? 





Jeff Gribbin  
Sent by: The IBM z/VM Operating System  

10/01/2010 01:35 PM 

Please respond to
The IBM z/VM Operating System 

To

IBMVM@LISTSERV.UARK.EDU 

cc

 

Subject

Re: Applying Maintenance - Best Practice

 

 

 




Just in case this helps ...

If your test system will never be IPLed 1st-level, are you aware that
IBM

deliberately does not allocate the last cylinder of any pack (3390-3 or
3390-9) that is part of an Initial Installation System? (That is,
540RES,
etc.)

because the last cylinder is not used, these packs can all be
accommodate
d
using minidisks that begin at real cylinder 1 - allowing you to name the
real packs whatever you wish and still retain the default names for your
virtual second-level packs.

I am trying to encourage IBM to make this information more obvious and
well-known but for some reason they feel reluctant so to do.  However, I
have had a clear indication (in reply to a Reader's Comment) that they
intend to continue to do this so I think it's fairly safe to go ahead on

the
assumption that the last cylinder of a, 'default installation' volume
wil
l
not be referenced.

In my view this approach makes much more sense than fiddling around with
real volsers - I am a great believer in keeping all guests away from
real

cylinder zero except when this is absolutely unavoidable.

Regards
Jeff



The information transmitted is intended only for the person or entity to which 
it is addressed and may contain confidential and/or privileged material.  Any 
review retransmission dissemination or other use of or taking any action in 
reliance upon this information by persons or entities other than the intended 
recipient or delegate is strictly prohibited.  If you received this in error 
please contact the sender and delete the material from any computer.  The 
integrity and security of this message cannot be guaranteed on the Internet.  
The sender accepts no liability for the content of this e-mail or for the 
consequences of any actions taken on the basis of information provided.  The 
recipient should check this e-mail and any attachments for the presence of 
viruses.  The sender accepts no liability for any damage caused by any virus 
transmitted by this e-mail.  This disclaimer is property of the TTC and must 
not be altered or circumvented in any manner.

Re: How DIRMAINT Work ?

[Dave Jones]

Hi, Sergio.

On 10/01/2010 02:06 PM, Sergio Lima wrote:
> 
> Hello Dave,
> 
>  
> 
> Thanks very much from your explanation despite being directed to George.
> 
>  
> 
> For us, is a good idea, do the same that you said, change the size from a 
> minidisk of a virtual machine.
> 
Glad to be of help there.
> 
> Looking in to Manual, We insert the DATAMOVE entries, in the CONFIG file, 
> then res-start again the DIRMAINT.
> 
>  
> 
> Now, We need implement, the EXTENT CONTROL file, and We thing good idea, 
> start define a Full Pack DISK to DRIMAINT define new minidisk.
> 
>  
> 
> Our EXTENT CONTROL file have this :
> 
>  
> 
>  EXTENT   CONTROL  E2  V 80  Trunc=80 Size=57 Line=36 Col=1 Alt=0 
>   
> > 
>   
>   
> |...+1+2+3+4+5+6+7... 
> = *   
>   
> = :REGIONS.   
>   
> =   *RegionId  VolSerRegStart  RegEnd  Dev-Type  Comments 
>   
> = :END.   
>   
> = :GROUPS.
>   
> =   *GroupName RegionList 
>   
> = :END.   
>   
> = :EXCLUDE.   
>   
> =   * UserId Address  
>   
> = :END.   
>   
> = :AUTOBLOCK. 
>   
> =   * IBM supplied defaults are contained in the AUTOBLK DATADVH file.
>   
> =   * The following are customer overrides and supplements.   
>   
> =   * 
>   
> =   *DASDType BlockSize Blocks/Unit Alloc_Unit Architecture   
>   
> = :END.   
>   
> = :DEFAULTS.  
>   
> =   * IBM supplied defaults are contained in the DEFAULTS DATADVH file.   
>   
> =   * The following are customer overrides and supplements.   
>   
> =   * 
>   
> =   *DASDType Max-Size
>   
> = :END.   
>   
> 
>  
> 
>  
> 
> So, Can I insert a DASD here, and start  ask to DIRMAINT create, or realocate 
> any minidisk?
> 
Yes, you can start here by updating the template EXTENT CONTROL file IBM
supplies with DIRMAINT. Just as an example, let's say to have two 3390-9
DASD volumes, with volids USR001 and USR002, that you want DIRMAINT to
control the space allocation on. You need to do the following steps:

1) in the REGIONS section of the EXTENT CONTROL file add the following:
two lines:
 USR001   USR001   1   END3390-09
 USR002   USR002   1   END3390-09

This will define to DIRMAINT two DASD regions named USR001 and USR002;
the regions have the same name as the volids that they are on.

2) In the GROUPS section, add the following two lines:
  VMDASD (ALLOCATE ROTATING)
  VMDASD USR001 USR002

This will define to DIRMAINT a group named VMDASD. The group is made up
of the two regions from step 1 above. The "ALLOCATE ROTATING line tells
DIRMAINT how to perform space allocation in the group.

3) Save the updated EXTENT CONTROL file and tell DIRMAINT to start using
it by the following commands:

 DIRM FILE EXTENT CONTROL
 DIRM RLDEXTN

The first DIRMAINT commands sends the updated EXTENT CONTROL file over
to the DIRMAINT virtual machine and the second command tells DIRMAINT to
start using the new EXTENT CONTROL file immediately.

That is all you need to do, DIRMAINT will now start to manage the DASD
space on the two real USR001 and USR002 volumes.

To use the previous example of changing the size of MAINT's 2CC minidisk
as an example:

DIRM FOR MAINT CMDISK 2CC 3390 AUTOG 150 VMDASD

DIRMAINT will search for 150 free cylinders in the EXTENT CONTROL group
named VMDASD for the needed space.

Have a good one.
>  
> 
> Thanks very much,
> 
>  
> 
> Sergio
> 
>  
> 
>  
> 
> 
>  
>> Date: Fri, 1 Oct 2010 10:22:47 -0500
>> From: d...@vsoft-software.com
>> Subject: Re: How DIRMAINT Work ?
>> To: IBMVM@LISTSERV.UARK.EDU
>>
>> George, the DIRMSAPI EXEC is supplied by IBM with the DIRMAINT
>> producthere's the text about it from the manual:
>>
>>> The DIRMSAPI EXEC is an example of a REXX program that sets up the
>>> proper environment for using the SAPI interface. The DVHSAPI 

Re: Maximum Virtual Storage

[Bill Munson]

Memory
? Central storage
? Supported central storage: 256 GB
? Unsupported central storage (maximum LPAR size):
? z9: 512 GB minus your HSA
? z10: 1 TB
? z196: 1TB
? z/VM primitive tests with 1TB
? Expanded storage (architected): 16TB
? z/VM Limit: 128GB supported
? Upto 660GB unsupported (depends on other factors)
? See http://www.vm.ibm.com/perf/tips/storconf.html
? Virtual machine size:
? Supported/Tested 1 TB (240)
? Hardware limits
? z10 8TB
? z9 1TB
? z990 256GB
? z900 256GB 
Memory
? Active, or instantiated, guest real limit imposed by
PTRM space limits (architected): 8 TB
? 16 4-GB PTRM spaces; each PTRM space can map 512 GB of guest real

http://proceedings.share.org/client_files/SHARE_in_Boston_2/Session_7124_handout_372_0.pdf
 






From:   "Gary M. Dennis" 
To: IBMVM@LISTSERV.UARK.EDU
Date:   10/01/2010 03:47 PM
Subject:Maximum Virtual Storage
Sent by:The IBM z/VM Operating System 



What is the maximum guest virtual storage supported by z/VM?

--.  .-  .-.  -.--

Gary Dennis
Mantissa Corporation



*** IMPORTANT
NOTE*-- The opinions expressed in this
message and/or any attachments are those of the author and not
necessarily those of Brown Brothers Harriman & Co., its
subsidiaries and affiliates ("BBH"). There is no guarantee that
this message is either private or confidential, and it may have
been altered by unauthorized sources without your or our knowledge.
Nothing in the message is capable or intended to create any legally
binding obligations on either party and it is not intended to
provide legal advice. BBH accepts no responsibility for loss or
damage from its use, including damage from virus.

Re: Maximum Virtual Storage

[O'Brien, Dennis L]

Gary,

It depends on your hardware.  From Bill Bitner's z/VM System Limits
SHARE presentation:

 

Virtual machine size:

- Supported/Tested 1 TB (240)

- Hardware limits

* z10 8TB

* z9 1TB

* z990 256GB

* z900 256GB

 

That's for one virtual machine.  There's also a guest real limit of 8 TB
imposed by PTRM space limits.

 

 
Dennis

 

"Decision" is not a verb.

 

From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Gary M. Dennis
Sent: Friday, October 01, 2010 12:47
To: IBMVM@LISTSERV.UARK.EDU
Subject: [IBMVM] Maximum Virtual Storage

 

What is the maximum guest virtual storage supported by z/VM?

--.  .-  .-.  -.--

Gary Dennis
Mantissa Corporation

Re: Applying Maintenance - Best Practice

[George Henke/NYLIC]

ty for this information, but I do not follow how the last cylinder of any 
pack on the IIS being unused allows you to name the real packs anything 
you want while still retaining the default names for the 2nd Level system.

Could you explain in a little more detail?





Jeff Gribbin  
Sent by: The IBM z/VM Operating System 
10/01/2010 01:35 PM
Please respond to
The IBM z/VM Operating System 


To
IBMVM@LISTSERV.UARK.EDU
cc

Subject
Re: Applying Maintenance - Best Practice






Just in case this helps ...

If your test system will never be IPLed 1st-level, are you aware that IBM

deliberately does not allocate the last cylinder of any pack (3390-3 or
3390-9) that is part of an Initial Installation System? (That is, 540RES,
 etc.)

because the last cylinder is not used, these packs can all be accommodate
d
using minidisks that begin at real cylinder 1 - allowing you to name the
real packs whatever you wish and still retain the default names for your
virtual second-level packs.

I am trying to encourage IBM to make this information more obvious and
well-known but for some reason they feel reluctant so to do.  However, I
have had a clear indication (in reply to a Reader's Comment) that they
intend to continue to do this so I think it's fairly safe to go ahead on 
the
assumption that the last cylinder of a, 'default installation' volume wil
l
not be referenced.

In my view this approach makes much more sense than fiddling around with
real volsers - I am a great believer in keeping all guests away from real

cylinder zero except when this is absolutely unavoidable.

Regards
Jeff

Re: Finding the PSP for z/VM 5.4 for z10

[Marcy Cortes]

Hopefully that is for a z10 BC.  A z10 EC is 2097DEVICE.  A z196 EC is 
2817DEVICE.

marcy

-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf 
Of Frank M. Ramaekers
Sent: Friday, October 01, 2010 10:40 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: [IBMVM] Finding the PSP for z/VM 5.4 for z10

Ahhh.

I finally found on the internet that the UPGRADE NAME is 2098DEVICE and
the SUBSET is 2098/ZVM and 2098/ZVSE.

Thanks,
 
Frank M. Ramaekers Jr.
 
 

-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Rich Smrcina
Sent: Friday, October 01, 2010 11:28 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Finding the PSP for z/VM 5.4 for z10

  Without IBMLink, I went here:

http://www.vm.ibm.com/service/

Clicked PSP search, then searched 'vm z10', it's about the third entry.

On 10/01/2010 11:22 AM, Frank M. Ramaekers wrote:
>
> How can I find the PSP bucket for z/VM 5.4 for a z10 (IBMLink)?
>
> Frank M. Ramaekers Jr.
>
>   
>
> Systems Programmer
>
>   
>
> MCP, MCP+I, MCSE & RHCE
>
> American Income Life Insurance Co.
>
>   
>
> Phone: (254)761-6649
>
> 1200 Wooded Acres Dr.
>
>   
>
> Fax: (254)741-5777
>
> Waco, Texas 76701
>
>   
>


-- 
Rich Smrcina
Velocity Software, Inc.
Mobile: 414-491-6001
Office: 262-392-3717
http://www.velocitysoftware.com

Catch the WAVV! http://www.wavv.org
WAVV 2011 - April 15-19, 2011 Colorado Springs, CO

_

This message contains information which is privileged and confidential and is 
solely for the use of the

intended recipient. If you are not the intended recipient, be aware that any 
review, disclosure,

copying, distribution, or use of the contents of this message is strictly 
prohibited. If you have

received this in error, please destroy it immediately and notify us at 
privacy...@ailife.com.

Maximum Virtual Storage

[Gary M. Dennis]

What is the maximum guest virtual storage supported by z/VM?

--.  .-  .-.  -.--

Gary Dennis
Mantissa Corporation

Re: How DIRMAINT Work ?

[Alan Altmark]

On Friday, 10/01/2010 at 02:43 EDT, David Boyes  
wrote:
> In that case, you need to open a PMR and insist that IBM fix that. 
That?s a 
> bug. 

Amen, brother!

Alan Altmark

z/VM and Linux on System z Consultant
IBM System Lab Services and Training 
ibm.com/systems/services/labservices 
office: 607.429.3323
alan_altm...@us.ibm.com
IBM Endicott

Re: How DIRMAINT Work ?

[Sergio Lima]

Thank you,

With these words I'll always be here.
You guys are the best,

 

Best Regards,

 

Sergio


 
> Date: Fri, 1 Oct 2010 14:04:40 -0500
> From: d...@vsoft-software.com
> Subject: Re: How DIRMAINT Work ?
> To: IBMVM@LISTSERV.UARK.EDU
> 
> You are welcome, Sergio. As you can see, everyone here on this list
> wants to be helpful.
> 
> Have a good weekend, too.
> 
> On 10/01/2010 01:10 PM, Sergio Lima wrote:
> > 
> > Hello Dave,
> > 
> > 
> > 
> > Help a lot, for us, was very good understand this.
> > 
> > 
> > 
> > Thanks again, and Best Regards,
> > 
> > 
> > 
> > Sergio
> > 
> > 
> > 
> >> Date: Fri, 1 Oct 2010 09:21:19 -0500
> >> From: d...@vsoft-software.com
> >> Subject: Re: How DIRMAINT Work ?
> >> To: IBMVM@LISTSERV.UARK.EDU
> >>
> >> Hi, Sergio.
> >>
> >> On 10/1/2010 8:54 AM, Sergio Lima wrote:
> >>> Hello List,
> >>>
> >>> We need implement the DIRMAINT product here, but we have some
> >>> doubts.
> >>>
> >>> Have a STEP there, when need migrate our VMUSERS DIRECT A to DIRMAINT
> >>> minidisk.
> >>>
> >>
> >>
> >>> After do this, We never more can edit our VMUSERS DIRECT, as we do
> >>> today?
> >>>
> >> Yes, once you give DIRMAINT control over your VMUSERS DIRECT file, you 
> >> can no longer edit it youself.all changes to the user dirctory mut 
> >> be done by DIRMAINT.
> >>
> >> However, it is very easy to switch bak to managing the VMUSERS DIRECT 
> >> file yourself, jut as you are doing now. Here ar the steps required:
> >>
> >> 1) First tell DIRAMINT to send you a copy of the current (source) user 
> >> directory file:
> >> DIRM USER WITHPASS
> >> 2) receive the sent file onto your A (191) minidisk
> >> RECEIVE  VMUSERS DIRECT A
> >> 3) Stop DIRMAINT processing:
> >> FORCE DIRMAINT
> >> 4) begin making changes to the user directory file by editing it and 
> >> then bringing it online:
> >> XEDIT VMUSRES DIRECT
> >> (make changes)
> >> DIRECTXA VMUSERS
> >>
> >> That's all there is to taking back control of the user directory file 
> >> from DIRMAINT.
> >>
> >> If you want DIRMAINT to (again) manage your user directoy, all you have 
> >> to do is rename the current user directory file USER INPUT to USER INPUT 
> >> and put it on DIRAMINT's 1DF minidisk, are restart the DIRMAINT virtual 
> >> machine.
> >>> We are very concerned about this implementation, which we should take
> >>> necessary precautions?
> >>>
> >>> We already have implemented this, in a test environment, apapparently
> >>> had no problems, but we need to make sure.
> >>>
> >>> Could someone give their opinion?
> >>>
> >>
> >> I've found DIRMAINT to be a useful and stable tool, especially where 
> >> managing DASD space is concerned. The olnly poblems I have ever 
> >> encountered are stalled workunits by the DATAMOVE virtual machine.
> >>
> >> Hope this helps some.
> >>> Thanks very much
> >>>
> >>> Sergio Lima Costa Sao Paulo - Brazil
> >>>
> >>>
> > 
> 
> -- 
> Dave Jones
> V/Soft Software
> www.vsoft-software.com
> Houston, TX
> 281.578.7544
  

Re: How DIRMAINT Work ?

[Sergio Lima]

Hello,

 

Thanks very much from your information.

 

Here, wen don't have a lot of CMS users like this :

 

q users  
   56 USERS,61 DIALED, 0 NET 
Ready; T=0.01/0.01 16:20:45  

 

But, how you said, the very good important point is about manage password 
changes, that is a question that We will study here, and also ask your opinion .

 

Thanks again, and Best Regards,

 

Sergio
 
> Date: Fri, 1 Oct 2010 11:53:13 -0600
> From: ron.schmie...@gmail.com
> Subject: Re: How DIRMAINT Work ?
> To: IBMVM@LISTSERV.UARK.EDU
> 
> Robert,
> DIRMAINT does come with a "wakeup" table of commands that includes a
> BACKUP command to backup your online directory into a source file. It
> runs daily and you always have a current backup on DIRMAINT 1DB. Look
> at DIRMAINT DATADVH
> 
> Sergio,
> I've been using DIRMAINT since coming back to VM in 1999 and it has
> not been a problem using it. I do not miss editing the entire
> directory at all. One other "pro" is that it is an added tool to beat
> back the auditors when they come around asking silly questions like
> "how do you manage password changes"? DIRMAINT can tell you who hasn't
> changed their passwords and you can either send them gentle reminders
> or have DIRMAINT give them a new password.
> 
> Ron
> 
> On Fri, Oct 1, 2010 at 10:13 AM, RPN01  wrote:
> > The benefits are far greater than the loss of directly editing your
> > directory. Have you ever edited your directory and put it online, only to
> > find out later that you’d managed to overlay a minidisk or important piece
> > of CP’s disk? It shouldn’t happen again if you correctly implement Dirmaint.
> > And you won’t have to hunt for space to add a user. You can just say “I need
> > a 200 cyl minidisk, and Dirmaint will find a place to put it. Have two
> > systems? Dirmaint can actually manage one common CP directory between the
> > two. There really isn’t a reason to hand-manage a CP directory that
> > outweighs using Dirmaint or some other directory management tool. The tool
> > is always a better choice.
> >
> > Now, a caveat. On some regular basis, use the command “Dirmaint user
> > withpass”, and save a copy of the old-style complete directory on maint’s,
> > or your 191 disk, just for emergency’s sake. Don’t get caught without a
> > fairly current source directory that you could put online yourself in an
> > emergency situation if something should happen and Dirmaint couldn’t run. I
> > don’t know what that situation might be, but I like the warm, fuzzy feeling
> > of being able to see that “user withpass” file on my 191 disk.
> >
> > --
> > Robert P. Nix  Mayo Foundation.~.
> > RO-OC-1-18 200 First Street SW/V\
> > 507-284-0844   Rochester, MN 55905   /( )\
> > -^^-^^
> > "In theory, theory and practice are the same, but
> >  in practice, theory and practice are different."
> >
> >
> >
> > On 10/1/10 8:54 AM, "Sergio Lima"  wrote:
> >
> > Hello List,
> >
> > We need implement the DIRMAINT product here, but we have some doubts.
> >
> > Have a STEP there, when need migrate our VMUSERS DIRECT A to DIRMAINT
> > minidisk.
> >
> > After do this, We never more can edit our VMUSERS DIRECT, as we do today?
> >
> > We are very concerned about this implementation, which we should take
> > necessary precautions?
> >
> > We already have implemented this, in a test environment, apapparently had no
> > problems, but we need to make sure.
> >
> > Could someone give their opinion?
> >
> > Thanks very much
> >
> > Sergio Lima Costa
> > Sao Paulo - Brazil
> >
> >
> >
> >
  

Re: How DIRMAINT Work ?

[Ray Waters]

Your welcome. Let me know if you need any further help.

Ray

From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf 
Of Sergio Lima
Sent: Friday, October 01, 2010 1:19 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: How DIRMAINT Work ?

Hello Ray,

Thanks from your help .

We imagine that soon will need same like this.

Best Regards,

Sergio


Date: Fri, 1 Oct 2010 10:24:47 -0400
From: ray.wat...@opensolutions.com
Subject: Re: How DIRMAINT Work ?
To: IBMVM@LISTSERV.UARK.EDU
We use all the "DIRMAINT " or "DIRM"  commands and also are able to use XEDIT 
to make our major directory changes. I wrote an EXEC to "DIRMAINT OFFLINE", 
"DIRMAINT BACKUP", DIRMAINT SHUTDOWN", then "COPY USER BACKUP B &DIRNAME DIRECT 
A (OLDD " , followed by "XEDIT &DIRNAME DIRECT A".

Once my EXDIT changes are made and I "FILE", I "COPY &DIRNAME DIRECT A USER 
INPUT C (OLDD" to the DIRMAINT 1DF mdisk," CP XAUTOLOG DIRMAINT", "EXEC 
DIRMAINT ONLINE".

Anyway you get the idea. There are precautions  and sleeps and performed by the 
EXEC, but that is the general idea.

Hope this helps,
Ray Waters

From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf 
Of Sergio Lima
Sent: Friday, October 01, 2010 8:55 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: How DIRMAINT Work ?

Hello List,

We need implement the DIRMAINT product here, but we have some doubts.

Have a STEP there, when need migrate our VMUSERS DIRECT A to DIRMAINT minidisk.

After do this, We never more can edit our VMUSERS DIRECT, as we do today?

We are very concerned about this implementation, which we should take necessary 
precautions?

We already have implemented this, in a test environment, apapparently had no 
problems, but we need to make sure.

Could someone give their opinion?

Thanks very much

Sergio Lima Costa
Sao Paulo - Brazil




NOTICE:
This e-mail is intended solely for the use of the individual to whom it is 
addressed and may contain information that is privileged, confidential or 
otherwise exempt from disclosure. If the reader of this e-mail is not the 
intended recipient or the employee or agent responsible for delivering the 
message to the intended recipient, you are hereby notified that any 
dissemination, distribution, or copying of this communication is strictly 
prohibited. If you have received this communication in error, please 
immediately notify us by replying to the original message at the listed email 
address. Thank You.


NOTICE:
This e-mail is intended solely for the use of the individual to whom it is 
addressed and may contain information that is privileged, confidential or 
otherwise exempt from disclosure. If the reader of this e-mail is not the 
intended recipient or the employee or agent responsible for delivering the 
message to the intended recipient, you are hereby notified that any 
dissemination, distribution, or copying of this communication is strictly 
prohibited. If you have received this communication in error, please 
immediately notify us by replying to the original message at the listed email 
address. Thank You.

Re: How DIRMAINT Work ?

[Scott Rohling]

Not necessarily..   some of those 'stuck workunits' are probably disk
cleaning.   The disks aren't deleted until there are no users linked to
them..other things like that as well..

Scott Rohling

On Fri, Oct 1, 2010 at 12:43 PM, David Boyes  wrote:

>  In that case, you need to open a PMR and insist that IBM fix that. That’s
> a bug.
>
>
>
>
> >  There’s nothing that you can’t change in a directory entry via DIRM
> commands these days,
> Sometimes it just won't delete a user ID when there are outstanding
> (stuck?) workunits (I wish DIRM PURGE had a --FORCE option :))
>
> "Mike MacIsaac"(845) 433-7061
>

Re: How DIRMAINT Work ?

[Sergio Lima]

Hello Dave,

 

Thanks very much from your explanation despite being directed to George.

 

For us, is a good idea, do the same that you said, change the size from a 
minidisk of a virtual machine.

 

Looking in to Manual, We insert the DATAMOVE entries, in the CONFIG file, then 
res-start again the DIRMAINT.

 

Now, We need implement, the EXTENT CONTROL file, and We thing good idea, start 
define a Full Pack DISK to DRIMAINT define new minidisk.

 

Our EXTENT CONTROL file have this :

 

 EXTENT   CONTROL  E2  V 80  Trunc=80 Size=57 Line=36 Col=1 Alt=0   
>   
  |...+1+2+3+4+5+6+7... 
= * 
= :REGIONS. 
=   *RegionId  VolSerRegStart  RegEnd  Dev-Type  Comments   
= :END. 
= :GROUPS.  
=   *GroupName RegionList   
= :END. 
= :EXCLUDE. 
=   * UserId Address
= :END. 
= :AUTOBLOCK.   
=   * IBM supplied defaults are contained in the AUTOBLK DATADVH file.  
=   * The following are customer overrides and supplements. 
=   *   
=   *DASDType BlockSize Blocks/Unit Alloc_Unit Architecture 
= :END. 
= :DEFAULTS.
=   * IBM supplied defaults are contained in the DEFAULTS DATADVH file. 
=   * The following are customer overrides and supplements. 
=   *   
=   *DASDType Max-Size  
= :END. 

 

 

So, Can I insert a DASD here, and start  ask to DIRMAINT create, or realocate 
any minidisk?

 

Thanks very much,

 

Sergio

 

 


 
> Date: Fri, 1 Oct 2010 10:22:47 -0500
> From: d...@vsoft-software.com
> Subject: Re: How DIRMAINT Work ?
> To: IBMVM@LISTSERV.UARK.EDU
> 
> George, the DIRMSAPI EXEC is supplied by IBM with the DIRMAINT
> producthere's the text about it from the manual:
> 
> > The DIRMSAPI EXEC is an example of a REXX program that sets up the
> > proper environment for using the SAPI interface. The DVHSAPI EXEC
> > issues a command to the DIRMAINT service machine and waits for the
> > response, which it passes back to DIRMSAPI EXEC. Both of these sample
> > exec files reside on the user interface disk (4VMDVH10 11F, by
> > default) as file names DIRMSAPI EXECSAMP and DVHSAPI EXECSAMP. These
> > files are available for your examination.
> > 
> > Given a DirMaint command string, the DIRMSAPI EXEC routine calls the
> > DVHSAPI EXEC to send the command to the DIRMAINT service machine and
> > wait for the responses from the service machine. The responses are
> > returned from DVHSAPI in the "DVHSAPI." stem variable.
> > 
> > The DVHSAPI EXEC routine is not intended to be invoked as a command
> > directly from the console. It is intended to be called by a customer
> > supplied REXX program. The DIRMSAPI EXEC (or DIRMSAPI EXECSAMP file)
> > is a sample of such a program.
> 
> To expand your 2CC minidisk, do this (assuming you have logged on as
> MAINT and have configured DIRMAINT correctly):
> 
> DIRM FOR MAINT CMDISK 2CC 3390 AUTOG  
> 
> CMDISK == change minidisk size
> 
> DIRMAINT will perform the following actions:
> 
> 1) search the available DASD space in the group "volume-group-name" for
> a contiguous free space amount of at least "new-mdisk-size".
> 2) If enough free space is available, allocate it to user MAINT at some
> unused virtual address (say FFF here); if not, return an error message
> 3) copy all of the existing files from MAINT's current 2CC disk to the
> new FFF one.
> 4) delete the existing 2CC mdisk definition from MAINT's user directory
> entry
> 5) change the virtual address of the new mdisk from FFF to 2CC.
> 6) bring the new user directory entry for MAINT online.
> 
> That's it, you now have a new 2CC midisk, of size "new-mdisk-size", with
> all of the old 2CC files on it.
> 
> BTW, if I were looking at automating some DIRMAINT tasks, I would use
> the new system management APIs inste

Re: How DIRMAINT Work ?

[Dave Jones]

You are welcome, Sergio. As you can see, everyone here on this list
wants to be helpful.

Have a good weekend, too.

On 10/01/2010 01:10 PM, Sergio Lima wrote:
> 
> Hello Dave,
> 
>  
> 
> Help a lot, for us, was very good understand this.
> 
>  
> 
> Thanks again, and Best Regards,
> 
>  
> 
> Sergio
> 
> 
>  
>> Date: Fri, 1 Oct 2010 09:21:19 -0500
>> From: d...@vsoft-software.com
>> Subject: Re: How DIRMAINT Work ?
>> To: IBMVM@LISTSERV.UARK.EDU
>>
>> Hi, Sergio.
>>
>> On 10/1/2010 8:54 AM, Sergio Lima wrote:
>>> Hello List,
>>>
>>> We need implement the DIRMAINT product here, but we have some
>>> doubts.
>>>
>>> Have a STEP there, when need migrate our VMUSERS DIRECT A to DIRMAINT
>>> minidisk.
>>>
>>
>>
>>> After do this, We never more can edit our VMUSERS DIRECT, as we do
>>> today?
>>>
>> Yes, once you give DIRMAINT control over your VMUSERS DIRECT file, you 
>> can no longer edit it youself.all changes to the user dirctory mut 
>> be done by DIRMAINT.
>>
>> However, it is very easy to switch bak to managing the VMUSERS DIRECT 
>> file yourself, jut as you are doing now. Here ar the steps required:
>>
>> 1) First tell DIRAMINT to send you a copy of the current (source) user 
>> directory file:
>> DIRM USER WITHPASS
>> 2) receive the sent file onto your A (191) minidisk
>> RECEIVE  VMUSERS DIRECT A
>> 3) Stop DIRMAINT processing:
>> FORCE DIRMAINT
>> 4) begin making changes to the user directory file by editing it and 
>> then bringing it online:
>> XEDIT VMUSRES DIRECT
>> (make changes)
>> DIRECTXA VMUSERS
>>
>> That's all there is to taking back control of the user directory file 
>> from DIRMAINT.
>>
>> If you want DIRMAINT to (again) manage your user directoy, all you have 
>> to do is rename the current user directory file USER INPUT to USER INPUT 
>> and put it on DIRAMINT's 1DF minidisk, are restart the DIRMAINT virtual 
>> machine.
>>> We are very concerned about this implementation, which we should take
>>> necessary precautions?
>>>
>>> We already have implemented this, in a test environment, apapparently
>>> had no problems, but we need to make sure.
>>>
>>> Could someone give their opinion?
>>>
>>
>> I've found DIRMAINT to be a useful and stable tool, especially where 
>> managing DASD space is concerned. The olnly poblems I have ever 
>> encountered are stalled workunits by the DATAMOVE virtual machine.
>>
>> Hope this helps some.
>>> Thanks very much
>>>
>>> Sergio Lima Costa Sao Paulo - Brazil
>>>
>>>
> 

-- 
Dave Jones
V/Soft Software
www.vsoft-software.com
Houston, TX
281.578.7544

Re: How DIRMAINT Work ?

[David Boyes]

In that case, you need to open a PMR and insist that IBM fix that. That’s a bug.


>  There’s nothing that you can’t change in a directory entry via DIRM commands 
> these days,
Sometimes it just won't delete a user ID when there are outstanding (stuck?) 
workunits (I wish DIRM PURGE had a --FORCE option :))

"Mike MacIsaac"(845) 433-7061

Re: How DIRMAINT Work ?

[Michael MacIsaac]

David,

>  There’s nothing that you can’t change in a directory entry via DIRM 
commands these days, 
Sometimes it just won't delete a user ID when there are outstanding 
(stuck?) workunits (I wish DIRM PURGE had a --FORCE option :))

"Mike MacIsaac"(845) 433-7061

Re: How DIRMAINT Work ?

[David Boyes]

Honestly, you should not be planning on doing this kind of thing (editing the 
directory source directly).

Once DIRMAINT has control, you're much better off letting it do it's thing, and 
making your changes transactional. You stand a very good chance of shooting 
yourself in the head by messing with the directory file outside. I can say from 
experience: you WILL mess up, and you WILL regret it. There's nothing that you 
can't change in a directory entry via DIRM commands these days, and the more 
human intervention you introduce, the more you increase the probability of 
hurting yourself badly.

Let DIRMAINT do it's job.

Re: How DIRMAINT Work ?

[Sergio Lima]

Hello Mike,

 

Thanks from your help,

 

Regards,

 

Sergio
 


Date: Fri, 1 Oct 2010 10:33:34 -0400
From: mike...@us.ibm.com
Subject: Re: How DIRMAINT Work ?
To: IBMVM@LISTSERV.UARK.EDU


>> We never more can edit our VMUSERS DIRECT 
> That is correct, Sergio. 

But "never" is a strong word.  I believe you can "reprime" the DirMaint pump by 
copying a USER DIRECT file to USER INPUT on the (I believe it is) DIRMAINT 1DF 
disk.  Then when DirMaint is started again, it loads that new directory. 

I agree Rich, in general you don't do that with DirMaint, but you can in a 
pinch. 

There have been times that I've gotten DirMaint royally mucked up so I can't 
delete a user ID. I did a DIRM USER WIHTPASS, pulled the file from the reader, 
changed a couple of settings, copied it as USER INPUT and started fresh. Not 
recommended, I know, but sometimes a useful tool. 

 

P.S. I see Dave Jones posted another method as I was putting this reply 
together.  That makes it look even easier.  Just one question - using that 
model, if DirMaint is restarted, will it have the correct USER DIRECT 
file/directory? 

"Mike MacIsaac"(845) 433-7061   
  

Re: How DIRMAINT Work ?

[Sergio Lima]

Hello Ray,

 

Thanks from your help .

 

We imagine that soon will need same like this.

 

Best Regards,

 

Sergio
 


Date: Fri, 1 Oct 2010 10:24:47 -0400
From: ray.wat...@opensolutions.com
Subject: Re: How DIRMAINT Work ?
To: IBMVM@LISTSERV.UARK.EDU






We use all the “DIRMAINT ” or “DIRM”  commands and also are able to use XEDIT 
to make our major directory changes. I wrote an EXEC to “DIRMAINT OFFLINE”, 
“DIRMAINT BACKUP”, DIRMAINT SHUTDOWN”, then “COPY USER BACKUP B &DIRNAME DIRECT 
A (OLDD “ , followed by “XEDIT &DIRNAME DIRECT A”.
 
Once my EXDIT changes are made and I “FILE”, I “COPY &DIRNAME DIRECT A USER 
INPUT C (OLDD” to the DIRMAINT 1DF mdisk,” CP XAUTOLOG DIRMAINT”, “EXEC 
DIRMAINT ONLINE”.
 
Anyway you get the idea. There are precautions  and sleeps and performed by the 
EXEC, but that is the general idea.
 
Hope this helps,  
Ray Waters
 


From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf 
Of Sergio Lima
Sent: Friday, October 01, 2010 8:55 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: How DIRMAINT Work ?
 
Hello List,
 
We need implement the DIRMAINT product here, but we have some doubts.
 
Have a STEP there, when need migrate our VMUSERS DIRECT A to DIRMAINT minidisk.
 
After do this, We never more can edit our VMUSERS DIRECT, as we do today? 
 
We are very concerned about this implementation, which we should take necessary 
precautions?
 
We already have implemented this, in a test environment, apapparently had no 
problems, but we need to make sure.
 
Could someone give their opinion?
 
Thanks very much
 
Sergio Lima Costa
Sao Paulo - Brazil
 
 


NOTICE:
This e-mail is intended solely for the use of the individual to whom it is 
addressed and may contain information that is privileged, confidential or 
otherwise exempt from disclosure. If the reader of this e-mail is not the 
intended recipient or the employee or agent responsible for delivering the 
message to the intended recipient, you are hereby notified that any 
dissemination, distribution, or copying of this communication is strictly 
prohibited. If you have received this communication in error, please 
immediately notify us by replying to the original message at the listed email 
address. Thank You.
  

Re: How DIRMAINT Work ?

[Sergio Lima]

Hello Dave,

 

Help a lot, for us, was very good understand this.

 

Thanks again, and Best Regards,

 

Sergio


 
> Date: Fri, 1 Oct 2010 09:21:19 -0500
> From: d...@vsoft-software.com
> Subject: Re: How DIRMAINT Work ?
> To: IBMVM@LISTSERV.UARK.EDU
> 
> Hi, Sergio.
> 
> On 10/1/2010 8:54 AM, Sergio Lima wrote:
> > Hello List,
> >
> > We need implement the DIRMAINT product here, but we have some
> > doubts.
> >
> > Have a STEP there, when need migrate our VMUSERS DIRECT A to DIRMAINT
> > minidisk.
> >
> 
> 
> > After do this, We never more can edit our VMUSERS DIRECT, as we do
> > today?
> >
> Yes, once you give DIRMAINT control over your VMUSERS DIRECT file, you 
> can no longer edit it youself.all changes to the user dirctory mut 
> be done by DIRMAINT.
> 
> However, it is very easy to switch bak to managing the VMUSERS DIRECT 
> file yourself, jut as you are doing now. Here ar the steps required:
> 
> 1) First tell DIRAMINT to send you a copy of the current (source) user 
> directory file:
> DIRM USER WITHPASS
> 2) receive the sent file onto your A (191) minidisk
> RECEIVE  VMUSERS DIRECT A
> 3) Stop DIRMAINT processing:
> FORCE DIRMAINT
> 4) begin making changes to the user directory file by editing it and 
> then bringing it online:
> XEDIT VMUSRES DIRECT
> (make changes)
> DIRECTXA VMUSERS
> 
> That's all there is to taking back control of the user directory file 
> from DIRMAINT.
> 
> If you want DIRMAINT to (again) manage your user directoy, all you have 
> to do is rename the current user directory file USER INPUT to USER INPUT 
> and put it on DIRAMINT's 1DF minidisk, are restart the DIRMAINT virtual 
> machine.
> > We are very concerned about this implementation, which we should take
> > necessary precautions?
> >
> > We already have implemented this, in a test environment, apapparently
> > had no problems, but we need to make sure.
> >
> > Could someone give their opinion?
> >
> 
> I've found DIRMAINT to be a useful and stable tool, especially where 
> managing DASD space is concerned. The olnly poblems I have ever 
> encountered are stalled workunits by the DATAMOVE virtual machine.
> 
> Hope this helps some.
> > Thanks very much
> >
> > Sergio Lima Costa Sao Paulo - Brazil
> >
> >
  

Re: How DIRMAINT Work ?

[Ron Schmiedge]

Robert,
DIRMAINT does come with a "wakeup" table of commands that includes a
BACKUP command to backup your online directory into a source file. It
runs daily and you always have a current backup on DIRMAINT 1DB. Look
at DIRMAINT DATADVH

Sergio,
I've been using DIRMAINT since coming back to VM in 1999 and it has
not been a problem using it. I do not miss editing the entire
directory at all. One other "pro" is that it is an added tool to beat
back the auditors when they come around asking silly questions like
"how do you manage password changes"? DIRMAINT can tell you who hasn't
changed their passwords and you can either send them gentle reminders
or have DIRMAINT give them a new password.

Ron

On Fri, Oct 1, 2010 at 10:13 AM, RPN01  wrote:
> The benefits are far greater than the loss of directly editing your
> directory. Have you ever edited your directory and put it online, only to
> find out later that you’d managed to overlay a minidisk or important piece
> of CP’s disk? It shouldn’t happen again if you correctly implement Dirmaint.
> And you won’t have to hunt for space to add a user. You can just say “I need
> a 200 cyl minidisk, and Dirmaint will find a place to put it. Have two
> systems? Dirmaint can actually manage one common CP directory between the
> two. There really isn’t a reason to hand-manage a CP directory that
> outweighs using Dirmaint or some other directory management tool. The tool
> is always a better choice.
>
> Now, a caveat. On some regular basis, use the command “Dirmaint user
> withpass”, and save a copy of the old-style complete directory on maint’s,
> or your 191 disk, just for emergency’s sake. Don’t get caught without a
> fairly current source directory that you could put online yourself in an
> emergency situation if something should happen and Dirmaint couldn’t run. I
> don’t know what that situation might be, but I like the warm, fuzzy feeling
> of being able to see that “user withpass” file on my 191 disk.
>
> --
> Robert P. Nix  Mayo Foundation    .~.
> RO-OC-1-18 200 First Street SW    /V\
> 507-284-0844   Rochester, MN 55905   /( )\
> -    ^^-^^
> "In theory, theory and practice are the same, but
>  in practice, theory and practice are different."
>
>
>
> On 10/1/10 8:54 AM, "Sergio Lima"  wrote:
>
> Hello List,
>
> We need implement the DIRMAINT product here, but we have some doubts.
>
> Have a STEP there, when need migrate our VMUSERS DIRECT A to DIRMAINT
> minidisk.
>
> After do this, We never more can edit our VMUSERS DIRECT, as we do today?
>
> We are very concerned about this implementation, which we should take
> necessary precautions?
>
> We already have implemented this, in a test environment, apapparently had no
> problems, but we need to make sure.
>
> Could someone give their opinion?
>
> Thanks very much
>
> Sergio Lima Costa
> Sao Paulo - Brazil
>
>
>
>

Re: Finding the PSP for z/VM 5.4 for z10

[Frank M. Ramaekers]

Ahhh.

I finally found on the internet that the UPGRADE NAME is 2098DEVICE and
the SUBSET is 2098/ZVM and 2098/ZVSE.

Thanks,
 
Frank M. Ramaekers Jr.
 
 

-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Rich Smrcina
Sent: Friday, October 01, 2010 11:28 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Finding the PSP for z/VM 5.4 for z10

  Without IBMLink, I went here:

http://www.vm.ibm.com/service/

Clicked PSP search, then searched 'vm z10', it's about the third entry.

On 10/01/2010 11:22 AM, Frank M. Ramaekers wrote:
>
> How can I find the PSP bucket for z/VM 5.4 for a z10 (IBMLink)?
>
> Frank M. Ramaekers Jr.
>
>   
>
> Systems Programmer
>
>   
>
> MCP, MCP+I, MCSE & RHCE
>
> American Income Life Insurance Co.
>
>   
>
> Phone: (254)761-6649
>
> 1200 Wooded Acres Dr.
>
>   
>
> Fax: (254)741-5777
>
> Waco, Texas 76701
>
>   
>


-- 
Rich Smrcina
Velocity Software, Inc.
Mobile: 414-491-6001
Office: 262-392-3717
http://www.velocitysoftware.com

Catch the WAVV! http://www.wavv.org
WAVV 2011 - April 15-19, 2011 Colorado Springs, CO

_
This message contains information which is privileged and confidential and is 
solely for the use of the
intended recipient. If you are not the intended recipient, be aware that any 
review, disclosure,
copying, distribution, or use of the contents of this message is strictly 
prohibited. If you have
received this in error, please destroy it immediately and notify us at 
privacy...@ailife.com.

Re: Applying Maintenance - Best Practice

[Jeff Gribbin]

Just in case this helps ...

If your test system will never be IPLed 1st-level, are you aware that IBM

deliberately does not allocate the last cylinder of any pack (3390-3 or
3390-9) that is part of an Initial Installation System? (That is, 540RES,
 etc.)

because the last cylinder is not used, these packs can all be accommodate
d
using minidisks that begin at real cylinder 1 - allowing you to name the
real packs whatever you wish and still retain the default names for your
virtual second-level packs.

I am trying to encourage IBM to make this information more obvious and
well-known but for some reason they feel reluctant so to do.  However, I
have had a clear indication (in reply to a Reader's Comment) that they
intend to continue to do this so I think it's fairly safe to go ahead on 
the
assumption that the last cylinder of a, 'default installation' volume wil
l
not be referenced.

In my view this approach makes much more sense than fiddling around with
real volsers - I am a great believer in keeping all guests away from real

cylinder zero except when this is absolutely unavoidable.

Regards
Jeff

Re: Finding the PSP for z/VM 5.4 for z10

[Rich Smrcina]

 Without IBMLink, I went here:

http://www.vm.ibm.com/service/

Clicked PSP search, then searched 'vm z10', it's about the third entry.

On 10/01/2010 11:22 AM, Frank M. Ramaekers wrote:


How can I find the PSP bucket for z/VM 5.4 for a z10 (IBMLink)?

Frank M. Ramaekers Jr.



Systems Programmer



MCP, MCP+I, MCSE & RHCE

American Income Life Insurance Co.



Phone: (254)761-6649

1200 Wooded Acres Dr.



Fax: (254)741-5777

Waco, Texas 76701






--
Rich Smrcina
Velocity Software, Inc.
Mobile: 414-491-6001
Office: 262-392-3717
http://www.velocitysoftware.com

Catch the WAVV! http://www.wavv.org
WAVV 2011 - April 15-19, 2011 Colorado Springs, CO

Finding the PSP for z/VM 5.4 for z10

[Frank M. Ramaekers]

How can I find the PSP bucket for z/VM 5.4 for a z10 (IBMLink)?

 

 Frank M. Ramaekers Jr.

 

Systems Programmer

MCP, MCP+I, MCSE & RHCE

American Income Life Insurance Co.

Phone: (254)761-6649

1200 Wooded Acres Dr.

Fax: (254)741-5777

Waco, Texas  76701

 

 


_
This message contains information which is privileged and confidential and is 
solely for the use of the
intended recipient. If you are not the intended recipient, be aware that any 
review, disclosure,
copying, distribution, or use of the contents of this message is strictly 
prohibited. If you have
received this in error, please destroy it immediately and notify us at 
privacy...@ailife.com.

Re: How DIRMAINT Work ?

[RPN01]

The benefits are far greater than the loss of directly editing your
directory. Have you ever edited your directory and put it online, only to
find out later that you¹d managed to overlay a minidisk or important piece
of CP¹s disk? It shouldn¹t happen again if you correctly implement Dirmaint.
And you won¹t have to hunt for space to add a user. You can just say ³I need
a 200 cyl minidisk, and Dirmaint will find a place to put it. Have two
systems? Dirmaint can actually manage one common CP directory between the
two. There really isn¹t a reason to hand-manage a CP directory that
outweighs using Dirmaint or some other directory management tool. The tool
is always a better choice.

Now, a caveat. On some regular basis, use the command ³Dirmaint user
withpass², and save a copy of the old-style complete directory on maint¹s,
or your 191 disk, just for emergency¹s sake. Don¹t get caught without a
fairly current source directory that you could put online yourself in an
emergency situation if something should happen and Dirmaint couldn¹t run. I
don¹t know what that situation might be, but I like the warm, fuzzy feeling
of being able to see that ³user withpass² file on my 191 disk.

-- 
Robert P. Nix  Mayo Foundation.~.
RO-OC-1-18 200 First Street SW/V\
507-284-0844   Rochester, MN 55905   /( )\
-^^-^^
"In theory, theory and practice are the same, but
 in practice, theory and practice are different."



On 10/1/10 8:54 AM, "Sergio Lima"  wrote:

> Hello List,
>  
> We need implement the DIRMAINT product here, but we have some doubts.
>  
> Have a STEP there, when need migrate our VMUSERS DIRECT A to DIRMAINT
> minidisk.
>  
> After do this, We never more can edit our VMUSERS DIRECT, as we do today?
>  
> We are very concerned about this implementation, which we should take
> necessary precautions?
>  
> We already have implemented this, in a test environment, apapparently had no
> problems, but we need to make sure.
>  
> Could someone give their opinion?
>  
> Thanks very much
>  
> Sergio Lima Costa
> Sao Paulo - Brazil
>  
>  
>

Re: DIRMAINT AUTH Question

[Sergio Lima]

Hello Scott, and others.

 

Now run very well.

 

Thanks very much from your help.

 

Thanks, you guys have encouraged us, continue working here.

 

 

Regards,

 

Sergio
 


Date: Fri, 1 Oct 2010 09:33:00 -0600
From: scott.rohl...@gmail.com
Subject: Re: DIRMAINT AUTH Question
To: IBMVM@LISTSERV.UARK.EDU

Give yourself more than just class A  (these are DIRMAINT classes - NOT CP 
classes):

ALL MAINT* 150A ADGHMOPSZ

If that doesn't help - it may be your system name specification - so try * as 
above..

Scott Rohling


On Fri, Oct 1, 2010 at 9:26 AM, Sergio Lima  wrote:


Hello Mr. Alan, and others,
 
We look the Manual, try do something here, and unfortynatelly still don't run.
We create the file below, with two records :
 
 AUTHFOR  CONTROL  E1  F 80  Trun
>
  |...+1+2+..
= * * * Top of File * * *
= ALL GERENTE GRV-DC 150A A  
= ALL MAINT   GRV-DC 150A A  
= * * * End of File * * *
 
We understand, that then, the MAINT virtual machine can do a lot, but, when try 
for example get a copy of a VMUSERS DIRECT, have te same message :
 
DIRM for * USER WITHPASS 
DVHXMT1191I Your USER request has been sent for processing.  
Ready; T=0.07/0.08 12:12:34  
 DVHREQ2283E Userid MAINT at GRV-DC is not authorized to issue the USER  
 DVHREQ2283E command for MAINT at *. 
 
So, what We need change more?
 
Thanks,

 
Sergio
 
> Date: Thu, 30 Sep 2010 14:25:27 -0400
> From: alan_altm...@us.ibm.com
> Subject: Re: DIRMAINT AUTH Question
> To: IBMVM@LISTSERV.UARK.EDU
> 



> On Thursday, 09/30/2010 at 02:10 EDT, Sergio Lima 
>  wrote:
> > Hello Dave,
> > 
> > Looking the DIRMAINT machine, can't found the AUTHFOR CONTROL file.
> > 
> > We found only here AUTHDASD DATADVH E2 , and the E disk is :
> > 
> > q disk 
> e 
> > LABEL VDEV M STAT CYL TYPE BLKSZ FILES BLKS USED-(%) BLKS LEFT 
> BLK TOTAL
> > DIR1DF 1DF E R/W 9 3390 4096 260 552-34 
> 1068 1620
> > 
> > Do you know if have other place from try find?
> 
> You need to read Chapter 8 of the DIRMAINT Administration book. Use the 
> DIRM AUTHFOR command to create or update the AUTHFOR CONTROL file.
> 
> Alan Altmark
> 
> z/VM and Linux on System z Consultant
> IBM System Lab Services and Training 
> ibm.com/systems/services/labservices 
> office: 607.429.3323
> alan_altm...@us.ibm.com
> IBM Endicott

  

Re: How DIRMAINT Work ?

[David Boyes]

Also, would someone please give the pro's and con's of using DIRMAINT as 
opposed to just XEDIT directly.
As  long as your check DISKMAP for OVER and specify the EDIT option for 
DIRECTXA, does DIRMAINT really buy you that much more, other than updating 
entries individually?

Unquestionably, yes.
Cons:
DIRMAINT costs money.
The user interface is “quaint”.  Quote from my lab manager: “What a screaming 
bloody nightmare. Whatever they’re giving the guy who was forced to implement 
this… it amounts to cruel and unusual punishment for spiders, cobras, and other 
noxious vermin, let alone human beings.”

Pros:
DIRMAINT doesn’t make math mistakes on cylinder offsets
DIRMAINT makes coping with RACF less of a PITA. RACF is still a PITA, but less 
so.
DIRMAINT allows you to delegate managing userids to other people without giving 
them the total keys to the entire system.
DIRMAINT maintains a audit trail as to who changed what when and from where.
DIRMAINT allows users to manage their own password changes.
DIRMAINT lets you programmatically script system changes via the SMAPI tools.
Etc, etc, etc.

I vastly prefer VM:Secure, but DIRM is a hard act to follow in terms of price, 
and having it preinstalled makes it really easy to have a working directory 
manager up and running ASAP after install. If it saves you one stupid mistake, 
it’s totally worth the small amount of money it costs to have a directory 
manager.

Re: DIRMAINT AUTH Question

[Scott Rohling]

Give yourself more than just class A  (these are DIRMAINT classes - NOT CP
classes):

ALL MAINT* 150A ADGHMOPSZ

If that doesn't help - it may be your system name specification - so try *
as above..

Scott Rohling

On Fri, Oct 1, 2010 at 9:26 AM, Sergio Lima  wrote:

>  Hello Mr. Alan, and others,
>
> We look the Manual, try do something here, and unfortynatelly still don't
> run.
> We create the file below, with two records :
>
>  AUTHFOR  CONTROL  E1  F 80  Trun
> >
>   |...+1+2+..
> = * * * Top of File * * *
> = ALL GERENTE GRV-DC 150A A
> = ALL MAINT   GRV-DC 150A A
> = * * * End of File * * *
>
> We understand, that then, the MAINT virtual machine can do a lot, but, when
> try for example get a copy of a VMUSERS DIRECT, have te same message :
>
> DIRM for * USER WITHPASS
> DVHXMT1191I Your USER request has been sent for processing.
> Ready; T=0.07/0.08 12:12:34
>  DVHREQ2283E Userid MAINT at GRV-DC is not authorized to issue the USER
>  DVHREQ2283E command for MAINT at *.
>
> So, what We need change more?
>
> Thanks,
>
>
> Sergio
>
> > Date: Thu, 30 Sep 2010 14:25:27 -0400
> > From: alan_altm...@us.ibm.com
> > Subject: Re: DIRMAINT AUTH Question
> > To: IBMVM@LISTSERV.UARK.EDU
> >
> > On Thursday, 09/30/2010 at 02:10 EDT, Sergio Lima
> >  wrote:
> > > Hello Dave,
> > >
> > > Looking the DIRMAINT machine, can't found the AUTHFOR CONTROL file.
> > >
> > > We found only here AUTHDASD DATADVH E2 , and the E disk is :
> > >
> > > q disk
> > e
> > > LABEL VDEV M STAT CYL TYPE BLKSZ FILES BLKS USED-(%) BLKS LEFT
> > BLK TOTAL
> > > DIR1DF 1DF E R/W 9 3390 4096 260 552-34
> > 1068 1620
> > >
> > > Do you know if have other place from try find?
> >
> > You need to read Chapter 8 of the DIRMAINT Administration book. Use the
> > DIRM AUTHFOR command to create or update the AUTHFOR CONTROL file.
> >
> > Alan Altmark
> >
> > z/VM and Linux on System z Consultant
> > IBM System Lab Services and Training
> > ibm.com/systems/services/labservices
> > office: 607.429.3323
> > alan_altm...@us.ibm.com
> > IBM Endicott
>

Re: DIRMAINT AUTH Question

[Sergio Lima]

Hello Mr. Alan, and others,

 

We look the Manual, try do something here, and unfortynatelly still don't run.

We create the file below, with two records :

 

 AUTHFOR  CONTROL  E1  F 80  Trun
>
  |...+1+2+..
= * * * Top of File * * *
= ALL GERENTE GRV-DC 150A A  
= ALL MAINT   GRV-DC 150A A  
= * * * End of File * * *

 

We understand, that then, the MAINT virtual machine can do a lot, but, when try 
for example get a copy of a VMUSERS DIRECT, have te same message :

 

DIRM for * USER WITHPASS 

DVHXMT1191I Your USER request has been sent for processing.  
Ready; T=0.07/0.08 12:12:34  
 DVHREQ2283E Userid MAINT at GRV-DC is not authorized to issue the USER  
 DVHREQ2283E command for MAINT at *. 

 

So, what We need change more?

 

Thanks,

 

Sergio
 
> Date: Thu, 30 Sep 2010 14:25:27 -0400
> From: alan_altm...@us.ibm.com
> Subject: Re: DIRMAINT AUTH Question
> To: IBMVM@LISTSERV.UARK.EDU
> 
> On Thursday, 09/30/2010 at 02:10 EDT, Sergio Lima 
>  wrote:
> > Hello Dave,
> > 
> > Looking the DIRMAINT machine, can't found the AUTHFOR CONTROL file.
> > 
> > We found only here AUTHDASD DATADVH E2 , and the E disk is :
> > 
> > q disk 
> e 
> > LABEL VDEV M STAT CYL TYPE BLKSZ FILES BLKS USED-(%) BLKS LEFT 
> BLK TOTAL
> > DIR1DF 1DF E R/W 9 3390 4096 260 552-34 
> 1068 1620
> > 
> > Do you know if have other place from try find?
> 
> You need to read Chapter 8 of the DIRMAINT Administration book. Use the 
> DIRM AUTHFOR command to create or update the AUTHFOR CONTROL file.
> 
> Alan Altmark
> 
> z/VM and Linux on System z Consultant
> IBM System Lab Services and Training 
> ibm.com/systems/services/labservices 
> office: 607.429.3323
> alan_altm...@us.ibm.com
> IBM Endicott
  

Re: How DIRMAINT Work ?

[Dave Jones]

George, the DIRMSAPI EXEC is supplied by IBM with the DIRMAINT
producthere's the text about it from the manual:

> The DIRMSAPI EXEC is an example of a REXX program that sets up the
> proper  environment for using the SAPI interface. The DVHSAPI EXEC
> issues a command to the DIRMAINT service machine and waits for the
> response, which it passes back to DIRMSAPI EXEC. Both of these sample
> exec files reside on the user interface disk (4VMDVH10 11F, by
> default) as file names DIRMSAPI  EXECSAMP and DVHSAPI EXECSAMP. These
> files are available for your examination.
> 
> Given a DirMaint command string, the DIRMSAPI EXEC routine calls the
> DVHSAPI EXEC to send the command to the DIRMAINT service machine and
> wait for the responses from the service machine. The responses are
> returned from DVHSAPI in the "DVHSAPI." stem variable.
> 
> The DVHSAPI EXEC routine is not intended to be invoked as a command
> directly from the console. It is intended to be called by a customer
> supplied REXX program. The DIRMSAPI EXEC (or DIRMSAPI EXECSAMP file)
> is a sample of such a program.

To expand your 2CC minidisk, do this (assuming you have logged on as
MAINT and have configured DIRMAINT correctly):

DIRM FOR MAINT CMDISK 2CC 3390 AUTOG  

CMDISK == change minidisk size

DIRMAINT will perform the following actions:

1) search the available DASD space in the group "volume-group-name" for
a contiguous free space amount of at least "new-mdisk-size".
2) If enough free space is available, allocate it to user MAINT at some
unused virtual address (say FFF here); if not, return an error message
3) copy all of the existing files from MAINT's current 2CC disk to the
new FFF one.
4) delete the existing 2CC mdisk definition from MAINT's user directory
entry
5) change the virtual address of the new mdisk from FFF to 2CC.
6) bring the new user directory entry for MAINT online.

That's it, you now have a new 2CC midisk, of size "new-mdisk-size", with
all of the old 2CC files on it.

BTW, if I were looking at automating some DIRMAINT tasks, I would use
the new system management APIs instead of the DIRMSAPI.they are
easier to code to (imho), can be driven across a TCPIP network, and
enable VM management functions on the HMC. (Point and click virtual
machine creation)

Hope this helps.
On 10/01/2010 10:03 AM, George Henke/NYLIC wrote:
> ty, Scott.
> 
> I would appreciate a copy of your DIRMSAPI EXEC.
> 
> Also, right now I am tight for space on my MAINT 2CC md.
> 
> Would DIRM allow me to expand that space with a single command as you
> say and, if so, would you be good enough to give the specifics.
> 
> tia
> 
> 
> 
> 
> Scott Rohling  Sent by: The IBM z/VM
> Operating System  10/01/2010 10:57 AM Please
> respond to The IBM z/VM Operating System 
> 
> 
> To IBMVM@LISTSERV.UARK.EDU cc
> 
> Subject Re: How DIRMAINT Work ?
> 
> 
> 
> 
> 
> 
> There are many pros -- including attempting to keep you from shooting
>  yourself in the foot - allowing administrative control over who can
> do what with the directory - allowing users to make their own changes
> (like changing their password -- if you don't use an ESM) - etc.   It
> also allow you to assign volumes in groups and DIRMAINT will
> automatically find free space and create minidisks out of those
> groups.  It attempts to prevent minidisk overlays, etc.   It cleans
> mindisks when they are deleted.   It gives you a one command way to
> increase a minidisk.   I could go on for awhile
> 
> To me -  one of the biggest advantages of DIRMAINT is that you now
> have an automated way to create guests.   You can use DIRMSAPI from
> an EXEC -- get synchronous responses from DIRMAINT -- and voila - you
> can manipulate the directory with an EXEC.   Imagine:   Create guest
> from template directory, do a DIRM ADD,  clone the disks, autolog the
> new guest - with one script.   Just ensure you have free space in
> your DASD pools and your good.
> 
> Scott Rohling
> 
> On Fri, Oct 1, 2010 at 8:35 AM, George Henke/NYLIC < 
> george_he...@newyorklife.com> wrote:
> 
> Ray,
> 
> Please attach a copy of your EXEC in a reply.
> 
> I would find it very useful.
> 
> Also, would someone please give the pro's and con's of using DIRMAINT
> as opposed to just XEDIT directly.
> 
> As  long as your check DISKMAP for OVER and specify the EDIT option
> for DIRECTXA, does DIRMAINT really buy you that much more, other than
> updating entries individually?
> 
> 
> 
> 
> Ray Waters  Sent by: The IBM z/VM
> Operating System  10/01/2010 10:24 AM
> 
> 
> Please respond to The IBM z/VM Operating System
> 
> 
> 
> To IBMVM@LISTSERV.UARK.EDU cc
> 
> Subject Re: How DIRMAINT Work ?
> 
> 
> 
> 
> 
> 
> 
> 
> We use all the “DIRMAINT ” or “DIRM”  commands and also are able to
> use XEDIT to make our major directory changes. I wrote an EXEC to
> “DIRMAINT OFFLINE”, “DIRMAINT BACKUP”, DIRMAINT SHUTDOWN”, then “COPY
> USER BACKUP B &DIRNAME DIRECT A (OLDD “ , followed by “XEDIT &DIRNAME
> DIRECT A”.
> 
> Once my EXDI

Re: How DIRMAINT Work ?

[Scott Rohling]

DIRMSAPI EXEC comes with DIRMAINT -- although it might come as a SAMPEXEC
--  it's on the DIRMAINT 11F on my system, but it should be on one of the
DIRMAINT minidisks.   It's purpose is to issue DIRMAINT commands -- but also
wait for a response -- so it normally used for writing EXECs which
communicate with DIRMAINT.

Let's say you have a group called 'SYSTEM' defined in EXTENT CONTROL that
contains 540W01 and  540W02.

DIRM FOR MAINT CMDISK 2CC 3390 AUTOG 10 SYSTEM

This tells DIRMAINT to change MAINT's 2CC to a 10 cylinder minidisk which
will be taken out of the SYSTEM group free space.   Note you need to DETACH
2CC from MAINT or the request will not complete.   DIRMAINT will assign the
current MAINT 2CC disk and a new 10 cylinder disk to DATAMOVE.   DATAMOVE
will copy all the files from the old 2CC to the new one.   After that's done
- DIRMAINT assigns the new 10 cylinder minidisk to MAINT as 2CC -- and tells
DATAMOVE to clean the old minidisk.   After all that - the old disk is free
space an unassigned.

If you wanted to put the space on a particular volume and you know what it
is:

DIRM FOR MAINT CMDISK 2CC 3390 AUTOV 10 540W01


Same process - but instead of picking from a group - DIRMAINT will look
specifically on 540W01 for the 10 cylinders.

Note AUTOV (automated volume) and AUTOG (automated group).   You can also
give specific cylinders if you want:

DIRM FOR MAINT CMDISK 2CC 3390 1051 10 540W01

As long as those cylinders aren't already assigned - DIRMAINT will put the
minidisk where you told him to.

Scott Rohling

On Fri, Oct 1, 2010 at 9:03 AM, George Henke/NYLIC <
george_he...@newyorklife.com> wrote:

>
> ty, Scott.
>
> I would appreciate a copy of your DIRMSAPI EXEC.
>
> Also, right now I am tight for space on my MAINT 2CC md.
>
> Would DIRM allow me to expand that space with a single command as you say
> and, if so, would you be good enough to give the specifics.
>
> tia
>
>
>
>  *Scott Rohling *
> Sent by: The IBM z/VM Operating System 
>
> 10/01/2010 10:57 AM
>  Please respond to
> The IBM z/VM Operating System 
>
>   To
> IBMVM@LISTSERV.UARK.EDU
> cc
>   Subject
> Re: How DIRMAINT Work ?
>
>
>
>
> There are many pros -- including attempting to keep you from shooting
> yourself in the foot - allowing administrative control over who can do what
> with the directory - allowing users to make their own changes (like changing
> their password -- if you don't use an ESM) - etc.   It also allow you to
> assign volumes in groups and DIRMAINT will automatically find free space and
> create minidisks out of those groups.  It attempts to prevent minidisk
> overlays, etc.   It cleans mindisks when they are deleted.   It gives you a
> one command way to increase a minidisk.   I could go on for awhile
>
> To me -  one of the biggest advantages of DIRMAINT is that you now have an
> automated way to create guests.   You can use DIRMSAPI from an EXEC -- get
> synchronous responses from DIRMAINT -- and voila - you can manipulate the
> directory with an EXEC.   Imagine:   Create guest from template directory,
> do a DIRM ADD,  clone the disks, autolog the new guest - with one script.
> Just ensure you have free space in your DASD pools and your good.
>
> Scott Rohling
>
> On Fri, Oct 1, 2010 at 8:35 AM, George Henke/NYLIC <*
> george_he...@newyorklife.com* > wrote:
>
> Ray,
>
> Please attach a copy of your EXEC in a reply.
>
> I would find it very useful.
>
> Also, would someone please give the pro's and con's of using DIRMAINT as
> opposed to just XEDIT directly.
>
> As  long as your check DISKMAP for OVER and specify the EDIT option for
> DIRECTXA, does DIRMAINT really buy you that much more, other than updating
> entries individually?
>
>
>
>   *Ray Waters <**ray.wat...@opensolutions.com*
> *>*
> Sent by: The IBM z/VM Operating System 
> <*ib...@listserv.uark.edu*
> >
>
> 10/01/2010 10:24 AM
>
>
>   Please respond to
> The IBM z/VM Operating System 
> <*ib...@listserv.uark.edu*
> >
>
>   To
> *ib...@listserv.uark.edu* 
> cc
>   Subject
> Re: How DIRMAINT Work ?
>
>
>
>
>
>
> We use all the “DIRMAINT ” or “DIRM”  commands and also are able to use
> XEDIT to make our major directory changes. I wrote an EXEC to “DIRMAINT
> OFFLINE”, “DIRMAINT BACKUP”, DIRMAINT SHUTDOWN”, then “COPY USER BACKUP B
> &DIRNAME DIRECT A (OLDD “ , followed by “XEDIT &DIRNAME DIRECT A”.
>
> Once my EXDIT changes are made and I “FILE”, I “COPY &DIRNAME DIRECT A USER
> INPUT C (OLDD” to the DIRMAINT 1DF mdisk,” CP XAUTOLOG DIRMAINT”, “EXEC
> DIRMAINT ONLINE”.
>
> Anyway you get the idea. There are precautions  and sleeps and performed by
> the EXEC, but that is the general idea.
>
> Hope this helps,
> Ray Waters
>   *
> From:* The IBM z/VM Operating System 
> [mailto:*ib...@listserv.uark.edu*]
> *On Behalf Of *Sergio Lima*
> Sent:* Friday, October 01, 2010 8:55 AM*
> To:* *ib...@listserv.uark.edu* *
> Subject:* How DIRMAINT Work ?
>
> Hello List,
>
> We need implement the DIRMAINT product here, but we have some doubts.
>
> Have a S

Re: How DIRMAINT Work ?

[George Henke/NYLIC]

ty, Scott.

I would appreciate a copy of your DIRMSAPI EXEC.

Also, right now I am tight for space on my MAINT 2CC md.

Would DIRM allow me to expand that space with a single command as you say 
and, if so, would you be good enough to give the specifics.

tia




Scott Rohling  
Sent by: The IBM z/VM Operating System 
10/01/2010 10:57 AM
Please respond to
The IBM z/VM Operating System 


To
IBMVM@LISTSERV.UARK.EDU
cc

Subject
Re: How DIRMAINT Work ?






There are many pros -- including attempting to keep you from shooting 
yourself in the foot - allowing administrative control over who can do 
what with the directory - allowing users to make their own changes (like 
changing their password -- if you don't use an ESM) - etc.   It also allow 
you to assign volumes in groups and DIRMAINT will automatically find free 
space and create minidisks out of those groups.  It attempts to prevent 
minidisk overlays, etc.   It cleans mindisks when they are deleted.   It 
gives you a one command way to increase a minidisk.   I could go on for 
awhile

To me -  one of the biggest advantages of DIRMAINT is that you now have an 
automated way to create guests.   You can use DIRMSAPI from an EXEC -- get 
synchronous responses from DIRMAINT -- and voila - you can manipulate the 
directory with an EXEC.   Imagine:   Create guest from template directory, 
do a DIRM ADD,  clone the disks, autolog the new guest - with one 
script.   Just ensure you have free space in your DASD pools and your 
good.

Scott Rohling

On Fri, Oct 1, 2010 at 8:35 AM, George Henke/NYLIC <
george_he...@newyorklife.com> wrote:

Ray, 

Please attach a copy of your EXEC in a reply. 

I would find it very useful. 

Also, would someone please give the pro's and con's of using DIRMAINT as 
opposed to just XEDIT directly. 

As  long as your check DISKMAP for OVER and specify the EDIT option for 
DIRECTXA, does DIRMAINT really buy you that much more, other than updating 
entries individually? 




Ray Waters  
Sent by: The IBM z/VM Operating System  
10/01/2010 10:24 AM 


Please respond to
The IBM z/VM Operating System 


To
IBMVM@LISTSERV.UARK.EDU 
cc

Subject
Re: How DIRMAINT Work ?








We use all the “DIRMAINT ” or “DIRM”  commands and also are able to use 
XEDIT to make our major directory changes. I wrote an EXEC to “DIRMAINT 
OFFLINE”, “DIRMAINT BACKUP”, DIRMAINT SHUTDOWN”, then “COPY USER BACKUP B 
&DIRNAME DIRECT A (OLDD “ , followed by “XEDIT &DIRNAME DIRECT A”. 
  
Once my EXDIT changes are made and I “FILE”, I “COPY &DIRNAME DIRECT A 
USER INPUT C (OLDD” to the DIRMAINT 1DF mdisk,” CP XAUTOLOG DIRMAINT”, 
“EXEC DIRMAINT ONLINE”. 
  
Anyway you get the idea. There are precautions  and sleeps and performed 
by the EXEC, but that is the general idea. 
  
Hope this helps,   
Ray Waters 
  
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On 
Behalf Of Sergio Lima
Sent: Friday, October 01, 2010 8:55 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: How DIRMAINT Work ? 
  
Hello List,

We need implement the DIRMAINT product here, but we have some doubts.

Have a STEP there, when need migrate our VMUSERS DIRECT A to DIRMAINT 
minidisk.

After do this, We never more can edit our VMUSERS DIRECT, as we do today? 

We are very concerned about this implementation, which we should take 
necessary precautions?

We already have implemented this, in a test environment, apapparently had 
no problems, but we need to make sure.

Could someone give their opinion?

Thanks very much

Sergio Lima Costa
Sao Paulo - Brazil


NOTICE:
This e-mail is intended solely for the use of the individual to whom it is 
addressed and may contain information that is privileged, confidential or 
otherwise exempt from disclosure. If the reader of this e-mail is not the 
intended recipient or the employee or agent responsible for delivering the 
message to the intended recipient, you are hereby notified that any 
dissemination, distribution, or copying of this communication is strictly 
prohibited. If you have received this communication in error, please 
immediately notify us by replying to the original message at the listed 
email address. Thank You. 

Re: How DIRMAINT Work ?

[Scott Rohling]

There are many pros -- including attempting to keep you from shooting
yourself in the foot - allowing administrative control over who can do what
with the directory - allowing users to make their own changes (like changing
their password -- if you don't use an ESM) - etc.   It also allow you to
assign volumes in groups and DIRMAINT will automatically find free space and
create minidisks out of those groups.  It attempts to prevent minidisk
overlays, etc.   It cleans mindisks when they are deleted.   It gives you a
one command way to increase a minidisk.   I could go on for awhile

To me -  one of the biggest advantages of DIRMAINT is that you now have an
automated way to create guests.   You can use DIRMSAPI from an EXEC -- get
synchronous responses from DIRMAINT -- and voila - you can manipulate the
directory with an EXEC.   Imagine:   Create guest from template directory,
do a DIRM ADD,  clone the disks, autolog the new guest - with one script.
Just ensure you have free space in your DASD pools and your good.

Scott Rohling

On Fri, Oct 1, 2010 at 8:35 AM, George Henke/NYLIC <
george_he...@newyorklife.com> wrote:

>
> Ray,
>
> Please attach a copy of your EXEC in a reply.
>
> I would find it very useful.
>
> Also, would someone please give the pro's and con's of using DIRMAINT as
> opposed to just XEDIT directly.
>
> As  long as your check DISKMAP for OVER and specify the EDIT option for
> DIRECTXA, does DIRMAINT really buy you that much more, other than updating
> entries individually?
>
>
>
>
>  *Ray Waters *
> Sent by: The IBM z/VM Operating System 
>
> 10/01/2010 10:24 AM
>  Please respond to
> The IBM z/VM Operating System 
>
>   To
> IBMVM@LISTSERV.UARK.EDU
> cc
>   Subject
> Re: How DIRMAINT Work ?
>
>
>
>
> We use all the “DIRMAINT ” or “DIRM”  commands and also are able to use
> XEDIT to make our major directory changes. I wrote an EXEC to “DIRMAINT
> OFFLINE”, “DIRMAINT BACKUP”, DIRMAINT SHUTDOWN”, then “COPY USER BACKUP B
> &DIRNAME DIRECT A (OLDD “ , followed by “XEDIT &DIRNAME DIRECT A”.
>
> Once my EXDIT changes are made and I “FILE”, I “COPY &DIRNAME DIRECT A USER
> INPUT C (OLDD” to the DIRMAINT 1DF mdisk,” CP XAUTOLOG DIRMAINT”, “EXEC
> DIRMAINT ONLINE”.
>
> Anyway you get the idea. There are precautions  and sleeps and performed by
> the EXEC, but that is the general idea.
>
> Hope this helps,
> Ray Waters
>
> *From:* The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] *On
> Behalf Of *Sergio Lima*
> Sent:* Friday, October 01, 2010 8:55 AM*
> To:* ib...@listserv.uark.edu*
> Subject:* How DIRMAINT Work ?
>
> Hello List,
>
> We need implement the DIRMAINT product here, but we have some doubts.
>
> Have a STEP there, when need migrate our VMUSERS DIRECT A to DIRMAINT
> minidisk.
>
> After do this, We never more can edit our VMUSERS DIRECT, as we do today?
>
> We are very concerned about this implementation, which we should take
> necessary precautions?
>
> We already have implemented this, in a test environment, apapparently had
> no problems, but we need to make sure.
>
> Could someone give their opinion?
>
> Thanks very much
>
> Sergio Lima Costa
> Sao Paulo - Brazil
>
>
>  --
> NOTICE:
> This e-mail is intended solely for the use of the individual to whom it is
> addressed and may contain information that is privileged, confidential or
> otherwise exempt from disclosure. If the reader of this e-mail is not the
> intended recipient or the employee or agent responsible for delivering the
> message to the intended recipient, you are hereby notified that any
> dissemination, distribution, or copying of this communication is strictly
> prohibited. If you have received this communication in error, please
> immediately notify us by replying to the original message at the listed
> email address. Thank You.
>
>

Re: How DIRMAINT Work ?

[Dave Jones]

Hi, Mike.

On 10/1/2010 9:33 AM, Michael MacIsaac wrote:
[snip]


P.S. I see Dave Jones posted another method as I was putting this
reply together. That makes it look even easier. Just one question -
using that model, if DirMaint is restarted, will it have the correct
USER DIRECT file/directory?



I see that in my original post I hosted up a sentence:


If you want DIRMAINT to (again) manage your user directoy, all you
have to do is rename the current user directory file USER INPUT to
USER INPUT and put it on DIRAMINT's 1DF minidisk, are restart the
DIRMAINT virtual machine.


What I meant to say was "...have to do is copy the current source user 
directory file (say, VMUSERS DIRECT) to DIRMAINT's 1DF minidisk and 
rename it USER INPUT (the file *must be*  named USER INPUT or DIRMAINT 
will not pick it up). Then restart the DIRMAINT virtual machine."


I hope that clears up the confusion Mike reported. Sorry about that.

Have a good one.
DJ


"Mike MacIsaac"  (845) 433-7061

Re: How DIRMAINT Work ?

[Dave Jones]

Hi, George.

I think the usefulness of directory manager tools like DIRMAINT are 
directly (ha! a pun) related to how often you make directory 
changesif you have a small set of stable users (like in a Linux PoC, 
say), then managing the directory by hand is feasible. But I can almost 
guarantee (from personal experience) that you will at one point or 
another make a mistake (in allocating DASD space for a new minidisk, 
say) that will cause you some grief. :-)


Of course, it is now quite clear from IBM announcements that their new 
tools for managing virtual images on mainframes will rely on having a 
tool like DIRMAINT available.


Just my opinion, of course.

Have a good one.
DJ

On 10/1/2010 9:35 AM, George Henke/NYLIC wrote:


Ray,

Please attach a copy of your EXEC in a reply.

I would find it very useful.

Also, would someone please give the pro's and con's of using DIRMAINT as
opposed to just XEDIT directly.

As long as your check DISKMAP for OVER and specify the EDIT option for
DIRECTXA, does DIRMAINT really buy you that much more, other than
updating entries individually?




*Ray Waters *
Sent by: The IBM z/VM Operating System 

10/01/2010 10:24 AM
Please respond to
The IBM z/VM Operating System 



To
IBMVM@LISTSERV.UARK.EDU
cc

Subject
Re: How DIRMAINT Work ?








We use all the “DIRMAINT ” or “DIRM” commands and also are able to use
XEDIT to make our major directory changes. I wrote an EXEC to “DIRMAINT
OFFLINE”, “DIRMAINT BACKUP”, DIRMAINT SHUTDOWN”, then “COPY USER BACKUP
B &DIRNAME DIRECT A (OLDD “ , followed by “XEDIT &DIRNAME DIRECT A”.

Once my EXDIT changes are made and I “FILE”, I “COPY &DIRNAME DIRECT A
USER INPUT C (OLDD” to the DIRMAINT 1DF mdisk,” CP XAUTOLOG DIRMAINT”,
“EXEC DIRMAINT ONLINE”.

Anyway you get the idea. There are precautions and sleeps and performed
by the EXEC, but that is the general idea.

Hope this helps,
Ray Waters

*From:* The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu]
*On Behalf Of *Sergio Lima*
Sent:* Friday, October 01, 2010 8:55 AM*
To:* ib...@listserv.uark.edu*
Subject:* How DIRMAINT Work ?

Hello List,

We need implement the DIRMAINT product here, but we have some doubts.

Have a STEP there, when need migrate our VMUSERS DIRECT A to DIRMAINT
minidisk.

After do this, We never more can edit our VMUSERS DIRECT, as we do today?

We are very concerned about this implementation, which we should take
necessary precautions?

We already have implemented this, in a test environment, apapparently
had no problems, but we need to make sure.

Could someone give their opinion?

Thanks very much

Sergio Lima Costa
Sao Paulo - Brazil


NOTICE:
This e-mail is intended solely for the use of the individual to whom it
is addressed and may contain information that is privileged,
confidential or otherwise exempt from disclosure. If the reader of this
e-mail is not the intended recipient or the employee or agent
responsible for delivering the message to the intended recipient, you
are hereby notified that any dissemination, distribution, or copying of
this communication is strictly prohibited. If you have received this
communication in error, please immediately notify us by replying to the
original message at the listed email address. Thank You.

Re: How DIRMAINT Work ?

[George Henke/NYLIC]

Ray,

Please attach a copy of your EXEC in a reply.

I would find it very useful.

Also, would someone please give the pro's and con's of using DIRMAINT as 
opposed to just XEDIT directly.

As  long as your check DISKMAP for OVER and specify the EDIT option for 
DIRECTXA, does DIRMAINT really buy you that much more, other than updating 
entries individually?





Ray Waters  
Sent by: The IBM z/VM Operating System 
10/01/2010 10:24 AM
Please respond to
The IBM z/VM Operating System 


To
IBMVM@LISTSERV.UARK.EDU
cc

Subject
Re: How DIRMAINT Work ?






We use all the “DIRMAINT ” or “DIRM”  commands and also are able to use 
XEDIT to make our major directory changes. I wrote an EXEC to “DIRMAINT 
OFFLINE”, “DIRMAINT BACKUP”, DIRMAINT SHUTDOWN”, then “COPY USER BACKUP B 
&DIRNAME DIRECT A (OLDD “ , followed by “XEDIT &DIRNAME DIRECT A”.
 
Once my EXDIT changes are made and I “FILE”, I “COPY &DIRNAME DIRECT A 
USER INPUT C (OLDD” to the DIRMAINT 1DF mdisk,” CP XAUTOLOG DIRMAINT”, 
“EXEC DIRMAINT ONLINE”.
 
Anyway you get the idea. There are precautions  and sleeps and performed 
by the EXEC, but that is the general idea.
 
Hope this helps, 
Ray Waters
 
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On 
Behalf Of Sergio Lima
Sent: Friday, October 01, 2010 8:55 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: How DIRMAINT Work ?
 
Hello List,
 
We need implement the DIRMAINT product here, but we have some doubts.
 
Have a STEP there, when need migrate our VMUSERS DIRECT A to DIRMAINT 
minidisk.
 
After do this, We never more can edit our VMUSERS DIRECT, as we do today? 
 
We are very concerned about this implementation, which we should take 
necessary precautions?
 
We already have implemented this, in a test environment, apapparently had 
no problems, but we need to make sure.
 
Could someone give their opinion?
 
Thanks very much
 
Sergio Lima Costa
Sao Paulo - Brazil
 
 

NOTICE:
This e-mail is intended solely for the use of the individual to whom it is 
addressed and may contain information that is privileged, confidential or 
otherwise exempt from disclosure. If the reader of this e-mail is not the 
intended recipient or the employee or agent responsible for delivering the 
message to the intended recipient, you are hereby notified that any 
dissemination, distribution, or copying of this communication is strictly 
prohibited. If you have received this communication in error, please 
immediately notify us by replying to the original message at the listed 
email address. Thank You.

Re: How DIRMAINT Work ?

[Michael MacIsaac]

>> We never more can edit our VMUSERS DIRECT
> That is correct, Sergio.

But "never" is a strong word.  I believe you can "reprime" the DirMaint 
pump by copying a USER DIRECT file to USER INPUT on the (I believe it is) 
DIRMAINT 1DF disk.  Then when DirMaint is started again, it loads that new 
directory.

I agree Rich, in general you don't do that with DirMaint, but you can in a 
pinch.

There have been times that I've gotten DirMaint royally mucked up so I 
can't delete a user ID. I did a DIRM USER WIHTPASS, pulled the file from 
the reader, changed a couple of settings, copied it as USER INPUT and 
started fresh. Not recommended, I know, but sometimes a useful tool.



P.S. I see Dave Jones posted another method as I was putting this reply 
together.  That makes it look even easier.  Just one question - using that 
model, if DirMaint is restarted, will it have the correct USER DIRECT 
file/directory?

"Mike MacIsaac"(845) 433-7061

MVMUA meeting October 19, 2010

[Bill Munson]

The fourth quarter meeting of the Metropolitan VM and LINUX Users 
Association 
will be on Tuesday October 19, 2010 at Brown Brothers Harriman in Jersey 
City.

Here is the link to the agenda, directions, and security procedures 

 http://www2.marist.edu/~mvmua/2010oct.html 

please let me know if you are attending

thanx
 
Bill Munson 
Sr. z/VM Systems Programmer 
Brown Brothers Harriman & CO.
525 Washington Blvd. 
Jersey City, NJ 07310 
201-418-7588

President - MVMUA
http://www2.marist.edu/~mvmua/
VM Project Officer - SHARE 
http://www.linkedin.com/in/BillMunson


*** IMPORTANT
NOTE*-- The opinions expressed in this
message and/or any attachments are those of the author and not
necessarily those of Brown Brothers Harriman & Co., its
subsidiaries and affiliates ("BBH"). There is no guarantee that
this message is either private or confidential, and it may have
been altered by unauthorized sources without your or our knowledge.
Nothing in the message is capable or intended to create any legally
binding obligations on either party and it is not intended to
provide legal advice. BBH accepts no responsibility for loss or
damage from its use, including damage from virus.

Re: How DIRMAINT Work ?

[Ray Waters]

We use all the "DIRMAINT " or "DIRM"  commands and also are able to use XEDIT 
to make our major directory changes. I wrote an EXEC to "DIRMAINT OFFLINE", 
"DIRMAINT BACKUP", DIRMAINT SHUTDOWN", then "COPY USER BACKUP B &DIRNAME DIRECT 
A (OLDD " , followed by "XEDIT &DIRNAME DIRECT A".

Once my EXDIT changes are made and I "FILE", I "COPY &DIRNAME DIRECT A USER 
INPUT C (OLDD" to the DIRMAINT 1DF mdisk," CP XAUTOLOG DIRMAINT", "EXEC 
DIRMAINT ONLINE".

Anyway you get the idea. There are precautions  and sleeps and performed by the 
EXEC, but that is the general idea.

Hope this helps,
Ray Waters

From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf 
Of Sergio Lima
Sent: Friday, October 01, 2010 8:55 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: How DIRMAINT Work ?

Hello List,

We need implement the DIRMAINT product here, but we have some doubts.

Have a STEP there, when need migrate our VMUSERS DIRECT A to DIRMAINT minidisk.

After do this, We never more can edit our VMUSERS DIRECT, as we do today?

We are very concerned about this implementation, which we should take necessary 
precautions?

We already have implemented this, in a test environment, apapparently had no 
problems, but we need to make sure.

Could someone give their opinion?

Thanks very much

Sergio Lima Costa
Sao Paulo - Brazil




NOTICE:
This e-mail is intended solely for the use of the individual to whom it is 
addressed and may contain information that is privileged, confidential or 
otherwise exempt from disclosure. If the reader of this e-mail is not the 
intended recipient or the employee or agent responsible for delivering the 
message to the intended recipient, you are hereby notified that any 
dissemination, distribution, or copying of this communication is strictly 
prohibited. If you have received this communication in error, please 
immediately notify us by replying to the original message at the listed email 
address. Thank You.

Re: How DIRMAINT Work ?

[Sergio Lima]

Hello Rich,

 

I'm glad to hear you again.

 

Thanks very much from your help,

 

Have a nice day, and best regards,

 

Sergio


 
> Date: Fri, 1 Oct 2010 09:11:25 -0500
> From: r...@velocitysoftware.com
> Subject: Re: How DIRMAINT Work ?
> To: IBMVM@LISTSERV.UARK.EDU
> 
> That is correct, Sergio. When Dirmaint is fully implemented, the systems 
> programmer 
> no longer maintains the USER DIRECT file. Dirmaint maintains the directory. 
> The 
> systems programmer performs directory maintenance using Dirmaint commands.
> 
> This is proven software that works very well. If there are problems with it, 
> IBM will 
> fix those problems.
> 
> On 10/01/2010 08:54 AM, Sergio Lima wrote:
> > Hello List,
> >
> > We need implement the DIRMAINT product here, but we have some doubts.
> >
> > Have a STEP there, when need migrate our VMUSERS DIRECT A to DIRMAINT 
> > minidisk.
> >
> > After do this, We never more can edit our VMUSERS DIRECT, as we do today?
> >
> > We are very concerned about this implementation, which we should take 
> > necessary 
> > precautions?
> >
> > We already have implemented this, in a test environment, apapparently had 
> > no problems, 
> > but we need to make sure.
> >
> > Could someone give their opinion?
> >
> > Thanks very much
> >
> > Sergio Lima Costa
> > Sao Paulo - Brazil
> >
> >
> 
> 
> -- 
> Rich Smrcina
> Velocity Software, Inc.
> Mobile: 414-491-6001
> Office: 262-392-3717
> http://www.velocitysoftware.com
> 
> Catch the WAVV! http://www.wavv.org
> WAVV 2011 - April 15-19, 2011 Colorado Springs, CO
  

Re: How DIRMAINT Work ?

[Dave Jones]

Hi, Sergio.

On 10/1/2010 8:54 AM, Sergio Lima wrote:

Hello List,

We need implement the DIRMAINT product here, but we have some
doubts.

Have a STEP there, when need migrate our VMUSERS DIRECT A to DIRMAINT
 minidisk.





After do this, We never more can edit our VMUSERS DIRECT, as we do
today?

Yes, once you give DIRMAINT control over your VMUSERS DIRECT file, you 
can no longer edit it youself.all changes to the user dirctory mut 
be done by DIRMAINT.


However, it is very easy to switch bak to managing the VMUSERS DIRECT 
file yourself, jut as you are doing now. Here ar the steps required:


1) First tell DIRAMINT to send you a copy of the current (source) user 
directory file:

   DIRM USER WITHPASS
2) receive the sent file onto your A (191) minidisk
   RECEIVE  VMUSERS DIRECT A
3) Stop DIRMAINT processing:
  FORCE DIRMAINT
4) begin making changes to the user directory file by editing it and 
then bringing it online:

   XEDIT VMUSRES DIRECT
 (make changes)
   DIRECTXA VMUSERS

That's all there is to taking back control of the user directory file 
from DIRMAINT.


If you want DIRMAINT to (again) manage your user directoy, all you have 
to do is rename the current user directory file USER INPUT to USER INPUT 
and put it on DIRAMINT's 1DF minidisk, are restart the DIRMAINT virtual 
machine.

We are very concerned about this implementation, which we should take
 necessary precautions?

We already have implemented this, in a test environment, apapparently
 had no problems, but we need to make sure.

Could someone give their opinion?



I've found DIRMAINT to be a useful and stable tool, especially where 
managing DASD space is concerned. The olnly poblems I have ever 
encountered are stalled workunits by the DATAMOVE virtual machine.


Hope this helps some.

Thanks very much

Sergio Lima Costa Sao Paulo - Brazil

Re: z/VM ISFC links

[Mark Wheeler]

In the Better Late (for John) Than Never department, the Redbook "FICON CTC 
Implementation" was published in 2001. Find it at 
http://www.redbooks.ibm.com/redpapers/pdfs/redp0158.pdf
 
Mark Wheeler
UnitedHealth Group 

--
 
"Excellence. Always. If Not Excellence, What? If Not Excellence Now, When?" 
Tom Peters, author of "The Little BIG Things"




 
> Date: Thu, 30 Sep 2010 19:25:24 +0200
> From: jphartm...@gmail.com
> Subject: Re: z/VM ISFC links
> To: IBMVM@LISTSERV.UARK.EDU
> 
> When I set up something similar in a 6-lpar VM system almost 10 years
> ago, it took me quite some time to get the CTC defined correctly in
> the IOCP so that I had n-to-n connectivity. Of course this was in the
> days of stand-alone IOCP. I hope you have better tools.
> 
> j.
> 
> On 30 September 2010 19:00, Mark Pace  wrote:
> > I see that now.
> > 1st criteria for this test is to share SFS across LPARs.
> > 2nd was to start learning about what will be involved with SSI.
> > So I guess I'm sticking to ISFC.
> > Glad I have extra ESCON and FICON CHPIDs.  Guess I'll start with ESCON as I
> > also have extra cables, no extra FICON cables.
> >
> > On Thu, Sep 30, 2010 at 12:49 PM, Rob van der Heij 
> > wrote:
> >>
> >> On Thu, Sep 30, 2010 at 6:21 PM, Mark Pace  wrote:
> >>
> >> > I think I'll also look into IPGATE.
> >>
> >> But that does not do ISFC ...
> >
> >
> >
> > --
> > Mark D Pace
> > Senior Systems Engineer
> > Mainline Information Systems
> >
> >
> >
> >
  

Re: How DIRMAINT Work ?

[Rich Smrcina]

 That is correct, Sergio.  When Dirmaint is fully implemented, the systems programmer 
no longer maintains the USER DIRECT file.  Dirmaint maintains the directory.  The 
systems programmer performs directory maintenance using Dirmaint commands.


This is proven software that works very well.  If there are problems with it, IBM will 
fix those problems.


On 10/01/2010 08:54 AM, Sergio Lima wrote:

Hello List,

We need implement the DIRMAINT product here, but we have some doubts.

Have a STEP there, when need migrate our VMUSERS DIRECT A to DIRMAINT minidisk.

After do this, We never more can edit our VMUSERS DIRECT, as we do today?

We are very concerned about this implementation, which we should take necessary 
precautions?


We already have implemented this, in a test environment, apapparently had no problems, 
but we need to make sure.


Could someone give their opinion?

Thanks very much

Sergio Lima Costa
Sao Paulo - Brazil





--
Rich Smrcina
Velocity Software, Inc.
Mobile: 414-491-6001
Office: 262-392-3717
http://www.velocitysoftware.com

Catch the WAVV! http://www.wavv.org
WAVV 2011 - April 15-19, 2011 Colorado Springs, CO

Re: z/VM ISFC links

[Shimon Lebowitz]

Hi John,
I also had a hard time setting up n-to-n CTC connections, 
but I tried to document how it is done for others, here:
http://www.sinenomine.net/node/265

>From its blurb on SineNomine:
"This document describes a cookbook example of how to
configure ESCON CTC connections between LPARs on a single
zSeries system. It demonstrates how to plan and code the
necessary IOCP statements to interconnect multiple LPARs"

Once again, I thank SineNomine for hosting it.

Shimon

 Original message 
>Date:   Thu, 30 Sep 2010 19:25:24 +0200
>From:   "John P. Hartmann"   
>Subject:   Re: z/VM ISFC links  
>To:   IBMVM@LISTSERV.UARK.EDU
>
>When I set up something similar in a 6-lpar VM system almost
10 years
>ago, it took me quite some time to get the CTC defined
correctly in
>the IOCP so that I had n-to-n connectivity.  Of course this
was in the
>days of stand-alone IOCP.  I hope you have better tools.
>
>   j.
>
>On 30 September 2010 19:00, Mark Pace
 wrote:
>> I see that now.
>> 1st criteria for this test is to share SFS across LPARs.
>> 2nd was to start learning about what will be involved with SSI.
>> So I guess I'm sticking to ISFC.
>> Glad I have extra ESCON and FICON CHPIDs.  Guess I'll start
with ESCON as I
>> also have extra cables, no extra FICON cables.
>>
>> On Thu, Sep 30, 2010 at 12:49 PM, Rob van der Heij

>> wrote:
>>>
>>> On Thu, Sep 30, 2010 at 6:21 PM, Mark Pace
 wrote:
>>>
>>> > I think I'll also look into IPGATE.
>>>
>>> But that does not do ISFC ...
>>
>>
>>
>> --
>> Mark D Pace
>> Senior Systems Engineer
>> Mainline Information Systems
>>
>>
>>
>>

How DIRMAINT Work ?

[Sergio Lima]

Hello List,

 

We need implement the DIRMAINT product here, but we have some doubts.

 

Have a STEP there, when need migrate our VMUSERS DIRECT A to DIRMAINT minidisk.

 

After do this, We never more can edit our VMUSERS DIRECT, as we do today? 

 

We are very concerned about this implementation, which we should take necessary 
precautions?

 

We already have implemented this, in a test environment, apapparently had no 
problems, but we need to make sure.

 

Could someone give their opinion?

 

Thanks very much

 

Sergio Lima Costa

Sao Paulo - Brazil

 

 
  

A confused CCW question.

[Tom Huegel]

Someone from our LINUX LAB asked me to trace 'TIMESTAMP' CCW's to
mini-disks.

I never heard of a 'TIMESTAMP' CCW, but since most of my channel programming
knowledge dates back to preXA hardware I thought I would try to look it up
in the manuals.
After searching I could find nothing even suggesting there is a CCW command
that instructs the control unit to timestamp something.

Has anyone ever heard of such a thing? or be able to point me to some doc
that explains it.


If I sound vague it is because I am. This request has been translated
through no less that 3 languages (all "English").

Thanks

Re: z/VM ISFC links

[George Henke/NYLIC]

On 9/30/10 5:55 PM, "George Henke/NYLIC"  
wrote:

> Unfortunately that was day 1, but its source did not appear until day 4. 


David Boyes wrote:

>Well, the tech support load for that day 1 thing was pretty heavy. We 
took a couple days off after the launch party. 8-) 


No, that was day 7, after everything was done.




David Boyes  
Sent by: The IBM z/VM Operating System 
09/30/2010 11:18 PM
Please respond to
The IBM z/VM Operating System 


To
IBMVM@LISTSERV.UARK.EDU
cc

Subject
Re: z/VM ISFC links







On 9/30/10 5:55 PM, "George Henke/NYLIC"  
wrote:

> Unfortunately that was day 1, but its source did not appear until day 4. 


Well, the tech support load for that day 1 thing was pretty heavy. We took 
a couple days off after the launch party. 8-)