Re: ECKD vs FBA problem on MF Linux Lpar

2006-08-08 Thread Ingo Adlung
EDEV: Oh, I missed that "minor detail" ... . I think to recall that EMC at some point in time really allowed to configure their systems to present SCSI disks as channel attached FBA as you asked for. Therefore I was misled. Don't know whether this feature still exists, though. Perhaps Mike can shed

Re: ECKD vs FBA problem on MF Linux Lpar

2006-08-08 Thread Richard Troth
Ah! I see what you meant. Yes, he was using EDEV. Neat stuff, EDEV. VM talks to the SAN and presents FBA to the guest. Wouldn't it be ... "elegant" ... if the storage vendors presented FBA to the System z host? -- R, Ingo Adlung <[EMAIL PROTECTED]> Sent by: Linux on 390 Port 08/08/

Re: HLASM for zLinux

2006-08-08 Thread Alan Altmark
On Tuesday, I wrote: > Yes, it [HLASM for Linux] can be licensed to standard > engines without a special bid. I am receiving information from other sources to the contrary (hey, learned somethin' new!). So talk to your IBM rep or business partner if you want HLASM for Linux on standard engines.

Re: ECKD vs FBA problem on MF Linux Lpar

2006-08-08 Thread Ingo Adlung
> Wow ... such an interesting suggestion. You mean, Ingo, that EMC might > speak FBA on the IBM "channel"? Hi Rick, when you sneak through Mike's initial mail (snippet) > lsdasd > 0.0.0100(ECKD) at ( 94: 0) is dasda : active at blocksize 4096, > 546840 blocks, 2136 MB > 0.0.0101(FBA ) at ( 94:

Re: ECKD vs FBA problem on MF Linux Lpar

2006-08-08 Thread Alan Altmark
On Tuesday, 08/08/2006 at 01:29 AST, Richard Troth <[EMAIL PROTECTED]> wrote: > It would be a great boon to all of us (VM, VSE, Linux) if EMC and STK > and IBM would give us an FBA handle on SAN volumes. Think about it! SAN > on one side, which can talk to z/VM and to zLinux, but also to Solar

Re: NMAP

2006-08-08 Thread David Boyes
> The actual fix is to add the parameter "fake_ll=1" to the appropriate > place so that when the qeth module loads it creates a fake link level > header. This is only necessary when going straight to the OSA adapter, and > only when using protocol analyzers (nmap, tcpdump) or daemons (DHCP) that >

Re: HLASM for zLinux

2006-08-08 Thread Alan Altmark
On Tuesday, 08/08/2006 at 10:03 MST, Dave Czajkowski/Phoenix/[EMAIL PROTECTED] wrote: > Can HLASM for Linux (5799-TCQ) be licensed on a general purpose engine > without going thru a special bid process? Most hits I see only talk about > IFLs. Yes, it can be licensed to standard engines without a

Re: NMAP

2006-08-08 Thread Paul Giordano
The actual fix is to add the parameter "fake_ll=1" to the appropriate place so that when the qeth module loads it creates a fake link level header. This is only necessary when going straight to the OSA adapter, and only when using protocol analyzers (nmap, tcpdump) or daemons (DHCP) that expect the

Re: ECKD vs FBA problem on MF Linux Lpar

2006-08-08 Thread Richard Troth
Wow ... such an interesting suggestion. You mean, Ingo, that EMC might speak FBA on the IBM "channel"? I have tried, and tried, and tried to get the storage vendors and/or in-house storage management teams to present FBA (eg: 9336) on the channel. I get the "deer in the headlights" response

Re: ECKD vs FBA problem on MF Linux Lpar

2006-08-08 Thread Richard Troth
I tried the same syntax as you did at first, having used it in the 2.4 days. But the world has changed. Lately, this is how it works for me: (cut-n-pasted so this may be rough) insmod /lib/modules/`uname -r`/kernel/drivers/s390/scsi/zfcp.ko echo 1 > /sys/bus/ccw/drivers/zfcp/0.0.fcfc/online e

Re: HLASM for zLinux

2006-08-08 Thread Thomas David Rivers
Hi Mark, We could have provided Systems/ASM (which the TPF labs has tested) for your z/TPF developers - probably with some serious savings. See http://www.dignus.com/dasm/ - Dave Rivers - > > >From what I can tell, yes. We just licensed it that way for our z/TPF > developers. > > > M

Re: HLASM for zLinux

2006-08-08 Thread Post, Mark K
>From what I can tell, yes. We just licensed it that way for our z/TPF developers. Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Dave Czajkowski Sent: Tuesday, August 08, 2006 1:04 PM To: LINUX-390@VM.MARIST.EDU Subject: HLASM for zLinux C

HLASM for zLinux

2006-08-08 Thread Dave Czajkowski
Can HLASM for Linux (5799-TCQ) be licensed on a general purpose engine without going thru a special bid process? Most hits I see only talk about IFLs. -- For LINUX-390 subscribe / signoff / archive access instructions, send emai

Re: ECKD vs FBA problem on MF Linux Lpar

2006-08-08 Thread Ingo Adlung
I'm confused. I think to recall that with EMC storage subsystems you could surface SCSI disks as FBA disks, hence the fba discipline of the dasd device driver would detect it and take care of it ... is this the use case described initially? In this case zfcp would be completely out of the picture

Re: ECKD vs FBA problem on MF Linux Lpar

2006-08-08 Thread Post, Mark K
That looks like you don't have the zfcp kernel module on your system. What does: find /lib/modules/`uname -r` -iname "*zfcp*" show you? Mark Post -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Michael Harvey Sent: Tuesday, August 08, 2006 12:30 PM To: L

Re: ECKD vs FBA problem on MF Linux Lpar

2006-08-08 Thread Michael Harvey
Another question on same issue, let me know if you can help. When I try to 'MAP' the FBA disk using the 'ZFCP' module this is what I get : LNOUC4D:~ # insmod zfcp map="0x0406 0x01:0x50060482ccb539c8 0x0:0x0107" insmod: can't read 'zfcp': No such file or directory LNOUC4D:~ # Can