Anybody know if VSWITCHes support 'spanning tree' , or need to do it ?
We have that question from our network people, because we will need
to connect to a separate physical LAN for one customer, and we want the
migration
as seamless as possible.
So we will have duplicates of connections, of which both are redundant as well.
This will obviously expose us for the risk of network routing loops, and this is
prohibited with 'spanning tree' functionality, normally supported by switches
or routers.
Any know if a z/VM vswitch support this or if it is perhaps not needed ?
Anyone having experinces of this ?
We run z/VM 6.1 and SLES11.1 and RHEL6
BR /Tore
Tore Agblad
System programmer, Volvo IT certified IT Architect
Volvo Information Technology
Infrastructure Mainframe Design Development, Linux servers
Dept 4253 DA1S
SE-405 08, Gothenburg Sweden
Telephone: +46-31-3233569
E-mail: tore.agb...@volvo.com
http://www.volvo.com/volvoit/global/en-gb/
-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Alan
Altmark
Sent: den 10 maj 2012 16:03
To: LINUX-390@VM.MARIST.EDU
Subject: Re: SLES 11 SP1 msg: kernel: scsi: host 0 channel 0 id 0 lun2 has a
LUN larger than allowed by the host adapter
On Wednesday, 05/09/2012 at 09:39 EDT, Raymond
Higgs/Poughkeepsie/IBM@IBMUS wrote:
11:12:11 scsi: host 0 channel 0 id 0 lun2 has a LUN larger than
allowed by the host adapter
There shouldn't be any limitations until 2 TB. I don't think linux is
complaining about the size of the lun. I think linux is complaining
about
the lun number. It is saying that it will only configure luns 0x
and
0x0001.
Nominally, that response means that the LUN number of one of the LUNs
returned on REPORT LUNS is larger than the value supported by the adapter,
which zfcp_scsi_adapter_register() sets to 0x. Those are
(supposed to be) unsigned ints, so the implication is, as you suggested,
that something changed this value via sysfs, assuming it is exported.
From drivers/scsi/scsi_scan.c:
1466 if (lun sdev-host-max_lun) {
1467printk(KERN_WARNING scsi: %s lun%d has a LUN
larger
1468than allowed by the host adapter\n,
1469 devname, lun);
Alan Altmark
Senior Managing z/VM and Linux Consultant
IBM System Lab Services and Training
ibm.com/systems/services/labservices
office: 607.429.3323
mobile; 607.321.7556
alan_altm...@us.ibm.com
IBM Endicott
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
LXFMT bug fix
http://download.sinenomine.net/lxfmt contains an updated LXFMT VMARC. A bug has been fixed that incorrectly decoded device addresses containing hex digits. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Anybody know if VSWITCHes support 'spanning tree' , or need to do it ?
On Tuesday, 05/15/2012 at 05:36 EDT, Agblad Tore tore.agb...@volvo.com wrote: We have that question from our network people, because we will need to connect to a separate physical LAN for one customer, and we want the migration as seamless as possible. So we will have duplicates of connections, of which both are redundant as well. This will obviously expose us for the risk of network routing loops, and this is prohibited with 'spanning tree' functionality, normally supported by switches or routers. Any know if a z/VM vswitch support this or if it is perhaps not needed ? The VSWITCH does not support Spanning Tree Protocol. I have yet to hear of anyone actually having a problem with broadcast storms on their zLinux guests. When a Linux guest broadcasts, that broadcast will go out on the wire, but will not be reflected back on the same port (IEEE standard). If it comes into another VSWITCH plugged into another port in the same VLAN, then it will be to a different interface on the Linux guest. Linux will not forward a broadcast or multicast packet, as other interfaces on the same subnet will have heard the bcast/mcast, and it is not permitted to forward them to other subnets. (Even subnet-directed broadcasts will not be forwarded.) When it comes to networking, Linux is pretty well-behaved. Alan Altmark Senior Managing z/VM and Linux Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Anybody know if VSWITCHes support 'spanning tree' , or need to do it ?
Any know if a z/VM vswitch support this or if it is perhaps not needed ? It does not (it'd be nice, but it doesn't). It's probably not necessary, but you can (at least with the Cisco hardware) configure the spanning tree parameters so that the real network hardware always has the lowest cost and bridge ID unless it is unavailable. You want the root bridge ID to be out in the real switches, always. Google for the book Cisco LAN Switching (Clark/Hamilton, ISBN 1-57870-094-9) online; chapters 6 and 7 cover in detail the reason why this matters and how to tune parameters so that the external switches always win the root bridge election. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: LXFMT bug fix
http://download.sinenomine.net/lxfmt contains an updated LXFMT VMARC. A bug has been fixed that incorrectly decoded device addresses containing hex digits. The files in the new LXFMT22 VMARC have dates in 1907, 1908, and 1912. Either we had some very forward-thinking programmers a hundred years ago, or there's an error. Is this a VMARC bug or a packaging error when the files were created? Dennis O'Brien No man`s life, liberty, or property are safe while the legislature is in session. -- Mark Twain -- This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. References to Sender are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
SLES11 - zfcp_disk_configure bug? (Could not deactivate SCSI disk)
Hi, I have small problem and tiny workaround for it. I am wondering if
anyone else had issues like this.
Sometimes (actually quite often), Yast complains when I try to deactivate a
scsi disk. (yast-hardware-zfcpdelete) with message Could not deactivate
SCSI disk).
Unfortunately it is being removed from from Yast LUNs list so at this point
there is not much I can do from Yast.
Yast would not allow me to recreate it because under the hood
(/sys/bus/ccw...) it wasn't completely removed.
I walked through Yast logs and than through /sbin/zfcp_disk_configure
script and I've narrowed the problem to those few lines of
/sbin/zfcp_disk_configure code :
(lines 134-219)
if [ -d $_zfcp_scsi_host_dir ] ; then
# Deregister the disk from SCSI layer
for target in $_zfcp_scsi_host_dir/rport-*/target*/* ; do
if [ -d $target ] ; then
_zfcp_tmp_targid=${target##*/}
read _zfcp_tmp_hba ${target}/hba_id
read _zfcp_tmp_wwpn ${target}/wwpn
read _zfcp_tmp_lun ${target}/fcp_lun
if [ 0x${FCP_LUN} = $_zfcp_tmp_lun -a 0x${FCP_WWPN} =
$_zfcp_tmp_wwpn ] ; then
* echo 1 $target/delete*
_zfcp_scsi_dir=$target
break;
fi
fi
done
/sbin/udevadm settle
else
debug_mesg No SCSI disk found for FCP disk ${FCP_WWPN}:${FCP_LUN}
fi
# Re-check whether the SCSI disk is gone
* if [ -d ${_zfcp_scsi_dir} ]; then*
debug_mesg Could not deactivate SCSI disk ${_zfcp_scsi_id}
exit 7
fi
I made some tests and played with this code and it looks that sometimes
after it does *echo1 $target/delete* there isn't enough time before it
checks if it was really removed.
At this point , *[ -d ${zfcp_scsi_dir*] is true, so it exits with 7
and debug mesg.
I made a small workaround by changing a little bit second part of that code
like here:
if [ -d ${_zfcp_scsi_dir} ]; then
sleep 1
if [ -d ${_zfcp_scsi_dir} ]; then
debug_mesg Could not deactivate SCSI disk ${_zfcp_scsi_id}
exit 7
fi
fi
So basically if it fails (if directory still exists), it should sleep for 1
second and than try again.
It looks like this solved my problem. Perhaps it will help to others.
z/VM Version 5 Release 4.0, Service Level 1102 (64-bit)
SUSE Linux Enterprise Server 11 (s390x)
VERSION = 11
PATCHLEVEL = 2
Linux d2ora000 3.0.13-0.27-default #1 SMP Wed Feb 15 13:33:49 UTC 2012
(d73692b) s390x s390x s390x GNU/Linux
Regards
Grzegorz Powiedziuk
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
Re: LXFMT bug fix
Not using the VMARC MODULE I am: LXFMTVMARCX1 F 80 111622 2012-05-15 09:45:58 LXFMTLOADMAP X5 V100 89 3 2012-05-15 09:44:25 LXFMTMODULE X1 V 18712 4 5 2012-05-15 09:44:25 LXFSETEXT X1 F 80121 3 2012-05-15 09:44:23 LXMSGTEXT X1 F 80 61 2 2012-05-15 09:44:20 LXFMTTEXT X1 F 80239 5 2012-05-15 09:44:19 LXASMEXEC X1 V 65 22 1 2012-05-15 09:42:45 LXFMTASSEMBLE X1 F 80 345668 2012-05-15 09:42:28 LXFSEASSEMBLE X1 F 8091718 2010-08-24 12:53:52 LXMSGASSEMBLE X1 F 80 78 2 2010-08-24 12:04:32 LXFMTREADME X1 F 80 46 1 2008-01-02 06:37:33 LXFMTHELPCMS X2 V 79148 2 2008-01-02 06:36:02 LXVMARC EXEC X1 V 54 16 1 2007-12-10 12:35:28 LXFMT1 LXCONFIG X1 F 80 3 1 2007-12-10 10:35:02 LNXVMCNTRLX2 F 80 5 1 2007-12-02 16:49:14 On 5/15/12 1:17 PM, O'Brien, Dennis L dennis.l.o'br...@bankofamerica.com wrote: The files in the new LXFMT22 VMARC have dates in 1907, 1908, and 1912. Either we had some very forward-thinking programmers a hundred years ago, or there's an error. Is this a VMARC bug or a packaging error when the files were created? -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: SLES11 - zfcp_disk_configure bug? (Could not deactivate SCSI disk)
Grzegorz,
I have been working with Novell to fix these problems. Novell has resolved
the problems and is putting the final touches on a PTF s390-tools package
that contains a /sbin/zfcp_disk_configure script without these problems.
You can probably get an advance copy, before the maintenance release,
through your support process.
Mike O'Reilly
IBM Linux Change Team
Grzegorz
Powiedziuk
gpowiedziuk@gmai To
l.comLINUX-390@vm.marist.edu,
Sent by: Linux on cc
390 Port
linux-...@vm.mar Subject
ist.edu SLES11 - zfcp_disk_configure bug?
(Could not deactivate SCSI disk)
05/15/2012 10:32
AM
Please respond to
Linux on 390 Port
linux-...@vm.mar
ist.edu
Hi, I have small problem and tiny workaround for it. I am wondering if
anyone else had issues like this.
Sometimes (actually quite often), Yast complains when I try to deactivate a
scsi disk. (yast-hardware-zfcpdelete) with message Could not deactivate
SCSI disk).
Unfortunately it is being removed from from Yast LUNs list so at this point
there is not much I can do from Yast.
Yast would not allow me to recreate it because under the hood
(/sys/bus/ccw...) it wasn't completely removed.
I walked through Yast logs and than through /sbin/zfcp_disk_configure
script and I've narrowed the problem to those few lines of
/sbin/zfcp_disk_configure code :
(lines 134-219)
if [ -d $_zfcp_scsi_host_dir ] ; then
# Deregister the disk from SCSI layer
for target in $_zfcp_scsi_host_dir/rport-*/target*/* ; do
if [ -d $target ] ; then
_zfcp_tmp_targid=${target##*/}
read _zfcp_tmp_hba ${target}/hba_id
read _zfcp_tmp_wwpn ${target}/wwpn
read _zfcp_tmp_lun ${target}/fcp_lun
if [ 0x${FCP_LUN} = $_zfcp_tmp_lun -a 0x${FCP_WWPN} =
$_zfcp_tmp_wwpn ] ; then
* echo 1 $target/delete*
_zfcp_scsi_dir=$target
break;
fi
fi
done
/sbin/udevadm settle
else
debug_mesg No SCSI disk found for FCP disk ${FCP_WWPN}:${FCP_LUN}
fi
# Re-check whether the SCSI disk is gone
* if [ -d ${_zfcp_scsi_dir} ]; then*
debug_mesg Could not deactivate SCSI disk ${_zfcp_scsi_id}
exit 7
fi
I made some tests and played with this code and it looks that sometimes
after it does *echo1 $target/delete* there isn't enough time before it
checks if it was really removed.
At this point , *[ -d ${zfcp_scsi_dir*] is true, so it exits with 7
and debug mesg.
I made a small workaround by changing a little bit second part of that code
like here:
if [ -d ${_zfcp_scsi_dir} ]; then
sleep 1
if [ -d ${_zfcp_scsi_dir} ]; then
debug_mesg Could not deactivate SCSI disk $
{_zfcp_scsi_id}
exit 7
fi
fi
So basically if it fails (if directory still exists), it should sleep for 1
second and than try again.
It looks like this solved my problem. Perhaps it will help to others.
z/VM Version 5 Release 4.0, Service Level 1102 (64-bit)
SUSE Linux Enterprise Server 11 (s390x)
VERSION = 11
PATCHLEVEL = 2
Linux d2ora000 3.0.13-0.27-default #1 SMP Wed Feb 15 13:33:49 UTC 2012
(d73692b) s390x s390x s390x GNU/Linux
Re: LXFMT bug fix
Interesting. I downloaded the latest VMARC MODULE from IBM, which is a slightly different size than my previous version from 2001, and also tried setting my date format to FULL and ISO. I tried this on both z/VM 5.4 and 6.2, and I still get dates in the 1900's. Time for a PMR, I suppose. Is VMARC officially supported? Dennis O'Brien No man`s life, liberty, or property are safe while the legislature is in session. -- Mark Twain -Original Message- From: Linux on 390 Port [mailto:LINUX-390@vm.marist.edu] On Behalf Of Neale Ferguson Sent: Tuesday, May 15, 2012 10:35 To: LINUX-390@vm.marist.edu Subject: Re: LXFMT bug fix Not using the VMARC MODULE I am: LXFMTVMARCX1 F 80 111622 2012-05-15 09:45:58 LXFMTLOADMAP X5 V100 89 3 2012-05-15 09:44:25 LXFMTMODULE X1 V 18712 4 5 2012-05-15 09:44:25 LXFSETEXT X1 F 80121 3 2012-05-15 09:44:23 LXMSGTEXT X1 F 80 61 2 2012-05-15 09:44:20 LXFMTTEXT X1 F 80239 5 2012-05-15 09:44:19 LXASMEXEC X1 V 65 22 1 2012-05-15 09:42:45 LXFMTASSEMBLE X1 F 80 345668 2012-05-15 09:42:28 LXFSEASSEMBLE X1 F 8091718 2010-08-24 12:53:52 LXMSGASSEMBLE X1 F 80 78 2 2010-08-24 12:04:32 LXFMTREADME X1 F 80 46 1 2008-01-02 06:37:33 LXFMTHELPCMS X2 V 79148 2 2008-01-02 06:36:02 LXVMARC EXEC X1 V 54 16 1 2007-12-10 12:35:28 LXFMT1 LXCONFIG X1 F 80 3 1 2007-12-10 10:35:02 LNXVMCNTRLX2 F 80 5 1 2007-12-02 16:49:14 On 5/15/12 1:17 PM, O'Brien, Dennis L dennis.l.o'br...@bankofamerica.com wrote: The files in the new LXFMT22 VMARC have dates in 1907, 1908, and 1912. Either we had some very forward-thinking programmers a hundred years ago, or there's an error. Is this a VMARC bug or a packaging error when the files were created? -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. References to Sender are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: LXFMT bug fix
If you execute VMARC with no args or ? it should tell you the version number ... Mine is 1.2.29 -- and what I see is things are a century off: LISTFILE LXFMT* * (ISODATE FILENAME FILETYPE FM FORMAT LRECL RECS BLOCKS DATE TIME LXFMTASSEMBLE A1 F 80 3456 68 5/15/1912 9:42:28 LXFMTTEXT A1 F 80239 5 5/15/1912 9:44:19 LXFMTMODULE A1 V 18712 4 5 5/15/1912 9:44:25 LXFMTREADME A1 F 80 46 1 1/02/1908 6:37:33 LXFMTHELPCMS A2 V 79148 2 1/02/1908 6:36:02 Ready; T=0.01/0.01 07:34:17 What VMARC version do you have, Neale? Scott Rohling On Tue, May 15, 2012 at 12:08 PM, O'Brien, Dennis L dennis.l.o'br...@bankofamerica.com wrote: Interesting. I downloaded the latest VMARC MODULE from IBM, which is a slightly different size than my previous version from 2001, and also tried setting my date format to FULL and ISO. I tried this on both z/VM 5.4 and 6.2, and I still get dates in the 1900's. Time for a PMR, I suppose. Is VMARC officially supported? Dennis O'Brien No man`s life, liberty, or property are safe while the legislature is in session. -- Mark Twain -Original Message- From: Linux on 390 Port [mailto:LINUX-390@vm.marist.edu] On Behalf Of Neale Ferguson Sent: Tuesday, May 15, 2012 10:35 To: LINUX-390@vm.marist.edu Subject: Re: LXFMT bug fix Not using the VMARC MODULE I am: LXFMTVMARCX1 F 80 111622 2012-05-15 09:45:58 LXFMTLOADMAP X5 V100 89 3 2012-05-15 09:44:25 LXFMTMODULE X1 V 18712 4 5 2012-05-15 09:44:25 LXFSETEXT X1 F 80121 3 2012-05-15 09:44:23 LXMSGTEXT X1 F 80 61 2 2012-05-15 09:44:20 LXFMTTEXT X1 F 80239 5 2012-05-15 09:44:19 LXASMEXEC X1 V 65 22 1 2012-05-15 09:42:45 LXFMTASSEMBLE X1 F 80 345668 2012-05-15 09:42:28 LXFSEASSEMBLE X1 F 8091718 2010-08-24 12:53:52 LXMSGASSEMBLE X1 F 80 78 2 2010-08-24 12:04:32 LXFMTREADME X1 F 80 46 1 2008-01-02 06:37:33 LXFMTHELPCMS X2 V 79148 2 2008-01-02 06:36:02 LXVMARC EXEC X1 V 54 16 1 2007-12-10 12:35:28 LXFMT1 LXCONFIG X1 F 80 3 1 2007-12-10 10:35:02 LNXVMCNTRLX2 F 80 5 1 2007-12-02 16:49:14 On 5/15/12 1:17 PM, O'Brien, Dennis L dennis.l.o'br...@bankofamerica.com wrote: The files in the new LXFMT22 VMARC have dates in 1907, 1908, and 1912. Either we had some very forward-thinking programmers a hundred years ago, or there's an error. Is this a VMARC bug or a packaging error when the files were created? -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. References to Sender are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to
Re: LXFMT bug fix
I'm glad to know it's not just me. I see the problem on both 1.2.27 and 1.2.29. Dennis O'Brien No man`s life, liberty, or property are safe while the legislature is in session. -- Mark Twain -Original Message- From: Linux on 390 Port [mailto:LINUX-390@vm.marist.edu] On Behalf Of Scott Rohling Sent: Tuesday, May 15, 2012 12:37 To: LINUX-390@vm.marist.edu Subject: Re: LXFMT bug fix If you execute VMARC with no args or ? it should tell you the version number ... Mine is 1.2.29 -- and what I see is things are a century off: LISTFILE LXFMT* * (ISODATE FILENAME FILETYPE FM FORMAT LRECL RECS BLOCKS DATE TIME LXFMTASSEMBLE A1 F 80 3456 68 5/15/1912 9:42:28 LXFMTTEXT A1 F 80239 5 5/15/1912 9:44:19 LXFMTMODULE A1 V 18712 4 5 5/15/1912 9:44:25 LXFMTREADME A1 F 80 46 1 1/02/1908 6:37:33 LXFMTHELPCMS A2 V 79148 2 1/02/1908 6:36:02 Ready; T=0.01/0.01 07:34:17 What VMARC version do you have, Neale? Scott Rohling On Tue, May 15, 2012 at 12:08 PM, O'Brien, Dennis L dennis.l.o'br...@bankofamerica.com wrote: Interesting. I downloaded the latest VMARC MODULE from IBM, which is a slightly different size than my previous version from 2001, and also tried setting my date format to FULL and ISO. I tried this on both z/VM 5.4 and 6.2, and I still get dates in the 1900's. Time for a PMR, I suppose. Is VMARC officially supported? Dennis O'Brien No man`s life, liberty, or property are safe while the legislature is in session. -- Mark Twain -Original Message- From: Linux on 390 Port [mailto:LINUX-390@vm.marist.edu] On Behalf Of Neale Ferguson Sent: Tuesday, May 15, 2012 10:35 To: LINUX-390@vm.marist.edu Subject: Re: LXFMT bug fix Not using the VMARC MODULE I am: LXFMTVMARCX1 F 80 111622 2012-05-15 09:45:58 LXFMTLOADMAP X5 V100 89 3 2012-05-15 09:44:25 LXFMTMODULE X1 V 18712 4 5 2012-05-15 09:44:25 LXFSETEXT X1 F 80121 3 2012-05-15 09:44:23 LXMSGTEXT X1 F 80 61 2 2012-05-15 09:44:20 LXFMTTEXT X1 F 80239 5 2012-05-15 09:44:19 LXASMEXEC X1 V 65 22 1 2012-05-15 09:42:45 LXFMTASSEMBLE X1 F 80 345668 2012-05-15 09:42:28 LXFSEASSEMBLE X1 F 8091718 2010-08-24 12:53:52 LXMSGASSEMBLE X1 F 80 78 2 2010-08-24 12:04:32 LXFMTREADME X1 F 80 46 1 2008-01-02 06:37:33 LXFMTHELPCMS X2 V 79148 2 2008-01-02 06:36:02 LXVMARC EXEC X1 V 54 16 1 2007-12-10 12:35:28 LXFMT1 LXCONFIG X1 F 80 3 1 2007-12-10 10:35:02 LNXVMCNTRLX2 F 80 5 1 2007-12-02 16:49:14 On 5/15/12 1:17 PM, O'Brien, Dennis L dennis.l.o'br...@bankofamerica.com wrote: The files in the new LXFMT22 VMARC have dates in 1907, 1908, and 1912. Either we had some very forward-thinking programmers a hundred years ago, or there's an error. Is this a VMARC bug or a packaging error when the files were created? -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/ -- This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in
