Re: DMSITP143T.... CONWAIT
z/VM went to production November 2007. Do know when the upgrade for Focus will happen. -Original Message- From: Bill Munson william.mun...@bbh.com Sent: Jul 23, 2009 6:37 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: DMSITP143T CONWAIT Jan, How long have you been on z/VM 5.3 ? FOCUS users on CMS 22 and above need more storage, you are on CMS 23. You probably need to increase the storage of each user from probably 4 maybe 7m to 12m of storage USER FOCUSUSR 12M 16M G If you have FOCUS users that have been around a long time they may still have only 4m of storage and if they just got around to creating a big TABLE or REPORT they probably ran out of storage good luck Bill Munson Sr. z/VM Systems Programmer Brown Brothers Harriman CO. 525 Washington Blvd. Jersey City, NJ 07310 201-418-7588 President MVMUA http://www2.marist.edu/~mvmua/ Jan Canavan canav...@earthlink.net Sent by: The IBM z/VM Operating System IBMVM@LISTSERV.UARK.EDU 07/22/2009 10:13 PM Please respond to canav...@earthlink.net To IBMVM@LISTSERV.UARK.EDU cc Subject DMSITP143T CONWAIT Has anyone run across this error with Focus and CMS? I'm told this has been running fine since 1998. z/VM 5.3 Focus Database Management/Query System Information Builders Install level =7.08R,7.11 DMSITP143T Specification exception occurred at 030C in system routine CONWAIT; re-IPL CMS HCPGIR450W CP entered; disabled wait PSW 000A 80F3F692 Jan Canavan canav...@earthlink.net VSE/VM SYSTEMS PROGRAMMER *** IMPORTANT NOTE* The opinions expressed in this message and/or any attachments are those of the author and not necessarily those of Brown Brothers Harriman Co., its subsidiaries and affiliates (BBH). There is no guarantee that this message is either private or confidential, and it may have been altered by unauthorized sources without your or our knowledge. Nothing in the message is capable or intended to create any legally binding obligations on either party and it is not intended to provide legal advice. BBH accepts no responsibility for loss or damage from its use, including damage from virus. Jan Canavan canav...@earthlink.net VSE/VM SYSTEMS PROGRAMMER
DMSITP143T.... CONWAIT
Has anyone run across this error with Focus and CMS? I'm told this has been running fine since 1998. z/VM 5.3 Focus Database Management/Query System Information BuildersInstall level =7.08R,7.11 DMSITP143T Specification exception occurred at 030C in system routine CONWAIT; re-IPL CMS HCPGIR450W CP entered; disabled wait PSW 000A 80F3F692 Jan Canavan canav...@earthlink.net VSE/VM SYSTEMS PROGRAMMER
[no subject]
query ibmvm Jan Canavan canav...@earthlink.net VSE/VM SYSTEMS PROGRAMMER
Re: IBM LINK Web Site.
Go here: https://www-304.ibm.com/usrsrvc/account/userservices/jsp/login.jsp?persistPage=true and there is a point to register and see if this helps -Original Message- From: Howard Rifkind <[EMAIL PROTECTED]>Sent: Jun 5, 2008 12:51 PM To: IBMVM@LISTSERV.UARK.EDU Subject: IBM LINK Web Site. All the organization I've worked for who had mainframes have all had IBMLink access (contracts) Unfortunately we don't have that now and I was wondering if IBMLink has some sort of free access level where you don't need a contract. All I need is to get the latest update for DIRMAINT...and look at the buckets. I there any IBM web site I can go to and register for free access even at a minimal level. Thanks. _LEGALNOTICEUnlessexpresslystatedotherwise,thismessageisconfidentialandmaybeprivileged.Itisintendedfortheaddressee(s)only.AccesstothisE-mailbyanyoneelseisunauthorized.Ifyouarenotanaddressee,anydisclosureorcopyingofthecontentsofthisE-mailoranyactiontaken(ornottaken)inrelianceonitisunauthorizedandmaybeunlawful.Ifyouarenotanaddressee,pleaseinformthesenderimmediately,thendeletethismessageandemptyfromyourtrash. Jan Canavan [EMAIL PROTECTED] VSE/VM SYSTEMS PROGRAMMER
Problem with stacked ddr tape and possible DYNAM
We have z/VM5.3, with an IBM 3494 tape library system running RMSMASTER (DFSMS), AND DYNAM. We are doing a stacked DDR tape switch 4 volumes on it. On the 4th tape we get: Tape 0590 given to DYNAMVM 0590 11:25:33 CADT822I DSN=DDR.XX.530W02.3 IS FILE NO. 3 THERE ARE ONLY 1 FILES ON TAPE 050094 CADT713E OPEN REQUEST FOR DDNAME DDROUT CANCELLED +++ RC(84) +++ 71 *-* 'CP Q T' CP Q T -- What we get on the previous volumes are: Tape 0590 given to DYNAMVM 0590 Tape 0181 attached 11:22:13 CADT831I *CLOSED* DDRWKLY 0590 050094 DDR.XX.530W01.2 -- You don’t see the TAPE 181 ATTACHED. If you add sleep of 180 seconds, or you put a trace in it works. DYNAM support cannot reproduce the problem. Anybody else had trouble with this? Jan Canavan [EMAIL PROTECTED] VSE/VM SYSTEMS PROGRAMMER
Looking for the VM WAVV presentations
I believe that IBM puts their presentations on their site. I found the VSE ones, but I don't found the one for VM. Even the WAVV site points you to the VSE side of things. I'm looking for the one that was for the HMC and setting up the profiles where you can see your machines. It was with the zVM5.3 tia Jan Canavan [EMAIL PROTECTED] VSE/VM SYSTEMS PROGRAMMER
Re: listing active user directory
My method. A. I always rename the user direct to user dirmmddyy copy user dirmmddyy to user direct make changes. I keep so many backups Your option on how many. # of months or items B. I log on as the new user and format the disk as them. -Original Message- From: LOREN CHARNLEY [EMAIL PROTECTED] Sent: Mar 10, 2008 8:40 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: listing active user directory z/VM has come with the directory defaulting to MAINT 2c2 disk accessed as c. I have always left it there because the 191 disk has too many accesses and changes. It seem to me that if you leave the directory on 2c2 it would less vulnerable to an accidental deletion or in my case, it would result in one less hole in my foot! Loren Charnley, Jr. IT Systems Engineer Family Dollar Stores, Inc. (704) 847-6961 Ext. 3327 (704) 814-3327 [EMAIL PROTECTED] -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Kris Buelens Sent: Monday, March 10, 2008 10:33 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: listing active user directory We've got MAINT B91 as backup of MAINT 191 since the VM/SP days. Our DIRBKP EXEC keep the last 9 levels of the CP directory there, as well as SYSTEM CONFIG; the result of a QUERY DASD and Q ALLOC. DIRBKP does not only maintain these backups but also performs some checks each night such as: is MDISK MAINT 298 (i.e. VTAM) still in the directory. Additionally, the 9 copies of the directory co are also copied to a central SFS: so when a system is down due to disk errors, we know what is lost (touching wood: didn't need this for more than 10 years). 2008/3/10, Mike Walter [EMAIL PROTECTED]: Maybe it would be better to keep the USER DIRECT file (or whatever you're using as the source directory) off the 191 disk altogether, placing it on a separate disk, and at known address? Known address could be defined in two parts: 1) Perhaps at cylinder 1 of a particular volser that you know and love (and can remember in a crisis)? 2) A new MAINT MDISK, maybe 5DD (following VMSES/E's convention of the '5' looking a bit like an 'S' when one squints ones eyes - the 5DD reminds one of the SDD or 'S'ource 'D'irectory 'D'isk )? Or, following the SYSTEM CONFIG CF1/CF2/CF3 disk standards, a paranoid sysprog could set up SD1, and SD2 disks. Where the live directory is on the SD1 directory (at a known extent on a known volume), always make a backup copy to the SD2 disk (at a known extent on a known volume) before making any changes. That way if anything goes wrong you can always go back one generation without needing to mount a tape. It vastly reduces the chances of formatting *both* disks. It depends on your level of paranoia. By placing it on a disk other than 191 one must be very sure to never copy or save it to the 191 disk by accident or on purpose (just for a test, of course) because then you have the opportunity to figure out which is the real USER DIRECT, or worse - which has some of the real entries and which has the rest of the real entries. A good PROFILE EXEC could easily check for such duplicate errors. Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. -- Kris Buelens, IBM Belgium, VM customer support NOTE: This e-mail message contains PRIVILEGED and CONFIDENTIAL information and is intended only for the use of the specific individual or individuals to which it is addressed. If you are not an intended recipient of this e-mail, you are hereby notified that any unauthorized use, dissemination or copying of this e-mail or the information contained herein or attached hereto is strictly prohibited. If you receive this e-mail in error, notify the person named above by reply e-mail and please delete it. Thank you. Jan Canavan [EMAIL PROTECTED] VSE/VM SYSTEMS PROGRAMMER
Re: Service level after RSU
So should we all do this? We id this back in when the RSU 0703 first came out. We checked it three times. We just thought that was just the way it was. If more than one is having trouble, something is out of sync. -Original Message- From: Alan Altmark [EMAIL PROTECTED] Sent: Mar 3, 2008 8:36 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Service level after RSU The easiest thing to do is to open a PMR. You will be granted audience with an Absolute Master of the Arcane. He or she will use their Power to divine the cause of your confusion. Alan Altmark z/VM Development IBM Endicott Jan Canavan [EMAIL PROTECTED] VSE/VM SYSTEMS PROGRAMMER
Re: Having trouble with re-installing CA-Librarian on z/VM 5.3
The users are on the 4.4 system still. We will try this. Thanks -Original Message- From: Rob van der Heij [EMAIL PROTECTED] Sent: Feb 12, 2008 9:39 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Having trouble with re-installing CA-Librarian on z/VM 5.3 On Feb 12, 2008 8:17 PM, [EMAIL PROTECTED] wrote: libgen DEFSEG for LIBDCSST must have previously been issued. Saved system name is LIBDCSST . . . origin address is 0030 . . . The old addresses look like they overlay the CMS nucleus areas... This may be an artefact of very ancient code that uses the wrong Diag64 subcode to find the skeleton. It ends up getting the address of the active segment rather than the skeleton you just prepared. If it did not abend, it would probably save the wrong code in it. If so, the easiest way out is either purge the active DCSS (by spool id) or issue a manual SAVESEG followed by a new DEFSEG for that segment. Both will make the DCSS unusable for your users until you finished the work, if that's a concern. Rob -- Rob van der Heij Velocity Software, Inc http://velocitysoftware.com/ Jan Canavan [EMAIL PROTECTED] VSE/VM SYSTEMS PROGRAMMER
