SPF Command Shell panel
Hi all I have a question about ISPF Command Shell panel. I used for example: telnet mvs01 and I received: no connection PFK1 gave me: The SELECT WSCMD and SELECT WSCMDV services are only valid when a connection with the workstation has been established. but if I start it in other place TSO telnet mvs01 it works well Could someone help me with this problem. Thanks in advance -- Best regards, Rafal Hanzel Systems Programmer, R&D of Computer System Department Z.E.T.O Katowice Sp. z o.o. ul. Owocowa 1 40-158 Katowice, Poland Phone: +48 32 3589 246 Mobile:+48 501677656 e-mail: hanz...@zetokatowice.pl www: http://www.zetokatowice.pl -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
And you ask why I hate OMVS?
This past weekend I had the dubious honour of shutting down and IPLing 5 systems, two of them with USS work. The shutting down part was really bad (now I know why our operators keep complaining). One lpar has my favourite hate-application running (called WBIFN, for all you European SWIFT customers). Around seven minutes into the shutdown (another lpar with similar workload but not this appliaction was already down after 7 minutes) D A,L revealed that there were some DB2s plus WBIFN still running plus the necessary system infrastructure. And one thing with the jobname of a TSO user, but OMVSEX in the step info, so the userid belonged to some USS process? thread? application? And they seemend to multiply while I was looking at them. Canceling any of them didn't really help, never mind that the duplicate jobname requires using the asid, which requires a list first. By the time I get around to killing the pid, it's already gone. Then I saw that *something* still had open DB2 threads, for which automation has made provisions and forces things out. So I thought that this must be related to this user. Given that I couldn't stop it from multiplying, much less get out of the system (f bpxoinit,shutdown=forkinit was replied with 'shutdown delayed'), I shut down the fork service. That stopped the multiplication, but a few of those 'user asids with a number' were still around. And it was a VERY bad idea to shutdown the fork service, as that effectively prevented WBIFN from terminating eventually (it never terminates in a timely manner, anyway). I ended up canceling things, which generated tons of coredumps which filled the directory, which eventually prevented the startup of this application. (And no, these useless coredumps cannot be prevented, believe me, I've tried.) The good news was that after 20 minutes I had WBIFN and that userid shut down, and then automation did the rest (in the case of our operators, they never get automation to do 'the rest'). So how are other installations handling system shutdown when there are active USS users (or at least their leftover processes)? For a 'pure' MVS, I can shutdown TSO and the Initiators, cancel any running batch jobs, and I am done. But how do I stop the USS things from multiplying? And this Tuesday, that users leftover processes are back. I tried killing the top one (right under ppid=1), but that only resulted in another process under ppid=1 (that killed process was just dropped). superkill didn't help, either. Isn't there any surefire way to get the whole tree stopped in one fell swoop? (and no, I won't kill pid 1). (An OMVS ignoramus is asking this, so please be gentle with me) Best regards, Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: And you ask why I hate OMVS?
Hi Barbara Either from within SDSF with the "PS" panel or from within OMVS and issuing the " ps -ef" are you able to see what the User is executing, Regards Gerard Ceruti may the 'z' be with you SharePoint (internal) -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Barbara Nitz Sent: 23 June 2009 11:23 To: IBM-MAIN@bama.ua.edu Subject: And you ask why I hate OMVS? This past weekend I had the dubious honour of shutting down and IPLing 5 systems, two of them with USS work. The shutting down part was really bad (now I know why our operators keep complaining). One lpar has my favourite hate-application running (called WBIFN, for all you European SWIFT customers). Around seven minutes into the shutdown (another lpar with similar workload but not this appliaction was already down after 7 minutes) D A,L revealed that there were some DB2s plus WBIFN still running plus the necessary system infrastructure. And one thing with the jobname of a TSO user, but OMVSEX in the step info, so the userid belonged to some USS process? thread? application? And they seemend to multiply while I was looking at them. Canceling any of them didn't really help, never mind that the duplicate jobname requires using the asid, which requires a list first. By the time I get around to killing the pid, it's already gone. Then I saw that *something* still had open DB2 threads, for which automation has made provisions and forces things out. So I thought that this must be related to this user. Given that I couldn't stop it from multiplying, much less get out of the system (f bpxoinit,shutdown=forkinit was replied with 'shutdown delayed'), I shut down the fork service. That stopped the multiplication, but a few of those 'user asids with a number' were still around. And it was a VERY bad idea to shutdown the fork service, as that effectively prevented WBIFN from terminating eventually (it never terminates in a timely manner, anyway). I ended up canceling things, which generated tons of coredumps which filled the directory, which eventually prevented the startup of this application. (And no, these useless coredumps cannot be prevented, believe me, I've tried.) The good news was that after 20 minutes I had WBIFN and that userid shut down, and then automation did the rest (in the case of our operators, they never get automation to do 'the rest'). So how are other installations handling system shutdown when there are active USS users (or at least their leftover processes)? For a 'pure' MVS, I can shutdown TSO and the Initiators, cancel any running batch jobs, and I am done. But how do I stop the USS things from multiplying? And this Tuesday, that users leftover processes are back. I tried killing the top one (right under ppid=1), but that only resulted in another process under ppid=1 (that killed process was just dropped). superkill didn't help, either. Isn't there any surefire way to get the whole tree stopped in one fell swoop? (and no, I won't kill pid 1). (An OMVS ignoramus is asking this, so please be gentle with me) Best regards, Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html _ Standard Bank email Disclaimer and confidentiality note This e-mail, its attachments and any rights attaching hereto are, unless the content clearly indicates otherwise, the property of Standard Bank Group Limited and its subsidiaries. It is confidential, private and intended for only the addressee. Should you not be the addressee and receive this e-mail by mistake, kindly notify the sender, and delete this e-mail immediately. Do not disclose or use it in any way. Views and opinions expressed in this e-mail are those of the sender unless clearly stated as those of Standard Bank Group. Standard Bank Group accepts no liability for any loss or damages howsoever incurred, or suffered, resulting, or arising, from the use of this email or its attachments. Standard Bank Group does not warrant the integrity of this e-mail nor that it is free of errors, viruses, interception or interference. Licensed divisions of the Standard Bank Group are authorised financial services providers in terms of the Financial Advisory and Intermediary Services Act, No 37 of 2002 (FAIS). For information about the Standard Bank Group visit our website http://www.standardbank.com -- For IBM-MAIN subscribe / signoff / ar
Re: And you ask why I hate OMVS?
On Tue, 23 Jun 2009 04:22:35 -0500, Barbara Nitz wrote: >I was looking at them. Canceling any of them didn't really help, never mind >that the duplicate jobname requires using the asid, which requires a list first. >By the time I get around to killing the pid, it's already gone. > CANCEL jobname.* cancels all tasks/jobs with the same jobname. No asid needed. Norbert Friemel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: And you ask why I hate OMVS?
Ahhhaaa, you named and shamed and I didn't have to *search the archives*! A lot of the Websphere portfolio doesn't port well to z/OS. I have anecdotal evidence (I was told by an IBMer) that Websphere messaage broker runs like a stallion on AIX but sucks big time on z/OS. Having said that, I still maintain that zUnix is reasonably solid. It comes down to quality of implementation, and that means tailoring for the z/OS platform. Barbara Nitz wrote: This past weekend I had the dubious honour of shutting down and IPLing 5 systems, two of them with USS work. The shutting down part was really bad (now I know why our operators keep complaining). One lpar has my favourite hate-application running (called WBIFN, for all you European SWIFT customers). Around seven minutes into the shutdown (another lpar with similar workload but not this appliaction was already down after 7 minutes) D A,L revealed that there were some DB2s plus WBIFN still running plus the necessary system infrastructure. And one thing with the jobname of a TSO user, but OMVSEX in the step info, so the userid belonged to some USS process? thread? application? And they seemend to multiply while I was looking at them. Canceling any of them didn't really help, never mind that the duplicate jobname requires using the asid, which requires a list first. By the time I get around to killing the pid, it's already gone. Then I saw that *something* still had open DB2 threads, for which automation has made provisions and forces things out. So I thought that this must be related to this user. Given that I couldn't stop it from multiplying, much less get out of the system (f bpxoinit,shutdown=forkinit was replied with 'shutdown delayed'), I shut down the fork service. That stopped the multiplication, but a few of those 'user asids with a number' were still around. And it was a VERY bad idea to shutdown the fork service, as that effectively prevented WBIFN from terminating eventually (it never terminates in a timely manner, anyway). I ended up canceling things, which generated tons of coredumps which filled the directory, which eventually prevented the startup of this application. (And no, these useless coredumps cannot be prevented, believe me, I've tried.) The good news was that after 20 minutes I had WBIFN and that userid shut down, and then automation did the rest (in the case of our operators, they never get automation to do 'the rest'). So how are other installations handling system shutdown when there are active USS users (or at least their leftover processes)? For a 'pure' MVS, I can shutdown TSO and the Initiators, cancel any running batch jobs, and I am done. But how do I stop the USS things from multiplying? And this Tuesday, that users leftover processes are back. I tried killing the top one (right under ppid=1), but that only resulted in another process under ppid=1 (that killed process was just dropped). superkill didn't help, either. Isn't there any surefire way to get the whole tree stopped in one fell swoop? (and no, I won't kill pid 1). (An OMVS ignoramus is asking this, so please be gentle with me) Best regards, Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: And you ask why I hate OMVS?
>CANCEL jobname.* cancels all tasks/jobs with the same jobname. I have only ever used the jobname.identifier construct when I had started gtf without specifiying the identifier at the start command. I didn't know that that might get rid of USS processes. I'll try it tomorrow morning, to see if it works on both stepname *omvsex and step1. - thanks for that tip! Best regards, Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Any one using JDBC type 4 to access IMS DB??
Hello Timothy, Thanks for replying. Actually, the goal is to migrate an application off to open platform. And the data updated on open platform also needs to be synch back to IMS. Therefore, we were thinking about using JDBC Type 4 driver. With that, there should be no need to develop mainframe programs. Fermat On Tue, Jun 23, 2009 at 2:30 PM, Timothy Sipples wrote: > It sounds like you have data-intensive applications, including batch and > online. If the goal is to add a Java environment to your application > runtime collection, then you have a couple choices. (And the choices can be > used in combination also.) > > One is that IMS Transaction Manager supports Java programming and has for > nearly 10 years now (since IMS V7), with progressive improvements as Java > has evolved. Java support is a base, standard feature provided with IMS and > z/OS at no additional charge. So if you want to write Java, go write Java. > You don't even have to phone IBM. (The same is true of CICS Transaction > Server and z/OS itself.) Just crack open the documentation and go for it. > It's darn easy, too: just 4 APIs from what I gather. With CICS look for > "JCICS" in your CICS documentation, and for z/OS look for the "JZOS > Cookbook" (Web search will find it) to get started. All this stuff is > standard, base function available at no additional charge. You've already > got it. > > Another is WebSphere Application Server for z/OS. The reason you should > consider WAS z/OS here very strongly (as opposed to WAS running elsewhere) > is that data-intensity you mentioned. You really want to try to avoid > taking trips over the wire for data access if you can avoid it. (Sometimes > you cannot avoid it, but you can certainly avoid it in this case.) Also, > financially you're very likely to do much better this way, at least in any > moderately responsible and competent cost analysis. > > - - - - - > Timothy Sipples > IBM Consulting Enterprise Software Architect > Based in Tokyo, Serving IBM Japan / Asia-Pacific > E-Mail: timothy.sipp...@us.ibm.com > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: And you ask why I hate OMVS?
>A lot of the Websphere portfolio doesn't port well to z/OS. I have >anecdotal evidence (I was told by an IBMer) that Websphere messaage >broker runs like a stallion on AIX but sucks big time on z/OS. Agreed to the z/OS part. My ears are still ringing from the cursing my colleague did when he installed this on MVS. That thing just doesn't play on z/OS! But please keep in mind that this time around, it wasn't the culprit! That user was executing with an application named SQS (where just about no one here has an idea what it is). Never mind that the SQS server (that *supposedly* everything else executes under) was long gone when I noticed that user. My shutting down the fork service brought WBIFN to a halt, and probably rightly so. On the other hand, a 'real' MVS component would have had recovery in place with provisions for that service happening and terminating all on its own. Just think of the lengths IMS goes to *not* to have an MPR canceled from under it! >and that means tailoring for the z/OS platform. Which for the most part, isn't done or done improperly. Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: And you ask why I hate OMVS?
- Original Message - From: "Barbara Nitz" Newsgroups: bit.listserv.ibm-main Sent: Tuesday, June 23, 2009 5:23 AM Subject: And you ask why I hate OMVS? This past weekend I had the dubious honour of shutting down and IPLing 5 systems, two of them with USS work. The shutting down part was really bad (now I know why our operators keep complaining). Barbara, There is a job that used to be on the USS Tools and Toys pages that would run a BPX batch step to kill all active tasks. I don't have the job handy, but I'll see if I can track it down and send it to you. I only ran it when the shutdown forkinit didn't work, but it usually nuked any OMVS process that was hanging up shutdown. Check out Zelden's page, he may have it there. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
ICHRIN03 not loading in the LPA correctly.
I'm in the process of migrating our RACF setup into a new z/OS 1.9 system and I can't get ICHRIN03 loaded in the LPA correclty. From a listlpa on our z/OS 1.7 system, the entry looks like this - ICHRIN03 00DD77D0 0028 80DD77D0 but in the new z/OS 1.9 system it looks like this - ICHRIN03 00CDB000 0008 00CDB000 In the lpalib library, they are both amode 31 rmode 24 and both entries have a length of 0028. Any ideas. Jim McAlpine -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: And you ask why I hate OMVS?
Tom, unless I can specify a certain jobname for that job, don't bother with searching for it. I cannot shut down *all* active processes, as that was what got me in trouble. Also, we have a clist that kills all processes left when JES2 doesn't shut down. Which doesn't help me, as that user is preventing Automation from even attempting to terminate jes2! But thanks! Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ICHRIN03 not loading in the LPA correctly.
What is shown on a D PROG,LPA,MOD=ichrin03 before adding it to lpa and after the SETPROG LPA,ADD,MODNAME=ichrin03,DSNAME=wherever-it-is-located? Regards, Barbara Nitz -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
SMS Dataset Allocation Problem
We have IBMUSER.NDSP.** defined as SMS Managed datasets. My DBA trying to allocate SMS Managed dataset with space as //SYSREC01 DD DSN=IBMUSER.NDSP.DATA, // DISP=(NEW,CATLG,DELETE), // SPACE=(CYL,(2000,1800),RLSE) The job is failing with error IEC030I B37-04,IFG0554A,IBMUSE1,S02,SYSREC01,9D96,ND0016,E6002130,IBMUSER.NDSP.DATA But if DBA submit the same job with space parameters as //SYSREC01 DD DSN=IBMUSER.NDSP.DATA, // DISP=(NEW,CATLG,DELETE), // SPACE=(CYL,(2000,1800),RLSE), // UNIT=(DISK,40) Then the JOB completes with RC 00. Please note that the only diff is of UNIT parameter. Can anyone explain me why this happens ? John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ICHRIN03 not loading in the LPA correctly.
On Tue, Jun 23, 2009 at 12:02 PM, Barbara Nitz wrote: > What is shown on a D PROG,LPA,MOD=ichrin03 before adding it to lpa and > after > the SETPROG LPA,ADD,MODNAME=ichrin03,DSNAME=wherever-it-is-located? > > Regards, Barbara Nitz > > It isn't added with setprog, it's included in user.lpalib which is in lpalstxx. Jim McAlpine -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS Dataset Allocation Problem
John, In the failing instance, you ran out of space on ND0016. Hence the B37-04 abend. In the second instance you provided up to 40 volumes to expand the dataset. Hence the file expanded successfully and there was no abend. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of John Mitchelle Sent: Tuesday, June 23, 2009 7:10 AM To: IBM-MAIN@bama.ua.edu Subject: SMS Dataset Allocation Problem We have IBMUSER.NDSP.** defined as SMS Managed datasets. My DBA trying to allocate SMS Managed dataset with space as //SYSREC01 DD DSN=IBMUSER.NDSP.DATA, // DISP=(NEW,CATLG,DELETE), // SPACE=(CYL,(2000,1800),RLSE) The job is failing with error IEC030I B37-04,IFG0554A,IBMUSE1,S02,SYSREC01,9D96,ND0016,E6002130,IBMUSER.NDSP.DATA But if DBA submit the same job with space parameters as //SYSREC01 DD DSN=IBMUSER.NDSP.DATA, // DISP=(NEW,CATLG,DELETE), // SPACE=(CYL,(2000,1800),RLSE), // UNIT=(DISK,40) Then the JOB completes with RC 00. Please note that the only diff is of UNIT parameter. Can anyone explain me why this happens ? John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS Dataset Allocation Problem
"John Mitchelle" wrote in message news:... > We have IBMUSER.NDSP.** defined as SMS Managed datasets. > > My DBA trying to allocate SMS Managed dataset with space as > //SYSREC01 DD DSN=IBMUSER.NDSP.DATA, > // DISP=(NEW,CATLG,DELETE), > // SPACE=(CYL,(2000,1800),RLSE) > > The job is failing with error > IEC030I > B37-04,IFG0554A,IBMUSE1,S02,SYSREC01,9D96,ND0016,E6002130,IBMUSER.NDSP.D ATA > > But if DBA submit the same job with space parameters as > > //SYSREC01 DD DSN=IBMUSER.NDSP.DATA, > // DISP=(NEW,CATLG,DELETE), > // SPACE=(CYL,(2000,1800),RLSE), > // UNIT=(DISK,40) > > Then the JOB completes with RC 00. > > Please note that the only diff is of UNIT parameter. Can anyone explain me > why this happens ? > > John Yes, the difference is not the "DISK", but the "40". Your ACS routines appanrently don't provide you with a multivolume dataset. Kees. ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS Dataset Allocation Problem
John, In your second example, the UNIT parameter is coded to allow for an allocation of up to 40 volumes. Your allocation originally failed with a b37 space abend for volume ND0016. A very common occurrence with an allocation of 2000,1800 cylinders, especially if the volume is a 3390 Mod-3. Check the successful allocation of your second example with a LISTCAT and determine the number of volumes used for the allocation, and the amount of space that was actually allocated. If you do not want the data set to be multi volume, use Mod-9, Mod-27 or Mod-54 (or EAV if you can). There are also ISV products and DFSMS DataClass construct settings that would prevent the B37 abend. Michael Spencer BMC Software -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of John Mitchelle Sent: Tuesday, June 23, 2009 7:10 AM To: IBM-MAIN@bama.ua.edu Subject: SMS Dataset Allocation Problem We have IBMUSER.NDSP.** defined as SMS Managed datasets. My DBA trying to allocate SMS Managed dataset with space as //SYSREC01 DD DSN=IBMUSER.NDSP.DATA, // DISP=(NEW,CATLG,DELETE), // SPACE=(CYL,(2000,1800),RLSE) The job is failing with error IEC030I B37-04,IFG0554A,IBMUSE1,S02,SYSREC01,9D96,ND0016,E6002130,IBMUSER.NDSP.DATA But if DBA submit the same job with space parameters as //SYSREC01 DD DSN=IBMUSER.NDSP.DATA, // DISP=(NEW,CATLG,DELETE), // SPACE=(CYL,(2000,1800),RLSE), // UNIT=(DISK,40) Then the JOB completes with RC 00. Please note that the only diff is of UNIT parameter. Can anyone explain me why this happens ? John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS Dataset Allocation Problem
Hi Kees, Thanks for this. But what is meant by "Your ACS routines appanrently don't provide you with a multivolume dataset" John On Tue, Jun 23, 2009 at 12:17 PM, Vernooij, CP - SPLXM wrote: > > > "John Mitchelle" wrote in message > news:... > > We have IBMUSER.NDSP.** defined as SMS Managed datasets. > > > > My DBA trying to allocate SMS Managed dataset with space as > > //SYSREC01 DD DSN=IBMUSER.NDSP.DATA, > > // DISP=(NEW,CATLG,DELETE), > > // SPACE=(CYL,(2000,1800),RLSE) > > > > The job is failing with error > > IEC030I > > > B37-04,IFG0554A,IBMUSE1,S02,SYSREC01,9D96,ND0016,E6002130,IBMUSER.NDSP.D > ATA > > > > But if DBA submit the same job with space parameters as > > > > //SYSREC01 DD DSN=IBMUSER.NDSP.DATA, > > // DISP=(NEW,CATLG,DELETE), > > // SPACE=(CYL,(2000,1800),RLSE), > > // UNIT=(DISK,40) > > > > Then the JOB completes with RC 00. > > > > Please note that the only diff is of UNIT parameter. Can anyone > explain me > > why this happens ? > > > > John > > Yes, the difference is not the "DISK", but the "40". Your ACS routines > appanrently don't provide you with a multivolume dataset. > > Kees. > ** > For information, services and offers, please visit our web site: > http://www.klm.com. This e-mail and any attachment may contain > confidential and privileged material intended for the addressee > only. If you are not the addressee, you are notified that no part > of the e-mail or any attachment may be disclosed, copied or > distributed, and that any other action related to this e-mail or > attachment is strictly prohibited, and may be unlawful. If you have > received this e-mail by error, please notify the sender immediately > by return e-mail, and delete this message. > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries > and/or its employees shall not be liable for the incorrect or > incomplete transmission of this e-mail or any attachments, nor > responsible for any delay in receipt. > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal > Dutch Airlines) is registered in Amstelveen, The Netherlands, with > registered number 33014286 > ** > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: And you ask why I hate OMVS?
Barbara Nitz wrote: My shutting down the fork service brought WBIFN to a halt, and probably rightly so. On the other hand, a 'real' MVS component would have had recovery in place with provisions for that service happening and terminating all on its own. Just think of the lengths IMS goes to *not* to have an MPR canceled from under it! IMS and it's BPE framework has it's hooks firmly in OMVS. IMS Connect cannot run without it. An IMS Java MPP/BPP requires OMS (anybody using IMS Java?). As Aussie Shane noted, the horse has bolted (you just can't avoid it). BTW, I enjoy reading your posts very much. You are obviously a good value expert. There's nothing better than a customer use case when things suck. IBM should take notice! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS Dataset Allocation Problem
Your SMS managed dataset goes through several SMS routines that determine the final shape of the dataset you requested. These routines are called Automatic Class Selection routines, ACS routines for short. Kees. "John Mitchelle" wrote in message news:... > Hi Kees, > Thanks for this. But what is meant by "Your ACS routines appanrently don't > provide you with a multivolume dataset" > > John > > > > On Tue, Jun 23, 2009 at 12:17 PM, Vernooij, CP - SPLXM > wrote: > > > > > > > "John Mitchelle" wrote in message > > news:... > > > We have IBMUSER.NDSP.** defined as SMS Managed datasets. > > > > > > My DBA trying to allocate SMS Managed dataset with space as > > > //SYSREC01 DD DSN=IBMUSER.NDSP.DATA, > > > // DISP=(NEW,CATLG,DELETE), > > > // SPACE=(CYL,(2000,1800),RLSE) > > > > > > The job is failing with error > > > IEC030I > > > > > B37-04,IFG0554A,IBMUSE1,S02,SYSREC01,9D96,ND0016,E6002130,IBMUSER.NDSP.D > > ATA > > > > > > But if DBA submit the same job with space parameters as > > > > > > //SYSREC01 DD DSN=IBMUSER.NDSP.DATA, > > > // DISP=(NEW,CATLG,DELETE), > > > // SPACE=(CYL,(2000,1800),RLSE), > > > // UNIT=(DISK,40) > > > > > > Then the JOB completes with RC 00. > > > > > > Please note that the only diff is of UNIT parameter. Can anyone > > explain me > > > why this happens ? > > > > > > John > > > > Yes, the difference is not the "DISK", but the "40". Your ACS routines > > appanrently don't provide you with a multivolume dataset. > > > > Kees. > > ** > > For information, services and offers, please visit our web site: > > http://www.klm.com. This e-mail and any attachment may contain > > confidential and privileged material intended for the addressee > > only. If you are not the addressee, you are notified that no part > > of the e-mail or any attachment may be disclosed, copied or > > distributed, and that any other action related to this e-mail or > > attachment is strictly prohibited, and may be unlawful. If you have > > received this e-mail by error, please notify the sender immediately > > by return e-mail, and delete this message. > > > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries > > and/or its employees shall not be liable for the incorrect or > > incomplete transmission of this e-mail or any attachments, nor > > responsible for any delay in receipt. > > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal > > Dutch Airlines) is registered in Amstelveen, The Netherlands, with > > registered number 33014286 > > ** > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ICHRIN03 not loading in the LPA correctly.
> It isn't added with setprog, it's included in user.lpalib which is in >lpalstxx. Did you browse storage at the location of the 8-byte-ICHRIN03? What does that show? As the one that is currently found is apparently not the right one, is there any reason why you cannot test with the setprog command? I just checked ours, and ours (1.8) is 528byte long, but we use class STARTED, so its not really customized, but rather an IBM default. Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: And you ask why I hate OMVS?
We use this, Barbera
Might help
I hope email code page problems don't trash the special characters I'm
using . . .
* Top of Data
#
# shell script to bring down daemon if running
#
set -x
#
#
# the following finds the pids by piping the output of ps -ef through
# three greps (pattern matching) and an awk (to get the second column).
# The two extra greps filter out the grep process itself and the
# jlp_killprocess
#
#
pids=`ps -ef|grep £1|grep -v grep|grep -v jlp_killprocess\
|awk '{print £2}'`
# pids is now the process id(s) of the syslog daemon(s) running
running=0
for pid in £pids
do
running=1
done
if test £running -eq 0
then
echo "jlp_killprocess: "£1" is not running "
exit 0
fi
echo "jlp_killprocess: issueing kill for "£pids
for pid in £pids
do
kill -s TERM £pid
done
sleep 10
for pid in £pids
do
kill -s KILL £pid
done
sleep 5
# check to make sure it ain't there any more . . .
pids=`ps -ef|grep £1|grep -v grep|grep -v jlp_killprocess\
|awk '{print £2}'`
running=0
for pid in £pids
do
running=1
done
if test £running -eq 0
then
echo "jlp_killprocess: "£1" has been killed "
exit 0
fi
echo "jlp_killprocess: "£1" - kill failed "
exit 12
Bottom of Data ***
Andy Robertson telephone mobile 0777 214 9545 home 01308
420797
-IBM Mainframe Discussion List wrote: -
To: IBM-MAIN@bama.ua.edu
From: David Crayford
Sent by: IBM Mainframe Discussion List
Date: 06/23/2009 11:41AM
Subject: Re: And you ask why I hate OMVS?
Barbara Nitz wrote:
>
> My shutting down the fork service brought WBIFN to a halt, and probably
> rightly so. On the other hand, a 'real' MVS component would have had
> recovery in place with provisions for that service happening and
terminating all
> on its own. Just think of the lengths IMS goes to *not* to have an MPR
> canceled from under it!
>
IMS and it's BPE framework has it's hooks firmly in OMVS. IMS Connect
cannot run without it. An IMS Java MPP/BPP requires OMS (anybody using
IMS Java?). As Aussie Shane noted, the horse has bolted (you just can't
avoid it).
BTW, I enjoy reading your posts very much. You are obviously a good
value expert. There's nothing better than a customer use case when
things suck. IBM should take notice!
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
**
This email is confidential and may contain copyright material of the John Lewis
Partnership.
If you are not the intended recipient, please notify us immediately and delete
all copies of this message.
(Please note that it is your responsibility to scan this message for viruses).
Email to and from the
John Lewis Partnership is automatically monitored for operational and lawful
business reasons.
**
John Lewis plc
Registered in England 233462
Registered office 171 Victoria Street London SW1E 5NN
Websites: http://www.johnlewis.com
http://www.waitrose.com
http://www.greenbee.com
http://www.johnlewispartnership.co.uk
**
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Another OMVS discussion (was: Re: And you ask why I hate OMVS?)
David, >> Just think of the lengths IMS goes to *not* to have an MPR >> canceled from under it! >IMS and it's BPE framework has it's hooks firmly in OMVS. IMS Connect >cannot run without it. An IMS Java MPP/BPP requires OMS (anybody using >IMS Java?). I was refering more to the fact that you cannot cancel/force arm/force *any* MPR. (Ask me how I know!) On the test system we get calls about once every 4-5 months, where a tso user testing as a BMP (I think) managed to screw things up so that his TSO useris is still living, but he cannot login anymore, and he cannot get canceled. cancel gets 'not cancelable, use force arm'. force arm gets some other error message. And I believe force gets rejected with 'use force arm first'. At that point I get called to take a dump and run IBMs CALLRTM program. In 50% of the cases that terminates the userid, and he can login again. The other 50% IMS needs to get restarted, impoacting all other users. And we also use IMS connect. We might even use IMS Java, but IMS is fortunately another group You've just given me another nightmare with 'has its hooks frimly in OMVS'. :-) Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ICHRIN03 not loading in the LPA correctly.
On Tue, Jun 23, 2009 at 12:46 PM, Barbara Nitz wrote: > > It isn't added with setprog, it's included in user.lpalib which is in > >lpalstxx. > > Did you browse storage at the location of the 8-byte-ICHRIN03? What does > that show? > > As the one that is currently found is apparently not the right one, is > there any > reason why you cannot test with the setprog command? > > I just checked ours, and ours (1.8) is 528byte long, but we use class > STARTED, so its not really customized, but rather an IBM default. > > Barbara > > > Barbara, thanks for your suggestions. A dump shows the 8 byte ichrin03 to be 8 bytes of low values. When I issue the setprog as you suggested, the modeule gets loaded correctly and the D PROG,LPA,MOD=ichrin03 now correctly shows the module as - D PROG,LPA,MOD=ICHRIN03 CSV550I 09.59.15 LPA DISPLAY 671 FLAGS MODULEENTRY PT LOAD PT LENGTHDIAG D P ICHRIN03 80C78000 00C78000 0028 02273040 very strange. Regards Jim McAlpine -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS Dataset Allocation Problem
I am aware of ACS routines and there is also Storage Class assigned for this dataset through this ACS routine. Are you saying that there is specific parameter which decides the multivolume dataset allocation ? On Tue, Jun 23, 2009 at 12:42 PM, Vernooij, CP - SPLXM wrote: > Your SMS managed dataset goes through several SMS routines that > determine the final shape of the dataset you requested. These routines > are called Automatic Class Selection routines, ACS routines for short. > > Kees. > > > "John Mitchelle" wrote in message > news:... > > Hi Kees, > > Thanks for this. But what is meant by "Your ACS routines appanrently > don't > > provide you with a multivolume dataset" > > > > John > > > > > > > > On Tue, Jun 23, 2009 at 12:17 PM, Vernooij, CP - SPLXM > > > wrote: > > > > > > > > > > > "John Mitchelle" wrote in message > > > > news:... > > > > We have IBMUSER.NDSP.** defined as SMS Managed datasets. > > > > > > > > My DBA trying to allocate SMS Managed dataset with space as > > > > //SYSREC01 DD DSN=IBMUSER.NDSP.DATA, > > > > // DISP=(NEW,CATLG,DELETE), > > > > // SPACE=(CYL,(2000,1800),RLSE) > > > > > > > > The job is failing with error > > > > IEC030I > > > > > > > > B37-04,IFG0554A,IBMUSE1,S02,SYSREC01,9D96,ND0016,E6002130,IBMUSER.NDSP.D > > > ATA > > > > > > > > But if DBA submit the same job with space parameters as > > > > > > > > //SYSREC01 DD DSN=IBMUSER.NDSP.DATA, > > > > // DISP=(NEW,CATLG,DELETE), > > > > // SPACE=(CYL,(2000,1800),RLSE), > > > > // UNIT=(DISK,40) > > > > > > > > Then the JOB completes with RC 00. > > > > > > > > Please note that the only diff is of UNIT parameter. Can anyone > > > explain me > > > > why this happens ? > > > > > > > > John > > > > > > Yes, the difference is not the "DISK", but the "40". Your ACS > routines > > > appanrently don't provide you with a multivolume dataset. > > > > > > Kees. > > > > ** > > > For information, services and offers, please visit our web site: > > > http://www.klm.com. This e-mail and any attachment may contain > > > confidential and privileged material intended for the addressee > > > only. If you are not the addressee, you are notified that no part > > > of the e-mail or any attachment may be disclosed, copied or > > > distributed, and that any other action related to this e-mail or > > > attachment is strictly prohibited, and may be unlawful. If you have > > > received this e-mail by error, please notify the sender immediately > > > by return e-mail, and delete this message. > > > > > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries > > > and/or its employees shall not be liable for the incorrect or > > > incomplete transmission of this e-mail or any attachments, nor > > > responsible for any delay in receipt. > > > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal > > > Dutch Airlines) is registered in Amstelveen, The Netherlands, with > > > registered number 33014286 > > > > ** > > > > > > > -- > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN > INFO > > > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > > > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > > Search the archives at http://bama.ua.edu/archives/ibm-main.html > ** > For information, services and offers, please visit our web site: > http://www.klm.com. This e-mail and any attachment may contain > confidential and privileged material intended for the addressee > only. If you are not the addressee, you are notified that no part > of the e-mail or any attachment may be disclosed, copied or > distributed, and that any other action related to this e-mail or > attachment is strictly prohibited, and may be unlawful. If you have > received this e-mail by error, please notify the sender immediately > by return e-mail, and delete this message. > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries > and/or its employees shall not be liable for the incorrect or > incomplete transmission of this e-mail or any attachments, nor > responsible for any delay in receipt. > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal > Dutch Airlines) is registered in Amstelveen, The Netherlands, with > registered number 33014286 > ** > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists
Re: ICHRIN03 not loading in the LPA correctly.
The one in SYS1.LPALIB is 8 bytes long and is 8 bytes of low values. But the lpalstxx member has the USER.LPALIB first like so - USER.LPALIB, ADCD.Z19S.LPALIB, EQA810.SEQALPA(S9RES1), SYS1.LPALIB, SYS1.SERBLPA, NET530.SCNMLPA1(S9RES2), FAN140.SEAGLPA(S9RES1), ISF.SISFLPA(S9RES1), EOY.SEOYLPA(S9RES2), SYS1.SBDTLPA, CEE.SCEELPA(S9RES2), ISP.SISPLPA(S9RES1), TCPIP.SEZALPA(S9RES1), SYS1.SORTLPA, SYS1.SDWWDLPA, SYS1.SICELPA why would the search not be in the sequence of the libraries above ??? Jim McAlpine -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ICHRIN03 not loading in the LPA correctly.
Jim, at this point, the only thing I can think of is that something is wrong with the lpalstxx member that you use. What else is in that user.lpalib? Is that *something else* loaded correctly? Were there any IPL lpa-error messages? Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS Dataset Allocation Problem
Yes, volumes in the Dataclass -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of John Mitchelle Sent: Tuesday, June 23, 2009 8:05 AM To: IBM-MAIN@bama.ua.edu Subject: Re: SMS Dataset Allocation Problem I am aware of ACS routines and there is also Storage Class assigned for this dataset through this ACS routine. Are you saying that there is specific parameter which decides the multivolume dataset allocation ? On Tue, Jun 23, 2009 at 12:42 PM, Vernooij, CP - SPLXM wrote: > Your SMS managed dataset goes through several SMS routines that > determine the final shape of the dataset you requested. These routines > are called Automatic Class Selection routines, ACS routines for short. > > Kees. > > > "John Mitchelle" wrote in message > news:... > > Hi Kees, > > Thanks for this. But what is meant by "Your ACS routines appanrently > don't > > provide you with a multivolume dataset" > > > > John > > > > > > > > On Tue, Jun 23, 2009 at 12:17 PM, Vernooij, CP - SPLXM > > > wrote: > > > > > > > > > > > "John Mitchelle" wrote in message > > > > news:... > > > > We have IBMUSER.NDSP.** defined as SMS Managed datasets. > > > > > > > > My DBA trying to allocate SMS Managed dataset with space as > > > > //SYSREC01 DD DSN=IBMUSER.NDSP.DATA, > > > > // DISP=(NEW,CATLG,DELETE), > > > > // SPACE=(CYL,(2000,1800),RLSE) > > > > > > > > The job is failing with error > > > > IEC030I > > > > > > > > B37-04,IFG0554A,IBMUSE1,S02,SYSREC01,9D96,ND0016,E6002130,IBMUSER.NDSP.D > > > ATA > > > > > > > > But if DBA submit the same job with space parameters as > > > > > > > > //SYSREC01 DD DSN=IBMUSER.NDSP.DATA, > > > > // DISP=(NEW,CATLG,DELETE), > > > > // SPACE=(CYL,(2000,1800),RLSE), > > > > // UNIT=(DISK,40) > > > > > > > > Then the JOB completes with RC 00. > > > > > > > > Please note that the only diff is of UNIT parameter. Can anyone > > > explain me > > > > why this happens ? > > > > > > > > John > > > > > > Yes, the difference is not the "DISK", but the "40". Your ACS > routines > > > appanrently don't provide you with a multivolume dataset. > > > > > > Kees. > > > > ** > > > For information, services and offers, please visit our web site: > > > http://www.klm.com. This e-mail and any attachment may contain > > > confidential and privileged material intended for the addressee > > > only. If you are not the addressee, you are notified that no part > > > of the e-mail or any attachment may be disclosed, copied or > > > distributed, and that any other action related to this e-mail or > > > attachment is strictly prohibited, and may be unlawful. If you have > > > received this e-mail by error, please notify the sender immediately > > > by return e-mail, and delete this message. > > > > > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries > > > and/or its employees shall not be liable for the incorrect or > > > incomplete transmission of this e-mail or any attachments, nor > > > responsible for any delay in receipt. > > > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal > > > Dutch Airlines) is registered in Amstelveen, The Netherlands, with > > > registered number 33014286 > > > > ** > > > > > > > -- > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN > INFO > > > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > > > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > > Search the archives at http://bama.ua.edu/archives/ibm-main.html > ** > For information, services and offers, please visit our web site: > http://www.klm.com. This e-mail and any attachment may contain > confidential and privileged material intended for the addressee > only. If you are not the addressee, you are notified that no part > of the e-mail or any attachment may be disclosed, copied or > distributed, and that any other action related to this e-mail or > attachment is strictly prohibited, and may be unlawful. If you have > received this e-mail by error, please notify the sender immediately > by return e-mail, and delete this message. > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries > and/or its employees shall not be liable for the incorrect or > incomplete transmission of this e-mail or any attachments, nor > responsible for any delay in receipt. > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal > Dutch Airlines) is registered in Amstelveen, The Netherlands, with > re
Re: What's Needed in Linklst?
As far as IPLing is required, the only required data sets are SYS1.LINKLIB (and the SYSLIB LINKLIB data set identified in PROGxx, if different) SYS1.MIGLIB (and the SYSLIB MIGLIB data set identified in PROGxx, if different) SYS1.CSSLIB (and the SYSLIB CSSLIB data set identified in PROGxx, if different) SYS1.SIEALNKE (and the SYSLIB LINKLIBE data set identified in PROGxx, if different) SYS1.SIEAMIGE (and the SYSLIB MIGLIBE data set identified in PROGxx, if different) Lack of these data sets will result in a wait state (code 0A with message IEA716I).. Basically, it's those data sets that are placed by the system, or required to be there, in (almost) all circumstances into every LNKLST set. All the other data sets that have been shown likely relate to a properly running system with all the various z/OS elements. So they're likely "necessary" in some way but won't result in an IPL-time wait state Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ICHRIN03 not loading in the LPA correctly.
Init&Tuning Reference: The LPALIB data set is always the first data set in the concatenation (see "Using the SYSLIB statement" in topic 67.3). Unless overridden by a SYSLIB statement in PROGxx, the LPALST concatenation begins with SYS1.LPALIB. If you do not use SYSLIB and place the LPALIB data set name on any record in any LPALSTxx member, the name is ignored. So I guess the module is found at IPL from the one in SYS1.LPALIB, not the one from your user.lpalib. Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS Dataset Allocation Problem
No, not a specific parameter for multivolume, this is part of the Dataclass. Possibly your SMS management has defined a Dataclass that you can request and gives you a multivolume dataset. Besides that, you can always overrule the values supplied by the ACS routines, e.g. specify UNIT=(DISK,40). However, starting from z/OS 1.10 (or maybe 1.9), SMS has parameters that allow him to ignore your overrulings. Kees. "John Mitchelle" wrote in message news:... > I am aware of ACS routines and there is also Storage Class assigned for this > dataset through this ACS routine. Are you saying that there is specific > parameter which decides the multivolume dataset allocation ? > > On Tue, Jun 23, 2009 at 12:42 PM, Vernooij, CP - SPLXM > wrote: > > > Your SMS managed dataset goes through several SMS routines that > > determine the final shape of the dataset you requested. These routines > > are called Automatic Class Selection routines, ACS routines for short. > > > > Kees. > > > > > > "John Mitchelle" wrote in message > > news:... > > > Hi Kees, > > > Thanks for this. But what is meant by "Your ACS routines appanrently > > don't > > > provide you with a multivolume dataset" > > > > > > John > > > > > > > > > > > > On Tue, Jun 23, 2009 at 12:17 PM, Vernooij, CP - SPLXM > > > > > wrote: > > > > > > > > > > > > > > > "John Mitchelle" wrote in message > > > > > > news:... > > > > > We have IBMUSER.NDSP.** defined as SMS Managed datasets. > > > > > > > > > > My DBA trying to allocate SMS Managed dataset with space as > > > > > //SYSREC01 DD DSN=IBMUSER.NDSP.DATA, > > > > > // DISP=(NEW,CATLG,DELETE), > > > > > // SPACE=(CYL,(2000,1800),RLSE) > > > > > > > > > > The job is failing with error > > > > > IEC030I > > > > > > > > > > > B37-04,IFG0554A,IBMUSE1,S02,SYSREC01,9D96,ND0016,E6002130,IBMUSER.NDSP.D > > > > ATA > > > > > > > > > > But if DBA submit the same job with space parameters as > > > > > > > > > > //SYSREC01 DD DSN=IBMUSER.NDSP.DATA, > > > > > // DISP=(NEW,CATLG,DELETE), > > > > > // SPACE=(CYL,(2000,1800),RLSE), > > > > > // UNIT=(DISK,40) > > > > > > > > > > Then the JOB completes with RC 00. > > > > > > > > > > Please note that the only diff is of UNIT parameter. Can anyone > > > > explain me > > > > > why this happens ? > > > > > > > > > > John > > > > > > > > Yes, the difference is not the "DISK", but the "40". Your ACS > > routines > > > > appanrently don't provide you with a multivolume dataset. > > > > > > > > Kees. > > > > > > ** > > > > For information, services and offers, please visit our web site: > > > > http://www.klm.com. This e-mail and any attachment may contain > > > > confidential and privileged material intended for the addressee > > > > only. If you are not the addressee, you are notified that no part > > > > of the e-mail or any attachment may be disclosed, copied or > > > > distributed, and that any other action related to this e-mail or > > > > attachment is strictly prohibited, and may be unlawful. If you have > > > > received this e-mail by error, please notify the sender immediately > > > > by return e-mail, and delete this message. > > > > > > > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries > > > > and/or its employees shall not be liable for the incorrect or > > > > incomplete transmission of this e-mail or any attachments, nor > > > > responsible for any delay in receipt. > > > > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal > > > > Dutch Airlines) is registered in Amstelveen, The Netherlands, with > > > > registered number 33014286 > > > > > > ** > > > > > > > > > > -- > > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN > > INFO > > > > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > > > > > > > > > -- > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > > > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > ** > > For information, services and offers, please visit our web site: > > http://www.klm.com. This e-mail and any attachment may contain > > confidential and privileged material intended for the addressee > > only. If you are not the addressee, you are notified that no part > > of the e-mail or any attachment may be disclosed, copied or > > distributed, and that any other action related to this e-mail or > > attachment is strictly prohibited, and may be unlawful. If you have > > received this e-mail by error, please notify the sender immediatel
Re: SMS Dataset Allocation Problem
Yes, that is the SMS technical side. I understood that John is an ignorant SMS user, so for him there are only the defined/published dataclasses to select from. Kees. "O'Brien, David W. [C] , NIH/CIT" wrote in message news:... > Yes, volumes in the Dataclass > > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of John Mitchelle > Sent: Tuesday, June 23, 2009 8:05 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: SMS Dataset Allocation Problem > > I am aware of ACS routines and there is also Storage Class assigned for this > dataset through this ACS routine. Are you saying that there is specific > parameter which decides the multivolume dataset allocation ? > > On Tue, Jun 23, 2009 at 12:42 PM, Vernooij, CP - SPLXM > wrote: > > > Your SMS managed dataset goes through several SMS routines that > > determine the final shape of the dataset you requested. These routines > > are called Automatic Class Selection routines, ACS routines for short. > > > > Kees. > > > > > > "John Mitchelle" wrote in message > > news:... > > > Hi Kees, > > > Thanks for this. But what is meant by "Your ACS routines appanrently > > don't > > > provide you with a multivolume dataset" > > > > > > John > > > > > > > > > > > > On Tue, Jun 23, 2009 at 12:17 PM, Vernooij, CP - SPLXM > > > > > wrote: > > > > > > > > > > > > > > > "John Mitchelle" wrote in message > > > > > > news:... > > > > > We have IBMUSER.NDSP.** defined as SMS Managed datasets. > > > > > > > > > > My DBA trying to allocate SMS Managed dataset with space as > > > > > //SYSREC01 DD DSN=IBMUSER.NDSP.DATA, > > > > > // DISP=(NEW,CATLG,DELETE), > > > > > // SPACE=(CYL,(2000,1800),RLSE) > > > > > > > > > > The job is failing with error > > > > > IEC030I > > > > > > > > > > > B37-04,IFG0554A,IBMUSE1,S02,SYSREC01,9D96,ND0016,E6002130,IBMUSER.NDSP.D > > > > ATA > > > > > > > > > > But if DBA submit the same job with space parameters as > > > > > > > > > > //SYSREC01 DD DSN=IBMUSER.NDSP.DATA, > > > > > // DISP=(NEW,CATLG,DELETE), > > > > > // SPACE=(CYL,(2000,1800),RLSE), > > > > > // UNIT=(DISK,40) > > > > > > > > > > Then the JOB completes with RC 00. > > > > > > > > > > Please note that the only diff is of UNIT parameter. Can anyone > > > > explain me > > > > > why this happens ? > > > > > > > > > > John > > > > > > > > Yes, the difference is not the "DISK", but the "40". Your ACS > > routines > > > > appanrently don't provide you with a multivolume dataset. > > > > > > > > Kees. > > > > > > ** > > > > For information, services and offers, please visit our web site: > > > > http://www.klm.com. This e-mail and any attachment may contain > > > > confidential and privileged material intended for the addressee > > > > only. If you are not the addressee, you are notified that no part > > > > of the e-mail or any attachment may be disclosed, copied or > > > > distributed, and that any other action related to this e-mail or > > > > attachment is strictly prohibited, and may be unlawful. If you have > > > > received this e-mail by error, please notify the sender immediately > > > > by return e-mail, and delete this message. > > > > > > > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries > > > > and/or its employees shall not be liable for the incorrect or > > > > incomplete transmission of this e-mail or any attachments, nor > > > > responsible for any delay in receipt. > > > > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal > > > > Dutch Airlines) is registered in Amstelveen, The Netherlands, with > > > > registered number 33014286 > > > > > > ** > > > > > > > > > > -- > > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN > > INFO > > > > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > > > > > > > > > -- > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > > > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > ** > > For information, services and offers, please visit our web site: > > http://www.klm.com. This e-mail and any attachment may contain > > confidential and privileged material intended for the addressee > > only. If you are not the addressee, you are notified that no part > > of the e-mail or any attachment may be disclosed, copied or > > distributed, and that any other action related to this e-mail or > > attachment is strictly prohibited, and may be unlawful. If you have > > received this e-mail
First time I am running rmf III in this shop
I'm getting this error message when I try to select rmf III from the main RMF monitor menu. There's nothing in the log or the output from my tso session. This works on one of our lpars and fails on the other two. TIA Unable to allocate file ADMGDF. Contact your system administrator. *** Ken Klein Sr. Systems Programmer Kentucky Farm Bureau Insurance - Louisville 1 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Peter Relson Sent: Tuesday, June 23, 2009 8:20 AM To: IBM-MAIN@bama.ua.edu Subject: Re: What's Needed in Linklst? As far as IPLing is required, the only required data sets are SYS1.LINKLIB (and the SYSLIB LINKLIB data set identified in PROGxx, if different) SYS1.MIGLIB (and the SYSLIB MIGLIB data set identified in PROGxx, if different) SYS1.CSSLIB (and the SYSLIB CSSLIB data set identified in PROGxx, if different) SYS1.SIEALNKE (and the SYSLIB LINKLIBE data set identified in PROGxx, if different) SYS1.SIEAMIGE (and the SYSLIB MIGLIBE data set identified in PROGxx, if different) Lack of these data sets will result in a wait state (code 0A with message IEA716I).. Basically, it's those data sets that are placed by the system, or required to be there, in (almost) all circumstances into every LNKLST set. All the other data sets that have been shown likely relate to a properly running system with all the various z/OS elements. So they're likely "necessary" in some way but won't result in an IPL-time wait state Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: And you ask why I hate OMVS?
I usually enter the command: F OMVS,SHUTDOWN And every UNIX process starts dying. But other than TCPIP, FTP, and TN3270, we don't run much UNIX stuff. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * (817)-961-6183 cell john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: First time I am running rmf III in this shop
Has RMFGAT been started (F RMF,S III)? Jim Horne Systems Programmer Large Systems Engineering & Messaging NC4IT Lowe's Companies, Inc. 1000 Lowe's Boulevard Mooresville, NC 704-758-5354 jim.ho...@lowes.com Ken Klein wrote: I'm getting this error message when I try to select rmf III from the main RMF monitor menu. There's nothing in the log or the output from my tso session. This works on one of our lpars and fails on the other two. TIA Unable to allocate file ADMGDF. Contact your system administrator. *** NOTICE: All information in and attached to the e-mail(s) below may be proprietary, confidential, privileged and otherwise protected from improper or erroneous disclosure. If you are not the sender's intended recipient, you are not authorized to intercept, read, print, retain, copy, forward, or disseminate this message. If you have erroneously received this communication, please notify the sender immediately by phone (704-758-1000) or by e-mail and destroy all copies of this message (electronic, paper, or otherwise). Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
AutoIPL
I am reading "z/OS 1.10 MVS Planning: Operations" about exploiting the Automatic IPL function and it alludes to all z10s but only z9 EC machines. Can someone verify for me that this function, indeed, *does not* support z9 BC machines? On ECs, it states feature code 9904 and Driver 67. Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ICHRIN03 not loading in the LPA correctly.
On Tue, Jun 23, 2009 at 1:21 PM, Barbara Nitz wrote: > Init&Tuning Reference: > > The LPALIB data set is always the first data set in the concatenation > (see "Using the SYSLIB statement" in topic 67.3). Unless overridden by a > SYSLIB statement in PROGxx, the LPALST concatenation begins with > SYS1.LPALIB. If you do not use SYSLIB and place the LPALIB data set > name on any record in any LPALSTxx member, the name is ignored. > > So I guess the module is found at IPL from the one in SYS1.LPALIB, not the > one from your user.lpalib. > > Barbara > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > Barbara, thanks very much. I had probably known that at some stage and forgotten it. Thanks again. Jim McAlpine -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: AutoIPL
"Richards, Robert B." wrote in message news:<538523e4ec70a1409a113c09a9179a970b80c...@wdcvexvs2.opm.gov>... > I am reading "z/OS 1.10 MVS Planning: Operations" about exploiting the > Automatic IPL function and it alludes to all z10s but only z9 EC > machines. > > > > Can someone verify for me that this function, indeed, *does not* support > z9 BC machines? On ECs, it states feature code 9904 and Driver 67. > > > > Bob My Parallel Sysplex Update 2008 tells me that it is available on "z9 and z10" machines, no further specifications or restrictions. Kees. ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: And you ask why I hate OMVS?
When all else fails: F OMVS,SHUTDOWN It will kick the skids out from under anything that is running! Not graceful, but effective. I've never had to issue it more that twice in a shutdown cycle... HTH, Subject: And you ask why I hate OMVS? This past weekend I had the dubious honour of shutting down and IPLing 5 systems, two of them with USS work. The shutting down part was really bad (now I know why our operators keep complaining). One lpar has my favourite hate-application running (called WBIFN, for all you European SWIFT customers). Around seven minutes into the shutdown (another lpar with similar workload but not this appliaction was already down after 7 minutes) D A,L revealed that there were some DB2s plus WBIFN still running plus the necessary system infrastructure. And one thing with the jobname of a TSO user, but OMVSEX in the step info, so the userid belonged to some USS process? thread? application? And they seemend to multiply while I was looking at them. Canceling any of them didn't really help, never mind that the duplicate jobname requires using the asid, which requires a list first. By the time I get around to killing the pid, it's already gone. Then I saw that *something* still had open DB2 threads, for which automation has made provisions and forces things out. So I thought that this must be related to this user. Given that I couldn't stop it from multiplying, much less get out of the system (f bpxoinit,shutdown=forkinit was replied with 'shutdown delayed'), I shut down the fork service. That stopped the multiplication, but a few of those 'user asids with a number' were still around. And it was a VERY bad idea to shutdown the fork service, as that effectively prevented WBIFN from terminating eventually (it never terminates in a timely manner, anyway). I ended up canceling things, which generated tons of coredumps which filled the directory, which eventually prevented the startup of this application. (And no, these useless coredumps cannot be prevented, believe me, I've tried.) The good news was that after 20 minutes I had WBIFN and that userid shut down, and then automation did the rest (in the case of our operators, they never get automation to do 'the rest'). So how are other installations handling system shutdown when there are active USS users (or at least their leftover processes)? For a 'pure' MVS, I can shutdown TSO and the Initiators, cancel any running batch jobs, and I am done. But how do I stop the USS things from multiplying? And this Tuesday, that users leftover processes are back. I tried killing the top one (right under ppid=1), but that only resulted in another process under ppid=1 (that killed process was just dropped). superkill didn't help, either. Isn't there any surefire way to get the whole tree stopped in one fell swoop? (and no, I won't kill pid 1). (An OMVS ignoramus is asking this, so please be gentle with me) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: HYPERPAV Definitions
On Tue, 23 Jun 2009 00:13:45 -0400, Jim Mulder wrote: s from Jim Mulder. >> > >> >> I need to go back and check, but I think for normal use of HYPERPAV, >> WLMPAV=YES is irrelevant. There was an issue related to page data >> sets only and that was why I think Jim suggested to leave it on >> in WLM and HCD at the time. That may have been fixed for z/OS 1.10. > > The HYPERPAV page data set issue has not yet been fixed in >any release of z/OS. > Thanks. I'll have to see what we used in our sysplexes that were using WLM PAVs prior to HYPERPAV. I'm fairly sure that WLMPAV=YES was left on because we weren't sure if we were going to get someone to pay for HYPERPAV when we started our latest DASD migration. In some of our other sysplexes, we shared DASD between sysplexes so WLM PAVs were never turned on anyway and we used static PAVs. I don't think it would be a concern if we lost the 2nd set of I/O control blocks in the (previously) WLM PAV sysplexes since we don't page much and local page data sets are entire 3390-27 volumes these days (1 local per volume). The other sysplexes sharing DASD had static PAVs and ASM would have never used them regardless, so we didn't lose anything by not specifying WLMPAV=YES when we migrated to HYPERPAV in those environments. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: First time I am running rmf III in this shop
Yes, thanks. The three lpars share catalogs and once one of the lpars allocates the dataset, the others enque on it. I want to put a system symbolic like &sysname in the data set names. Did you get all done moving down from Wilkesboro? Ken Klein Sr. Systems Programmer Kentucky Farm Bureau Insurance - Louisville kenneth.kl...@kyfb.com 502-495-5000 x7011 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Horne, Jim - James S Sent: Tuesday, June 23, 2009 8:29 AM To: IBM-MAIN@bama.ua.edu Subject: Re: First time I am running rmf III in this shop Has RMFGAT been started (F RMF,S III)? Jim Horne Systems Programmer Large Systems Engineering & Messaging NC4IT Lowe's Companies, Inc. 1000 Lowe's Boulevard Mooresville, NC 704-758-5354 jim.ho...@lowes.com Ken Klein wrote: I'm getting this error message when I try to select rmf III from the main RMF monitor menu. There's nothing in the log or the output from my tso session. This works on one of our lpars and fails on the other two. TIA Unable to allocate file ADMGDF. Contact your system administrator. *** NOTICE: All information in and attached to the e-mail(s) below may be proprietary, confidential, privileged and otherwise protected from improper or erroneous disclosure. If you are not the sender's intended recipient, you are not authorized to intercept, read, print, retain, copy, forward, or disseminate this message. If you have erroneously received this communication, please notify the sender immediately by phone (704-758-1000) or by e-mail and destroy all copies of this message (electronic, paper, or otherwise). Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: And you ask why I hate OMVS?
On Tuesday 23 June 2009, Andy Robertson wrote:
> We use this, Barbera
>
> Might help
>
> I hope email code page problems don't trash the special characters
> I'm using . . .
Looks clean except for all those pound sterling symbols, which need
to be changed to dollar signs.
Cheers,
Bob
>
>
> * Top of Data
>
> #
> # shell script to bring down daemon if running
> #
> set -x
>
> #
> #
> # the following finds the pids by piping the output of ps -ef through
> # three greps (pattern matching) and an awk (to get the second
> column). # The two extra greps filter out the grep process itself and
> the # jlp_killprocess
> #
> #
> pids=`ps -ef|grep £1|grep -v grep|grep -v jlp_killprocess\
>
> |awk '{print £2}'`
>
> # pids is now the process id(s) of the syslog daemon(s) running
>
> running=0
> for pid in £pids
> do
> running=1
> done
> if test £running -eq 0
> then
> echo "jlp_killprocess: "£1" is not running "
> exit 0
> fi
>
>
> echo "jlp_killprocess: issueing kill for "£pids
> for pid in £pids
> do
> kill -s TERM £pid
> done
> sleep 10
> for pid in £pids
> do
> kill -s KILL £pid
> done
> sleep 5
>
>
> # check to make sure it ain't there any more . . .
>
> pids=`ps -ef|grep £1|grep -v grep|grep -v jlp_killprocess\
>
> |awk '{print £2}'`
>
> running=0
> for pid in £pids
> do
> running=1
> done
> if test £running -eq 0
> then
> echo "jlp_killprocess: "£1" has been killed "
> exit 0
> fi
>
> echo "jlp_killprocess: "£1" - kill failed "
> exit 12
>
> Bottom of Data
> ***
>
>
>
>
>
>
>
>
> Andy Robertson telephone mobile 0777 214 9545 home
> 01308 420797
>
>
>
> -IBM Mainframe Discussion List wrote:
> -
>
>
> To: IBM-MAIN@bama.ua.edu
> From: David Crayford
> Sent by: IBM Mainframe Discussion List
> Date: 06/23/2009 11:41AM
> Subject: Re: And you ask why I hate OMVS?
>
> Barbara Nitz wrote:
> > My shutting down the fork service brought WBIFN to a halt, and
> > probably rightly so. On the other hand, a 'real' MVS component
> > would have had recovery in place with provisions for that service
> > happening and
>
> terminating all
>
> > on its own. Just think of the lengths IMS goes to *not* to have an
> > MPR canceled from under it!
>
> IMS and it's BPE framework has it's hooks firmly in OMVS. IMS Connect
> cannot run without it. An IMS Java MPP/BPP requires OMS (anybody
> using IMS Java?). As Aussie Shane noted, the horse has bolted (you
> just can't avoid it).
>
> BTW, I enjoy reading your posts very much. You are obviously a good
> value expert. There's nothing better than a customer use case when
> things suck. IBM should take notice!
>
> -
>- For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>
> *
>* This email is confidential and may contain copyright material of the
> John Lewis Partnership. If you are not the intended recipient, please
> notify us immediately and delete all copies of this message. (Please
> note that it is your responsibility to scan this message for
> viruses). Email to and from the John Lewis Partnership is
> automatically monitored for operational and lawful business reasons.
> *
>*
>
> John Lewis plc
> Registered in England 233462
> Registered office 171 Victoria Street London SW1E 5NN
>
> Websites: http://www.johnlewis.com
> http://www.waitrose.com
> http://www.greenbee.com
> http://www.johnlewispartnership.co.uk
>
> *
>*
>
> -
>- For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: And you ask why I hate OMVS?
On Tue, 23 Jun 2009 04:22:35 -0500, Barbara Nitz wrote: Isn't >there any surefire way to get the whole tree stopped in one fell swoop? F OMVS,SHUTDOWN? That is what we do. We don't even shutdown ZFS (shutting down OMVS takes care of ZFS and there was a timing bug with shared file systems in the recent past and this was the suggested work around). Of course automation tries to take things down in the correct order first to eliminate unix processes and then displays them at the end and tries to get rid of any stragglers if they exist, but 'F OMVS,SHUTDOWN' is still the last thing done. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: And you ask why I hate OMVS?
On Tue, 23 Jun 2009 06:46:24 -0400, Pinnacle wrote: >- Original Message - >From: "Barbara Nitz" >Newsgroups: bit.listserv.ibm-main >Sent: Tuesday, June 23, 2009 5:23 AM >Subject: And you ask why I hate OMVS? > > >> This past weekend I had the dubious honour of shutting down and IPLing 5 >> systems, two of them with USS work. The shutting down part was really bad >> (now I know why our operators keep complaining). >> > > >Barbara, > >There is a job that used to be on the USS Tools and Toys pages that would >run a BPX batch step to kill all active tasks. I don't have the job handy, >but I'll see if I can track it down and send it to you. I only ran it when >the shutdown forkinit didn't work, but it usually nuked any OMVS process >that was hanging up shutdown. Check out Zelden's page, he may have it >there. You're thinking of BPXSTOP. We used that a long time ago. It may cause a problem with shared file systems. Our old shutdown used to be: F BPXOINIT,SHUTDOWN=FORKINIT F BPXOINIT,SHUTDOWN=FILESYS S BPXSTOP Now we just use "F OMVS,SHUTDOWN" The z/OS Unix System Services Planning manual has information about planned shutdowns using both methods. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ICHRIN03 not loading in the LPA correctly.
On Tue, Jun 23, 2009 at 1:43 PM, Jim McAlpine wrote: > >> > Barbara, thanks very much. I had probably known that at some stage and > forgotten it. > > Thanks again. > > Jim McAlpine > I obviously had known that as I have a procxx member containing a SYSLIB statement in my z/OS 1.7 system. Isn't getting older wonderful. Jim McAlpine -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ICHRIN03 not loading in the LPA correctly.
On Tue, 23 Jun 2009 13:09:17 +0100, Jim McAlpine wrote: >The one in SYS1.LPALIB is 8 bytes long and is 8 bytes of low values. But the >lpalstxx member has the USER.LPALIB first like so - > >USER.LPALIB, >ADCD.Z19S.LPALIB, >EQA810.SEQALPA(S9RES1), >SYS1.LPALIB, >SYS1.SERBLPA, >NET530.SCNMLPA1(S9RES2), >FAN140.SEAGLPA(S9RES1), >ISF.SISFLPA(S9RES1), >EOY.SEOYLPA(S9RES2), >SYS1.SBDTLPA, >CEE.SCEELPA(S9RES2), >ISP.SISPLPA(S9RES1), >TCPIP.SEZALPA(S9RES1), >SYS1.SORTLPA, >SYS1.SDWWDLPA, >SYS1.SICELPA >why would the search not be in the sequence of the libraries above ??? > PROGxx SYSLIB LPALIB() could put a library ahead of those defined in LPALSTxx. IEALPAxx could load something in MLPA. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: AutoIPL
Kees, Okay, now we have conflicting documentation, which, on paper, is an improvement! :-) However, I still need to know if anyone is actually able to exploit AutoIPL with a z9 BC machine. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Vernooij, CP - SPLXM Sent: Tuesday, June 23, 2009 8:43 AM To: IBM-MAIN@bama.ua.edu Subject: Re: AutoIPL "Richards, Robert B." wrote in message news:<538523e4ec70a1409a113c09a9179a970b80c...@wdcvexvs2.opm.gov>... > I am reading "z/OS 1.10 MVS Planning: Operations" about exploiting the > Automatic IPL function and it alludes to all z10s but only z9 EC > machines. > > > > Can someone verify for me that this function, indeed, *does not* support > z9 BC machines? On ECs, it states feature code 9904 and Driver 67. > > > > Bob My Parallel Sysplex Update 2008 tells me that it is available on "z9 and z10" machines, no further specifications or restrictions. Kees. ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: And you ask why I hate OMVS?
On Tue, 23 Jun 2009 04:22:35 -0500, Barbara Nitz wrote: >This past weekend I had the dubious honour of shutting down and IPLing 5 >systems, two of them with USS work. The shutting down part was really bad >(now I know why our operators keep complaining). > Just a brief comment that, as far as I know, the z/OS UNIX experts within IBM do not watch IBM-MAIN, so if you want your message (and frustrations) to reach them you probably should use the MVS-OE mailing list instead. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS Dataset Allocation Problem
John, A lot of SMS sites provide for multi-volume allocation in the default DATACLAS, but 40 would be unusually high Unit Count to provide all datasets. SMS has not changed the way JCL works however, so if you need a multi-volume dataset with more volumes than the DATACLAS provides, you just use your own value in the Unit Count parm. I'd suggest omitting the ESOTERIC this may be restricted to a subset of available volumes in the SMS STORGRUP. The following JCL is what I would suggest using: //SYSREC01 DD DSN=IBMUSER.NDSP.DATA, // DISP=(NEW,CATLG,DELETE), // SPACE=(CYL,(2000,1800),RLSE), // UNIT=(,40) This is not an SMS problem. DATACLAS provides some defaults that reduce JCL coding, but if you want something other than the DATACLAS values there is nothing stopping you overriding the JCL. Ron > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of > Vernooij, CP - SPLXM > Sent: Tuesday, June 23, 2009 5:21 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: [IBM-MAIN] SMS Dataset Allocation Problem > > Yes, that is the SMS technical side. > I understood that John is an ignorant SMS user, so for him there are > only the defined/published dataclasses to select from. > > Kees. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: And you ask why I hate OMVS?
On Tue, 2009-06-23 at 08:50 -0500, Walt Farrell wrote: > ... if you want your message (and frustrations) to > reach them you probably should use the MVS-OE mailing list instead. And have us all miss out on the entertainment ?. How's that fair ?. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS Dataset Allocation Problem
A B37-04 says you did not successfully get all the space needed for the primary allocation on the 1st volumes. Products like DTS Software, STOPX37, etc can also help prevent these types of failures. When SPACE= is coded you have 5 extents to get the primary allocation on the volume. The secondary space allocation has upto (I think) 123 extents to get it. But when you go after the primary allocation, you need to do it in 5 extents. This can be avoided by codind VOLUME COUNT in Data class, or using a software product like STOPX37. When the pack or pool is fragmented, small chunks of storage is available, then it is possible you can not get 2000 cylinders in 5 extents. Hence the SB37-04 To correct this you can code your Data Class to allow more volumes (canidates) to be available to your files. In one of my Data Class definitions I have Data Class Name : DB2VOLS Description : MULTI VOLUMES FOR DB2 LINEAR DATA SETS Recfm . . . . . . . . . : Lrecl . . . . . . . . . : Space Avgrec . . . . . . : Avg Value . . . . : Primary . . . . . : Secondary . . . . : Directory . . . . : Retpd Or Expdt . . . . . : Volume Count . . . . . . : 50 Add'l Volume Amount . . : The VOLUME COUNT tells SMS to use upto 50 more volumes before failure. Hope this helps. Lizette >Hi Kees, >Thanks for this. But what is meant by "Your ACS routines appanrently don't >provide you with a multivolume dataset" > >John > > >> > We have IBMUSER.NDSP.** defined as SMS Managed datasets. >> > >> > My DBA trying to allocate SMS Managed dataset with space as >> > //SYSREC01 DD DSN=IBMUSER.NDSP.DATA, >> > // DISP=(NEW,CATLG,DELETE), >> > // SPACE=(CYL,(2000,1800),RLSE) >> > >> > The job is failing with error >> > IEC030I >> > >> B37-04,IFG0554A,IBMUSE1,S02,SYSREC01,9D96,ND0016,E6002130,IBMUSER.NDSP.D >> ATA >> > >> > But if DBA submit the same job with space parameters as >> > >> > //SYSREC01 DD DSN=IBMUSER.NDSP.DATA, >> > // DISP=(NEW,CATLG,DELETE), >> > // SPACE=(CYL,(2000,1800),RLSE), >> > // UNIT=(DISK,40) >> > >> > Then the JOB completes with RC 00. >> > >> > Please note that the only diff is of UNIT parameter. Can anyone >> explain me >> > why this happens ? >> > >> > John >> >> Yes, the difference is not the "DISK", but the "40". Your ACS routines >> appanrently don't provide you with a multivolume dataset. >> >> Kees. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS Dataset Allocation Problem
"Lizette Koehler" wrote in message news:<14824640.1245766523930.javamail.r...@elwamui-darkeyed.atl.sa.earth link.net>... > A B37-04 says you did not successfully get all the space needed for the primary allocation on the 1st volumes. Products like DTS Software, STOPX37, etc can also help prevent these types of failures. > > When SPACE= is coded you have 5 extents to get the primary allocation on the volume. The secondary space allocation has upto (I think) 123 extents to get it. But when you go after the primary allocation, you need to do it in 5 extents. This can be avoided by codind VOLUME COUNT in Data class, or using a software product like STOPX37. > > When the pack or pool is fragmented, small chunks of storage is available, then it is possible you can not get 2000 cylinders in 5 extents. Hence the SB37-04 > > To correct this you can code your Data Class to allow more volumes (canidates) to be available to your files. > Correction: "this" cannot be corrected with multivolume datasets. A next volume will be taken when a *secondary* extent does not fit anymore. Kees. ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Looking for an MVS Wizard ICON (not what you think)
Lizette, here are two more. Mary Anne http://www.snowcrest.net/kitty/hpages/hpic3/tinywiz1.gif http://www.animationplayhouse.com/merrly.gif On Tue, Jun 23, 2009 at 10:29 AM, Mary Anne Matyaz wrote: > Here are a couple from the old z/os wizard web pages. > Gmail won't let me imbed pics so I'm attaching as a word doc. > > Mary Anne > > On Mon, Jun 22, 2009 at 4:52 PM, Lizette Koehler < > stars...@mindspring.com> wrote: > >> I am working on a web page and thought it would be fun to put a figure of >> a Wizard preforming MVS Magic. I would like it animated if possible. You >> know a little guy/gal that has a wand making magical motions over a CPU or >> MVS Operating system. >> >> The web searches I have done have billions and billons for WIZARD but not >> what I am looking for. >> >> Does anyone know where I can find animated (or not) images to put on >> webpages related to MVS??? >> >> Lizette >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO >> Search the archives at http://bama.ua.edu/archives/ibm-main.html >> > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS Dataset Allocation Problem
The other option might be the SPACE CONSTRAINT Parameter within the DATA CLASS. Spreading the requested quantity over multiple volumes Allocating a percentage of the requested quantity Using more than 5 extents Space Constraint Relief specifies whether or not to retry an allocation that was unsuccessful due to space constraints on the volume. Note that allocation is attempted on all candidate volumes before it is retried. This attribute applies only to system- managed data sets, and is limited to new data set allocations, and while extending the data set on new volumes. Y specifies that SMS retry the allocation. N specifies that SMS does not retry the allocation, so that allocation is not attempted on multiple volumes. This is the default. Reduce Space Up to (%) specifies the amount by which you want to reduce the requested space quantity when the allocation is retried. You must specify Y for the Space Constraint Relief attribute. Valid values are 0 to 99. If you request space constraint relief but do not specify a percentage value (either 0 or blank), SMS does not reduce the requested space quantity. This implies your application cannot tolerate a reduction in the space to be allocated, so only the 5 extent limit is relieve Data Class Name . . : DB2VOLS Data Set Name Type . . . . . : If Extended . . . . . . . . : Extended Addressability . . : NO Record Access Bias . . . . : Space Constraint Relief . . . : YES Reduce Space Up To (%) . . : 20 Dynamic Volume Count . . . : Compaction . . . . . . . . . : Spanned / Nonspanned . . . . : Media Interchange Media Type . . . . . . . . : Recording Technology . . . : Performance Scaling . . . . : Performance Segmentation . : And the last area you might look at is EXTENT CONSTRAINT REMOVAL Data Class Name : DB2VOLS Reuse . . . . . . . . . . . : NO Initial Load . . . . . . . . : RECOVERY BWO . . . . . . . . . . . . : Log . . . . . . . . . . . . : Logstream Id . . . . . . . . : FRlog . . . . . . . . . . . : RLS CF Cache Value . . . . . : ALL RLS Above the 2-GB Bar . . . : NO Extent Constraint Removal . : NO Lizette >> A B37-04 says you did not successfully get all the space needed for >the primary allocation on the 1st volumes. Products like DTS Software, >STOPX37, etc can also help prevent these types of failures. >> >> When SPACE= is coded you have 5 extents to get the primary allocation >on the volume. The secondary space allocation has upto (I think) 123 >extents to get it. But when you go after the primary allocation, you >need to do it in 5 extents. This can be avoided by codind VOLUME COUNT >in Data class, or using a software product like STOPX37. >> >> When the pack or pool is fragmented, small chunks of storage is >available, then it is possible you can not get 2000 cylinders in 5 >extents. Hence the SB37-04 >> >> To correct this you can code your Data Class to allow more volumes >(canidates) to be available to your files. >> > >Correction: "this" cannot be corrected with multivolume datasets. A next >volume will be taken when a *secondary* extent does not fit anymore. > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: And you ask why I hate OMVS?
With respect, you guys just don't quite get it. Barbara was not particularly bashing zUnix (pun intended). -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of David Crayford Sent: Tuesday, June 23, 2009 5:28 AM To: IBM-MAIN@bama.ua.edu Subject: Re: And you ask why I hate OMVS? Ahhhaaa, you named and shamed and I didn't have to *search the archives*! A lot of the Websphere portfolio doesn't port well to z/OS. I have anecdotal evidence (I was told by an IBMer) that Websphere messaage broker runs like a stallion on AIX but sucks big time on z/OS. Having said that, I still maintain that zUnix is reasonably solid. It comes down to quality of implementation, and that means tailoring for the z/OS platform. NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: And you ask why I hate OMVS?
On Tue, 23 Jun 2009 04:22:35 -0500, Barbara Nitz wrote: > >So how are other installations handling system shutdown when there are >active USS users (or at least their leftover processes)? For a 'pure' MVS, I >can >shutdown TSO and the Initiators, cancel any running batch jobs, and I am >done. But how do I stop the USS things from multiplying? > >(An OMVS ignoramus is asking this, so please be gentle with me) > a conventional UNIX system's shutdown procedure sends SIGTERM to all user processes. o Those that catch SIGTERM can perform orderly shutdown. o For those that don't catch SIGTERM (the default), SIGTERM is immediately fatal. After a minute or so, it sends SIGKILL. This is very similar to Andy Robertson's script. This is like STOP or MODIFY to all STCs. Superuser processes are brought down later. BSD and Linux are more elaborate, with a "runlevel" characteristic to bring down daemons in approximately the reverse order they started in. I once suggested in MVS-OE that MVS shutdown should likewise send SIGTERM to all dubbed processes to accommodate the prevailing UNIX custom. The suggestion received strong disapproval because so many address spaces nowadays get dubbed inadvertently and would suffer badly from an unexpected and uncaught SIGTERM. So, which to use: STOP, MODIFY, or SIGTERM; and in what order? Oil and water. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
SHARE Requirements and IBM
Today's email brings notice of several IBM responses to SHARE requirements. Many of these were rejected, including this one: SOMVSE85160 Title: TSO/E - Allow Multi-Level PREFIX Values Status: RJ-Rejected Text: IBM does not intend to provide a solution to this request for the following reason: Reject Reason : Business Justification Reject Explanation : We have not been able to implement this in twenty years. The odds are that it will not be implemented. External Response : Response Date: 19951108 Response: DATE--RESPONSE 8603 Long Range Consideration. Response entered on 19951108 at 16:15:58 RECOGNIZED Some 20+ years ago, I was working for an organization that wanted to do this, so that a separate catalog alias would not have to be established for each new TSO user. Some research showed that if the TSO PROFILE command would allow values such as PREFIX(SYS.CLK), we could implement a system where a catalog alias would only have to be established for the group (SYS), and not for the individual users within the group. Experimentation showed that the PROFILE command would not accept such a value, because of the way the PREFIX parameter was defined in the PARSE list. But a quick look at the source code (this was prior to OCO), showed that a small ZAP could be used to change the definition of the parameter so that a period was a accepted as a valid character. So one small USERMOD accomplished what we wanted to do. This does not mean the implementation was perfect. A new user would have to remember to change their PREFIX the first time they signed on, or they would not be able to create new data sets - this was eventually automated as part of LOGON processing. There were also 2-3 minor TSO commands that just would not work well with the prefix, and required special handling. And the prefix was still limited to a total of 7 characters. But for the most part, the USERMOD worked well, and accomplished what (I think) the writer of this requirement also wanted. So I had to chuckle when I read that IBM (with all of its resources) has not been able to figure this out for the past 20 years! I would be happy to share the USERMOD, but it was probably thrown out with my last box of punched cards. Also, based on this latest group of responses (4 out of 7 rejected), I'm wondering if IBM still considers requirements to be anything valuable, or whether they are just another annoyance that needs to be buried in paperwork for a decade and then rejected. It used to be that the requirements process was a valuable tool for setting future product direction, and I hope that will still be the case. Clark -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: INFOZIP >2Gb
>> /u/userid/zip31b: >zip -av -1 /tmp/BIG_FILE.zip "//'userid.BIG.FILE'" > Sadly, it's all a dead end, because it looks like zip can't handle > this kind of filename: > It looks like all that "dots" stuff in the filename handling code > needs another wrinkle added for full MVS + USS support. Bob, thanks for confirming that infozip in USS is unable to handle MVS files as I kept getting : zip warning: name not matched: //userid.BIG.FILE zip error: Nothing to do! (BIG_FILE.ZIP) was wondering perhaps I had gotten the syntax wrong. > See comments on the Info-ZIP forum where I offer some SWAG theorizing > about how I must have broken the name display -- and somebody (EG, I > think) explains the use of the 3 name fields. Thanks, I seen the comments made on the forum and changed z->oname to z->name which appears to resolve the display problem. > Maybe this weekend I can refresh my memory of what I did and send you a > proper diff. Thank you. Perhaps for a different thread, but INFOZIP related, anyone know if its possible : 1. to retain trailing blanks in the file for FB records ? 2. modify the current EBCDIC/ASCII translation table (eg. to change all non-keyboard characters to '?') Thanks to all for your reponses. Please Note: This email and its contents are subject to our email legal notice which can be viewed at http://www.sars.gov.za/Email_Disclaimer.pdf -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Any one using JDBC type 4 to access IMS DB??
What is the real goal? Cost reduction? The conventional wisdom is that you won't reduce costs. The application is the data. The supporting software is, well, just that. Trying to replicate data and keep it in sync is an expensive nightmare. Therefore, I would agree with Timothy and keep the database in one place then use data sharing facilities. You could try to invent your own, but why not exploit proven methods? By the way, the term 'open platform' seems to have fallen out of favor a while back. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Fermat Ma Sent: Tuesday, June 23, 2009 5:34 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Any one using JDBC type 4 to access IMS DB?? Hello Timothy, Thanks for replying. Actually, the goal is to migrate an application off to open platform. And the data updated on open platform also needs to be synch back to IMS. Therefore, we were thinking about using JDBC Type 4 driver. With that, there should be no need to develop mainframe programs. Fermat On Tue, Jun 23, 2009 at 2:30 PM, Timothy Sipples wrote: > It sounds like you have data-intensive applications, including batch and > online. If the goal is to add a Java environment to your application > runtime collection, then you have a couple choices. (And the choices can be > used in combination also.) > > One is that IMS Transaction Manager supports Java programming and has for > nearly 10 years now (since IMS V7), with progressive improvements as Java > has evolved. Java support is a base, standard feature provided with IMS and > z/OS at no additional charge. So if you want to write Java, go write Java. > You don't even have to phone IBM. (The same is true of CICS Transaction > Server and z/OS itself.) Just crack open the documentation and go for it. > It's darn easy, too: just 4 APIs from what I gather. With CICS look for > "JCICS" in your CICS documentation, and for z/OS look for the "JZOS > Cookbook" (Web search will find it) to get started. All this stuff is > standard, base function available at no additional charge. You've already > got it. > > Another is WebSphere Application Server for z/OS. The reason you should > consider WAS z/OS here very strongly (as opposed to WAS running elsewhere) > is that data-intensity you mentioned. You really want to try to avoid > taking trips over the wire for data access if you can avoid it. (Sometimes > you cannot avoid it, but you can certainly avoid it in this case.) Also, > financially you're very likely to do much better this way, at least in any > moderately responsible and competent cost analysis. > > - - - - - > Timothy Sipples > IBM Consulting Enterprise Software Architect > Based in Tokyo, Serving IBM Japan / Asia-Pacific > E-Mail: timothy.sipp...@us.ibm.com > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
How big of a staff do you have on your mainframe?
This might seem like an odd request- But, as part of the platform analysis we're undertaking, I'd like to gauge how our staff size compares with other companies' resource allocation to their mainframe. What I'd like to know is how many employees/contractors do various companies have supporting and working within their mainframe environment, broken down in a few broad categories. 1) application developers 2) system programmers 3) operators 4) any other staff specifically dedicated to the MF (B/A's, managers, etc) 5) contractors/consultants dedicated to your MF 6) total company employees Also, what operating system are you on? (VSE, z\OS, etc) For the record, our answers are 1) 4 2) 1 3) 0 4) 2 5) 1 6) 4100 and we're VSE, with about 40% of our total data processing taking place on our mainframe, and the remainder on other platforms. Thanks Bill Washburn -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: And you ask why I hate OMVS?
On Wed, 24 Jun 2009 00:12:37 +1000, Shane wrote: >On Tue, 2009-06-23 at 08:50 -0500, Walt Farrell wrote: > >> ... if you want your message (and frustrations) to >> reach them you probably should use the MVS-OE mailing list instead. > >And have us all miss out on the entertainment ?. >How's that fair ?. If you want the full entertainment value associated with z/OS UNIX you, too, should subscribe to MVS-OE, and then you won't miss anything :-) -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How big of a staff do you have on your mainframe?
On Tue, 23 Jun 2009 11:59:24 -0400, Bill Washburn wrote: >This might seem like an odd request- > >But, as part of the platform analysis we're undertaking, I'd like to gauge >how our staff size compares with other companies' resource allocation to >their mainframe. > There are more than a few vendors you can pay to do this analysis for you and come up with the same meaningless results you can get on IBM-MAIN. -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How big of a staff do you have on your mainframe?
> -Original Message- > From: IBM Mainframe Discussion List On Behalf Of Mark Zelden > > On Tue, 23 Jun 2009 11:59:24 -0400, Bill Washburn > wrote: > > >This might seem like an odd request- > > > >But, as part of the platform analysis we're undertaking, I'd like to gauge > >how our staff size compares with other companies' resource allocation to > >their mainframe. > > > > There are more than a few vendors you can pay to do this analysis for > you and come up with the same meaningless results you can get on > IBM-MAIN. But if the "paid advice" is worth the same as the "free advice", why pay? -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How big of a staff do you have on your mainframe?
Because management will consider meaningless advice to be credible if they have to pay for it. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Chase, John Sent: Tuesday, June 23, 2009 11:23 AM To: IBM-MAIN@bama.ua.edu Subject: Re: How big of a staff do you have on your mainframe? > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of Mark Zelden > > On Tue, 23 Jun 2009 11:59:24 -0400, Bill Washburn > wrote: > > >This might seem like an odd request- > > > >But, as part of the platform analysis we're undertaking, I'd like to gauge > >how our staff size compares with other companies' resource allocation to > >their mainframe. > > > > There are more than a few vendors you can pay to do this analysis for > you and come up with the same meaningless results you can get on > IBM-MAIN. But if the "paid advice" is worth the same as the "free advice", why pay? -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SHARE Requirements and IBM
Yes, we absolutely do still consider requirements valuable, and we DO use them when prioritizing work for upcoming releases. Buy me a beer at SCIDS in Denver and I'll tell you what happened with this one. Clark Kidd wrote: Today's email brings notice of several IBM responses to SHARE requirements. Many of these were rejected, including this one: SOMVSE85160 Title: TSO/E - Allow Multi-Level PREFIX Values Status: RJ-Rejected Text: IBM does not intend to provide a solution to this request for the following reason: Reject Reason : Business Justification Reject Explanation : We have not been able to implement this in twenty years. The odds are that it will not be implemented. External Response : Response Date: 19951108 Response: DATE--RESPONSE 8603 Long Range Consideration. Response entered on 19951108 at 16:15:58 RECOGNIZED Some 20+ years ago, I was working for an organization that wanted to do this, so that a separate catalog alias would not have to be established for each new TSO user. Some research showed that if the TSO PROFILE command would allow values such as PREFIX(SYS.CLK), we could implement a system where a catalog alias would only have to be established for the group (SYS), and not for the individual users within the group. Experimentation showed that the PROFILE command would not accept such a value, because of the way the PREFIX parameter was defined in the PARSE list. But a quick look at the source code (this was prior to OCO), showed that a small ZAP could be used to change the definition of the parameter so that a period was a accepted as a valid character. So one small USERMOD accomplished what we wanted to do. This does not mean the implementation was perfect. A new user would have to remember to change their PREFIX the first time they signed on, or they would not be able to create new data sets - this was eventually automated as part of LOGON processing. There were also 2-3 minor TSO commands that just would not work well with the prefix, and required special handling. And the prefix was still limited to a total of 7 characters. But for the most part, the USERMOD worked well, and accomplished what (I think) the writer of this requirement also wanted. So I had to chuckle when I read that IBM (with all of its resources) has not been able to figure this out for the past 20 years! I would be happy to share the USERMOD, but it was probably thrown out with my last box of punched cards. Also, based on this latest group of responses (4 out of 7 rejected), I'm wondering if IBM still considers requirements to be anything valuable, or whether they are just another annoyance that needs to be buried in paperwork for a decade and then rejected. It used to be that the requirements process was a valuable tool for setting future product direction, and I hope that will still be the case. Clark -- John Eells z/OS Technical Marketing IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How big of a staff do you have on your mainframe?
Unfortunately all too true. If their employees tell them something, they ignore it, but if a highly paid consultant tells them the exact same thing, then all of a sudden it becomes a godsend. - Original Message - From: "Hal Merritt" Newsgroups: bit.listserv.ibm-main To: Sent: Tuesday, June 23, 2009 12:29 PM Subject: Re: How big of a staff do you have on your mainframe? Because management will consider meaningless advice to be credible if they have to pay for it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How big of a staff do you have on your mainframe?
On 23 Jun 2009 09:24:39 -0700, jch...@ussco.com (Chase, John) wrote: >> There are more than a few vendors you can pay to do this analysis for >> you and come up with the same meaningless results you can get on >> IBM-MAIN. > >But if the "paid advice" is worth the same as the "free advice", why >pay? Blame control. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: INFOZIP >2Gb
There are commands (todsn and fromdsn) in our free Co:Z Toolkit for converting MVS datasets to/from Unix pipes, which you can redirect into infozip / gzip / bzip2. They offer all sorts of options like line termination rules, codepage conversion, padding/truncation rules, etc. See: http://dovetail.com/products/dspipes.html An example for converting a text dataset to Latin-1 ASCII using CR/LF as a line terminator and preserving trailing spaces: fromdsn -l crlf -k -s IBM-1047 -t ISO8859-1 //my.dsn | zip my.zip - And if you want to pipe to a dataset or DD, you can use the Co:Z Batch utility to put your shell script inline and work with DD names: // EXEC PGM=COZBATCH //INDD ... //OUT DD ... //STDIN DD * fromdsn -l crlf -k -s IBM-1047 -t ISO8859-1 //DD:IN | zip - - | todsn -b //DD:OUT // BTW: for me gzip or bzip2 works better for piped input, since zip creates a zip file with a single file named "-" in it. Of course, if you hate OMVS you won't like this ;-) Kirk Wolf Dovetailed Technologies http://dovetail.com PS> Sometimes when you need to deal with many combinations of compressing, encrypting, converting, and transfering datasets from z/OS its just easier (and cheaper) to offload processing to a Linux "gateway appliance". Here's an article from a past zJournal that discusses one approach: http://www.zjournal.com/index.cfm?section=article&aid=1075 On Tue, Jun 23, 2009 at 10:25 AM, Vikesh Bhoola wrote: > > Thank you. > > Perhaps for a different thread, but INFOZIP related, anyone know if its > possible : > 1. to retain trailing blanks in the file for FB records ? > 2. modify the current EBCDIC/ASCII translation table (eg. to change all > non-keyboard characters to '?') > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS Dataset Allocation Problem
>A lot of SMS sites provide for multi-volume allocation in the default >DATACLAS, but 40 would be unusually high Unit Count to provide all datasets. Why? I've worked in shops that set the default, through ACS, to the max (59). - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How big of a staff do you have on your mainframe?
That may be true in some environments. However, I *am* management. Sometimes answers are more solid coming from the experts (such as the lists I queried) than they are coming from a consulting company who oftentimes tries to give you the answer they think you want to hear, or position an answer as to lead you in a certain direction. Bottom line- I trust you guys more than a consulting co. Thanks for the replies so far, both on and offlist- they are far from meaningless. Hal Merritt To Sent by: IBM IBM-MAIN@bama.ua.edu Mainframe cc Discussion List Subject Re: How big of a staff do you have 06/23/2009 12:34 on your mainframe? PM Please respond to IBM Mainframe Discussion List Because management will consider meaningless advice to be credible if they have to pay for it. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Chase, John Sent: Tuesday, June 23, 2009 11:23 AM To: IBM-MAIN@bama.ua.edu Subject: Re: How big of a staff do you have on your mainframe? > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of Mark Zelden > > On Tue, 23 Jun 2009 11:59:24 -0400, Bill Washburn > wrote: > > >This might seem like an odd request- > > > >But, as part of the platform analysis we're undertaking, I'd like to gauge > >how our staff size compares with other companies' resource allocation to > >their mainframe. > > > > There are more than a few vendors you can pay to do this analysis for > you and come up with the same meaningless results you can get on > IBM-MAIN. But if the "paid advice" is worth the same as the "free advice", why pay? -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: And you ask why I hate OMVS?
Barbara, You could always list the omvs tasks by issuing D OMVS,A=ALL Followed by F BPXOINIT,TERM=identified-process-id and if term did not work, you could use F BPXOINIT,FORCE=identified-processs-id. But shutting down OMVS by issuing F OMVS,SHUTDOWN quiesce all the running process and shutsdown USS. Natarajan NOTICE OF CONFIDENTIALITY The information contained in this communication, including but not limited to any accompanying document(s) and/or attachment(s), is privileged and confidential and is intended solely for the above-named individual(s). If you are not the intended recipient, please be advised that any distribution, copying, disclosure, and/or use of the information contained herein is strictly prohibited. If you received this communication in error, please destroy all copies of the communication, whether in electronic or hard copy format, and immediately contact the Security Office at EDFUND at (916) 526-7539 or securityoff...@edfund.org. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
RMM and STGADMIN.EDG Resources
Mike Wood, We have been taking a careful look at RACF protection for RMM resources, specifically those protected by FACILITY class resources prefixed with STGADMIN.EDG. Based on our review of the z/OS 1.10 manuals and limited observed access activity, we've come to the following understanding as to how it works. We are hoping you can confirm or correct our interpretation of its functionality. 1) If a user has CONTROL access to STGADMIN.EDG.MASTER, the user automatically has CONTROL access to all of the following resources (and no others). Access permission to STGADMIN.EDG.MASTER is checked first, and if CONTROL has been granted, no further access checking is performed for these specific functions. STGADMIN.EDG.ACTIONS.action STGADMIN.EDG.AV.status.volser STGADMIN.EDG.CMOVE.location.destination STGADMIN.EDG.CRLSE.action STGADMIN.EDG.DV.SCRATCH.volser STGADMIN.EDG.INIT STGADMIN.EDG.LIST STGADMIN.EDG.MOVES.location.destination STGADMIN.EDG.MASTER STGADMIN.EDG.OWNER.userid STGADMIN.EDG.RELEASE 2) If a user has less than CONTROL access to STGADMIN.EDG.MASTER and attempts to access one of the resources listed above for which there is _no_ protecting RACF profile, the manuals seems to suggest RMM looks again at the user's level of access permission to STGADMIN.EDG.MASTER to decide whether to grant access. For instance, if a user attempts to perform a function governed by resource STGADMIN.EDG.ACTIONS.RETURN which would ordinarily require UPDATE permission and there is no RACF profile covering this resource, RMM will see if the user has UPDATE access to STGADMIN.EDG.MASTER and will allow the action if the user has this permission. Conversely, if the user only had READ access to STGADMIN.EDG.MASTER, the user wouldn't be allowed to perform the function. 3) Contrary to 2) above, if the user attempts to use CHANGEVOLUME on a volume the user does _not_ own, and the corresponding resource STGADMIN.EDG.OWNER.userid is _not_ defined to RACF, access is denied. UPDATE to STGADMIN.EDG.MASTER alone is insufficient. 4) If STGADMIN.EDG.LISTCONTROL is protected by a profile, the profile governs access. If not, the user requires CONTROL access to STGADMIN.EDG.MASTER to use it. 5) If the user attempts to use the FORCE operand and has UPDATE access to STGADMIN.EDG.FORCE, the user also needs CONTROL access to STGADMIN.EDG.MASTER to perform the function. 6) What is meant by "Based on STGADMIN.EDG.MASTER access." for access level of NONE to resource STGADMIN.EDG.OWNER.userid as stated in the DFSMSrmm Implementation and Customization Guide. Thank you for your time in helping us better understand RMM. Regards, Bob - Robert S. Hansel | 2009 RACF Training Lead RACF Specialist | > Intro & Basic Admin - Boston - SEPT 22-24 RSH Consulting, Inc. | > Audit for Results - Boston - NOV 3-5 www.rshconsulting.com | Visit our website for registration & details 617-969-8211 | - -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How big of a staff do you have on your mainframe?
Oh yuk, you've just unleashed a storm of Survey Spam. You should have asked for private replies. We might be interested in the summary but not the ongoing tabulation. updating my subject line filter. :-((( -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Bill Washburn Sent: Tuesday, June 23, 2009 10:59 AM To: IBM-MAIN@bama.ua.edu Subject: How big of a staff do you have on your mainframe? This might seem like an odd request- But, as part of the platform analysis we're undertaking, I'd like to gauge how our staff size compares with other companies' resource allocation to their mainframe. What I'd like to know is how many employees/contractors do various companies have supporting and working within their mainframe environment, broken down in a few broad categories. 1) application developers 2) system programmers 3) operators 4) any other staff specifically dedicated to the MF (B/A's, managers, etc) 5) contractors/consultants dedicated to your MF 6) total company employees Also, what operating system are you on? (VSE, z\OS, etc) For the record, our answers are 1) 4 2) 1 3) 0 4) 2 5) 1 6) 4100 and we're VSE, with about 40% of our total data processing taking place on our mainframe, and the remainder on other platforms. Thanks Bill Washburn -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.339 / Virus Database: 270.12.87/2195 - Release Date: 06/23/09 05:54:00 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS Dataset Allocation Problem
TIOT > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of > Ted MacNEIL > Sent: Tuesday, June 23, 2009 9:57 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: [IBM-MAIN] SMS Dataset Allocation Problem > > >A lot of SMS sites provide for multi-volume allocation in the default > DATACLAS, but 40 would be unusually high Unit Count to provide all datasets. > > Why? > I've worked in shops that set the default, through ACS, to the max (59). > - > Too busy driving to stop for gas! > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How big of a staff do you have on your mainframe?
Tony, I don't know about you, but the only responses I've seen on-list have been the chatter revolving around it. I haven't seen any actual numbers coming across the listserv. Maybe my filters are already hiding them. :-) Rex -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Tony B. Sent: Tuesday, June 23, 2009 12:07 PM To: IBM-MAIN@bama.ua.edu Subject: Re: How big of a staff do you have on your mainframe? Oh yuk, you've just unleashed a storm of Survey Spam. You should have asked for private replies. We might be interested in the summary but not the ongoing tabulation. updating my subject line filter. :-((( -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Bill Washburn Sent: Tuesday, June 23, 2009 10:59 AM To: IBM-MAIN@bama.ua.edu Subject: How big of a staff do you have on your mainframe? This might seem like an odd request- But, as part of the platform analysis we're undertaking, I'd like to gauge how our staff size compares with other companies' resource allocation to their mainframe. What I'd like to know is how many employees/contractors do various companies have supporting and working within their mainframe environment, broken down in a few broad categories. 1) application developers 2) system programmers 3) operators 4) any other staff specifically dedicated to the MF (B/A's, managers, etc) 5) contractors/consultants dedicated to your MF 6) total company employees Also, what operating system are you on? (VSE, z\OS, etc) For the record, our answers are 1) 4 2) 1 3) 0 4) 2 5) 1 6) 4100 and we're VSE, with about 40% of our total data processing taking place on our mainframe, and the remainder on other platforms. Thanks Bill Washburn -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How big of a staff do you have on your mainframe?
Interesting. We are VSE currently, moving to z/OS next year. 1) 21 (including 3 managers who are also developers) 2) 6 (3 VSE only, 2 z/OS only, 1 VSE and z/OS) 3) 6 (I think; 2 per shift, 3 shifts) 4) 1 (I didn't include the manager of systems/operations above) 5) 0 6) Hmm, about 2000 I think How does your business work without operators? Everything is automated? Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation Lakewood, CO USA P: 303-235-1403 F: 303-235-2075 On 6/23/2009 at 9:59 AM, in message , Bill Washburn wrote: > This might seem like an odd request- > > But, as part of the platform analysis we're undertaking, I'd like to gauge > how our staff size compares with other companies' resource allocation to > their mainframe. > > What I'd like to know is how many employees/contractors do various > companies have supporting and working within their mainframe environment, > broken down in a few broad categories. > > 1) application developers > 2) system programmers > 3) operators > 4) any other staff specifically dedicated to the MF (B/A's, managers, etc) > 5) contractors/consultants dedicated to your MF > 6) total company employees > > Also, what operating system are you on? (VSE, z\OS, etc) > > For the record, our answers are > 1) 4 > 2) 1 > 3) 0 > 4) 2 > 5) 1 > 6) 4100 > > and we're VSE, with about 40% of our total data processing taking place on > our mainframe, and the remainder on other platforms. > > > Thanks > > Bill Washburn > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html >>> The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Any one using JDBC type 4 to access IMS DB??
Well, I also agree with your guys too. But unfortunately, my assignment is to explore a do-able way to migrate off the mainframe. Client says,'We lack of mainframe skills. IMS not flexible to add a field. Migrate IMS to RDBMS involves re-write of programs. If so, why don't we move to midrange platform?' Of course, JDBC Type 4 is not as good as natiive access. But if the update volume is not too high, and service level acceptable. That will probably be a do-able method. That is why I hope to find some reference that are doing similar thing. However, I may have to prove to my client that it is simply not wise to do distribute the database across different platform and try to maintain one logical copy of the database in the first place. Fermat On Tue, Jun 23, 2009 at 11:55 PM, Hal Merritt wrote: > What is the real goal? Cost reduction? The conventional wisdom is that you > won't reduce costs. > > The application is the data. The supporting software is, well, just that. > Trying to replicate data and keep it in sync is an expensive nightmare. > > Therefore, I would agree with Timothy and keep the database in one place > then use data sharing facilities. You could try to invent your own, but why > not exploit proven methods? > > By the way, the term 'open platform' seems to have fallen out of favor a > while back. > > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of Fermat Ma > Sent: Tuesday, June 23, 2009 5:34 AM > To: IBM-MAIN@bama.ua.edu > Subject: Re: Any one using JDBC type 4 to access IMS DB?? > > Hello Timothy, > > Thanks for replying. Actually, the goal is to migrate an application off to > open platform. And the data updated on open platform also needs to be synch > back to IMS. Therefore, we were thinking about using JDBC Type 4 driver. > With that, there should be no need to develop mainframe programs. > > Fermat > > On Tue, Jun 23, 2009 at 2:30 PM, Timothy Sipples > wrote: > > > It sounds like you have data-intensive applications, including batch and > > online. If the goal is to add a Java environment to your application > > runtime collection, then you have a couple choices. (And the choices can > be > > used in combination also.) > > > > One is that IMS Transaction Manager supports Java programming and has for > > nearly 10 years now (since IMS V7), with progressive improvements as Java > > has evolved. Java support is a base, standard feature provided with IMS > and > > z/OS at no additional charge. So if you want to write Java, go write > Java. > > You don't even have to phone IBM. (The same is true of CICS Transaction > > Server and z/OS itself.) Just crack open the documentation and go for it. > > It's darn easy, too: just 4 APIs from what I gather. With CICS look for > > "JCICS" in your CICS documentation, and for z/OS look for the "JZOS > > Cookbook" (Web search will find it) to get started. All this stuff is > > standard, base function available at no additional charge. You've already > > got it. > > > > Another is WebSphere Application Server for z/OS. The reason you should > > consider WAS z/OS here very strongly (as opposed to WAS running > elsewhere) > > is that data-intensity you mentioned. You really want to try to avoid > > taking trips over the wire for data access if you can avoid it. > (Sometimes > > you cannot avoid it, but you can certainly avoid it in this case.) Also, > > financially you're very likely to do much better this way, at least in > any > > moderately responsible and competent cost analysis. > > > > - - - - - > > Timothy Sipples > > IBM Consulting Enterprise Software Architect > > Based in Tokyo, Serving IBM Japan / Asia-Pacific > > E-Mail: timothy.sipp...@us.ibm.com > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > NOTICE: This electronic mail message and any files transmitted with it are > intended > exclusively for the individual or entity to which it is addressed. The > message, > together with any attachment, may contain confidential and/or privileged > information. > Any unauthorized review, use, printing, saving, copying, disclosure or > distribution > is strictly prohibited. If you have received this message in error, please > immediately advise the sender by reply email and delete all copies. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with
Re: CICS SVC module name for Z/OS 1.6 CICS transaction server 23
Our CICS has two SVC's: a type 3 in LPA and a type 6 in the nucleus configured as sollows: We list SYS1.CICSTS.SDFHLPA in PARMLIB(LPALST00). In PARMLIB(IEASVC00) we have the following two lines: SVCPARM 214,REPLACE,TYPE(3),EPNAME(DFHCSVC) SVCPARM 215,REPLACE,TYPE(6),EPNAME(DFHHPSVC) In SYS1.IPLPARM(LOAD00) we added this one line: NUCLST 00 N (column dependent) Note that the trailing "N" indicates to not load a wait state if any modules in NUCLST00 can't be found. Our SYS1.IPLPARM(NUCLST00) has only this one line: INCLUDE DFHHPSVC DFHCSVC is in SDFHLPA and becomes SVC 214 as per IEASVC00. We copy DFHHPSVC from CICSTS.SDFHLOAD to SYS1.NUCLEUS via a USERMOD to the SYSRES's target zone. DFHHPSVC gets loaded as SVC 215 during the IPL as per SYS1.IPLPARM. We're at z/OS 1.9 and TS 3.1. IIRC we had the same config for previous releases. HTH, Alan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How big of a staff do you have on your mainframe?
-- This might seem like an odd request- But, as part of the platform analysis we're undertaking, I'd like to gauge how our staff size compares with other companies' resource allocation to their mainframe. What I'd like to know is how many employees/contractors do various companies have supporting and working within their mainframe environment, broken down in a few broad categories. 1) application developers 2) system programmers 3) operators 4) any other staff specifically dedicated to the MF (B/A's, managers, etc) 5) contractors/consultants dedicated to your MF 6) total company employees Also, what operating system are you on? (VSE, z\OS, etc) For the record, our answers are 1) 4 2) 1 3) 0 4) 2 5) 1 6) 4100 and we're VSE, with about 40% of our total data processing taking place on our mainframe, and the remainder on other platforms. For my last "real job": 1. 225 2. 4 3. 21 4. 6 5. 80 6. 300 The company was essentially a "Service Bureau" for the Chicago Board of Trade, but is no longer associated with CBOT, and was running z/OS 1.4 when I got "riffed". I cannot, and will not, discuss the firms that I've done contract work for since then. -- Rick -- Remember that if you’re not the lead dog, the view never changes. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 64-bit Common Storage in z/OS 1.10 (HVCOMMON)
Mark, We are in the process of updating the doc for 64-bit common apparently we missed the Extended Addressability Guide. There is information about the GETCOMMON parameter of IARV64 in "z/OS V1R10.0 MVS Programming Authorized Assembler Services Reference Vol 2 (EDTINFO-IXGWRITE)". Also my SHARE session "2818 - Common Storage Virtual Storage Constraint Relief (VSCR)" from the August 2008 San Jose Share contains information on 64-bit Common. Let me know if you have any additional questions. Elpida Tzortzatos z/OS Design/Development (RSM,ASM,VSM) email:elp...@us.ibm.com Phone: (845) 435-3125 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
smf layout question
I /we have a scheduleing system that is no longer "supported" ,well it is but it isn't. Anyway, something weird happened and the operator on dusty says he didn't do it. What happened was an external replay was given to release a certain part of the schedule. This all occurred Friday a.m. and I was off yesterday that is why I'm asking today. I've been through syslog, the scheduling systems log ,tcpip and several reports, but have found nothing to clear or blame the operator. I am tyring to clear him(he asked me to look into this). We do have some remotte logins and they could have done it but I have found no evidence. I know that smf collects everything but I wouldn't know where to start looking thanks Mace -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: INFOZIP >2Gb
On Tuesday 23 June 2009, Vikesh Bhoola wrote: > > > See comments on the Info-ZIP forum where I offer some SWAG > > theorizing about how I must have broken the name display -- and > > somebody (EG, I > > > > think) explains the use of the 3 name fields. > > Thanks, I seen the comments made on the forum and changed z->oname to > z->name which appears to resolve the display problem. Ah, but that I was just playing around with the code to see what would happen. Based on EG's comments, I've modified the function local_to_display_string in fileio.c to play nicer with EBCDIC - at least it seems nicer to me. That's the function that formats the z->oname string, so you should be able to back out that little hack. I've got a bunch of mods to the Unix version that I think are fairly clean, and I'm hoping to create a good set of diffs later today. I'll post then here and on the InfoZIP forum. I'd like to get some feedback from the developers who are familiar with the code, because there are still areas I'm not too sure about when it comes to large file support - like the encryption code, which never even uses the 64-bit functions (???). But, for the basic zip functions - adding, updating, deleting - under z/OS USS, it should be OK. Once that's done, I'll start looking at the cmsmvs side again. (My feeble brain was getting too confused trying to keep both sorted out at the same time.) Cheers, Bob Bob Woodside rwoodsi...@woodsway.com http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Reusing old 3590 Tapes
R.S. wrote: Richman, Saul pisze: Hello, Anyone with experience of re-using "old" tapes? Can we reuse physical 3590 Cartridges (High-Performance Model-B11) that have been stored for ca. 6 Years in Computer Room condition? Our (non-IBM) Engineer claims: "Old tapes that have been left in storage can damage the Drive heads in our VTS" True or False? The tapes come from a VTS B18 Machine that was decommissioned due to ahem, the collapse of Swissair… They had been used for only ca. 2 years. We have re-inserted ca. 30 cartriges, and had a handful of ejects so far. Whilst I'm here, our 2 current VTS B18 models are now approaching their 10th Birthday!! I'll be buying them a new Wii console and some chocolate and ice-cream .-)) Seriously, can any shop beat 10 years of continual VTS B18 Operations? Not a competition, just out of interest. 1. It has nothing to do with VTS, except the fact VTS uses real drives in real 3494 library. So the problem regards 3590 drives in the library. 2. See IBM statements about tape life periods. AFAIK your tapes did not exceeded any of them. 3. Risk of drive damage is FUD. Don't believe it. At worst your tapes will claim nonrecorverable errors. Of course the assumption that the tapes were stored in good conditions is crucial here. My $0.02 I agree the likelyhood of damaging a drive is unlikely if the tapes have been boxed and stored in the correct environmental conditions. I haven't had of any problems with 3590 media. Mind you the last time media gave me a serious problems was with 3420's. But the only way you are going to be sure the media is good is to verify the tape by writing to it and reading it back the data. It is would be better to find any problems now rather than wait until you get hit in production. Please feel free to contact me off list if you would like my recommendations. Tony. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: smf layout question
SMF collects everything it is told to collect. SYSLOG is not one of those items. If you have RACF OPERCMDS class active and being fully audited, you may find the command in the type 80 records. If the scheduling system has a user interface to say ISPF, items there may not be logged. I would look at SYSLOG and the schedulers logs. The RACF idea is a long shot. Dennis Roach GHG Corporation Lockheed Martin Mission Services Flight Design and Operations Contract NASA/JSC Address: 2100 Space Park Drive LM-15-4BH Houston, Texas 77058 Mail: P.O. Box 58487 Mail Code H4C Houston, Texas 77258 Phone: Voice: (281)336-5027 Cell: (713)591-1059 Fax:(281)336-5410 E-Mail: dennis.ro...@lmco.com All opinions expressed by me are mine and may not agree with my employer or any person, company, or thing, living or dead, on or near this or any other planet, moon, asteroid, or other spatial object, natural or manufactured, since the beginning of time. > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of larry macioce > Sent: Tuesday, June 23, 2009 1:24 PM > To: IBM-MAIN@bama.ua.edu > Subject: smf layout question > > I /we have a scheduleing system that is no longer "supported" ,well it > is > but it isn't. > Anyway, something weird happened and the operator on dusty says he > didn't do > it. > What happened was an external replay was given to release a certain > part of > the schedule. > This all occurred Friday a.m. and I was off yesterday that is why I'm > asking > today. > I've been through syslog, the scheduling systems log ,tcpip and several > reports, but have found nothing to clear or blame the operator. > I am tyring to clear him(he asked me to look into this). > We do have some remotte logins and they could have done it but I have > found > no evidence. > I know that smf collects everything but I wouldn't know where to start > looking > thanks > Mace > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: smf layout question
On Tue, 23 Jun 2009 14:24:15 -0400, larry macioce wrote: >I /we have a scheduleing system that is no longer "supported" ,well it is >but it isn't. >Anyway, something weird happened and the operator on dusty says he didn't do >it. >What happened was an external replay was given to release a certain part of >the schedule. >This all occurred Friday a.m. and I was off yesterday that is why I'm asking >today. >I've been through syslog, the scheduling systems log ,tcpip and several >reports, but have found nothing to clear or blame the operator. >I am tyring to clear him(he asked me to look into this). >We do have some remotte logins and they could have done it but I have found >no evidence. >I know that smf collects everything but I wouldn't know where to start >looking > thanks >Mace > Your comment about "...an external replay was given to release a certain part of the schedule." is ambiguous in reference to whether the "reply" was made within the scheduling system or as an MVS prompt reply. You should see MVS reply occurences in the SYSLOG with the TSO USERID or the console reference information. If the reply occurred within the scheduling system through some terminal interaction or batch interface request, it's more up to you to bird-dog that one. Scott Barry SBBWorks, Inc. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How big of a staff do you have on your mainframe?
In my shop, there is no new development. We support legacy applications on a small z9 running z/OS 1.9. I would say that 5% of the processing iremains on the mainframe. 1) ? (application support has been outsourced) 2) 2 3) 5 (they no longer cover the day shift) 4) dedicated = 0 (2 managers, 2 prodution support analysts) 5) 0 6) 25,000 On Tue, 23 Jun 2009 11:59 -0400, "Bill Washburn" wrote: > This might seem like an odd request- > > But, as part of the platform analysis we're undertaking, I'd like to gauge > how our staff size compares with other companies' resource allocation to > their mainframe. > > What I'd like to know is how many employees/contractors do various > companies have supporting and working within their mainframe environment, > broken down in a few broad categories. > > 1) application developers > 2) system programmers > 3) operators > 4) any other staff specifically dedicated to the MF (B/A's, managers, etc) > 5) contractors/consultants dedicated to your MF > 6) total company employees > > Also, what operating system are you on? (VSE, z\OS, etc) > > Thanks > > Bill Washburn -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How big of a staff do you have on your mainframe?
Re operations, we have about 10 minutes of 'traditional' operator tasks each day- loading and unloading the nightly DR/backup tapes, plus a couple hours of work on sundays to babysit a few tape reorgs which are too big to go disk-disk, and then kick off the weekly IPL. These tasks are performed by someone in our network dept. There are no production jobs or processes which require tapes or an operator- we have automated everything within a job submission system that puts everything into the hands of the users. When a user runs a batch 'job' off the menu, it asks questions to build the parameters, then runs, and then the user looks at the results in the list queue or some other CICS interface. We don't print anything for internal use- although if a user wants a printed copy of a report they are free to fire it off to their laser printer. So technically we don't have *zero* operator hours... but it is literally less than a tenth of an employee. Bill Frank Swarbrick To Sent by: IBM IBM-MAIN@bama.ua.edu Mainframe cc Discussion List Subject Re: How big of a staff do you have 06/23/2009 01:24 on your mainframe? PM Please respond to IBM Mainframe Discussion List Interesting. We are VSE currently, moving to z/OS next year. 1) 21 (including 3 managers who are also developers) 2) 6 (3 VSE only, 2 z/OS only, 1 VSE and z/OS) 3) 6 (I think; 2 per shift, 3 shifts) 4) 1 (I didn't include the manager of systems/operations above) 5) 0 6) Hmm, about 2000 I think How does your business work without operators? Everything is automated? Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation Lakewood, CO USA P: 303-235-1403 F: 303-235-2075 On 6/23/2009 at 9:59 AM, in message , Bill Washburn wrote: > This might seem like an odd request- > > But, as part of the platform analysis we're undertaking, I'd like to gauge > how our staff size compares with other companies' resource allocation to > their mainframe. > > What I'd like to know is how many employees/contractors do various > companies have supporting and working within their mainframe environment, > broken down in a few broad categories. > > 1) application developers > 2) system programmers > 3) operators > 4) any other staff specifically dedicated to the MF (B/A's, managers, etc) > 5) contractors/consultants dedicated to your MF > 6) total company employees > > Also, what operating system are you on? (VSE, z\OS, etc) > > For the record, our answers are > 1) 4 > 2) 1 > 3) 0 > 4) 2 > 5) 1 > 6) 4100 > > and we're VSE, with about 40% of our total data processing taking place on > our mainframe, and the remainder on other platforms. > > > Thanks > > Bill Washburn > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html >>> The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, s
Re: SMS Dataset Allocation Problem
>TIOT Set it to the max, and (in general) it won't be an issue. And, IIRC, DB2 uses a different type of table for allocation. The number of datasets it can allocate is way beyond what the TIOT, in theory, allows for. (This was about DB2, originally). - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How big of a staff do you have on your mainframe?
I do have about 20 replies so far (not counting the 'survey spam chatter' variety). I posted the query to the VSE list as well as this list, and a slight majority of the responses have come from there. I will post a summary (without revealing names, as some have requested) in a day or so. Thanks for the replies. "Pommier, Rex R." To Sent by: IBM IBM-MAIN@bama.ua.edu Mainframe cc Discussion List Subject Re: How big of a staff do you have 06/23/2009 01:15 on your mainframe? PM Please respond to IBM Mainframe Discussion List Tony, I don't know about you, but the only responses I've seen on-list have been the chatter revolving around it. I haven't seen any actual numbers coming across the listserv. Maybe my filters are already hiding them. :-) Rex -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Tony B. Sent: Tuesday, June 23, 2009 12:07 PM To: IBM-MAIN@bama.ua.edu Subject: Re: How big of a staff do you have on your mainframe? Oh yuk, you've just unleashed a storm of Survey Spam. You should have asked for private replies. We might be interested in the summary but not the ongoing tabulation. updating my subject line filter. :-((( -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Bill Washburn Sent: Tuesday, June 23, 2009 10:59 AM To: IBM-MAIN@bama.ua.edu Subject: How big of a staff do you have on your mainframe? This might seem like an odd request- But, as part of the platform analysis we're undertaking, I'd like to gauge how our staff size compares with other companies' resource allocation to their mainframe. What I'd like to know is how many employees/contractors do various companies have supporting and working within their mainframe environment, broken down in a few broad categories. 1) application developers 2) system programmers 3) operators 4) any other staff specifically dedicated to the MF (B/A's, managers, etc) 5) contractors/consultants dedicated to your MF 6) total company employees Also, what operating system are you on? (VSE, z\OS, etc) For the record, our answers are 1) 4 2) 1 3) 0 4) 2 5) 1 6) 4100 and we're VSE, with about 40% of our total data processing taking place on our mainframe, and the remainder on other platforms. Thanks Bill Washburn -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: smf layout question
Unfortunately it is through the the scheduling system. The system is the old beta43 which is now owned by ASG and called workload scheduler. We are a small shop and it works great but no new enhancements are to be added. On Tue, Jun 23, 2009 at 2:59 PM, Scott Barry wrote: > On Tue, 23 Jun 2009 14:24:15 -0400, larry macioce > wrote: > > >I /we have a scheduleing system that is no longer "supported" ,well it is > >but it isn't. > >Anyway, something weird happened and the operator on dusty says he didn't > do > >it. > >What happened was an external replay was given to release a certain part > of > >the schedule. > >This all occurred Friday a.m. and I was off yesterday that is why I'm > asking > >today. > >I've been through syslog, the scheduling systems log ,tcpip and several > >reports, but have found nothing to clear or blame the operator. > >I am tyring to clear him(he asked me to look into this). > >We do have some remotte logins and they could have done it but I have > found > >no evidence. > >I know that smf collects everything but I wouldn't know where to start > >looking > > thanks > >Mace > > > > > Your comment about "...an external replay was given to release a certain > part of > the schedule." is ambiguous in reference to whether the "reply" was made > within the scheduling system or as an MVS prompt reply. You should see MVS > reply occurences in the SYSLOG with the TSO USERID or the console reference > information. If the reply occurred within the scheduling system through > some terminal interaction or batch interface request, it's more up to you > to > bird-dog that one. > > Scott Barry > SBBWorks, Inc. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How big of a staff do you have on your mainframe?
Your levels roughly reflect ours with fewer app programmers and more sysprogs. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Bill Washburn Sent: Tuesday, June 23, 2009 10:59 AM To: IBM-MAIN@bama.ua.edu Subject: How big of a staff do you have on your mainframe? This might seem like an odd request- But, as part of the platform analysis we're undertaking, I'd like to gauge how our staff size compares with other companies' resource allocation to their mainframe. What I'd like to know is how many employees/contractors do various companies have supporting and working within their mainframe environment, broken down in a few broad categories. 1) application developers 2) system programmers 3) operators 4) any other staff specifically dedicated to the MF (B/A's, managers, etc) 5) contractors/consultants dedicated to your MF 6) total company employees Also, what operating system are you on? (VSE, z\OS, etc) For the record, our answers are 1) 4 2) 1 3) 0 4) 2 5) 1 6) 4100 and we're VSE, with about 40% of our total data processing taking place on our mainframe, and the remainder on other platforms. Thanks Bill Washburn -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: smf layout question
>I know that smf collects everything SMF only collects what it is told to. Your scheduler may (or may not) write SMF (user) records. And, SMF may (or may not) accept them. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS Dataset Allocation Problem
Ted, It was not DB2 that had a problem. It was CICS and a few batch jobs. I don't have a problem with multi-volume datasets at all, and in fact I design SMS to allocate large datasets on as many volumes as possible. It was simply having so many candidate volumes for every dataset, 1 track or 1 pack, was excessive and we started having TIOT blow outs. I think we were using 20 for the unit count when the problem happened. We ended up using 5 for both VSAM and PS and, let SRS from DTS look after adding volumes beyond five. Ron > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of > Ted MacNEIL > Sent: Tuesday, June 23, 2009 12:21 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: [IBM-MAIN] SMS Dataset Allocation Problem > > >TIOT > > Set it to the max, and (in general) it won't be an issue. > And, IIRC, DB2 uses a different type of table for allocation. > The number of datasets it can allocate is way beyond what the TIOT, in theory, > allows for. > > (This was about DB2, originally). > - > Too busy driving to stop for gas! > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Reusing old 3590 Tapes
>snip> >> Seriously, can any shop beat 10 years of continual VTS B18 Operations? >> Not a competition, just out of interest. > > 1. It has nothing to do with VTS, except the fact VTS uses real drives > in real 3494 library. So the problem regards 3590 drives in the library. >>>snip>>> Ours made almost 12 years. Our VTS side is shut down now, it costing more for maint than replacement. We are still running the ATL part in production, but we are in the process of moving off for the same reason. Linda Mooney -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS Dataset Allocation Problem
Most people are running on VIRTUAL disks anyway. z/os may "see" a 2105 or a 2107 but in most cases its tiny little brown round and spinning in RAID 5 on the SAN so it doesn't much matter any more. We used to place datasets on disks in accordance to their activity level and distance from the VTOC. To check your work you could open the door, look into the HDA and watch how much the actuator was bouncing around. Ken Klein Sr. Systems Programmer Kentucky Farm Bureau Insurance - Louisville kenneth.kl...@kyfb.com 502-495-5000 x7011 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ron Hawkins Sent: Tuesday, June 23, 2009 3:52 PM To: IBM-MAIN@bama.ua.edu Subject: Re: SMS Dataset Allocation Problem Ted, It was not DB2 that had a problem. It was CICS and a few batch jobs. I don't have a problem with multi-volume datasets at all, and in fact I design SMS to allocate large datasets on as many volumes as possible. It was simply having so many candidate volumes for every dataset, 1 track or 1 pack, was excessive and we started having TIOT blow outs. I think we were using 20 for the unit count when the problem happened. We ended up using 5 for both VSAM and PS and, let SRS from DTS look after adding volumes beyond five. Ron > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of > Ted MacNEIL > Sent: Tuesday, June 23, 2009 12:21 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: [IBM-MAIN] SMS Dataset Allocation Problem > > >TIOT > > Set it to the max, and (in general) it won't be an issue. > And, IIRC, DB2 uses a different type of table for allocation. > The number of datasets it can allocate is way beyond what the TIOT, in theory, > allows for. > > (This was about DB2, originally). > - > Too busy driving to stop for gas! > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS Dataset Allocation Problem
>It was not DB2 that had a problem. It was CICS and a few batch jobs. Okay. I stand/sit corrected. >I don't have a problem with multi-volume datasets at all, and in fact I design >SMS to allocate large datasets on as many volumes as possible. I didn't think you did have a problem. The issue is not multi-volume; it's number of volumes. >It was simply having so many candidate volumes for every dataset, 1 track or 1 >pack, was excessive and we started having TIOT blow outs. Were you using the max TIOT size? I believe it's 64K. >I think we were using 20 for the unit count when the problem happened. While I've said we've used 59, usually I've used 20, but that's for Batch. For online, we left it up to apps/DBA, except for DB2, since it uses a different method. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS Dataset Allocation Problem
>TIOT > >> >A lot of SMS sites provide for multi-volume allocation in the default >> DATACLAS, but 40 would be unusually high Unit Count to provide all >datasets. >> >> Why? >> I've worked in shops that set the default, through ACS, to the max (59). I would also be careful with just setting the max (been burnt). My favourite is Dynamic Multivolume. You still need to watch the TIOT size, but you don't get any of those candidate volume entries in the catalog until the unit gets used. You can still override the dynamic setting by coding your own unit count. Oh - if you're going to set a dataclass with multivolume in your ACS routines, make sure the DSORG of the data set supports multivolume (e.g. not PO). John John Ticic IntelliMagic - Storage Intelligence Perzikweg 13a, 2321 DG Leiden, The Netherlands www.intellimagic.net -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS Dataset Allocation Problem
>Most people are running on VIRTUAL disks anyway. z/os may "see" a 2105 or a >2107 but in most cases its tiny little brown round and spinning in RAID 5 on >the SAN so it doesn't much matter any more. We're not talking performance, here. We're talking space, volumes, & TIOT (Task I/O Table). >We used to place datasets on disks in accordance to their activity level and >distance from the VTOC. While interesting from a history perspective, this has nothing to do with the issue under discussion. Performance is something I've been doing since 1981 & 3330 disk, but space constraints are different. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS Dataset Allocation Problem
Ken, I think I have a bit of an understanding about virtual arrays. Unfortunately allocation doesn't, and shops without PAV still suffer from IOSQ. And I still open the doors up to see if there some sort of IO skew happening - flashing lights still tell you something about destage and cache miss activity. Ron > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of > Klein, Kenneth > Sent: Tuesday, June 23, 2009 1:00 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: [IBM-MAIN] SMS Dataset Allocation Problem > > Most people are running on VIRTUAL disks anyway. z/os may "see" a 2105 > or a 2107 but in most cases its tiny little brown round and spinning in > RAID 5 on the SAN so it doesn't much matter any more. We used to place > datasets on disks in accordance to their activity level and distance > from the VTOC. To check your work you could open the door, look into the > HDA and watch how much the actuator was bouncing around. > > > Ken Klein > Sr. Systems Programmer > Kentucky Farm Bureau Insurance - Louisville > kenneth.kl...@kyfb.com > 502-495-5000 x7011 > > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of Ron Hawkins > Sent: Tuesday, June 23, 2009 3:52 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: SMS Dataset Allocation Problem > > Ted, > > It was not DB2 that had a problem. It was CICS and a few batch jobs. I > don't have a problem with multi-volume datasets at all, and in fact I > design SMS to allocate large datasets on as many volumes as possible. It > was simply having so many candidate volumes for every dataset, 1 track > or 1 pack, was excessive and we started having TIOT blow outs. I think > we were using 20 for the unit count when the problem happened. > > We ended up using 5 for both VSAM and PS and, let SRS from DTS look > after adding volumes beyond five. > > Ron > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of > > Ted MacNEIL > > Sent: Tuesday, June 23, 2009 12:21 PM > > To: IBM-MAIN@bama.ua.edu > > Subject: Re: [IBM-MAIN] SMS Dataset Allocation Problem > > > > >TIOT > > > > Set it to the max, and (in general) it won't be an issue. > > And, IIRC, DB2 uses a different type of table for allocation. > > The number of datasets it can allocate is way beyond what the TIOT, in > theory, > > allows for. > > > > (This was about DB2, originally). > > - > > Too busy driving to stop for gas! > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > > email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search > the archives at http://bama.ua.edu/archives/ibm-main.html > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMS Dataset Allocation Problem
The TIOT concern is related to the DVC value rather than the volume count value. The DVC total is counted whether or not the dataset extends to that count total. Whereas the volume count is recorded in the catalog as candidate volumes. Terry Traylor charlesSCHWAB TIS Mainframe Storage Management Remedy Queue: tis-hs-mstg (602) 977-5154 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Tuesday, June 23, 2009 1:00 PM To: IBM-MAIN@bama.ua.edu Subject: Re: SMS Dataset Allocation Problem >It was not DB2 that had a problem. It was CICS and a few batch jobs. Okay. I stand/sit corrected. >I don't have a problem with multi-volume datasets at all, and in fact I >design SMS to allocate large datasets on as many volumes as possible. I didn't think you did have a problem. The issue is not multi-volume; it's number of volumes. >It was simply having so many candidate volumes for every dataset, 1 track or 1 pack, was excessive and we started having TIOT blow outs. Were you using the max TIOT size? I believe it's 64K. >I think we were using 20 for the unit count when the problem happened. While I've said we've used 59, usually I've used 20, but that's for Batch. For online, we left it up to apps/DBA, except for DB2, since it uses a different method. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
