Re: Size of Mdisk
Or maybe better, the Byte File System. That would provide a hierarchical storage mechanism for VSE. Yeah, there's an NFS client for VSE, but that's tied to a specific vendor... :( Huegel, Thomas wrote: Your last point.. Wouldn't it be so cool if VSE (zOS too) understood SFS.. Especially now that VSAM is no longer available for z/VM. -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2008 - Chattanooga - April 18-22, 2008
Re: RSU for z/VM 5.3
Hello Mike and Robert, Thank for the info. I use the SERVICE EXEC. service cp status to find my current level. VMFSRV2760I SERVICE processing started VMFSRV1225I CP (5VMCPR30%CP) status: VMFSRV1225IService Level RSU-0701 VMFSRV1225IProduction Level RSU-0701 VMFSRV2760I SERVICE processing completed successfully I was just hazy about whether UM97530 was always the highest RSU level. Ed Martin Aultman Health Foundation 330-588-4723 [EMAIL PROTECTED] ext. 40441 From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter Sent: Thursday, September 06, 2007 4:50 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: RSU for z/VM 5.3 Getting the answer to that question is why I keep a CURRRSU EXEC on MAINT's 191 disk. It contains: ---snip--- /* */ say 'The most-current RSU is always included on PTF UM97vrm' say 'e.g. UM97520 for z/VM 5.2.0, and UM97530 for z/VM 5.3.0.' ---snip--- Very simple, usually relatively easy to find the next time I can't remember by (from MAINT) entering: FL *RSU* EXEC * Currently, UM97530 leads to: APAR Identifier .. VM64232 Which in turn, states: 5301RSU AVAILABLE, ORDER UM97530 You should be good to go. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. Edward M. Martin [EMAIL PROTECTED] Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 09/06/2007 03:10 PM Please respond to The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU To IBMVM@LISTSERV.UARK.EDU cc Subject RSU for z/VM 5.3 Hello Everyone, What is the highest RSU for z/VM 5.3? 5301 (701)? Ed Martin Aultman Health Foundation 330-588-4723 [EMAIL PROTECTED] ext. 40441 The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited.
Re: Me thnks 'Chuckie' is afoot -
Hi Raymond,
Okay, let's get the obvious question out of the way first, you _are_
running this on the z/OS system, and not on VM?
Can you test this on another z/OS system to see if it is consistently
wrong? If consistently wrong, then that would suggest a bug.
Is z/OS REXX returning something 'extra' at the end of the data that
just looks like it is an extra '1'? (I have no z/OS manuals to check.)
Not very helpful, I know, but that's all I can think of.
Peter
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Raymond Noal
Sent: September 6, 2007 16:46
To: IBMVM@LISTSERV.UARK.EDU
Subject: Me thnks 'Chuckie' is afoot -
Ok, you network gurus; I've got one for you -
The TCP/IP address of my z/OS 1.8 system is 111.222.333.11. (not really,
and yes, I know this is the VM list)
When I run this REXX Exec -
/* REXX */
SAY SOCKET('INITIALIZE','MYID')
SAY SOCKET('GETHOSTID');
EXIT;
The results are:
0 MYID 40 *INET
0 111.222.333.111
Why is the last octet coming back as '111' and not '11'?
TIA
HITACHI
DATA SYSTEMS
Raymond E. Noal
Senior Technical Engineer
Office: (408) 970 - 7978
The information transmitted is intended only for the person or entity to which
it is addressed and may contain confidential and/or privileged material. Any
review retransmission dissemination or other use of or taking of any action in
reliance upon this information by persons or entities other than the intended
recipient or delegate is strictly prohibited. If you received this in error
please contact the sender and delete the material from any computer. The
integrity and security of this message cannot by guaranteed on the Internet.
The Sender accepts no liability for the content of this e-mail or for the
consequences of any actions taken on basis of the information provided. The
recipient should check this e-mail and any attachments for the presence of
viruses. The sender accepts no liability for any damage caused by any virus
transmitted by this e-mail. This disclaimer is the property of the TTC and
must not be altered or circumvented in any manner.
Re: 3590 (B1A) Hardware Compression
Bingo! My Linux programmer was using the GNU mt command, which evidently was setting compression off. He switched to mtst and provided the compression operand and it works fine now. Thanks much, I'll keep this note in my Linux/VM Compatibility folder for future reference! :) -Mike -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Rempel, Horst Sent: Thursday, September 06, 2007 9:59 AM To: IBMVM@LISTSERV.UARK.EDU Subject: AW: 3590 (B1A) Hardware Compression Hello Michael, you must install the mtst command in your Linux. After that you can enable the hardwarecompression (as far as I know the dafault is OFF) # mtst -f /dev/rtibm0 compression 1 This helped in my environment(Suse sles9) kindest regards Mit freundlichen Grüßen, Horst Rempel Berufsgenossenschafthttp://www.bgchemie.de http://www.bgchemie.de/ der chemischen Industriee-mail [EMAIL PROTECTED] Abteilung EDV/DV-ORG Kurfürstenanlage 62 69115 Heidelberg Tel.: 06221 / 523-1303 Fax : 06221 / 523-227 -Ursprüngliche Nachricht- Von: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Auftrag von Michael Coffin Gesendet: Donnerstag, 6. September 2007 15:14 An: IBMVM@LISTSERV.UARK.EDU Betreff: 3590 (B1A) Hardware Compression We use 3590 B1A drives, with 10/30 carts providing native capacity of 10GB, with up to 30GB using hardware compression. I am under the impression that the hardware will choose the best compression possible UNLESS it is specifically told otherwise (i.e. via a TAPE COMP/NOCOMP and DDR COMP/NOCOMP/LZCOMP options). Is this true, and is there a way to query the hardware from z/VM (4.4) to see if default hardware compression has been enabled on the drives (I imagine it has to be set by the CE during install/configuration)? I have a z/Linux user that was trying to dump 13GB of data and ran out of space, so it looks as though default hardware compression is not working. :( -Mike
Re: Size of Mdisk
Your last point.. Wouldn't it be so cool if VSE (zOS too) understood SFS.. Especially now that VSAM is no longer available for z/VM. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of David Boyes Sent: Thursday, September 06, 2007 8:26 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Size of Mdisk This application now has 2 3390-9s. The SFS sounds like a reasonable option. Some tips about SFS: 1) Be sure to do the math for the size of the control disks and catalog disks before you start seriously loading stuff into SFS and overallocate, overallocate, overallocate; better too big than too small. It's not trivial to change them later. 2) Give SFS fullpack minidisks for data storage when/if you can. Again, it's not trivial to reorganize a filepool once you create it, and consolidating SFS pool minidisks usually involves a dump and reload which is disruptive (and a genuine PITA if you don't have a SFS-enabled backup tool for CMS data). 3) You may be tempted to use the VMXXX: filepools that come with VM; DON'T. Those pools can't be shared between VM systems, the SFS servers are hardcoded not to permit it. Build a separate filepool for your user data. 4) The SFS security model is genuinely *weird*. If you're seriously going to use SFS, make sure your ESM understands SFS (not all do), and strongly consider buying Safe Software's SafeSFS. Trying to manage SFS security with the native SFS tools will drive you bonkers faster than sharing an office with your CEO and all your bosses at once. 5) Get a commercial backup tool that really understands SFS. The native SFS backup tools are difficult to use and understand. These days, that's either VM:Backup or the IBM Backup Manager. VM:Backup is a lot easier to install and use, but the IBM tools is a lot cheaper. 6) Be cautious about granting PUBLIC access. There are impacts on the security management that you may not expect. Ditto ADMIN access; read the docs carefully. 7) Find a copy of IPGATE (a nifty widget that lets you pass APPC traffic over IP). It's really useful for 2nd level systems and remote access to SFS from other VM systems, and if you're using SFS, you should have it in your toolbox. SFS is neat, but it's not easy to administer. It'd be cool if something other than CMS could use it effectively, but that's probably not ever going to happen. -- db __ ella for Spam Control has removed VSE-List messages and set aside VM-List for me You can use it too - and it's FREE! http://www.ellaforspam.com
Re: Size of Mdisk
On Friday, 09/07/2007 at 09:14 EDT, Huegel, Thomas [EMAIL PROTECTED] wrote: Your last point.. Wouldn't it be so cool if VSE (zOS too) understood SFS.. Especially now that VSAM is no longer available for z/VM. The common transform is NFS. Alan Altmark z/VM Development IBM Endicott
Re: Size of Mdisk
Was thinking more of a CMS VSAM interface, but you're right that the hooks might already be there.
Re: Size of Mdisk
You write the requirement and I'll vote for it! -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of David Boyes Sent: Friday, September 07, 2007 10:29 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Size of Mdisk Your last point.. Wouldn't it be so cool if VSE (zOS too) understood SFS.. Especially now that VSAM is no longer available for z/VM. That *is* a cool idea. I can submit it as a WAVV requirement; the VSE lab is a lot more cooperative about that sort of thing, and the WAVV guys tend towards the VSE environment more than SHARE does. I doubt z/OS would ever use it (although it would be a very elegant way to get FBA and SCSI disk support into z/OS in short order...) I wonder how difficult writing a VSAM to SFS block store driver would be... hmm. Another project to do *later*... __ ella for Spam Control has removed VSE-List messages and set aside VM-List for me You can use it too - and it's FREE! http://www.ellaforspam.com
Re: Size of Mdisk
Your last point.. Wouldn't it be so cool if VSE (zOS too) understood SFS.. Especially now that VSAM is no longer available for z/VM. That *is* a cool idea. I can submit it as a WAVV requirement; the VSE lab is a lot more cooperative about that sort of thing, and the WAVV guys tend towards the VSE environment more than SHARE does. I doubt z/OS would ever use it (although it would be a very elegant way to get FBA and SCSI disk support into z/OS in short order...) I wonder how difficult writing a VSAM to SFS block store driver would be... hmm. Another project to do *later*...
Re: Size of Mdisk
The VSE development lab won't be of much help there. As far as they're concerned they already have an NFS client as delivered by the Connectivity Systems TCP/IP Stack (which is delivered as a pre-installed, priced feature with every VSE shipment). Unfortunately that doesn't solve the problem for the significant percentage of the customers that are using TCP/IP Tools from Barnard Software (an alternative TCP/IP stack for VSE), which does not provide an NFS client. Perhaps the requirement should go to Jeff... :) David Boyes wrote: Your last point.. Wouldn't it be so cool if VSE (zOS too) understood SFS.. Especially now that VSAM is no longer available for z/VM. That *is* a cool idea. I can submit it as a WAVV requirement; the VSE lab is a lot more cooperative about that sort of thing, and the WAVV guys tend towards the VSE environment more than SHARE does. I doubt z/OS would ever use it (although it would be a very elegant way to get FBA and SCSI disk support into z/OS in short order...) I wonder how difficult writing a VSAM to SFS block store driver would be... hmm. Another project to do *later*... -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2008 - Chattanooga - April 18-22, 2008
Re: Size of Mdisk
At least for ESDS files, the VSAM hooks are already there (I don't know if KSDS would be any different or would really matter). The TCP/IP Tools Transparent FTP support is built that way. When a VSAM ESDS file is opened an FTP open is triggered, the data flows to or from the program through the FTP channels. The process is controlled via JCL and a VSE librarian member handles the destination and FTP credentials. David Boyes wrote: I wonder how difficult writing a VSAM to SFS block store driver would be... hmm. Another project to do *later*... -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2008 - Chattanooga - April 18-22, 2008
Re: Me thnks 'Chuckie' is afoot -
Peter,,
It turned out to be a TCP/IP configuration problem. There were two
PRIMARYINTERFACE statements and the second on had the 'erroneous' value
for the last octet. I changed the configuration file and now everything
is working just fine.
The same REXX Exec worked fine under z/VM. It was just the z/OS systems
having this problem.
Thanks.
HITACHI
DATA SYSTEMS
Raymond E. Noal
Senior Technical Engineer
Office: (408) 970 - 7978
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of [EMAIL PROTECTED]
Sent: Friday, September 07, 2007 5:58 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Me thnks 'Chuckie' is afoot -
Hi Raymond,
Okay, let's get the obvious question out of the way first, you _are_
running this on the z/OS system, and not on VM?
Can you test this on another z/OS system to see if it is consistently
wrong? If consistently wrong, then that would suggest a bug.
Is z/OS REXX returning something 'extra' at the end of the data that
just looks like it is an extra '1'? (I have no z/OS manuals to check.)
Not very helpful, I know, but that's all I can think of.
Peter
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Raymond Noal
Sent: September 6, 2007 16:46
To: IBMVM@LISTSERV.UARK.EDU
Subject: Me thnks 'Chuckie' is afoot -
Ok, you network gurus; I've got one for you -
The TCP/IP address of my z/OS 1.8 system is 111.222.333.11. (not really,
and yes, I know this is the VM list)
When I run this REXX Exec -
/* REXX */
SAY SOCKET('INITIALIZE','MYID')
SAY SOCKET('GETHOSTID');
EXIT;
The results are:
0 MYID 40 *INET
0 111.222.333.111
Why is the last octet coming back as '111' and not '11'?
TIA
HITACHI
DATA SYSTEMS
Raymond E. Noal
Senior Technical Engineer
Office: (408) 970 - 7978
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review retransmission dissemination or other use of or
taking of any action in reliance upon this information by persons or
entities other than the intended recipient or delegate is strictly
prohibited. If you received this in error please contact the sender and
delete the material from any computer. The integrity and security of
this message cannot by guaranteed on the Internet. The Sender accepts no
liability for the content of this e-mail or for the consequences of any
actions taken on basis of the information provided. The recipient should
check this e-mail and any attachments for the presence of viruses. The
sender accepts no liability for any damage caused by any virus
transmitted by this e-mail. This disclaimer is the property of the TTC
and must not be altered or circumvented in any manner.
Re: MVS/XA Link Editor Limits
Using the BIND command to replace the LKED command did not solve my problem. The BIND is used to produce a MODULE and I need to use a LOADLIB. The CSECT size of my user logon table in VTAM/SWITCH had exceeded X'03'. Even though VTAM/SWITCH has not been a supported product on VM for many years, Wendell Lovewell at MacKinney Systems was kind enough to help with this problem. The solution was to change the LOADLIB blocksize from 516 to 1024. Wendell sent me an EXEC to do this and it worked perfectly. My thanks go out to Wendell and MacKinney System for excellent service. /Fran Hensler at Slippery Rock University of Pennsylvania USA for 44 years [EMAIL PROTECTED] +1.724.738.2153 Yes, Virginia, there is a Slippery Rock On Thu, 16 Aug 2007 14:44:44 -0400 Michael Donovan said: Take a look at the BIND command as a replacement for LKED. It first shipped in z/VM 3.1 and does remove many of the limit restrictions of LKED.See the Program Management Binder for CMS book for details. On Thu, 16 Aug 2007 13:17:13 EDT Fran Hensler said: I am compiling a CSECT (GSFDFUS) that has grown past the limits of LKED in z/VM 3.1. This is the output I am getting: MVS/XA DFP VER 2 LINKAGE EDITOR11:38:18 THU AUG 16, 2007 JOBSTEP INVOCATION PARAMETERS - TERM,SIZE=(180K,100K),REUS,INVALID ACTUAL SIZE=(122880,65520) OUTPUT DATA SET GSMINIT IS ON VOLUME IEW0364 CSECT GSFDFUS EXCEEDS 512 TIMES 00512, THE SYSLMOD RECORD SIZE. DIAGNOSTIC MESSAGE DIRECTORY IEW0364 ERROR - TABLE OVERFLOW -- INPUT TEXT EXCEEDED MAXIMUM OR TOO MANY CHANGES OF ORIGIN IN INPUT. Is there anything newer in z/VM than LKED that can handle bigger CSECTS? Is there a parameter for LKED that will allow CSECTs larger than 03? /Fran Hensler at Slippery Rock University of Pennsylvania USA for 44 years [EMAIL PROTECTED] +1.724.738.2153 Yes, Virginia, there is a Slippery Rock
Re: Size of Mdisk
On Friday, 09/07/2007 at 11:58 EDT, Huegel, Thomas [EMAIL PROTECTED] wrote: You write the requirement and I'll vote for it! AVAILABLE (via NFS). I wonder how difficult writing a VSAM to SFS block store driver would be... hmm. Another project to do *later*.. I would be remiss if I didn't point out that CMS has a VSAM API redirector in it. Look at the SUBSYS operand of FILEDEF. We added it in 1984 or thereabouts and the SQL/DS product had hook to let it process VSAM requests. I don't know if DB2 for VM/VSE still supports that. Look at Interface to an Alternate VSAM Emulator in the CMS Application Development Guide for Assembler. Your routine gets control on OPEN, CLOSE, and CLOSE TYPE=T with the address of the ACB. On OPEN your routine fills in the read/write vectors in the ACB. Alan Altmark z/VM Development IBM Endicott
Debbie Abel/Phoenix/IBM is out of the office.
I will be out of the office starting 09/07/2007 and will not return until 09/10/2007.
Re: Size of Mdisk
Oohh... niiice Alan Altmark wrote: I would be remiss if I didn't point out that CMS has a VSAM API redirector in it. Look at the SUBSYS operand of FILEDEF. We added it in 1984 or thereabouts and the SQL/DS product had hook to let it process VSAM requests. I don't know if DB2 for VM/VSE still supports that. Look at Interface to an Alternate VSAM Emulator in the CMS Application Development Guide for Assembler. Your routine gets control on OPEN, CLOSE, and CLOSE TYPE=T with the address of the ACB. On OPEN your routine fills in the read/write vectors in the ACB. Alan Altmark z/VM Development IBM Endicott -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2008 - Chattanooga - April 18-22, 2008
RPWLIST DATA
Does anyone know off the top of their head where IBM hides this DIRMAINT 'example' file on 5.2? RPWLIST DATA __ ella for Spam Control has removed VSE-List messages and set aside VM-List for me You can use it too - and it's FREE! http://www.ellaforspam.com
Re: Weizmann Institute of Science (WIS) VM Closing
Sigh, this makes me sad and nostalgic. More than 20 years ago, traveling in Israel, a friend and I visited Weizmann. Being geeks/techies (me VMer, she document technology expert), we of course arranged to visit VM sites around the world. We received a wonderful/warm reception equal to any red-carpet treatment. Visiting Weizmann was a high point of the trip for us. So, regards to the Weizmann folk and thanks for the long-ago visit! And maybe we should all wish you continued bad luck in shutting down VM... Larry Israel said: After slightly missing the closing date of end of 2001, it looks like we will be shutting down sometimes between October 1 and December 30. One good thing about our VM/ESA 2.4 system -- no new bugs in a very long time. I have been baby-sitting the system on a part-time basis for the last four years, so I will be really retired. -- Gabriel Goldberg, Computers and Publishing, Inc. (703) 204-0433 3401 Silver Maple Place, Falls Church, VA 22042[EMAIL PROTECTED]
Re: RPWLIST DATA
Hello Thomas, For Both 4.3.0 and 5.3.0 it is on 2CC (maint). I would suspect it is there for 5.2. Ed Martin Aultman Health Foundation 330-588-4723 [EMAIL PROTECTED] ext. 40441 From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Huegel, Thomas Sent: Friday, September 07, 2007 3:09 PM To: IBMVM@LISTSERV.UARK.EDU Subject: RPWLIST DATA Does anyone know off the top of their head where IBM hides this DIRMAINT 'example' file on 5.2? RPWLIST DATA __ ella for Spam Control has removed VSE-List messages and set aside VM-List for me You can use it too - and it's FREE! http://www.ellaforspam.com
Re: RPWLIST DATA
Thanks Ed. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Edward M. Martin Sent: Friday, September 07, 2007 2:15 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: RPWLIST DATA Hello Thomas, For Both 4.3.0 and 5.3.0 it is on 2CC (maint). I would suspect it is there for 5.2. Ed Martin Aultman Health Foundation 330-588-4723 [EMAIL PROTECTED] ext. 40441 _ From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Huegel, Thomas Sent: Friday, September 07, 2007 3:09 PM To: IBMVM@LISTSERV.UARK.EDU Subject: RPWLIST DATA Does anyone know off the top of their head where IBM hides this DIRMAINT 'example' file on 5.2? RPWLIST DATA __ ella for Spam Control has removed VSE-List messages and set aside VM-List for me You can use it too - and it's FREE! http://www.ellaforspam.com http://www.ellaforspam.com _ ella for Spam Control has removed 12692 VSE-List messages and set aside 11854 VM-List for me You can use it too - and it's FREE! www.ellaforspam.com http://www.ellaforspam.com
Re: RPWLIST DATA
I'm just implementing Dirmaint and it's on MAINTs 2CC (where the original directory was). I don't see it on any of Dirmaint's disks. You can use the FILE command to send it over. Huegel, Thomas wrote: Does anyone know off the top of their head where IBM hides this DIRMAINT 'example' file on 5.2? RPWLIST DATA __ ella for Spam Control has removed VSE-List messages and set aside VM-List for me You can use it too - and it's FREE! http://www.ellaforspam.com -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2008 - Chattanooga - April 18-22, 2008
