I agree about numberless and undocumented messages. Except from my code, of
course.
How about determining what disks/filespaces are accessed my your server, then
running a Pipe to read in every accessed ececutable file (MODULE, LOADLIB,
EXEC, and XEDIT to start), run a LOCATE stage for that
We have a SVM that periodically complains that "File CSLCALL TRACE not found" -
note the lack of a message number, the quote is complete and exact. Would I be
correct is concluding that this is a quirk/problem with the 3rd-party s/w
running in that machine? I can find no file named CSLCALL banan
On May 15, 2009, at 4:09 PM, Miguel Delapaz wrote:
> OK, so, look, surely I'm not the first person to want to do this.
With the ETHERNET option on the QDIOETHERNET LINK statement (in case
you missed my other note)
Yay! Thank you! (Your other note hadn't arrived quite yet.)
I now have
> OK, so, look, surely I'm not the first person to want to do this.
With the ETHERNET option on the QDIOETHERNET LINK statement (in case you
missed my other note)
Regards,
Miguel Delapaz
z/VM Development
On May 15, 2009, at 3:36 PM, David Kreuter wrote:
Why are you picking on poor ole DIRMAINT? It's CP that doesn't support
it in the NICDEF statement! not DIRMAINT -
OK, so, look, surely I'm not the first person to want to do this.
How do I couple a virtual machine's virtual NIC to a Layer 2 Gu
*Sigh*...yeah it's Friday...you tell the TCP/IP stack that this is a Layer
2 device by specifying the ETHERNET option on the LINK statement in PROFILE
TCPIP
Regards,
Miguel Delapaz
z/VM Development
The IBM z/VM Operating System wrote on 05/15/2009
01:33:27 PM:
>
> Adam,
> You don’t specify lay
Perhaps because historically it has been such an easy target? :-)
Regards,
Richard Schuh
> Why are you picking on poor ole DIRMAINT? It's CP that
> doesn't support it in the NICDEF statement! not DIRMAINT -
Why are you picking on poor ole DIRMAINT? It's CP that doesn't support
it in the NICDEF statement! not DIRMAINT -
from the zvm540 planning and admin guide:
NICDEF__vdev _TYPE__ _HIPERsockets_
_|_>< |
| | |_QDIO_| | |
| |_DEVices__devs_
On May 15, 2009, at 3:24 PM, Miguel Delapaz wrote:
> I defined it to TCPIP with DIRM NICDEF and I don't see any way
> to specify whether I mean Layer 2 or Layer 3. I just defined it
as QDIO.
>
> I think my cough syrup is failing me. How do I tell DIRMAINT, "no,
> really, QDIO *ETHERNET
On May 15, 2009, at 3:22 PM, O'Brien, Dennis L wrote:
Adam,
You don’t specify layer 2 or 3 on the NICDEF. You specify it on
your DEFINE LAN or DEFINE VSWITCH statement.
Yeah, but I DID that:
Here's the L3 LAN:
LAN SYSTEM GLAN1Type: QDIOConnected: 1Maxconn: INFINITE
PERSI
Adam,
You don't specify layer 2 or 3 on the NICDEF. You specify it on your
DEFINE LAN or DEFINE VSWITCH statement.
Dennis O'Brien
"If I'd only followed CNBC's advice, I'd have $1 million today, provided
I'd started with $100 million." -
> I defined it to TCPIP with DIRM NICDEF and I don't see any way
> to specify whether I mean Layer 2 or Layer 3. I just defined it as QDIO.
>
> I think my cough syrup is failing me. How do I tell DIRMAINT, "no,
> really, QDIO *ETHERNET*" ?
Huh...that appears to be an "interesting" oversight
On May 15, 2009, at 2:29 PM, Miguel Delapaz wrote:
Adam,
> Transport Type: IP
This says your NIC is defined as Layer 3.
> 14:55:58 DTCOSD355E OSD device ETH1: Possible LAN transport
misconfiguration detected during OSD device initialization.
This says you tried to attach a Layer 3 NIC to
Adam,
> Transport Type: IP
This says your NIC is defined as Layer 3.
> 14:55:58 DTCOSD355E OSD device ETH1: Possible LAN transport
misconfiguration detected during OSD device initialization.
This says you tried to attach a Layer 3 NIC to a Layer 2 LAN (or
vice-versa)
Regards,
Miguel Delapaz
z/
On May 15, 2009, at 2:14 PM, Miguel Delapaz wrote:
Adam,
What does NETSTAT DEV say?
Well, *IT* says that my interface there is not working, and TCPIP
startup bears this out:
Device ETH1Type: OSDStatus: Inactive
Queue size: 0 CPU: 0 Address: 7008
Adam,
What does NETSTAT DEV say?
Regards,
Miguel Delapaz
z/VM Development
>
> NETSTAT HOME shows the right information (ETH1 is the L2 LAN; ETH0 a
> Layer 3 QDIO LAN, HSI0 is L3 Hypersockets, and CTC0 is a point-to-
> point CTC TCPIP link):
>
> netstat home
> VM TCP/IP Netstat Level 540 TC
I was under the impression that z/VM 5.4 allowed you to define a Layer
2 guest LAN and then give z/VM an interface on that guest LAN. Am I
confused? I know that earlier z/VM versions did not support a Layer 2
Guest LAN interface for z/VM, but I thought the restriction had been
lifted in 5
(In the following comments, I use the term thin client in lose terms, it
can either be a true thin client or a pc that boots from the network,
PXE, TFTP and all that stuff).
I'm a little confused by this virtualized desktop thread. To me, it
sounds like LTSP or the pregen'd system K12LTSP. I've
On Fri, May 15, 2009 at 4:00 PM, Jim Bohnsack wrote:
> If you're as PIPE illiterate as I am and you don't need to get fancy, IBM's
> DDR program with the TYPE option may suit your needs. If you need quite a
> bit of output and/or formatted in a better manner, follow Kris's advice and
> dig out t
If you're as PIPE illiterate as I am and you don't need to get fancy,
IBM's DDR program with the TYPE option may suit your needs. If you need
quite a bit of output and/or formatted in a better manner, follow Kris's
advice and dig out the PIPE manuals.
Jim
Kris Buelens wrote:
PIPE's TRACKREA
PIPE's TRACKREAD and friends should allow you to store these remains
in a CMS file.
2009/5/15 João Carlos dos Reis Baptista :
> Dear VMers
>
>
>
> I have got a piece of file to recover. The remaining of a file, a few
> cylinders of 3390 volume, are in 4k records I have been trying to read thru
>
Maybe my DRMGUI then? It is using CMS/GUI, and allows you to move
minidisks around, using DIRMAINT or DFSMS. Bugs in CMS/GUI make that
it doesn't 100% work the way I'd like best.
2009/5/14 Karl Kingston
>
> Yup.. I'm aware of them.
>
> Just looking for something different.
>
>
> The IBM z/VM Op
22 matches
Mail list logo
