Re: performance question
Huegel, Thomas <[EMAIL PROTECTED]> writes: Thank you, I better understand your problem. There is no trivial way I know of to break this apart as you would like. My best suggestion is: - isolate this processing to a TCP/IP stack that does this alone - use either SCEXIT or cons logs to track rate of dial/drop. - record total usage of the TCP/IP stack from Performance Toolkit - correlate the CPU to dial/drop rate to get an average cost of cost in the TCP/IP stack - you could also perhaps create a dummy guest for test purposes and measure that part of it without skewing from other work. Ugly, but all I have to offer. And would give you ballpark numbers. Not sure you need any significant precision. Bill Bitner - VM Performance Evaluation - IBM Endicott - 607-429-3286
Re: performance question
Title: RE: performance question Bill, I wasn't concerned with just the SCEXIT itself, if I thought that was the issue I would rewrite it in assembler. I was interested in the whole DIAL/DROP path. From the time TCP/IP first saw the connection until VSE/VTAM saw the terminal and how much overhead there was to keep dialing and dropping the same terminal. Then my next step will be to try and find what goes on in VSE with VTAM, CICS autoinstalls, lostterm clean ups ... Tom -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU]On Behalf Of Bill Bitner Sent: Thursday, October 12, 2006 3:31 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: performance question Huegel, Thomas <[EMAIL PROTECTED]> writes: Tom, I'm not sure I completely follow the question. I am not aware of any way to get just the cost of the SCEXIT from existing data. You could at least bound it by looking at total costs in the TCP/IP stack machine to understand what the costs may be. One thought is to add something to the exit that grabs perhaps QUERY TIME or something before at entering and leaving the exit. Bill Bitner - VM Performance Evaluation - IBM Endicott - 607-429-3286 __ << 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: performance question
Huegel, Thomas <[EMAIL PROTECTED]> writes: Tom, I'm not sure I completely follow the question. I am not aware of any way to get just the cost of the SCEXIT from existing data. You could at least bound it by looking at total costs in the TCP/IP stack machine to understand what the costs may be. One thought is to add something to the exit that grabs perhaps QUERY TIME or something before at entering and leaving the exit. Bill Bitner - VM Performance Evaluation - IBM Endicott - 607-429-3286
Re: Business case for restoring the PWD Flex license
David, while I was once the relationship manager between FSI and IBM (working for IBM), I can only guess based on that history, what might be going on in either company. I'm sure you already realize this is a very complex situation between two companies coming to terms with a number of issues and a multitude of options. Unfortunately for all of us, the PWD program wound up in the middle. First, I am certain that FSI would continue their support of the PWD program, if they felt comfortable in doing so. They have worked with IBM and the PWD resellers to provide several hundred licenses in support of that program, which seems to have been a success. Apparently, FSI now feels a degree of risk due to the expiration of certain IBM patents on 11/1 along with some agreements that are dated.. (Note: This was covered in some detail on the FLEX LISTSERV..) Conversely, IBM owns the patents, approves zArch licenses for PWD use, and simply expects FSI to continue delivering them via PWD resellers (Cornerstone and T3) for distribution to the PWD members. It seems a simple enough matter to resolve and we all hope that will happen some time soon at least by November. I suspect that both IBM and FSI are working hard to resolve the issues before them. Unfortunately, we can't predict that an agreement will be reached any time soon. For this reason Steve Friedman (T3) and I have been notifying partners of the pending end date. Hopefully, IBM and FSI will reach an agreement that benefits us all. Whatever the outcome, Cornerstone intends to continue support for our PWD customers. Regards, Len Diegel VP IBM zSeries & zFrame Solutions Cornerstone Systems Inc.
AW: JDBC and DB2/VM
You need to use the db2 "connect". The normal drivers for db2 does not support connects to a vm database. -Ursprüngliche Nachricht- Von: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Im Auftrag von Alan Ackerman Gesendet: Sonntag, 8. Oktober 2006 07:17 An: IBMVM@LISTSERV.UARK.EDU Betreff: Re: JDBC and DB2/VM I'm afraid we've only got DB2 Connect on a PC to work with DB2/VM (7.4 and earlier). Are you using DB2 Connect? I don't know if anyone is using JDBC or not. On Fri, 6 Oct 2006 16:16:26 -0400, Henry Wilusz <[EMAIL PROTECTED]> wrote: >Hello >Just a short question to see if anyone has gotten JDBC drivers on a >windows machine to successfully access DB2/VM. We know that the >drivers work with DB2/universal. but fail miserably with DB2/VM. >DB2/VM is at version 7.2 The attempt to access DB2/VM returns a >authorization failure message to the windows machine (incorrect message >there) and a data capture dump on DB2/VM. > >The reason for exploring the JDBC angle is that ODBC connections to >this database sometimes hang with no error messages, and we cannot seem >to reproduce the hang conditions. > >An interesting part of the DB2 dump is below. Note that the probable >cause section does not tell what the unsupported value was that it is >trying to deal with.DDM VALUE > >SYMPTOM STRING:MS/ARI2909I PIDS/5697F4201 RIDS/ARITPAC PRCS/11 > >PROBABLE CAUSE OF FAILURE: >DDM VALUE NOT SUPPORTED > > >If anyone has gotten cold fusion or JDBC to work to DB2/VM, and is >willing to share the secrets, I would like to hear from them > >thanks > >Henry Wilusz >[EMAIL PROTECTED] > >Failure is not an option . . . . . >. . . . . It comes standard with windows >=== ==
Re: Trapping output of VTAM Commands from a GCS Routine
On Thursday, 10/12/2006 at 11:49 AST, "Stracka, James (GTI)" <[EMAIL PROTECTED]> wrote: > I wanted to simulate the output from: D NET,ROUTE,BLOCKED > On a VM/VTAM session using VM:Operator. This rather than require us to > logon to NetView to issue an NCCFLST command. Since D NET,ROUTE,BLOCKED > is not a valid VM/VTAM command. "GETBLOCK " and generate output equivalent to D NET,ROUTE,DESTSUB=nn,BLOCKED? Well, you can use the SPO to issue the D NET,ROUTE,DESTSUB=nnn and you are free to massage the output to your heart's content! (I wouldn't want to do it) Alan Altmark z/VM Development IBM Endicott
Re: Trapping output of VTAM Commands from a GCS Routine
Dave, I think I used VTAMOP at in a prior life. Trying to assemble VTAMOP has been a problem trying to find the MACLIBs: CSISP and DMKSP. I thing I found their replacements and will give it a shot. Thank you, Jim -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Dave Wade Sent: Wednesday, October 11, 2006 3:14 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Trapping output of VTAM Commands from a GCS Routine --- "Stracka, James (GTI)" <[EMAIL PROTECTED]> wrote: > I know that this can be done in a NETVIEW NCCFLST > but I would like to do > this as a VM/VTAM GCS routine. > > Can EXECIO or PIPE, or some other function, be run > in a GCS routine in > VMVTAM to trap the output of a command such as: > > d route,destsub=02 > I know this used to work in SP5 GCS. Not sure if its any use in a modern GCS. http://vm.marist.edu/~vmshare/browse?fn=VTAMOP&ft=NOTE but it kind of does all this sort of things Dave __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/
Re: Trapping output of VTAM Commands from a GCS Routine
I wanted to simulate the output from: D NET,ROUTE,BLOCKED On a VM/VTAM session using VM:Operator. This rather than require us to logon to NetView to issue an NCCFLST command. Since D NET,ROUTE,BLOCKED is not a valid VM/VTAM command. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Wednesday, October 11, 2006 4:14 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Trapping output of VTAM Commands from a GCS Routine On Wednesday, 10/11/2006 at 11:02 AST, "Stracka, James (GTI)" <[EMAIL PROTECTED]> wrote: > I know that this can be done in a NETVIEW NCCFLST but I would like to > do this > as a VM/VTAM GCS routine. > > Can EXECIO or PIPE, or some other function, be run in a GCS routine in VMVTAM > to trap the output of a command such as: > > d route,destsub=02 The way you do this in GCS is exactly the way NetView does it: by using a "secondary programmed operator" ACB (APPL AUTH=SPO) to talk to VTAM and get responses. An example of such a program is VTAMOP, a VTAM/GCS application written by Bob Pesner back in the 80s and published on VMSHARE. The nice thing was that it accepted SMSGs, could handle simultaneous commands from multiple users, and you could apply your own authorizations. A copy is available in the VMSHARE archives at http://vm.marist.edu/~vmshare/browse?fn=VTAMOP&ft=NOTE. Not knowing what you want to do with the output (hand to human, process by program, ...), it's somewhat difficult to know whether VTAMOP is what you need. Alan Altmark z/VM Development IBM Endicott
performance question
Title: performance question Good morning everyone. I have a little performance question to pose this morning. This is sort of related to the thread 'VTAM Cross Domain problem/question'. We have an application that 'webifies' the look of some CICS screens. The app runs on a wintell server somewhere that connects the session via TCP/IP to the Z/890. My VM-TCPIP uses the SCEXIT (REXX not assembler) to DAIL to a VSE/VTAM. After every CICS transaction the session gets DROPPED. When looking at my log I see ten's of thousands of DIAL/DROPPED messages per day. Here is the question: From the z/VM standpoint how bad is this? Where (in either VMPERFTK or ESAMON) can I find stats to backup my assumption that this is not good? Thanks Tom __ << 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: Real core
On Wed, 11 Oct 2006 10:28:07 -0500, Tom Duerbusch <[EMAIL PROTECTED]> wrote: >So I guess the question I'm wondering... > >How many others have shipped dumps, online, back before high speed >Internet connections? Why send the entire dump when they're only going to look at a tiny fraction of it? On multiple occasions I did it live over the phone with the support center. They said what they wanted to look at and I read it out to them. So that's "on line" in one sense. We shipped tapes too, but not for the problems that were easy to diagnose . Brian Nielsen
Re: Use of VMSES/E SERVICE EXEC w/ CP Modifications
Us too. It's safe. Marcy Cortes "This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation." From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Steve Gentry Sent: Thursday, October 12, 2006 8:16 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Use of VMSES/E SERVICE EXEC w/ CP Modifications Same here. Steve G, "O'Brien, Dennis L" Sent by: The IBM z/VM Operating System 10/11/2006 07:18 PM Please respond to The IBM z/VM Operating System To:IBMVM@LISTSERV.UARK.EDU cc: Subject:Re: Use of VMSES/E SERVICE EXEC w/ CP Modifications Dennis, It's safe to use SERVICE and PUT2PROD on a system that has VM:Secure Rules installed. I do it all the time. Dennis O'Brien
Re: Use of VMSES/E SERVICE EXEC w/ CP Modifications
Same here. Steve G, "O'Brien, Dennis L" Sent by: The IBM z/VM Operating System 10/11/2006 07:18 PM Please respond to The IBM z/VM Operating System To: IBMVM@LISTSERV.UARK.EDU cc: Subject: Re: Use of VMSES/E SERVICE EXEC w/ CP Modifications Dennis, It's safe to use SERVICE and PUT2PROD on a system that has VM:Secure Rules installed. I do it all the time. Dennis O'Brien There are 10 kinds of people in the world; those that understand binary and those that don't. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Dennis Schaffer Sent: Wednesday, October 11, 2006 16:08 To: IBMVM@LISTSERV.UARK.EDU Subject: [IBMVM] Use of VMSES/E SERVICE EXEC w/ CP Modifications Hi, We have historically used the VMSES/E SERVICE EXEC to install RSU and COR service to the Starter System during our initial z/VM installations. Shortly after the Starter System has reached our desired level of maintenance, we implement CP usermods in support of CA's VM:Secure Rules facility. That consists of replacing object decks for six CP modules with versions supplied by CA. We use the official VMSES techniques (VMFREPL, VMFBLD) to replace those CP modules and rebuild the CP nucleus. Thereafter, we avoid use of the SERVICE EXEC to install subsequent CP maintenance because I recall that SERVICE only works on an "unmodified" (whatever that means) VM system. We've used VMFREC, VMFMRDSK, VMFAPPLY, VMFBLD, etc.) to install subsequent maintenance. I've tried to find documentation on what sort of modifications are supported in order to continue using SERVICE and I'm unable to find that documentation. Can anyone point me to any documentation which describes the limitations of SERVICE EXEC w/ modified VM systems? Alternatively, can anyone tell me if its safe to use SERVICE with the usermods I've described? I suspect I'm being too conservative and maybe I can continue to use SERVICE but I want to be certain. Thanks in advance for any information you can provide, Dennis Schaffer Mutual of Omaha
Re: Business case for restoring the PWD Flex license
Try IBM/Jim Bishop at [EMAIL PROTECTED].. Sharon Chen GM & Founder CSL International LTD From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of David Boyes Sent: Wednesday, October 11, 2006 9:09 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Business case for restoring the PWD Flex license As some of you might know, IBM and Fundamental Software have not been able to agree on renewing the PWD access to the zArchitecture-capable version of Flex-ES. While I understand that IBM has made this decision on what they believe to be a valid business case, several of my customers who do PWD development have asked if there are any opportunities to attempt to help IBM understand why this may be a mistake. Does anyone know who within IBM would be the correct address to begin this discussion? David Boyes Sine Nomine Associates
Re: DFSMS and SFS
>There is a bypass (I think). Store a UCOMDIR NAMES file on the A-disk of >DFSMS servers. In this file, you aasign a nickname to a filepool: > :nick.VMSYS :tpn.MYPOOL >Note: to activate this, the easiest way it to IPL CMS > I tried this and it appears it will work (at least I received the message the filepool was unavailable). Ira, give this a try and let us know if it works. If it does, I will have the RMS book updated to reflect how the hardcoded directory name can be changed. Best Regards, Les Geer IBM z/VM and Linux Development
Re: bandwidth of a swallow (was: Real core)
Paul B. Nieman wrote: > In the early 1990's we consolidated a data center from Sydney into > Philadelphia. We used SYBACK to do a full dump of specific (most) > minidisks to tape and shipped the tapes. We then performed daily > incrementals to disk, and sent the incrementals via RSCS, via a 9600 > baud line at most. I think we had a 9600 baud line that was shared > for RSCS and VTAM traffic, but the telecom part wasn't mine to worry > over. Each minidisk intended to move was a separate file and sent via > SENDFILE. There were service machines written to send and receive > them. I think the first incrementals arrived before the tapes. In > any case, we kept track of different day's incrementals for a whole > week and applied them as they finished arriving. The line was kept > very busy and watched closely, but it was easy to restart if it > dropped. > > Our actual cutover the following weekend went fairly quickly and met > whatever target we had, which I certainly think wasn't enough to allow > for backing up, shipping, and applying the tapes. in the later part of the mid-70s, one of the vm370 based commercial time-sharing services had datacenter on the east coast and put in datacenter on the west coast connected via 56kbit link. the had enhanced vm370 to support process migration between loosely-coupled machines in the same datacenter cluster ... i.e. for one thing, as they moved to 7x24 worldwide service ... there was no window left for doing preventive maintenance. process migration allowed them to move everything off a complex (that needed to be taken down for maint). the claim was that they could even do process migration over the 56kbit link ... modulo most of the file stuff having been replicated (so that there wasn't a lot needing movement in real time). misc. past posts mentioning vm time-sharing service http://www.garlic.com/~lynn/subtopic.html#timeshare they had also implemented page mapped filesystem capability with lots of advanced bells and whistles ... similar to the cms page mapped filesystem stuff that i had originally done in the early 70s for cp67. http://www.garlic.com/~lynn/subtopic.html#mmap which also included a superset of the memory segment stuff ... a small subset was later released as DCSS http://www.garlic.com/~lynn/subtopic.html#adcon for other drift ... as mentioned before ... the internal network was larger than the arpanet/internet from just about the beginning until around sometime mid-85. misc. posts mentioning internal network http://www.garlic.com/~lynn/subnetwork.html#internalnet one of the issues was what to do about JES2 nodes on the internal network. one of the issues was that relatively trivial changes in JES2 headers between releases would precipitate JES2 (& MVS) system crashes. for that reason (and quite a few others), JES2 nodes were pretty well limited to a few boundary nodes. A library of vnet/rscs line drivers grew up for JES2 that supported a cannonical JES2 header format ... and the nearest VNET/RSCS node would have the specific line-driver started that would make sure that all JES2 headers sent to the JES2 system ... met the requirements of that specific JES2 version/release. Sporadically, there were still some (infamous) cases where JES2 systems on one side of the world would precipitate JES2 systems on the other side of the world to crash (one particular well known case was JES2 systems in san jose causing JES2/MVS systems in hursley to crash). misc. past posts mentioning hasp &/or jes2 http://www.garlic.com/~lynn/subtopic.html#hasp Another scenario was there was some work to do load-balancing offload between STL/bld90 and Hursley around 1980 (since they were offset by a full shift). the test was between two jes2 systems (carefully checked to be at compatible release/version) ... over a double-hop 56kbit satellite link (i.e. up from west coast to satellite over the us, down to the east coast, up to satellite over the atlantic, down to UK). JES2 couldn't make connection ... but all error indicators were clean. So finally it was suggested to try the link between two vnet systems. The link came up and ran with no problem. The person overseeing the operations was extremely sna/vtam indoctrinated. So the first reaction was what ever caused the problem went away. So it was time to switch it back between JES2 ... it didn't work. Several more switches were made ... always ran between VNET, never ran between JES2. The person overseeing the operation finally declared that the link actually had severe error problems but the primitive VNET drivers weren't seeing them ... and only the advanced VTAM error analysis was realizing there was lots of errors. it turned out the problem was with the double-hop satellite roundtrip (four hops, 44k miles per hop, 22k-up, 22k-down) propogation delay ... which VNET tolerated and vtam/jes2 didn't (not only was the majority of the internal network not jes2 ... it was also not sna/vtam)
Re: DFSMS and SFS
If anyone tries this bypass please post whether it works. This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system. From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Kris Buelens Sent: Thursday, October 12, 2006 12:42 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DFSMS and SFS There is a bypass (I think). Store a UCOMDIR NAMES file on the A-disk of DFSMS servers. In this file, you aasign a nickname to a filepool: :nick.VMSYS :tpn.MYPOOL Note: to activate this, the easiest way it to IPL CMS Kris, IBM Belgium, VM customer support The IBM z/VM Operating System wrote on 2006-10-11 19:27:30: > >We are currently running z/VM 5.1 with the RMS (Removable Media Services) > >feature of DFSMS. We are using the default system SFS (Shared File System) > >that comes with the base system. (VMSERVR, S, U). I want to install DFSMS in > >my local SFS however Chapter 2 of the install instructions says that the > >control file and config file must reside on the VMSYS:DFSMS.CONTROL SFS > >directory which is VMSERVS. Does anyone know how to get around this > >requirement? > Unfortunately no, the DFSMS/VM code was written to look for the > control file in that particular directory without providing a way > to change it. You could do an alias, however the files would still > need to be in a directory within the VMSYS: filepool. > Best Regards, > Les Geer > IBM z/VM and Linux Development
Sending Dumps (was Re: Real core)
Continuing a discussion started on VMESA and now cross posted on VSE-L. I remember sending a printed dump of the DOS Release 18 Supervisor back in 1968 via Greyhound Bus. And that reminds me of the User Manual for the original Westinghouse Disk Backup/Restore Utility. It had a very large and humorous section on sending dumps to IBM. I remember laughing out loud when I read it. This manual was the most verbose and humorous I have ever read. I regret that I didn't keep it. I have Googled for it and checked bitsavers.org but no luck. Does anyone else have fond memories of this manual? /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"
Re: Real core
Tom Duerbusch <[EMAIL PROTECTED]> wrote: >How many others have shipped dumps, online, back before high speed >Internet connections? This is the inverse, or maybe the perverse: In 1990 or so, we had a distributor in Europe. A customer took a database ABEND and was very unhappy. I was in Manhattan that day speaking 4x at MVMUA, and over lunch called the office (pre-cellphone!) and heard about the crisis. "We might need you to come back immediately", I was told. "Um...that makes no sense: I need the dump. Get them to overnight it and I'll be back tonight, will look at it tomorrow." So the next day, FredEks (or more likely DHL) delivers a too-large, too-heavy box. I open it...and find a paper dump! The lucky part was, I was able to find an overlay in page 0, so I was able to diagnose it impressively quickly... ...phsiii
