I certainly am. It is time to ask the big question, WHY ME, GOD?
The files are anything from jobs being submitted to files being sent via
SENDFILE. There are no error messages, neither before nor after, on
either side of the link. As for recreation, all I have to do is to stop
the link and then
I certainly am. It is time to ask the big question, WHY ME, GOD?
The files are anything from jobs being submitted to files being sent via
SENDFILE. There are no error messages, neither before nor after, on
either side of the link. As for recreation, all I have to do is to stop
the link and then
BTW, I have just opened an incident. We reproduce the problem by
starting the link. I cannot start the trace before the link is up;
hence, no trace.
Since I cannot get a FLUSH to work without stopping the link, I no of no
way to start the trace before a file is hung on the link.
Regards,
BTW, I have just opened an incident. We reproduce the problem by
starting the link. I cannot start the trace before the link is up;
hence, no trace.
Since I cannot get a FLUSH to work without stopping the link, I no of no
way to start the trace before a file is hung on the link.
You can specify
Could you: CP TRANSFER RSCS sfid other_ID RDR
(preferably other_ID = the origin ID)
Then start the link, RSCS REORDER, then start the trace and TRANSFER the
reader file back to RSCS's RDR?
Mike Walter
Hewitt Associates
Any opinions expressed herein are mine alone and do not necessarily
No, it appears to fail on any file. We have gone through at least a
dozen different files.
Regards,
Richard Schuh
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Mike Walter
Sent: Tuesday, August 07, 2007 10:15 AM
To:
There are being forced R/O because Maint already has them linked R/W.
Logoff maint and try again.
On 8/7/07, KEETON Dave * OR SDC [EMAIL PROTECTED] wrote:
HCPLNM103E DASD 019D forced R/O; R/W by MAINT, R/O by18 users
--
Mark Pace
Mainline Information Systems
True enough. Thank you.
How come the other disks are coming up R/O? They are assigned to DFSMS,
so shouldn't they be attached R/W?
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Mark Pace
Sent: Tuesday, August 07, 2007 10:38 AM
Hi Dave,
Is it possible that 01A6, 01A4, 01A2 and 01B5 are links to other
minidisks owned by DFSMS?
Peter
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of KEETON Dave * OR SDC
Sent: August 7, 2007 13:27
To: IBMVM@LISTSERV.UARK.EDU
DFSMS needs to be logged off in order for you to have WRITE access to
those minidisks. Multiple WRITE accesses are VERY dangerous in CMS! :)
David Wakser
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of [EMAIL PROTECTED]
Sent: Tuesday,
On 8/7/07, KEETON Dave * OR SDC [EMAIL PROTECTED] wrote:
How come the other disks are coming up R/O? They are assigned to DFSMS,
so shouldn't they be attached R/W?
I don't quite understand
HCPLNM102E DASD 01A6 forced R/O; R/W by DFSMS
If you are logging on to DFSMS. What does the directory
Dave,
Issue
CP QUERY VIRTUAL DASD
on the DFSMS machine to see what MiniDisks the machine is currently
linked to. As someone indicated, it seems you have the same MiniDisk
already linked at another virtual address, and that link is already a
R/W link.
JR (Steven) Imler
CA
Senior
Q DASD shows:
DASD 01A6 3390 DFSMD0 R/O 2 CYL ON DASD 982B SUBCHANNEL = 000D
But the directory entry is:
MDISK 1A6 3390 0117 0002 DFSMD0 MR
That's what I don't understand. Seems to me that the MR mode should
attach it as read-write.
Hi Dave,
Could you post the complete directory entry for DFSMS, please.
Peter
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of KEETON Dave * OR SDC
Sent: August 7, 2007 14:23
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: DFSMS/VM
Q
When CP links a minidisk to a user, either via a LINK statement or command
or a MDISK statement, it is given 2 alternative link methods on the
command. In your case, you have asked for a MR link. CP will attempt to
make a M link first which on its own says gimme a R/W link regardless if
anyone has
To know who/what prohibits a R/W link, link in RR and then issue Q LINKS.
Like this:
CP LINK DFSMS 1A6 111 RR
CP Q LINKS 111
--
Kris Buelens,
IBM Belgium, VM customer support
2007/8/7, Judson West [EMAIL PROTECTED]:
When CP links a minidisk to a user, either via a LINK statement or
On: Tue, Aug 07, 2007 at 11:23:14AM -0700,KEETON Dave * OR SDC Wrote:
} Q DASD shows:
}
} DASD 01A6 3390 DFSMD0 R/O 2 CYL ON DASD 982B SUBCHANNEL = 000D
}
} But the directory entry is:
}
} MDISK 1A6 3390 0117 0002 DFSMD0 MR
}
} That's what I don't understand. Seems to me that the MR
Thanks for all the help, folks. I seem to have missed a critical step
and made a couple of errors in the directory entry. I had overlaps in
the MDISK statements that appeared when I ran DISKMAP. I've corrected
those and now the errors about R/O links are gone.
Thanks for the tutorial, Rich. I'm
Following up on one of my earlier questions, does anyone know what this
is supposed to mean (from the PLANINFO file generated by VMFINS):
TARGID: VMSYS:DFSMS.CONTROL
SIZE: 300
BLKSIZE:4K
All of the other information from the PLANINFO file made sense to me,
but this one has me
That's an indication of the space required for DFSMS's CONTROL file if you
install in into SFS (the other choice is minidisks, which you appear to be
using from prior posts).
In short, that says that the DFSMS CONTROL file would need 300 4k disk
blocks of SFS space, and would be placed in the
It means that a file area in the SFS (shared file system) needs 300 4k
blocks defined. (SFS defaults to 4k blocksize)
It should be defined in the VMSYS SFS, directory DFSMS, subdirectory
CONTROL.
You have to do this. DFSMS expects this file area to be defined. It is used
for
storing some
The most frustrating part of all of this is determining exactly what I
need to get access to the 3495. Stephen Gentry said that SFS is a
requirement, so okay; I'll go down that road next. In previous posts
I've asked folks about using DDR and some have offered to send me REXX
scripts that can
You don't need DirMaint or ISPF for the RMS component of DFSMS. You do
need to put the control files in SFS, unless you're willing to modify
the code to use a minidisk. Some of the code is in REXX, but some
isn't, so I don't know if it's even possible to change it to use a
minidisk.
You don't need DirMaint or ISPF for the RMS component of DFSMS. You do
need to put the control files in SFS, unless you're willing to modify
the code to use a minidisk. Some of the code is in REXX, but some
isn't, so I don't know if it's even possible to change it to use a
minidisk.
RMS
soapbox=on
It's time to remove that requirement IBM.
Let it be on a minidisk by default (or if too hard, make minidisk the
only option).
I've answered a whole lot of questions in the past 18 months from my new
to VM'ers here. It's not obvious to them for sure.
You have 3 service machines each
Hello Dave, welcome to VM!
Overlaps... You mentioned in a previous email.
That's what DIRMAINT will solve for you (an if there's more than 1 of
you at your shop doing directory thingies... Dirmaint will solve that
sharing problem).
SOX/Audit? Eventually, those will probably get you too
I won't get on a soapbox ... but I do agree with Marcy!
Even the old VMers end up frustrated about the fact to run a 3494 on
VM *REQUIRES* SFS (not that I think SFS is a bad thing ... my life
depends on it every day!).
However, it is particularly tough for these new (z/Linux) installations
to
JR wrote: I won't get on a soapbox ... but I do agree with Marcy!
I'll mover over and make space. Or we can get together and make a bigger
one. I'm sure there's a couple of others that I know that want to hop on
too. Hmmm Maybe I'll write SHARE requirement next week.
Marcy Cortes
This
28 matches
Mail list logo
