Re: cross posting urgent problem w/lvm
found the prob ...a bad sys config file entry.. mace
Re: oops
At 06:50 AM 8/7/2006, Jim Bohnsack wrote: As a junior assistant probationery trainee IBM systems engineer in a Chicago branch office, I worked on a project that needed a lot of data center machine time. I ran a benchmark for a custom at the IBM Des Plaines data center and used a 360/40 that had an unusual toggle switch on the front panel with the labeling on the switch being virtual/real. It was a few years before I understood what that meant. At that time, also, the downtown Chicago IBM data center had a 360/67 which I always used in 360/65 mode. Jim That 360/40, serial number 2040-x0002, made two outstanding contributions to IBM. After serving as the first 360 testbed for CP (CP/40), it went on to be the primary development machine for CICS! Bob Shair Open Systems Consulting Champaign, Illinois
Re: oops
If I had known about that (CICS development), maybe I would have snipped a wire or two. At that time, I was installing (separate project) a S/360/40 at different IBM Chicgo customer running FASTER, which was another, comparable online system that, I believe, was developed initially by the Kansas City police dept. It lost out to CICS, which I think was developed originally by a utility company. Jim At 07:55 AM 8/7/2006, you wrote: That 360/40, serial number 2040-x0002, made two outstanding contributions to IBM. After serving as the first 360 testbed for CP (CP/40), it went on to be the primary development machine for CICS! Bob Shair Open Systems Consulting Champaign, Illinois Jim Bohnsack Cornell Univ. (607) 255-1760
Re: oops
At 07:16 AM 8/7/2006, you wrote: If I had known about that (CICS development), maybe I would have snipped a wire or two. At that time, I was installing (separate project) a S/360/40 at different IBM Chicgo customer running FASTER, which was another, comparable online system that, I believe, was developed initially by the Kansas City police dept. It lost out to CICS, which I think was developed originally by a utility company. Jim Yes, CICS was a co-development with the Northern Indiana Public Service Company (NIPSCo). I vaguely remember FASTER from ~1968. Yet another one around this time was DUCS (the Display Unit Control System) which, IIRC, ran on DOS rather than on big OS like CICS. Bob Shair Open Systems Consulting Champaign, Illinois
Re: SYSPROF in INSTSEG
I think that the biggest reason for keeping it in a DCSS is that it is important code that you really don't want the casual user to muck around with. How many problems have we all had to dig into only to find out that there is a private copy of the XYZ EXEC on the user's a-disk that gets used instead of the one that you've got out on a common disk. Maybe it would be worthwhile to attempt to categorize execs in INSTSEG by frequency or likelihood of usage, putting the seldom used ones all together so that they will be in the page likely to be paged out. Even that, tho, given the price and quantity of real storage kind of falls into the category of bit twiddling. Do a cost benefit analysis and you'll probably find that even the cost in your time of the analysis vs. the benefit of not having three, 4k blocks of SYSPROF exec in the INSTSEG, isn't there, let alone the real cost of the storage the exec takes. This is similiar to what a marketing rep I used to work with said when he would talk about the grief to earnings ratio of something. Jim At 05:36 PM 8/5/2006, you wrote: But do you really want to bother with the effort of removing it? It would be a local mod to remove it, no big deal, but nonetheless ... Well... Way back when, I took a bunch of my heaviest local routines and put them IN the INSTSEG. So, once I set up the mod, I took SYSPROF out at the same time. I understand from your response that the problem was that everyone in the organization would be using SYSPROF *at the same time*. I guess that would make a difference. Shimon Jim Bohnsack Cornell Univ. (607) 255-1760
ESAMON Users
Hello all, I have a question regarding the use of ESAALERT. I am playing with the configuration files and trying to determine appropriate levels at which to take action, or at least start sending messages screaming to people. I'm curious as to what others have done with this. Anybody wish to offer any of their own experience? Choices? Appreciate all comments. Bob Bates Citigroup Technology Infrastructure 817-317-8033
Removing NETVIEW
Title: Removing NETVIEW Since IBM is dropping VSAM for VM we are eliminating NETVIEW on our VM systems. It has left some 'remnants' of its previous life on our VM systems. At system IPL right after the 'directory is brought online' message we see: HCPCRC8080I NETVIEW is not connected to the *LOGREC system service. HCPCRC8080I NETVALT is not connected to the *LOGREC system service. When we enter 'Q REC' we receive the following response: RECORDING COUNT LMT USERID COMMUNICATION EREP ON 002 SYSEREP ACTIVE ACCOUNT ON 020 SYSACNT ACTIVE SYMPTOM ON 002 OPERSYMP ACTIVE EREP ON 002 NETVIEW INACTIVE EREP ON 002 NETVALT INACTIVE Ready; Is there any way to remove NETVIEW from the system common area without a COLD IPL? The HCPCRC808I message seems to indicate a COLD IPL is needed. * This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies. *
Re: Removing NETVIEW
On Monday, 08/07/2006 at 10:51 AST, Smith, Ann (ISD, IT) [EMAIL PROTECTED] wrote: Since IBM is dropping VSAM for VM we are eliminating NETVIEW on our VM systems. It has left some 'remnants' of its previous life on our VM systems. At system IPL right after the 'directory is brought online' message we see: HCPCRC8080I NETVIEW is not connected to the *LOGREC system service. HCPCRC8080I NETVALT is not connected to the *LOGREC system service. When we enter 'Q REC' we receive the following response: RECORDINGCOUNT LMT USERID COMMUNICATION EREP ON 002 SYSEREP ACTIVE ACCOUNT ON 020 SYSACNT ACTIVE SYMPTOM ON 002 OPERSYMP ACTIVE EREP ON 002 NETVIEW INACTIVE EREP ON 002 NETVALT INACTIVE Ready; Is there any way to remove NETVIEW from the system common area without a COLD IPL? The HCPCRC808I message seems to indicate a COLD IPL is needed. Try CP RECORDING EREP OFF QID NETVIEW. CP is complaining because RECORDING is ON for NETVIEW, but NETVIEW isn't connected to the *LOGREC system service. CP should remember the OFF state (for warm IPLs) and not complain any more until you get around to doing a cold start. The issue for a COLD start is that the RECORDING command also creates an authorization. The cold start deletes that authorization. Alan Altmark z/VM Development IBM Endicott
Re: SYSPROF in INSTSEG
Doesn't SYSPROF execute BEFORE the user's A disk is accessed? If that's the case, no problem with them having a copy on their A disk - it will never execute ahead of the system version on MAINT 190 (or 19E). Michael Coffin, President MC Consulting Company, Inc. 57 Tamarack Drive Stoughton, Massachusetts 02072 Voice: (781) 344-9837FAX: (781) 344-7683 [EMAIL PROTECTED] www.mccci.com We employ aggressive SPAM filters. If you cannot reply or send email to mccci.com go to www.mccci.com/spamblockremove.php Click here to help fight the war on Spam! Report an unsolicited commercial email or a spamming organization. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Jim Bohnsack Sent: Monday, August 07, 2006 8:28 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: SYSPROF in INSTSEG I think that the biggest reason for keeping it in a DCSS is that it is important code that you really don't want the casual user to muck around with. How many problems have we all had to dig into only to find out that there is a private copy of the XYZ EXEC on the user's a-disk that gets used instead of the one that you've got out on a common disk. Maybe it would be worthwhile to attempt to categorize execs in INSTSEG by frequency or likelihood of usage, putting the seldom used ones all together so that they will be in the page likely to be paged out. Even that, tho, given the price and quantity of real storage kind of falls into the category of bit twiddling. Do a cost benefit analysis and you'll probably find that even the cost in your time of the analysis vs. the benefit of not having three, 4k blocks of SYSPROF exec in the INSTSEG, isn't there, let alone the real cost of the storage the exec takes. This is similiar to what a marketing rep I used to work with said when he would talk about the grief to earnings ratio of something. Jim At 05:36 PM 8/5/2006, you wrote: But do you really want to bother with the effort of removing it? It would be a local mod to remove it, no big deal, but nonetheless ... Well... Way back when, I took a bunch of my heaviest local routines and put them IN the INSTSEG. So, once I set up the mod, I took SYSPROF out at the same time. I understand from your response that the problem was that everyone in the organization would be using SYSPROF *at the same time*. I guess that would make a difference. Shimon Jim Bohnsack Cornell Univ. (607) 255-1760
Re: Updated Community VM Redbook outline posted
The problem is that IE ignores the content-type header. In Windows Help search for - 258452 In which the cause is described as - 'Internet Explorer is RFC compliant, but does not take into account some deviations that are allowed within the specification' Sounds like a fancy way to say the programmers didn't read all the specs. David Boyes wrote: Still horked. LOL - I like that word...nice ring to it. Hmph. The file is fine, and Firefox can retrieve it fine, just not IE. For now, download it to local disk (right click and save it) and open it from there. I'll track down what's going on later this evening, but you can still get the file to read on the plane. *** PLEASE NOTE: This internet email message has been checked for viruses and appropriate content to ensure it complies with TABCORP's electronic communication policy. *** .. For: [EMAIL PROTECTED] -- Chris Langford, Cestrian Software: Consulting services for: VM, VSE, MVS, z/VM, z/OS, OS/2, P/3x0 etc. z/FM - A toolbox for VM MVS at http://zfm.cestrian.com Deva Woodcrafting: Furniture creation, House remodeling, Wagon restoration etc.
Re: Signal support
Title: RE: Signal support I am waiting breathlessly. Has the highly-placed and respected person at VSE developement responded, and cleared the air? -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU]On Behalf Of Alan Altmark Sent: Thursday, August 03, 2006 11:01 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Signal support On Thursday, 08/03/2006 at 11:30 AST, Wakser, David [EMAIL PROTECTED] wrote: A previous post mentioned that the only way the facility could be enabled in VSE was through a special PTF that IBM had provided to one customer. Now the question is: why did he need that PTF? This whole matter seems poorly documented from the VSE side. A highly-placed and respected person in VSE Development is investigating to find out what's going on. If all goes acccording to plan, I should have an answer tomorrow. BTW, that previous post was over in VSE-L. Very confusing. :-) Alan Altmark z/VM Development IBM Endicott __ 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: Signal support
Title: RE: Signal support Only breathlessly? EMS had to come to revive my blue-toned face multiple times over the weekend! :) David Wakser From: Huegel, Thomas [mailto:[EMAIL PROTECTED] Sent: Monday, August 07, 2006 11:58 AMTo: IBMVM@LISTSERV.UARK.EDUSubject: Re: Signal support I am waiting breathlessly. Has the highly-placed and respected person at VSE developement responded, and cleared the air? -Original Message- From: The IBM z/VM Operating System [mailto:IBMVM@LISTSERV.UARK.EDU]On Behalf Of Alan Altmark Sent: Thursday, August 03, 2006 11:01 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Signal support On Thursday, 08/03/2006 at 11:30 AST, "Wakser, David" [EMAIL PROTECTED] wrote: A previous post mentioned that the only way the facility could be enabled in VSE was through a special PTF that IBM had provided to one customer. Now the question is: why did he need that PTF? This whole matter seems poorly documented from the VSE side. A highly-placed and respected person in VSE Development is investigating to find out what's going on. If all goes acccording to plan, I should have an answer tomorrow. BTW, that "previous post" was over in VSE-L. Very confusing. :-) Alan Altmark z/VM Development IBM Endicott __ 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 Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or "Protected Health Information," within the meaning of the regulations under the Health Insurance Portability & Accountability Act of 1996. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you.
WAS on zSeries
Does anyone know where I can get a trial version of Websphere App Server for Linux on zSeries machine? I have version 5 (and 5.0.2) but I was wanting something a little more current. It would need to be 64bit Thanks, Steve
Re: Signal support
On Monday, 08/07/2006 at 10:58 EST, Huegel, Thomas [EMAIL PROTECTED] wrote: I am waiting breathlessly. Has the highly-placed and respected person at VSE developement responded, and cleared the air? This just in... Yes, VSE did briefly add registration for the LPAR deactivation signal (SIGNAL SHUTDOWN), but the implementation was incomplete and created other problems. In particular, VSE doesn't load the shutdown complete PSW, causing LPAR deactivation to delay 5 minutes. The support has been removed. If you need the support, work with your fave user group or the Support Center to get a requirement opened. If your need is urgent, you *may* be able to get the enablement fix, but it isn't supported. Those who have the fix already know they are on their own. And that's the way it is Alan Altmark z/VM Development IBM Endicott
Re: Programmable Operator: The epic conclusion
Tomangle Terry Pratchett, a one-in-a-million-chance will come through nine times out of ten. Jon snip I have an entry in the RTABLE to look for NOT in positions 10 thru 13. The last three letters of the file name just so happen to be in 10 thru 13. What are the chances? /snip
Re: SYSPROF in INSTSEG
You're right. I forgot about that, altho I still hold that going to the bother of removing SYSPROF from INSTSEG is bit-twiddling. Jim At 11:43 AM 8/7/2006, you wrote: Doesn't SYSPROF execute BEFORE the user's A disk is accessed? If that's the case, no problem with them having a copy on their A disk - it will never execute ahead of the system version on MAINT 190 (or 19E). Michael Coffin, President MC Consulting Company, Inc. 57 Tamarack Drive Stoughton, Massachusetts 02072 Voice: (781) 344-9837FAX: (781) 344-7683 [EMAIL PROTECTED] www.mccci.com We employ aggressive SPAM filters. If you cannot reply or send email to mccci.com go to www.mccci.com/spamblockremove.php Click here to help fight the war on Spam! Report an unsolicited commercial email or a spamming organization. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Jim Bohnsack Sent: Monday, August 07, 2006 8:28 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: SYSPROF in INSTSEG I think that the biggest reason for keeping it in a DCSS is that it is important code that you really don't want the casual user to muck around with. How many problems have we all had to dig into only to find out that there is a private copy of the XYZ EXEC on the user's a-disk that gets used instead of the one that you've got out on a common disk. Maybe it would be worthwhile to attempt to categorize execs in INSTSEG by frequency or likelihood of usage, putting the seldom used ones all together so that they will be in the page likely to be paged out. Even that, tho, given the price and quantity of real storage kind of falls into the category of bit twiddling. Do a cost benefit analysis and you'll probably find that even the cost in your time of the analysis vs. the benefit of not having three, 4k blocks of SYSPROF exec in the INSTSEG, isn't there, let alone the real cost of the storage the exec takes. This is similiar to what a marketing rep I used to work with said when he would talk about the grief to earnings ratio of something. Jim At 05:36 PM 8/5/2006, you wrote: But do you really want to bother with the effort of removing it? It would be a local mod to remove it, no big deal, but nonetheless ... Well... Way back when, I took a bunch of my heaviest local routines and put them IN the INSTSEG. So, once I set up the mod, I took SYSPROF out at the same time. I understand from your response that the problem was that everyone in the organization would be using SYSPROF *at the same time*. I guess that would make a difference. Shimon Jim Bohnsack Cornell Univ. (607) 255-1760 Jim Bohnsack Cornell Univ. (607) 255-1760
Re: Signal support
If somebody wants to write up a WAVV requirement, I would vote for it. [EMAIL PROTECTED] wrote: This just in... Yes, VSE did briefly add registration for the LPAR deactivation signal (SIGNAL SHUTDOWN), but the implementation was incomplete and created other problems. In particular, VSE doesn't load the shutdown complete PSW, causing LPAR deactivation to delay 5 minutes. The support has been removed. If you need the support, work with your fave user group or the Support Center to get a requirement opened. If your need is urgent, you *may* be able to get the enablement fix, but it isn't supported. Those who have the fix already know they are on their own. And that's the way it is Alan Altmark z/VM Development IBM Endicott -- Stephen Frazier Information Technology Unit Oklahoma Department of Corrections 3400 Martin Luther King Oklahoma City, Ok, 73111-4298 Tel.: (405) 425-2549 Fax: (405) 425-2554 Pager: (405) 690-1828 email: stevef%doc.state.ok.us
Re: Removing NETVIEW
Since IBM is dropping VSAM for VM we are eliminating NETVIEW on our VM systems. Netview has me confused. I also was under the impression that it required VSAM (I remember all the VSAM work I had to do in order to get it up and running), but, in spite of the demise of VSAM, I still see on the VM LP Matrix Documentation Updates (for 5.2), at http://www.vm.ibm.com/techinfo/lpmigr/vml04276.html , the following statement: * Removed End of Service from Netview V2 for VM/ESA V2.3.0. This product is still supported. That's great news, but... how can it be supported without VSAM? Shimon * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Shimon Lebowitz mailto:[EMAIL PROTECTED] Jerusalem, IsraelPGP: http://www.poboxes.com/shimonpgp * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Re: SYSPROF in INSTSEG
On Mon, 7 Aug 2006 11:43:13 -0400 Michael Coffin said: Doesn't SYSPROF execute BEFORE the user's A disk is accessed? If that's the case, no problem with them having a copy on their A disk - it will never execute ahead of the system version on MAINT 190 (or 19E). Actually, SYSPROF accesses the A filemode, either SFS directory or 191. If I was pedantic, I would say No, it doesn't execute BEFORE, since SYSPROF doesn't complete until after the ACCESS, but the intent is yes, the A filemode isn't available when the SYSPROF starts. However, you probably could take the opposite approach, and remove the SYSPROF from the S-disk and only keep it in the INSTSEG. Then you just have to resave the INSTSEG to change it, not resave CMS to save the SSTAT. What happens when you purge your INSTSEG is left as an exercise for the reader. Michael Coffin, President /ahw
