Hello all,
I have a 3390-3 allocated as all Perm (PERM 0 3338
3339). Dirmaint will
not let me allocate past cylinder 1170? I have another 3390-3 also
allocated as all
Perm and Dirmaint won't let me allocate past cylinder 1100? Any ideas?
Thanks,
Mary Zervos
VM Systems
Does your EXTENT CONTROL file have them configured as 3390-3? Does
DIRMAINT think there is something else on the volume?
Mary Zervos wrote:
Hello all,
I have a 3390-3 allocated as all Perm (PERM 0 3338
3339). Dirmaint will
not let me allocate past cylinder 1170? I have
Yes, the Extent control file has them as 3390-3. A Dirm Usedext shows
all the users mdisks. A Dirm Freext comes up empty.
Rich Smrcina wrote:
Does your EXTENT CONTROL file have them configured as 3390-3? Does
DIRMAINT think there is something else on the volume?
Mary Zervos wrote:
Hello
Does EXTENT CONTROL have a subset of the volumes configured? The third
and fourth tokens on each line is the starting and ending cylinders of
the area that DIRMAINT is allowed to allocate.
Are you having problems with any other 3390-3 volumes?
Mary Zervos wrote:
Yes, the Extent control file
It's sounding like the disks already have minidisks on them so you can't
allocate past those values?Can you show entries from EXTENT CONTROL (for
these volumes - and also the 3390-3 definition at the bottom (check for dupe
3390-3 defs!)) -- and also from USEDEXT ?
Scott Rohling
On Tue, Aug
This is a new z/VM 5.3 system I'm working on. Very few userids with
mdisks have been allocated so far.
I've only added the following to the Extent Control file.and the
Defaults Datadvh file is set right.
:REGIONS.
*RegionId VolSer
When you added it to EXTENT CONTROL, did you send the file back to
DIRMAINT and tell it to reload the EXTENT CONTROL file (DIRM RLDEXTN)?
Mary Zervos wrote:
This is a new z/VM 5.3 system I'm working on. Very few userids with
mdisks have been allocated so far.
I've only added the following to
Make sure you do *not* have an EXTENT CONTROL file on your A disk,
DIRMAINT will use that one first.
Thank you,
Scott R Wandschneider
Senior Systems Programmer
Infocrossing
Office 402.963.8905
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED]
On Behalf
Maint's 191 A disk is where I purposely place the Extent Control file to
tailor and to
send back to Dirmaint, followed by a Dirm Rldextn.
Wandschneider, Scott wrote:
Make sure you do *not* have an EXTENT CONTROL file on your A disk,
DIRMAINT will use that one first.
Thank you,
Scott R
Assuming the vol 530TDK has meaning.
The rest of the volume has been allocated as t-disk area.
Tom Duerbusch
THD Consulting
Law of Dinner Table Attendance
Cats must attend all meals when anything good is served.
Scott Rohling [EMAIL PROTECTED] 8/19/2008 10:18 AM
This isn't true..
Your EXTENT CONTROL entries came out garbled when I look at them.. I see
3390-01 in there - which is the size it seems to be using.
What do your DEFAULTS show for 3390-3 or 3390-03 or whichever you are using
in REGIONS?
It's sounding very much like it thinks these are 3390-01 -- so either it's
Could someone please send me their Z/VM 5.3 Extent Control file to peek at?
Thanks.
Scott Rohling wrote:
Your EXTENT CONTROL entries came out garbled when I look at them.. I
see 3390-01 in there - which is the size it seems to be using.
What do your DEFAULTS show for 3390-3 or 3390-03 or
sent our extent control and defaults datadvh to ya..
Scott Rohling
On Tue, Aug 19, 2008 at 9:31 AM, Mary Zervos [EMAIL PROTECTED] wrote:
Could someone please send me their Z/VM 5.3 Extent Control file to peek at?
Thanks.
Scott Rohling wrote:
Your EXTENT CONTROL entries came out garbled
Thanks Scott. I'm heading out the door for the day and I'll talk to you
tomorrow.
Mary
Scott Rohling wrote:
sent our extent control and defaults datadvh to ya..
Scott Rohling
On Tue, Aug 19, 2008 at 9:31 AM, Mary Zervos [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Could someone
Dirmaint doesn't look at all at the real disk, so how you have
allocated it does not influence where Dirmaint will place minidisks.
One exception: for CPOWEND volumes, DIRMAINT finds out where PAGE,
SPOOL (and DRCT TDISK?) is and flags those cylinders as in use. I
guess DIRMAINT uses some form
A while ago there was a thread here about the ability to DDR DASD to remote
location. Well there is an answer! I modified DDR so it can communicate
with CMS PIPES (DDR can now be a pipe stage). The modules can be
downloaded from here:
http://www.vm.ibm.com/download/packages/descript.cgi?DRPC
I remember years ago a similar problem where my extent control didn't adhere
to columns restriction in the REGIONS section. I never found a word on this
in the doc but the support told me add 'spaces' between each column. That
resolved my problem.
Alain Benveniste
Le 19/08/08 18:01, « Mary
Waw, that sounds great.
2008/8/19 Jiri Stehlik [EMAIL PROTECTED]:
A while ago there was a thread here about the ability to DDR DASD to remote
location. Well there is an answer! I modified DDR so it can communicate
with CMS PIPES (DDR can now be a pipe stage). The modules can be
downloaded
A while ago there was a thread here about the ability to DDR DASD to
remote
location. Well there is an answer! I modified DDR so it can
communicate
with CMS PIPES (DDR can now be a pipe stage). The modules can be
downloaded from here:
Fantastic! That was me asking about that, I ended up using PIPE
TRACKREAD, creating an intermediate file, and VMFTP'ing that (but it's
VERY time consuming). I'll take a look at your mods ASAP and give you
feedback (do you want it here or privately, if the latter is your email
in the package?).
Hi Dave,
Have you talked to the product owner? There is an open requirement
against DDR that you could be a hero by helping them close it.
Yep, George has been working on this project with that exact requirement
in mind. Considering the recent discussions here on this very topic, we
Yep, George has been working on this project with that exact
requirement in mind.
Fantastic. That's exactly what I wanted to hear.
Q: does this version also include the CMSDDR mods?
No, this is an otherwise unmodified DDR module.
Yeah, about 3 seconds after hitting send I realized that
On Tuesday, 08/19/2008 at 01:49 EDT, David Boyes [EMAIL PROTECTED]
wrote:
Have you talked to the product owner? There is an open requirement
against DDR that you could be a hero by helping them close it.
LOL. George left one small thing off of his signature:
z/VM I/O Development
IBM
Details details details.!
Thanks
Alan Altmark wrote:
On Tuesday, 08/19/2008 at 01:49 EDT, David Boyes [EMAIL PROTECTED]
wrote:
Have you talked to the product owner? There is an open requirement
against DDR that you could be a hero by helping them close it.
LOL.
On Tue, 19 Aug 2008 13:21:40 -0400 Jiri Stehlik said:
http://www.vm.ibm.com/download/packages/descript.cgi?DRPC
The FTPPUT and FTPGET PIPE stages were also included and documented at the
above address.
I have the latest CMS PIPLINES but it doesn't include FTPGET and
FTPPUT. I can't find them on
On Aug 19, 2008, at 1:39 PM, Fran Hensler wrote:
On Tue, 19 Aug 2008 13:21:40 -0400 Jiri Stehlik said:
http://www.vm.ibm.com/download/packages/descript.cgi?DRPC
The FTPPUT and FTPGET PIPE stages were also included and documented
at the
above address.
I have the latest CMS PIPLINES but it
LOL. George left one small thing off of his signature:
z/VM I/O Development
IBM Endicott
Alan Altmark
z/VM Development
IBM Endicott
Well, far be it from me that I suggest that VM Development begin to talk
to themselves. You lot 're odd enough to begin with...8-)
-- db
Hello,
I compiled the FTPPUT and FTPGET pipe stages into the DRPC Module. So once
you execute it, three pipe-stages (FTPPUT, FTPGET and DDR) will get
registered.
-George
(on Alan's insistance):
z/VM I/O Development
IBM Endicott
The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU wrote on
On Aug 19, 2008, at 1:48 PM, David Boyes wrote:
Well, far be it from me that I suggest that VM Development begin to
talk
to themselves. You lot 're odd enough to begin with...8-)
As Zork so eloquently put it, Talking to yourself is said to be a
sign of impending mental collapse.
Adam
As Zork so eloquently put it, Talking to yourself is said
to be a sign of impending mental collapse.
You see, I was never worried about it when I talked to myself.
I only started to wonder when I started ANSWERING myself. That's
when even the wife and kids leave the room and stay out of my
On Aug 19, 2008, at 1:39 PM, Fran Hensler wrote:
I have the latest CMS PIPLINES but it doesn't include FTPGET and
FTPPUT. I can't find them on the IBM Download site either.
Where can I get them?
On Tue, 19 Aug 2008 13:48:20 -0500 Adam Thornton said:
Run INSTPIPE MODULE from MAINT 2CC.
I'm
As Zork so eloquently put it, Talking to yourself is said to be a sign
of impending mental collapse.
I prefer to think of this as discussing the problem with the person who
understands it the best. That's my story and I'm sticking with it.
Nora Graves
On Aug 19, 2008, at 2:29 PM, Fran Hensler wrote:
On Aug 19, 2008, at 1:39 PM, Fran Hensler wrote:
I have the latest CMS PIPLINES but it doesn't include FTPGET and
FTPPUT. I can't find them on the IBM Download site either.
Where can I get them?
On Tue, 19 Aug 2008 13:48:20 -0500 Adam
Now if we could get the TERSE/DETERSE stages added, we might get these du
mps
down to a better size for transferring cross-country.
/Tom Kern
/301-903-2211
On Tue, 19 Aug 2008 14:49:38 -0400, Jiri Stehlik [EMAIL PROTECTED] wro
te:
Hello,
I compiled the FTPPUT and FTPGET pipe stages into the
Use VMARC. It will get them down and the support folks know how to
handle them in that format.
Regards,
Richard Schuh
-Original Message-
From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Thomas Kern
Sent: Tuesday, August 19, 2008 1:20 PM
To:
Does VMARC work as a pipe stage? Writing 3390-m9s as cms files and then
reading then, compressing them and writing them as cms files is too much
I/O
for the process. A pipe stage to properly compress the piped input is
necessary for efficiency. The PACK stage can be used but it doesn't buy y
ou
No. it doesn't. Keep plugging for a way.
Regards,
Richard Schuh
-Original Message-
From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Thomas Kern
Sent: Tuesday, August 19, 2008 1:38 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: DDR'ing 3390 DASD To
I have a service machine the runs with MSG set to IUCV. If I enter the
command SET SECUSER svcid *, messages are displayed on my console
rather than being sent to the IUCV handler. The messages do not get
displayed on the console if I log on to the id; why should they be
reflected to the SECUSER
I am new to z/VM and am sure to have a lot of questions.
My first is about documentation. I did not receive a copy of the z/VM
Guide for Automated Installation and Service with my 5.3 SDO. Should I
have gotten this? It sure appears from the program directories for the
SDO and for z/VM
On Tuesday, 08/19/2008 at 05:22 EDT, Schuh, Richard [EMAIL PROTECTED]
wrote:
I have a service machine the runs with MSG set to IUCV. If I enter the
command
SET SECUSER svcid *, messages are displayed on my console rather than
being
sent to the IUCV handler. The messages do not get
Richard, It is working as it has for a long time.. The *MSG system
Service description in the Programming Services manual describes just what
you are seeing. See Chapter 17 of CP Programming Services
If a virtual machine has both a valid path to *MSG and a functioning
secondary user,
Has anyone ever submitted a requirement that this function (needed to
share SFS across IP) be added to the product and formally supported?
Marcy
This message may contain confidential and/or privileged information. If
you are not the addressee or authorized to receive this for the
addressee,
On Tuesday, 08/19/2008 at 06:04 EDT, Marcy Cortes
[EMAIL PROTECTED] wrote:
Has anyone ever submitted a requirement that this function (needed to
share SFS across IP) be added to the product and formally supported?
There is an open requirement for this function.
Alan Altmark
z/VM Development
Cool. Was it accepted?
Marcy
This message may contain confidential and/or privileged information. If
you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based on
this message or any information herein. If you have
Hi, Susan.
I don't know if the documents you mention should have been shipped or not, but in any
case, IBM makes all of the VM doc available online, in both PDF and Book format.
For all of the general z/VM publications, go here:
Hi Susan. Welcome. Yes you should have received the documentation.
Look for the z/VM SDO program directory which describes the install in more
detail. Don't forget to request the buckets as documented.
http://www.vm.ibm.com/sdo/sdozvm53.html
Hans
-Original Message-
From: The IBM
Thanks George. Works really well. Ran backup of VMSRES (mod3) in 8 minutes
using LZ and pack (600MB) to my desktop and the restore of a mdisk from the
backup worked just fine.
Thanks very much.
Hans
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Thanks Alan. I have found a way to use SMSG, so I have circumvented a
design feature.
So it is documented. That does not alter the fact that the treatment of
the MSG traffic seems to be somewhat inconsistent. If the id has a logon
console, the messages are sent to the *MSG trap, regardless of
On Tuesday, 08/19/2008 at 07:25 EDT, Schuh, Richard [EMAIL PROTECTED]
wrote:
Is there some good reason why it works like this? It would be more
consistent if the things that are set to be trapped by IUCV or SMSG were
treated the same in all cases. After all, if it is OK for the machine to
On Tue, Aug 19, 2008 at 11:58 PM, Alan Altmark [EMAIL PROTECTED] wrote:
Ah, one of the Great Schisms. See the 3rd from the last paragraph in the
description of *MSG in the CP Programming Services book:
What troubles me is that the folks in IBM who push the new automated
operator product seem
On Tuesday, 08/19/2008 at 06:12 EDT, Marcy Cortes
[EMAIL PROTECTED] wrote:
Cool. Was it accepted?
I see three requirements out there. One (general case of APPC-over-IP) is
a Suggestion and the other two (Performance Toolkit) are Recognized.
Alan Altmark
z/VM Development
IBM Endicott
The SET OBSERVER command is working the right way, i.e. it won't take
MSGs away from the *MSG IUCV handler. I tested this the first day I
had a VM system with SET OBSERVER. I use it since then to debug SVMs
that connect to *MSG(ALL).
Can one use SET OBSERVER then without *any* side effect?
On Wednesday, 08/20/2008 at 12:50 EDT, Rob van der Heij
[EMAIL PROTECTED] wrote:
On Tue, Aug 19, 2008 at 11:58 PM, Alan Altmark [EMAIL PROTECTED]
wrote:
Ah, one of the Great Schisms. See the 3rd from the last paragraph in
the
description of *MSG in the CP Programming Services book:
Susan,
I deliver the z/VM Installation - From Cardboard Box to IPL session at
SHARE, and point out the difference between the 2-sided tri-fold Summary
and the much more detailed Guide (the full manual). The session also
includes the URLs for the these any other IBM z/VM installation
54 matches
Mail list logo
