Re: How can we quickly determine the number of output blocks a file will need on a CMS disk?
What is the source of the file? That other system, maybe? What are the record characteristics? If the file has fixed-length records but is written as variable, that will consume a lot of extra space. Besides, how critical can it be if you don't give it the dasd real estate it needs? :) Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Rich Greenberg Sent: Monday, June 19, 2006 4:37 PM To: IBMVM@LISTSERV.UARK.EDU Subject:Re: How can we quickly determine the number of output blocks a file will need on a CMS disk? On: Mon, Jun 19, 2006 at 05:56:31PM -0500,Mike Walter Wrote: } Well, this has been an interesting day. One of our commands to copy files } into production failed to copy a critical file because the output disk was } too full to handle the file. Just a WAG here Mike, but if the file has more shorter records, wouldn't the number of pointer blocks go up? I haven't looked at DISKSIZE in ages but would assume that it uses an average record size to estimate the number of pointer blocks, and that average is way off for this file Also, just IMHO, if its a "critical" production file, you should add a bit to the DISKSIZE estimate for a safety factor. -- Rich Greenberg N Ft Myers, FL, USA richgr atsign panix.com + 1 239 543 1353 Eastern time. N6LRT I speak for myself & my dogs only.VM'er since CP-67 Canines:Val, Red & Shasta (RIP),Red, Zero & Casey, Siberians Owner:Chinook-L Retired at the beachAsst Owner:Sibernet-L
Re: How can we quickly determine the number of output blocks a file will need on a CMS disk?
On: Mon, Jun 19, 2006 at 05:56:31PM -0500,Mike Walter Wrote: } Well, this has been an interesting day. One of our commands to copy files } into production failed to copy a critical file because the output disk was } too full to handle the file. Just a WAG here Mike, but if the file has more shorter records, wouldn't the number of pointer blocks go up? I haven't looked at DISKSIZE in ages but would assume that it uses an average record size to estimate the number of pointer blocks, and that average is way off for this file Also, just IMHO, if its a "critical" production file, you should add a bit to the DISKSIZE estimate for a safety factor. -- Rich Greenberg N Ft Myers, FL, USA richgr atsign panix.com + 1 239 543 1353 Eastern time. N6LRT I speak for myself & my dogs only.VM'er since CP-67 Canines:Val, Red & Shasta (RIP),Red, Zero & Casey, Siberians Owner:Chinook-L Retired at the beachAsst Owner:Sibernet-L
How can we quickly determine the number of output blocks a file will need on a CMS disk?
Well, this has been an interesting day. One of our commands to copy files into production failed to copy a critical file because the output disk was too full to handle the file. We've been using a "DISKSIZE EXEC" for years (posted to the post a long time ago) to determine the number of blocks a CMS file really uses, including the CMS pointer blocks. But somewhere along the line, the algorithm seems to have changed. The heart of DISKSIZE EXEC computed: -- dblocks = totsize%blocksize /* Total number of data blocks req'd */ If totsize//blocksize > 0 then dblocks = dblocks+1 mapped = blocksize/4 /* # of blks mapped by a single ptr blk */ /* Calculate the number of pointer levels required */ Do i=0 by 1 If mapped**i >= dblocks then Leave End /* Calculate the number of level 1 pointer blks required, if any */ pblocks=0 If i>0 then Do pblocks = dblocks%mapped If dblocks//mapped>0 then pblocks = pblocks+1 End /* Add the number of pointer blks req'd for level 2 & greater!!! */ If i>1 then Do j=0 to i-2 pblocks = pblocks + mapped**j End tot=dblocks+pblocks -- That formula no longer works reliably, and I have not (yet) found a recent copy of the old "CMS Diagnosis Guide" which explained the CMS File System overhead. The file in particular is: Filename Filetype Fm Format Lrecl Records Blocks Date Time B2 V 242 37884 2256 6/19/06 2:22:45 "PIPE < B | count bytes | cons" displays: 9163140 Running 9163140 through the above formula yields: 2242 or 2243 (Total blocks, depending on of the byte count or the LRECL and number of records is supplied to DISKSIZE). Rather short of what LISTFILE reports for even data blocks, much less the pointer blocks. Copying the file to SFS and issuing a "Q BLOCKS fm" yields: 2256 data blocks (in agreement with LISTFILE) and 8 system (pointer) blocks. Did something change in CMS since the 20030724 date on my trusty old DISKSIZE EXEC? Thanks in advance. Mike Walter Hewitt Associates The opinions expressed herein are mine alone, not my employer's. 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: RES: VSE/VSAM for VM
I received the following reply from Gerhard Zierl from IBM in April: "...The news is that after assessing the situation the product stays withdrawn from market. Toady VM/VSAM is used in very stable environments by customers who have the product already licensed and installed for a long time, IBM hasn't seen new customers to this product for a long time. Therefore we do not see any problem associated with the withdrawal from market.. z/VM 5.2 customers can use their old VSAM distribution tape which they have received with their current version of z/VM. Same is true for end of service. The last APAR was 2001 (more than 5 years). Before that there was one (new function) APAR in 1999 and 2 defect APARs in 1996. VM/VSAM is a very stable product. In addion VM/VSAM is used by customers in mature and stable environments, no new applications, no major changes, etc... I would assume the same applies to your product. So the risk of encountering a severe problem is extremely low. In case customers decide they have a critical need to have service beyond the EOS-date, then there is in general an option to ask IBM for a charged service extension agreement." Mark. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Shimon Lebowitz Sent: Tuesday, 20 June 2006 6:48 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: RES: VSE/VSAM for VM > IBM MUST give an option. There are some products from IBM that uses VSAM/VM > and how we should handle this? Netview Access is one of them. Change it > means to re-think all our mainframe access. My list of current uses of VSAM also included Netview. The response of the product owner was "Netview for VM has already been discontinued, so that doesn't count". I just looked at the VM LP Matrix for 5.2 (Dec. 16, 2005), http://www.vm.ibm.com/techinfo/lpmigr/vml12165.html and it says both apparently contradictory statements: - Removed End of Service from Netview V2 for VM/ESA V2.3.0. This product is still supported. - Added Discontinuance of Service date for VSE/VSAM (5686-081), effective February 28, 2007. In any case we have LOTS more using VSAM than Netview. Shimon
Re: RES: VSE/VSAM for VM
> IBM MUST give an option. There are some products from IBM that uses VSAM/VM > and how we should handle this? Netview Access is one of them. Change it > means to re-think all our mainframe access. My list of current uses of VSAM also included Netview. The response of the product owner was "Netview for VM has already been discontinued, so that doesn't count". I just looked at the VM LP Matrix for 5.2 (Dec. 16, 2005), http://www.vm.ibm.com/techinfo/lpmigr/vml12165.html and it says both apparently contradictory statements: - Removed End of Service from Netview V2 for VM/ESA V2.3.0. This product is still supported. - Added Discontinuance of Service date for VSE/VSAM (5686-081), effective February 28, 2007. In any case we have LOTS more using VSAM than Netview. Shimon
Re: z/VM PING tool and the LINK option?
See the thread in the archives with title: How to PING through a secondary TCPIP stack? at: http://listserv.uark.edu/scripts/wa.exe?A2=ind0602&L=IBMVM&D=0&I=-3&P=61750 > The z/OS (v1.7 here) version of PING allows you to code an option to specify > which interface to use when you want to ping a remote host. I notice that the > z/VM version (level 510) has an option called LINK, but when I use it, it says > that it's only for use with IP version 6. I was able to confirm in the User's > Guide too, where it says "The LINK parameter is valid for pinging IPv6 targets > only." Bummer. I was hoping to ping test some remote hosts by going out a > specific link, but like most everyone else we are still a IPv4 network. > > Thanks > >
Re: IOCP for MP2003-204
SYSC is the HMC Integrated "C"onsole - a linemode beast requiring user of the awkwardly defined syntax: VINPUT VMSG command_text_here SYSG is the HMC Integrated 3270 Console - I remember it as a "G"RAF console, as in: CP DEFINE GRAF 3270 Both work, but differently... SYSG is a regular 3270 emulator console (with a very frustrating and weirdly customizable) keyboard. Of the two, I'd choose SYSG every time. Mike Walter Hewitt Associates The opinions expressed herein are mine alone, not my employer's. "Steve Gentry" <[EMAIL PROTECTED]> Sent by: "The IBM z/VM Operating System" 06/19/2006 01:29 PM Please respond to "The IBM z/VM Operating System" To IBMVM@LISTSERV.UARK.EDU cc Subject Re: IOCP for MP2003-204 Is it SYSG or SYSC? Kris Buelens <[EMAIL PROTECTED]> Sent by: The IBM z/VM Operating System 06/19/2006 12:21 PM Please respond to The IBM z/VM Operating System To: IBMVM@LISTSERV.UARK.EDU cc: Subject: Re: IOCP for MP2003-204 SYSG was already supported on 9672, with a recent EC-level. I don't know about MP3000. VM/ESA 2.3 surely did not support SYSG; z/VM 4.2 or 4.4 was the first to support SYSG. Kris, IBM Belgium, VM customer support 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: IOCP for MP2003-204
On 6/19/06, Steve Gentry <[EMAIL PROTECTED]> wrote: Is it SYSG or SYSC? Yes ;-) SYSC is the linemode interface in the HMC (the one that is emulated by CP throught the VINPUT stuff) and SYSG is the (more recent) 3270-emulator sessions on the HMC. -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/
Re: IOCP for MP2003-204
Is it SYSG or SYSC? Kris Buelens <[EMAIL PROTECTED]> Sent by: The IBM z/VM Operating System 06/19/2006 12:21 PM Please respond to The IBM z/VM Operating System To: IBMVM@LISTSERV.UARK.EDU cc: Subject: Re: IOCP for MP2003-204 SYSG was already supported on 9672, with a recent EC-level. I don't know about MP3000. VM/ESA 2.3 surely did not support SYSG; z/VM 4.2 or 4.4 was the first to support SYSG. Kris, IBM Belgium, VM customer support
RES: VSE/VSAM for VM
IBM MUST give an option. There are some products from IBM that uses VSAM/VM and how we should handle this? Netview Access is one of them. Change it means to re-think all our mainframe access. Carlos -Mensagem original- De: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Em nome de Shimon Lebowitz Enviada em: segunda-feira, 19 de junho de 2006 10:09 Para: IBMVM@LISTSERV.UARK.EDU Assunto: VSE/VSAM for VM Hi, Back in December there was a flurry of activity here on the topic of VSE/VSAM for VM being discontinued. At the time, I, and I believe lots of others, wrote to the product owner expressing our concerns with this policy. Has anyone heard of there being any result to these comments/complaints? The VSE/VSAM web page at http://www.vm.ibm.com/related/vsevsam/ still announces: VSE/VSAM (5686-081) ends service February 28, 2007. Do we have to just assume that VSAM is dead, and drop all of our production applications that use it? Is that what all of you out there have done? I am pretty scared about that possibility... Shimon
Re: IOCP for MP2003-204
SYSG was already supported on 9672, with a recent EC-level. I don't know about MP3000. VM/ESA 2.3 surely did not support SYSG; z/VM 4.2 or 4.4 was the first to support SYSG. Kris, IBM Belgium, VM customer support
Re: IOCP for MP2003-204
Hi George, I have 5 CPOWNED volumes. I have used ICKDSF to formated and DDR restored them all. The other 59 DASDs are for user DATA. I just put a volume number on. The DISABLE WAIT PSW is 000A9025 - and the explaination is; "SCP initialiated reset of the I/O interface". Maybe something I should not have included in the IOCDS? Let me check. Regards, ...Roland George Haddad <[EMAIL PROTECTED]> wrote: If any of these DASD are in your CP-owned list, be sure to FORMAT the CP areas as well as defining the Labels. Especially if they are PAGE areas. Bad things have happened to us in the past trying to page to an un-formatted area.As another poster said, please pass on your Disabled Wait PSW as that will most likely pinpoint your current woes.Roland P. Chung wrote:> Thanks George I over the hump right now... I managed to get a IOCDS created on Sunday that gave me access to the tape, 3278's and DASDs.> > Now, I am tying to load the CP. It is not cooperating yet. Nowhere to check why it went into DISABLE WAIT! Maybe because I was to lazy to type in all the command using the standalone ICKDSF. I have not initialized all the other 59 3390-3 and CP is getting upset. I am in the process of using ICKDSF to do a quick initialize putting a volume seriam number on these DASDs and try again. Wish me luck.> > This is a classic case of "lack of planning and totally reflected on me" ^e^ ...> > Thanks again.> > ..Roland>>>
z/VM PING tool and the LINK option?
The z/OS (v1.7 here) version of PING allows you to code an option to specify which interface to use when you want to ping a remote host. I notice that the z/VM version (level 510) has an option called LINK, but when I use it, it says that it's only for use with IP version 6. I was able to confirm in the User's Guide too, where it says "The LINK parameter is valid for pinging IPv6 targets only." Bummer. I was hoping to ping test some remote hosts by going out a specific link, but like most everyone else we are still a IPv4 network. Thanks
Re: IOCP for MP2003-204
If any of these DASD are in your CP-owned list, be sure to FORMAT the CP areas as well as defining the Labels. Especially if they are PAGE areas. Bad things have happened to us in the past trying to page to an un-formatted area. As another poster said, please pass on your Disabled Wait PSW as that will most likely pinpoint your current woes. Roland P. Chung wrote: Thanks George I over the hump right now... I managed to get a IOCDS created on Sunday that gave me access to the tape, 3278's and DASDs. Now, I am tying to load the CP. It is not cooperating yet. Nowhere to check why it went into DISABLE WAIT! Maybe because I was to lazy to type in all the command using the standalone ICKDSF. I have not initialized all the other 59 3390-3 and CP is getting upset. I am in the process of using ICKDSF to do a quick initialize putting a volume seriam number on these DASDs and try again. Wish me luck. This is a classic case of "lack of planning and totally reflected on me" ^e^ ... Thanks again. ..Roland
Re: VSE/VSAM for VM
Shimon - I wrote to the product owner about my concerns. I explained to him that VSE/REXX performance on VSAM files was poor and that I could get better performance in VM/REXX using Address REXXVSAM and Pipe stage NASHVSAM while linked to the VSE/VSAM files. He wrote back asking for examples (which I sent him) and then I never heard from him again. /Fran Hensler at Slippery Rock University of Pennsylvania USA for 43 years [EMAIL PROTECTED] +1.724.738.2153 "Yes, Virginia, there is a Slippery Rock" On Mon, 19 Jun 2006 15:09:08 +0200 Shimon Lebowitz said: >Hi, >Back in December there was a flurry of activity here >on the topic of VSE/VSAM for VM being discontinued. >At the time, I, and I believe lots of others, wrote to the >product owner expressing our concerns with this policy. > >Has anyone heard of there being any result to these >comments/complaints? > >The VSE/VSAM web page at http://www.vm.ibm.com/related/vsevsam/ >still announces: >VSE/VSAM (5686-081) ends service February 28, 2007. > >Do we have to just assume that VSAM is dead, and >drop all of our production applications that use it? >Is that what all of you out there have done? > >I am pretty scared about that possibility... >Shimon
Re: IOCP for MP2003-204
Roland Can you post the Disable Wait PSW? eric Eric Schadow Mainframe Technical Support www.davisvision.com The information contained in this communication is intended only for the use of the recipient(s) named above. It may contain information that is privileged or confidential, and may be protected by State and/or Federal Regulations. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please return it to the sender immediately and delete the original message and any copy of it from your computer system. If you have any questions concerning this message, please contact the sender.
Re: IOCP for MP2003-204
Thanks George I over the hump right now... I managed to get a IOCDS created on Sunday that gave me access to the tape, 3278's and DASDs. Now, I am tying to load the CP. It is not cooperating yet. Nowhere to check why it went into DISABLE WAIT! Maybe because I was to lazy to type in all the command using the standalone ICKDSF. I have not initialized all the other 59 3390-3 and CP is getting upset. I am in the process of using ICKDSF to do a quick initialize putting a volume seriam number on these DASDs and try again. Wish me luck. This is a classic case of "lack of planning and totally reflected on me" ^e^ ... Thanks again. ..RolandGeorge Haddad <[EMAIL PROTECTED]> wrote: I believe I mis-spoke in my prev email, it is the CUNUMBR field on the CNTLUNIT macro that we use to re-define our CHPIDs to "more desirable" numbers.With best regards,...Roland ChungSenior Technical Specialist (S/390,VM/VSE,DB2/VSE&VM)MAXC Consultants Inc.Voice/Fax: 416-469-3280 (If busy, call: 416-469-2268)197 Hastings Ave., Toronto, Ontario, Canada. M4L 2L6** Life is short. Stop once in a while and smell the roses. **
Re: IOCP for MP2003-204
I believe I mis-spoke in my prev email, it is the CUNUMBR field on the CNTLUNIT macro that we use to re-define our CHPIDs to "more desirable" numbers.
Re: IOCP for MP2003-204
ROland, sorry I could not get back to "the list" on Friday with our IOCP. While it is much less populated than the other posters' examples, ours *may* help with your console problems if you have a similar config. We have a 3174 attached to one of the MP2003 bus&tag channels. However, we've redefined the Channels to be different from the Paths via the UNITADDR parm on the CNTRLUNIT stmts. THe bus&tag channels are at paths 40-45 on our MP2003-205, but to match a config from a previous machine, we redefined them so that our 3174 appears as Channel 00, our Tapes are on Channel 05 (and formerly Channel 15), and our now-de-installed external DASD were on Channels 0B/0F. I'll append the IOCP source file at the end of your quote. It's worked for us since our initial migration back in 1999. Hope it helps. Roland P. Chung wrote: Hello All, thanks to all who responded. After hours of struggling, I manage to set up a IOCDS which I was able to get at the tape drives, DASDs and 3174. IPLed the standalone ICKDSF and DDR. I was very happy to be able to restore all 5 CP OWNED volumes. Came to the monent of truth IPL'ed VM hit the terminal... nothing... After spent hours investigating and trial many different address on the 3174, I only can figure out that VM can't get at the 3174 because in the SYSTEM CONFIG file, it says: Operator_Consoles 001F 0020 0021 0022 0023 Emergency_Message_Consoles 0020 0021 0022 0023 And in MP2003 world, I think there are no channel 0 anymore and there re no good old 01F(the integrated console) hangs on that channel either. I think the address (at least the UU) has been hardcoded as 40-5F on the 3174 controler. I was very tire my brian can only think of a few solutions: 1) find an IBM "Productivity Centre" near Washinging, DC (if there are such thing in US!), restore the 5 pack VM system, IPL it and fix the SYSTEM CONFIG to include 040 - 043 (the address on that 3174); Backup the 230RES, restore it back here and I should be in business 2) reconfigure the 3174 to start the UU from 20 - well, the Utility and a backup disk are there only thing I need is a manual. Anyone has a LINK I can get a softcopy? 3) get a zVM DVD? How and where? Anyone has a better idea on how to resolve this problem? TIA MSU's MP2003-205 IOCP: -- ID MSG1='2003VM3 IOCP FOR MP2003 RUNNING MSUVM3', * MSG2='Created 04/14/99 GJH', * SYSTEM=(2003,1) *IOCP = *IOCP IOCDS for 2003-205 running MSUVM3 *IOCP *IOCP 09/26/91 GJH: Created (from original 9221 IOCDS via export) *IOCP 09/30/91 GJH: Add Def for 7171 (300-33F) *IOCP 05/07/93 GJH: Add Def for 3480 (590-59F) *IOCP 09/09/93 GJH: Add Def for BTI (380-38F) *IOCP 12/06/94 GJH: Add Def for 9336 (D40-D5F) *IOCP 01/04/95 GJH: Remove 9332's, define 9336's on channel C *IOCP 07/18/96 GJH: Remove extraneous 9336 defs *IOCP 10/03/97 GJH: Define 3990/3390s (B40/F40) *IOCP 02/02/98 GJH: Add defs for MP2003 internal devices *IOCP 01/07/99 GJH: Add defs for Memorex Cart Tape drives *IOCP *IOCP *IOCP = *IOCP *IOCP MP2003 Internal Devices *IOCP CHPID PATH=(5A),TYPE=ISD CHPID PATH=(5C),TYPE=OSA CHPID PATH=(5E),TYPE=ISD *IOCP *IOCP Parallel (Bus & Tag) Channels: *IOCP CHPID PATH=(40),TYPE=BL CHPID PATH=(41),TYPE=BL CHPID PATH=(42),TYPE=BL CHPID PATH=(44),TYPE=BL
Re: IOCP for MP2003-204
Hi Roland, There are two places you must specify the console address. First off, you have to tell the hardware. That is what you are seeing on the Support Element console. For the IPL address, you use your dasd device address. For the Loadparm, just enter the device address of the terminal you want to use for the console. IPL the processor. SAPL should come up on the device you entered in the Loadparm field. At that point you can enter cons= to tell VM where to find the console, and continue with the VM IPL. Peter -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Roland P. Chung Sent: June 19, 2006 09:50 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: IOCP for MP2003-204 Hi All, thanks for all your responses. How could I forget the SAPL. Must be getting old The customer is still using VM/ESA 2.30... I don't know if the SAPL would take the LOADPARM. Anyway, the application runing on the MP2003-204 allows a place to put in a load address and a load parameter. However, it only allows 8 characters in this load parameter field, but NO special characters allows, like the = sign... RRRrr.. There are no "intergrated console support" in this beast either Do you have other suggestions? TIA Regards, ...Roland Kris Buelens <[EMAIL PROTECTED]> wrote: In some z/VM release, new possibilities have been added in the area of console address override. I don't know which release, but it surely already work in z/VM 4.4 Here's a summary of what you now can do - LOADPARM rdev --> starts SAPL on "rdev", there you can enter CONS=rdev to tell CP where to go and load CP - LOADPARM CONSrdev -> SAPL directly loads CP and passes CONS=rdev As rdev one can also specify SYSG to indicate the "integrated 3270 CONSOLE", very easy but first you must drag a "3270 console" icon on the icon of the LPAR in which you want to load VM. Both SAPLand CP support this console (z/OS does not), so the LOADPARM can be SYSG or CONSSYSG Similar, there is SYSC, the integrated linemode console, not supported by SAPL, so you can also enter LOADPARM CONSSYSC to directly load CP and instruct it to got to that linemode terminal. Kris, IBM Belgium, VM customer support 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: IOCP for MP2003-204
Hi All, thanks for all your responses. How could I forget the SAPL. Must be getting old The customer is still using VM/ESA 2.30... I don't know if the SAPL would take the LOADPARM. Anyway, the application runing on the MP2003-204 allows a place to put in a load address and a load parameter. However, it only allows 8 characters in this load parameter field, but NO special characters allows, like the = sign... RRRrr.. There are no "intergrated console support" in this beast either Do you have other suggestions? TIA Regards, ...RolandKris Buelens <[EMAIL PROTECTED]> wrote: In some z/VM release, new possibilities have been added in the area of console address override. I don't know which release, but it surely already work in z/VM 4.4 Here's a summary of what you now can do - LOADPARM rdev --> starts SAPL on "rdev", there you can enter CONS=rdev to tell CP where to go and load CP - LOADPARM CONSrdev -> SAPL directly loads CP and passes CONS=rdev As rdev one can also specify SYSG to indicate the "integrated 3270 CONSOLE", very easy but first you must drag a "3270 console" icon on the icon of the LPAR in which you want to load VM. Both SAPLand CP support this console (z/OS does not), so the LOADPARM can be SYSG or CONSSYSG Similar, there is SYSC, the integrated linemode console, not supported by SAPL, so you can also enter LOADPARM CONSSYSC to directly load CP and instruct it to got to that linemode terminal. Kris,IBM Belgium, VM customer support
VSE/VSAM for VM
Hi, Back in December there was a flurry of activity here on the topic of VSE/VSAM for VM being discontinued. At the time, I, and I believe lots of others, wrote to the product owner expressing our concerns with this policy. Has anyone heard of there being any result to these comments/complaints? The VSE/VSAM web page at http://www.vm.ibm.com/related/vsevsam/ still announces: VSE/VSAM (5686-081) ends service February 28, 2007. Do we have to just assume that VSAM is dead, and drop all of our production applications that use it? Is that what all of you out there have done? I am pretty scared about that possibility... Shimon
Re: IOCP for MP2003-204
The use of SYSG as the console device is both hardware and software dependent. So you need both a SAPL utility that supports SYSG, but also a processor. I think the hardware level set for SYSG is maybe z/890 / z/990, so it's unlikely the box Roland is using supports SYSG. However, as others have said, you should certainly be able to supply one of your valid 3174 addresses via the LOADPARM override to get the system IPL'd. JR (Steven) Imler CA Senior Software Engineer Tel: +1 703 708 3479 Fax: +1 703 708 3267 [EMAIL PROTECTED] From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Kris BuelensSent: Monday, June 19, 2006 04:33 AMTo: IBMVM@LISTSERV.UARK.EDUSubject: Re: IOCP for MP2003-204 In some z/VM release, new possibilities have been added in the area of console address override. I don't know which release, but it surely already work in z/VM 4.4 Here's a summary of what you now can do - LOADPARM rdev --> starts SAPL on "rdev", there you can enter CONS=rdev to tell CP where to go and load CP - LOADPARM CONSrdev -> SAPL directly loads CP and passes CONS=rdev As rdev one can also specify SYSG to indicate the "integrated 3270 CONSOLE", very easy but first you must drag a "3270 console" icon on the icon of the LPAR in which you want to load VM. Both SAPLand CP support this console (z/OS does not), so the LOADPARM can be SYSG or CONSSYSG Similar, there is SYSC, the integrated linemode console, not supported by SAPL, so you can also enter LOADPARM CONSSYSC to directly load CP and instruct it to got to that linemode terminal. Kris,IBM Belgium, VM customer support
Re: IOCP for MP2003-204
In some z/VM release, new possibilities have been added in the area of console address override. I don't know which release, but it surely already work in z/VM 4.4 Here's a summary of what you now can do - LOADPARM rdev --> starts SAPL on "rdev", there you can enter CONS=rdev to tell CP where to go and load CP - LOADPARM CONSrdev -> SAPL directly loads CP and passes CONS=rdev As rdev one can also specify SYSG to indicate the "integrated 3270 CONSOLE", very easy but first you must drag a "3270 console" icon on the icon of the LPAR in which you want to load VM. Both SAPLand CP support this console (z/OS does not), so the LOADPARM can be SYSG or CONSSYSG Similar, there is SYSC, the integrated linemode console, not supported by SAPL, so you can also enter LOADPARM CONSSYSC to directly load CP and instruct it to got to that linemode terminal. Kris, IBM Belgium, VM customer support
Re: IOCP for MP2003-204
On 19 Jun 2006 at 1:16, Roland P. Chung wrote: > Came to the monent of truth IPL'ed VM hit the > terminal... nothing... > > After spent hours investigating and trial many different > address on the 3174, I only can figure out that VM can't > get at the 3174 because in the SYSTEM CONFIG file, it says: > > Operator_Consoles 001F 0020 0021 0022 0023 > Emergency_Message_Consoles 0020 0021 0022 0023 Isn't the VM IPL volume initialized with the SAPL? The Stand Alone Program Loader screen should come up on the terminal device supplied as the IPL Loadparm value, regardless of the contents of the SYSTEM CONFIG. (Since SAPL is *not* VM, it does not rely on the SYSTEM CONFIG file, it just "boots" VM). So.. are you using the correct value as the load parameter? Once you have the SAPL screen, you can override the console values in the SYSTEM CONFIG by typing: CONS=123 (or whatever valid address you have there) in the "parameters" section below the horizontal line on the screen. Then, when you hit PF10, VM should initialize using "123" as its IPL console. Good luck! Shimon
Re: IOCP for MP2003-204
On 6/19/06, Roland P. Chung <[EMAIL PROTECTED]> wrote: Came to the monent of truth IPL'ed VM hit the terminal... nothing... So you got a disabled wait or just sitting there with enabled wait? Did you use the LOADPARM to direct SAPL to your console and did it come up there? As far as I recall the cons= parameter on the SAPL options implies the set rdevice for it, so that should work for you. Rob -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/
