ADCD systems - was: I broke it - programcontrolled programs
Mark, Until this thread, I didn't realize that anyone used ADCD for production systems. I know developers / small ISVs used it. I know an ISV's system is production to then, but that's not what I am referring to. For small ISVs it is prohibitively expensive to have their own z/OS. It is even expensive to get an RDT or z/PDT system due to the licence costs per year. And running Hercules is a clear violation of licence agreements. Not to mention that developers/small ISVs normally don't have the manpower/knowledge to install z/OS and customize it. Which means we use an ADCD distribution (with all the drawbacks this entails to a sysprog). Now that I have seen what an ADCD system looks like I am not surprised anymore about some of the questions about z/OS on this list and about the installation instructions for products developed on an ADCD system. But yes, to an ISV it is most certainly production, especially during cutoff time for a new release. My client uses RDz also, but the system(s) they use it on are still part of a production sysplex running production online and batch applications with high availability SLAs. Well, our ADCD system is a monoplex. With sometimes really bad response times due to the amount of MSU we get (all of 4). There is no way to start an application that is heavily into USS/Java. RDz takes a while to come up, but at least it does come up in a timely fashion. Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Syntax checker jes
Mitch wrote: ...or you can hook J-Man from RES-IT into the job submission software and it will do it all for you. You can even have it be part of the production batch schedule so that it does a final full validation on the logic and constructs of JCL just before the schedule, an application, a series of jobs, a specific net, etc. is submitted. Can J-Man check the JES2PARMS (and ALTPARM too) which the OP originally asked? Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: I broke it - programcontrolled programs
Scott, The IP configuration changes and RACF changes to meet operational environments were the obvious ones to me. Agreed, I would go that route unless you could find a complete inventory of all the load modules that shipped with ADCD..see if the module in error shipped worth 1.13 ...compare 1.10 or I have 1.12 I could compare also for you, if you like Please check in your mvs.global.csi if sysmod ims0001 is installed and then, where DFSMRCL0 is located on your system. My guess is that the usermod will be installed in your z/OS, too, and that you will find the dfsmrcl0 in ADCD.z112.linklib. It doesn't matter if you run IMS or not. Chances are that you never cleaned up the RACF database that came with your ADCD system, so please check if the library DFSMRCL0 is in (ADCD.z112.linklib?) is program-controlled. If not (and if BPX.DAEMON in FACILITY has UACC(READ) and is defined) then ftp *should* fail with CSV telling you that the environment is not program controlled. It only fails with my cleaned-up RACF data base. :-( Happy New Year! Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: I broke it - programcontrolled programs
Barbara, This is in regards to your statement Asking about it here (and eventually finding where DFSMRCL0 is located) helped me when I had to get RDz running. Which insisted on a program-controlled environment despite BPX.DAEMON not being defined. According to the books and your explanation, the need for a program-controlled environment should not have been there. This was true for ftp, but not for RDz. IBM documentation states that Rational should be permitted UPDATE access to FACILITY class profile BPX.SERVER, and on our ADCD system, BPX.SERVER is defined and the Rational Started Task ID STCRSE has been permitted the required access. BPX.SERVER also requires a program-controlled environment. Regards, Bob Robert S. Hansel Lead RACF Specialist RSH Consulting, Inc. 617-969-8211 www.linkedin.com/in/roberthansel www.rshconsulting.com - 2013 RACF Training - Securing z/OS UNIX - WebEx - JAN 15-17 - Intro Basic Admin - WebEx - FEB 4-8 - Audit for Results - Boston - APR 24-26 - Intro Basic Admin - Boston - MAY 21-23 - Securing z/OS UNIX - WebEx - JUL 23-25 - -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Syntax checker jes
Well, one (or more) of those HASP programs must do the parsing of the JESPARMS, too bad IBM doesn't make a driver program which could use the same module(s) which could be run in batch, TSO, __or UNIX__, and simply output a report. On Wed, Jan 2, 2013 at 9:37 AM, Paul Gilmartin paulgboul...@aim.com wrote: On Tue, 1 Jan 2013 13:48:21 -0500, Scott Ford wrote: To bad you can't do a TYPRUN=SCAN on JES2 parms Only if that putative scanner did a far better detection of syntax errors in JES2 parms than TYPRUN=SCAN does for JCL. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
IKJ574I NO SPACE IN BROADCAST DATA SET FOR MAIL
Hi, We have a problem with our Broadcast Dataset. We keep getting the message: IKJ574I NO SPACE IN BROADCAST DATA SET FOR MAIL I tried using TSO SYNC - that didn't work. I installed the program from CBT247 to take a peek at the individual messages, but it looks like there are no messages in the Broadcast dataset. I ran BCMSCAN and BCMCLEAN, but that didn't help either. The output from BCMCLEAN looks like this TOTAL AVAILABLE BLOCKS IN DATASET7,897 BLOCKS NECESSARY FOR BROADCST MSGS (DIRECTORY/MESSAGES)104 THE FOLLOWING KEY BREAKDOWN WAS FOUND COUNT OF 1ST REC OF BRODCAST (SHOULD BE 1) 1 NUMBER OF BRODCAST NOTICES DIRECTORY RECORDS 4 NUMBER OF BRODCAST NOTICES MESSAGE RECORDS 100 NUMBER OF USER MAIL DIRECTORY RECORDS42 NUMBER OF USER MAIL MESSAGE RECORDS 0 COUNT OF FREE SEARCH RECORD (SHOULD BE 1) 1 NUMBER OF DUMMY INACTIVE MAIL MSG RECORDS 7,749 NUMBER OF INACTIVE MAIL RECORDS CLEANED:7,749 SYS1.BROADCAST is hardcoded in the MSTJCL00 member of parmlib. The system is running OS/390 v2.8 (Yes, I know it's ancient). Does anyone one have an idea how to fix this problem? Thanks Gadi לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance with Malam's signatory rights, no offer, agreement, concession or representation is binding on the company, unless accompanied by a duly signed separate document (or a scanned version thereof), affixed with the company's seal. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: I broke it - programcontrolled programs
Answer to my own query: Jim Mulder pointed out that the module name had indeed been in Barbara's initial post; sorry. DFSMRCL0 which, prior to IMS V9, had to be zapped into IEAVTRML but, as of IMS V9, should not be. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IKJ574I NO SPACE IN BROADCAST DATA SET FOR MAIL
Do you have DISP=OLD or DISP=SHR in MSTJCL00? For Brodcast. If SHR, then you can manually delete the dataset. I would recommend that you go to individual TSO Broadcast data sets. It reduces this type of issue. Only impact is lost notifications to TSO users on jobs ending or SEND messages (I think) You may wish to look at expanding your SYS1.Brodcast dataset at a later date if you do not want to use Individual TSO broadcast datasets. The CBT software can delete your messages on the fly. There should be an ISPF Panel that will provide a table to delete any or all messages. But you definitely need to empty SYS1.BRODCAST. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of ??? ?? ??? Sent: Wednesday, January 02, 2013 8:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: IKJ574I NO SPACE IN BROADCAST DATA SET FOR MAIL Hi, We have a problem with our Broadcast Dataset. We keep getting the message: IKJ574I NO SPACE IN BROADCAST DATA SET FOR MAIL I tried using TSO SYNC - that didn't work. I installed the program from CBT247 to take a peek at the individual messages, but it looks like there are no messages in the Broadcast dataset. I ran BCMSCAN and BCMCLEAN, but that didn't help either. The output from BCMCLEAN looks like this TOTAL AVAILABLE BLOCKS IN DATASET7,897 BLOCKS NECESSARY FOR BROADCST MSGS (DIRECTORY/MESSAGES)104 THE FOLLOWING KEY BREAKDOWN WAS FOUND COUNT OF 1ST REC OF BRODCAST (SHOULD BE 1) 1 NUMBER OF BRODCAST NOTICES DIRECTORY RECORDS 4 NUMBER OF BRODCAST NOTICES MESSAGE RECORDS 100 NUMBER OF USER MAIL DIRECTORY RECORDS42 NUMBER OF USER MAIL MESSAGE RECORDS 0 COUNT OF FREE SEARCH RECORD (SHOULD BE 1) 1 NUMBER OF DUMMY INACTIVE MAIL MSG RECORDS 7,749 NUMBER OF INACTIVE MAIL RECORDS CLEANED:7,749 SYS1.BROADCAST is hardcoded in the MSTJCL00 member of parmlib. The system is running OS/390 v2.8 (Yes, I know it's ancient). Does anyone one have an idea how to fix this problem? Thanks Gadi לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance with Malam's signatory rights, no offer, agreement, concession or representation is binding on the company, unless accompanied by a duly signed separate document (or a scanned version thereof), affixed with the company's seal. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IKJ574I NO SPACE IN BROADCAST DATA SET FOR MAIL
Like I said, SYS1.BRODCAST Seems to be empty. I will check about the DISP. Gadi From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler [stars...@mindspring.com] Sent: 02 January 2013 18:10 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IKJ574I NO SPACE IN BROADCAST DATA SET FOR MAIL Do you have DISP=OLD or DISP=SHR in MSTJCL00? For Brodcast. If SHR, then you can manually delete the dataset. I would recommend that you go to individual TSO Broadcast data sets. It reduces this type of issue. Only impact is lost notifications to TSO users on jobs ending or SEND messages (I think) You may wish to look at expanding your SYS1.Brodcast dataset at a later date if you do not want to use Individual TSO broadcast datasets. The CBT software can delete your messages on the fly. There should be an ISPF Panel that will provide a table to delete any or all messages. But you definitely need to empty SYS1.BRODCAST. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of ??? ?? ??? Sent: Wednesday, January 02, 2013 8:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: IKJ574I NO SPACE IN BROADCAST DATA SET FOR MAIL Hi, We have a problem with our Broadcast Dataset. We keep getting the message: IKJ574I NO SPACE IN BROADCAST DATA SET FOR MAIL I tried using TSO SYNC - that didn't work. I installed the program from CBT247 to take a peek at the individual messages, but it looks like there are no messages in the Broadcast dataset. I ran BCMSCAN and BCMCLEAN, but that didn't help either. The output from BCMCLEAN looks like this TOTAL AVAILABLE BLOCKS IN DATASET7,897 BLOCKS NECESSARY FOR BROADCST MSGS (DIRECTORY/MESSAGES)104 THE FOLLOWING KEY BREAKDOWN WAS FOUND COUNT OF 1ST REC OF BRODCAST (SHOULD BE 1) 1 NUMBER OF BRODCAST NOTICES DIRECTORY RECORDS 4 NUMBER OF BRODCAST NOTICES MESSAGE RECORDS 100 NUMBER OF USER MAIL DIRECTORY RECORDS42 NUMBER OF USER MAIL MESSAGE RECORDS 0 COUNT OF FREE SEARCH RECORD (SHOULD BE 1) 1 NUMBER OF DUMMY INACTIVE MAIL MSG RECORDS 7,749 NUMBER OF INACTIVE MAIL RECORDS CLEANED:7,749 SYS1.BROADCAST is hardcoded in the MSTJCL00 member of parmlib. The system is running OS/390 v2.8 (Yes, I know it's ancient). Does anyone one have an idea how to fix this problem? Thanks Gadi לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance with Malam's signatory rights, no offer, agreement, concession or representation is binding on the company, unless accompanied by a duly signed separate document (or a scanned version thereof), affixed with the company's seal. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance with Malam's signatory rights, no offer, agreement, concession or representation is binding on the company, unless accompanied by a duly signed separate document (or a scanned version thereof), affixed with the company's seal. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IKJ574I NO SPACE IN BROADCAST DATA SET FOR MAIL
On Wed, 2 Jan 2013 09:10:27 -0700, Lizette Koehler wrote: Do you have DISP=OLD or DISP=SHR in MSTJCL00? For Brodcast. If SHR, then you can manually delete the dataset. ??? How? Even if it's allocated SHR, you need to ENQ EXC to delete it. Unless you zap the VTOC. (Ugh.) I would recommend that you go to individual TSO Broadcast data sets. It reduces this type of issue. Only impact is lost notifications to TSO users on jobs ending or SEND messages (I think) Would this be an impediment to hacks or possible future enhancements that might allow concurrent logons? (Is the individual BCDS temp DSN or catalogued?) The CBT software can delete your messages on the fly. There should be an ISPF Panel that will provide a table to delete any or all messages. But you definitely need to empty SYS1.BRODCAST. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IKJ574I NO SPACE IN BROADCAST DATA SET FOR MAIL
Gil Not to delete the dataset, but to empty the dataset. If you want to expand it, I would create a new one, put it in the MSTJCL00 and IPL. Then Delete the old one, Allocate a new one with the original name (if desired) and then IPL again. I have not heard of any issues with multiple logons and the individual brodcast datasets. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Wednesday, January 02, 2013 9:39 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IKJ574I NO SPACE IN BROADCAST DATA SET FOR MAIL On Wed, 2 Jan 2013 09:10:27 -0700, Lizette Koehler wrote: Do you have DISP=OLD or DISP=SHR in MSTJCL00? For Brodcast. If SHR, then you can manually delete the dataset. ??? How? Even if it's allocated SHR, you need to ENQ EXC to delete it. Unless you zap the VTOC. (Ugh.) I would recommend that you go to individual TSO Broadcast data sets. It reduces this type of issue. Only impact is lost notifications to TSO users on jobs ending or SEND messages (I think) Would this be an impediment to hacks or possible future enhancements that might allow concurrent logons? (Is the individual BCDS temp DSN or catalogued?) The CBT software can delete your messages on the fly. There should be an ISPF Panel that will provide a table to delete any or all messages. But you definitely need to empty SYS1.BRODCAST. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IKJ574I NO SPACE IN BROADCAST DATA SET FOR MAIL
So does that mean the messages have stopped? Or are they continuing? If stopped, you are good for now. If they are still occurring and the Scan utility shows it empty. Then you may need to contact IBM Also, check your TSO Parm IKJTSOxx member (you can use the command under TSO called PARMLIB) to see what your Brodcast dataset is set to. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of ??? ?? ??? Sent: Wednesday, January 02, 2013 9:27 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IKJ574I NO SPACE IN BROADCAST DATA SET FOR MAIL Like I said, SYS1.BRODCAST Seems to be empty. I will check about the DISP. Gadi From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler [stars...@mindspring.com] Sent: 02 January 2013 18:10 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IKJ574I NO SPACE IN BROADCAST DATA SET FOR MAIL Do you have DISP=OLD or DISP=SHR in MSTJCL00? For Brodcast. If SHR, then you can manually delete the dataset. I would recommend that you go to individual TSO Broadcast data sets. It reduces this type of issue. Only impact is lost notifications to TSO users on jobs ending or SEND messages (I think) You may wish to look at expanding your SYS1.Brodcast dataset at a later date if you do not want to use Individual TSO broadcast datasets. The CBT software can delete your messages on the fly. There should be an ISPF Panel that will provide a table to delete any or all messages. But you definitely need to empty SYS1.BRODCAST. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of ??? ?? ??? Sent: Wednesday, January 02, 2013 8:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: IKJ574I NO SPACE IN BROADCAST DATA SET FOR MAIL Hi, We have a problem with our Broadcast Dataset. We keep getting the message: IKJ574I NO SPACE IN BROADCAST DATA SET FOR MAIL I tried using TSO SYNC - that didn't work. I installed the program from CBT247 to take a peek at the individual messages, but it looks like there are no messages in the Broadcast dataset. I ran BCMSCAN and BCMCLEAN, but that didn't help either. The output from BCMCLEAN looks like this TOTAL AVAILABLE BLOCKS IN DATASET7,897 BLOCKS NECESSARY FOR BROADCST MSGS (DIRECTORY/MESSAGES)104 THE FOLLOWING KEY BREAKDOWN WAS FOUND COUNT OF 1ST REC OF BRODCAST (SHOULD BE 1) 1 NUMBER OF BRODCAST NOTICES DIRECTORY RECORDS 4 NUMBER OF BRODCAST NOTICES MESSAGE RECORDS 100 NUMBER OF USER MAIL DIRECTORY RECORDS42 NUMBER OF USER MAIL MESSAGE RECORDS 0 COUNT OF FREE SEARCH RECORD (SHOULD BE 1) 1 NUMBER OF DUMMY INACTIVE MAIL MSG RECORDS 7,749 NUMBER OF INACTIVE MAIL RECORDS CLEANED:7,749 SYS1.BROADCAST is hardcoded in the MSTJCL00 member of parmlib. The system is running OS/390 v2.8 (Yes, I know it's ancient). Does anyone one have an idea how to fix this problem? Thanks Gadi לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance with Malam's signatory rights, no offer, agreement, concession or representation is binding on the company, unless accompanied by a duly signed separate document (or a scanned version thereof), affixed with the company's seal. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance with Malam's signatory rights, no offer, agreement, concession or representation is binding on the company, unless accompanied by a duly signed separate
Re: Syntax checker jes
On Wed, 2 Jan 2013 09:52:41 -0600, John McKown wrote: Well, one (or more) of those HASP programs must do the parsing of the JESPARMS, too bad IBM doesn't make a driver program which could use the same module(s) which could be run in batch, TSO, __or UNIX__, and simply output a report. But that might presume modularity, a possible transgression of Conway's Law. And RYO, FOSS, and even some ISV validators tend to fall behind enhancements in JCL syntax. The trouble with your technique mentioned earlier, as with TYPRUN=SCAN is that both are difficult to script. And RYO, FOSS, and even some ISV validators tend to fall behind enhancements in JCL syntax. __UNIX__!? Heretic! It would _so_ be useless to your co-workers. Unless you wrapped it in an ISPF dialog. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IKJ574I NO SPACE IN BROADCAST DATA SET FOR MAIL
The messages are continuing. Do think IBM will help with a problem with OS / 390? IKJTSO00 shows that sys1.brodcast is being used Gadi Gadi Ben-Avi Malam Systems Jerusalem, Israel Original message From: Lizette Koehler stars...@mindspring.com Date: To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IKJ574I NO SPACE IN BROADCAST DATA SET FOR MAIL So does that mean the messages have stopped? Or are they continuing? If stopped, you are good for now. If they are still occurring and the Scan utility shows it empty. Then you may need to contact IBM Also, check your TSO Parm IKJTSOxx member (you can use the command under TSO called PARMLIB) to see what your Brodcast dataset is set to. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of ??? ?? ??? Sent: Wednesday, January 02, 2013 9:27 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IKJ574I NO SPACE IN BROADCAST DATA SET FOR MAIL Like I said, SYS1.BRODCAST Seems to be empty. I will check about the DISP. Gadi From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler [stars...@mindspring.com] Sent: 02 January 2013 18:10 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IKJ574I NO SPACE IN BROADCAST DATA SET FOR MAIL Do you have DISP=OLD or DISP=SHR in MSTJCL00? For Brodcast. If SHR, then you can manually delete the dataset. I would recommend that you go to individual TSO Broadcast data sets. It reduces this type of issue. Only impact is lost notifications to TSO users on jobs ending or SEND messages (I think) You may wish to look at expanding your SYS1.Brodcast dataset at a later date if you do not want to use Individual TSO broadcast datasets. The CBT software can delete your messages on the fly. There should be an ISPF Panel that will provide a table to delete any or all messages. But you definitely need to empty SYS1.BRODCAST. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of ??? ?? ??? Sent: Wednesday, January 02, 2013 8:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: IKJ574I NO SPACE IN BROADCAST DATA SET FOR MAIL Hi, We have a problem with our Broadcast Dataset. We keep getting the message: IKJ574I NO SPACE IN BROADCAST DATA SET FOR MAIL I tried using TSO SYNC - that didn't work. I installed the program from CBT247 to take a peek at the individual messages, but it looks like there are no messages in the Broadcast dataset. I ran BCMSCAN and BCMCLEAN, but that didn't help either. The output from BCMCLEAN looks like this TOTAL AVAILABLE BLOCKS IN DATASET7,897 BLOCKS NECESSARY FOR BROADCST MSGS (DIRECTORY/MESSAGES)104 THE FOLLOWING KEY BREAKDOWN WAS FOUND COUNT OF 1ST REC OF BRODCAST (SHOULD BE 1) 1 NUMBER OF BRODCAST NOTICES DIRECTORY RECORDS 4 NUMBER OF BRODCAST NOTICES MESSAGE RECORDS 100 NUMBER OF USER MAIL DIRECTORY RECORDS42 NUMBER OF USER MAIL MESSAGE RECORDS 0 COUNT OF FREE SEARCH RECORD (SHOULD BE 1) 1 NUMBER OF DUMMY INACTIVE MAIL MSG RECORDS 7,749 NUMBER OF INACTIVE MAIL RECORDS CLEANED:7,749 SYS1.BROADCAST is hardcoded in the MSTJCL00 member of parmlib. The system is running OS/390 v2.8 (Yes, I know it's ancient). Does anyone one have an idea how to fix this problem? Thanks Gadi לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך כאמור (לרבות מסמך סרוק) המצורף להודעת דואר אלקטרוני זאת, אין לראות באמור בהודעה אלא משום טיוטה לדיון, ואין להסתמך עליה לביצוע פעולה עסקית או משפטית כלשהי. Please note that in accordance with Malam's signatory rights, no offer, agreement, concession or representation is binding on the company, unless accompanied by a duly signed separate document (or a scanned version thereof), affixed with the company's seal. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN לשימת לבך, בהתאם לנהלי החברה וזכויות החתימה בה, כל הצעה, התחייבות או מצג מטעם החברה, מחייבים מסמך נפרד וחתום על ידי מורשי החתימה של החברה, הנושא את לוגו החברה או שמה המודפס ובצירוף חותמת החברה. בהעדר מסמך
Re: IKJ574I NO SPACE IN BROADCAST DATA SET FOR MAIL
If I recall from way back when, it was needful to reformat SYS1.BRODCAST not simply reinitialise it. Andy Robertson telephone mobile 0797 0005958 home 01308 420797 -IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU wrote: - To: IBM-MAIN@LISTSERV.UA.EDU From: #1490;#1491;#1497; #1489;#1503; #1488;#1489;#1497; Sent by: IBM Mainframe Discussion List Date: 01/02/2013 05:01PM Subject: Re: IKJ574I NO SPACE IN BROADCAST DATA SET FOR MAIL The messages are continuing. Do think IBM will help with a problem with OS / 390? IKJTSO00 shows that sys1.brodcast is being used Gadi ** 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.johnlewis.com/insurance http://www.johnlewispartnership.co.uk ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Large table in memory
2^10 (1,024) is 2.4 percent larger than 10^3 (1,000), which in turn is 2.34375 percent smaller than 2^10 (1,024). This percent difference compounds exponentially with every three additional decimal zeroes or ten additional binary zeroes, and reaches nearly 50 percent different at 10^51, FWIW. Bill Fairchild Programmer Rocket Software 408 Chamberlain Park Lane * Franklin, TN 37069-2526 * USA t: +1.617.614.4503 * e: bfairch...@rocketsoftware.com * w: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Gilmore Sent: Wednesday, December 26, 2012 11:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Large table in memory Tom, Thank you for the silent correction. The 'exa' in 'exabytes' is certainly a radical improvement over 'exo', which was not confidence-inspiring. That said, it seems to me that for these magnitudes the binary prefix 'exbi' should be used. We have (2^10)^6 = 115_2921_5046_0684_6976 exbibytes (10^3)^6 = 100____ exabytes and there is thus a non-trivial 13+% difference between these two numbers. All this began with the notion of the rough equivalence of 2^10 = 1024 and 10^3 = 1000, which is a 2+% difference. The practical difference between a kibibyte and a kilobyte was thus unimportant, particularly in discussions among highly numerate people who understood what sort of approximation they were using. Things have, however, changed. We are now often dealing with the easily confused innumerate, and the differences are large enough to make dissimulation attractive to some, certainly not all, marketing types. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IKJ574I NO SPACE IN BROADCAST DATA SET FOR MAIL
When you run those jobs in batch to clean up the SYS1.BRODCAST data set, are you sure that they are pointing to the same physical data set as is being using by the _running_ system? I ask because I had a case where I had to enlarge SYS1.BRODCAST. I first did an uncatalog on the existing SYS1.BRODCAST. Then I created a new SYS1.BRODCAST on a new volume and cataloged it. Until we did an IPL, the cataloged SYS1.BRODCAST was empty and doing things to is, such as SYNC, did not affect the actual BRODCAST data set which the system was using. I don't know if it is available in OS/390, but is it possible to create a new SYS1.BRODCAST with a new name (such as SYS1.SYSNAME..BRODCAST) and update SYS1.PARMLIB(IKJTSOnn) to point to the new data set name, then activate it with the T IKJTSO=nn command? On Wed, Jan 2, 2013 at 11:33 AM, Andy Robertson andy_robert...@johnlewis.co.uk wrote: If I recall from way back when, it was needful to reformat SYS1.BRODCAST not simply reinitialise it. Andy Robertson telephone mobile 0797 0005958 home 01308 420797 -IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU wrote: - To: IBM-MAIN@LISTSERV.UA.EDU From: #1490;#1491;#1497; #1489;#1503; #1488;#1489;#1497; Sent by: IBM Mainframe Discussion List Date: 01/02/2013 05:01PM Subject: Re: IKJ574I NO SPACE IN BROADCAST DATA SET FOR MAIL The messages are continuing. Do think IBM will help with a problem with OS / 390? IKJTSO00 shows that sys1.brodcast is being used Gadi ** 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.johnlewis.com/insurance http://www.johnlewispartnership.co.uk ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OT - Huge Maple Syrup heist solved.
To get this OT back on topic, how many exaliters of maple syrup did they steal? :-) Bill Fairchild Programmer Rocket Software 408 Chamberlain Park Lane * Franklin, TN 37069-2526 * USA t: +1.617.614.4503 * e: bfairch...@rocketsoftware.com * w: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mike Schwab Sent: Thursday, December 27, 2012 12:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: OT - Huge Maple Syrup heist solved. http://www.cbc.ca/news/canada/new-brunswick/story/2012/12/20/arrests-maple-syrup-quebec.html -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OT - Huge Maple Syrup heist solved.
W dniu 2013-01-02 18:54, Bill Fairchild pisze: To get this OT back on topic, how many exaliters of maple syrup did they steal? :-) To be on topic you should ask about exiliters. ;-) BTW: To make this topic never-ending - how many exaliters of syrup can fit in single USS filesystem? ;-) Another try: FFST is not needed since we can use syrup. -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OT - Huge Maple Syrup heist solved.
42 U.S. Gallons or 158.987 Liters or 336 pounds per barrel of Maple Syrup. 9,600 barrels is 403,200 U.S. Gallons or 1,526,275.2 Liters or 3,225,600 pounds (plus barrels) of Maple Syrup. That would be about 64 semis of 50,000 pounds cargo. US$18M is US$11.80 per liter. On Wed, Jan 2, 2013 at 11:54 AM, Bill Fairchild bfairch...@rocketsoftware.com wrote: To get this OT back on topic, how many exaliters of maple syrup did they steal? :-) Bill Fairchild Programmer Rocket Software 408 Chamberlain Park Lane * Franklin, TN 37069-2526 * USA t: +1.617.614.4503 * e: bfairch...@rocketsoftware.com * w: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mike Schwab Sent: Thursday, December 27, 2012 12:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: OT - Huge Maple Syrup heist solved. http://www.cbc.ca/news/canada/new-brunswick/story/2012/12/20/arrests-maple-syrup-quebec.html -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BPXP024I BPXAS INITIATOR STARTED ON BEHALF OF... ( was: JVMDUMP032I message)
Happy New Year to everybody. Barbara, I'm sorry for the delayed response. I've been too busy with the year end porocessing. Let's assume you start your TSO session (your ID is BARBARA), then do something with Z/OS UNIX that starts a new UNIX *non-local* process. A simple 'tso ishell' will start two BPXASs: BPXP024I BPXAS INITIATOR STARTED ON BEHALF OF JOB BARBARA RUNNING IN ASID 0030 BPXP024I BPXAS INITIATOR STARTED ON BEHALF OF JOB BARBARA1 RUNNING IN ASID 001E x'30' is my TSO userid, and asid x'1E' is so short-lived that it is gone (without a trace, no BPXAS, no nothing) at the time I look at the log. According to what you wrote, I *should* see at least one BPXAS being idle (in asid x'1E'). There is no asid x'1E'. No, the BPXP024I message documents the ASID that caused this BPXAS to be startet. That ASID may or may not be another BPXAS. Since you mention X'1E' I'd say this is a system address space started during IPL. One of these that are starting UNIX work, and thus are initiating BPXAS starts, is BPXOINIT. The SDSF ps display shows two processes in asid x'30' - in my TSO asid, one for EXEC and the other for /bin/fomfuish. Yes, the first process is the ISHELL REXX and the second one is started to be able to display time/date values in your timezone, provided there is one configured in your UNIX shell environment. (The BPXAS that has been used for a short time is part of this processing.) Once I leave ishell, the two processes are gone. No message in syslog. No idle BPXAS anywhere. I must be missing something. No, you're not missing anything. The two processes are *local* processes, i.e. they run in your TSO address space. You confimed this when you saw two processes in your ASID X'30' in SDSF's PS display. No address space terminated just because you quit ishell. Therefore no end of AS messages are logged. Is there a magic command that I am unaware of that would show me idle BPXASs, provided they exist?!? Have you tried DA ALL in SDSF or D A,BPXAS on the console. SDSF does not show idle initiators in the DA unless you proivde the ALL parm. But then, OMVS/Unix never really made sense to me. It's not a question of whether it makes sense or not. It is an integral part of z/OS and even system tasks (TCP/IP, DB2, IMS, etc., etc.) make use of it. There is no way around it anymore. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: HSM Log extract
On Wed, 2 Jan 2013 06:43:33 -0600, Gilbert Cardenas gilbertcarde...@grocerybiz.com wrote: I didn't know that SAS had some kind of built in module for HSM. I save the MIGLOG, CMDLOG and BAKLOG to disk datasets and then pass them through a SAS routine I wrote that collects any non-zero return codes and does a SAS email with the errors. I oftened wondered how others were tracking HSM errors and thought of posting the question many times but never got around to it. I'd be interested in know what provisions SAS has as well as we do not have MXG. If you license SAS (regardless of OS platform) and do not license MXG, your site/enterprise should seriously reconsider, given the relative inexpensive cost of MXG as compared to its benefit/purpose. There are many information data sources that MXG supports and Merrill Associates is always welcome to consider adding more, when requested, without any SAS programming cost to the client. MXG/SAS support is provided for the SMF (user type) record (FSR and DSR event / interval stats) activities; see SOURCLIB members VMACHSM, ADOCHSM, to start. Also, MXG/SAS supports DFHSM MCDS/BCDS inventory data source, generated by DCOLLECT; see members VMACDCOL, ADOCDCOL. Scott Barry SBBWorks, Inc. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
FW: I broke it - programcontrolled programs
RDz.Which insisted on a program-controlled environment despite BPX.DAEMON not being defined. According to the books and your explanation, the need for a program-controlled environment should not have been there. This was true for ftp, but not for RDz. BPX.DAEMON is for processes changing the security environment of the AS (setuid()). There is a second, similar profile called BPX.SERVER which aims to enable a higher security level for processes changing the security environment on a UNIX thread (similar to MVS subtasks) level using the pthread_security_np() service. From what you describe, I guess that RDz might be using this call, and that BPX.SERVER is defined on your system. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFSMRCL0 usermod - was: I broke it
ADCD is used by ISVs - typically the smaller ones. This list is full of people who have experience with it (including me), so this may be the best user group for ADCD. Is anyone of you using an ADCD system still having a V1.10 system? If so, would someone please see, if the DFSMRCL0 module is in any of the LPA libraries in addition to the ADCD...LINKLIB. Just curios, because it still isn't clear why Barbara had no problem with FTP on her V1.10 system. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
RMF and ISFOUT
We have been executing an IBM process that collects DA ALL type system views for a long time. EDIT SYS1.PROCLIB(RMFM3B) - 01.00Columns 1 Command === Scroll === ** * Top of Data *** 50 //RMFM3B PROC RMF=SYS1,ISPF=SYS1,REPORT=WFEX,HLQ= 51 //*** 52 //* 53 //* PROPRIETARY STATEMENT: 54 //*LICENSED MATERIALS - PROPERTY OF IBM 55 //*RESTRICTED MATERIALS OF IBM 56 //*5694-A01 57 //*COPYRIGHT IBM CORP. 1998, 2007 58 //*STATUS=HRM7740 (Z/OS V1R9 RMF) 59 //* 60 //* DESCRIPTION: 80 //*RMF MONITOR III REPORTER BACKGROUND SESSION 000100 //*PRODUCES FREE SELECTABLE REPORTS ACCORDINGLY 000200 //*TO THE REPORT INPUT PARAMETER 000210 //*THE REPORT FREQUENCY DEPENDS ON THE MINTIME 000220 //*OPTION OF THE MONITOR III GATHERER (DEFAULT 100S) 000221 //* On 22DEC12 this started task abended with: IEC130I ISFOUT DD STATEMENT MISSING ISF037I SDSF SDUMP NOT TAKEN, SUPPRESSED BY DAE ISF012I SDSF ABEND USER 13 AT 11203582 IN MODULE ISFBDSP ISF013I SDSF ABEND R0-R7 8000 800D 0041 0388 ISF014I SDSF ABEND R8-R15 11201BCC 11201AF8 11204318 00998730 IEA995I SYMPTOM DUMP OUTPUT 528 USER COMPLETION CODE=0013 We have been trying to find an environment change to explain this to no avail. Might someone have some insight into this situation? Thankyou John Donnelly Texas Instruments SVA 2900 Semiconductor Drive Santa Clara, CA 95051 408-721-5640 408-470-8364 Cell john.p.donne...@ti.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMF and ISFOUT
What changes have been recently made? What program are you running? Did you change operating system releases? If not, what version of z/OS are you running? Lizette -Original Message- From: Donnelly, John john.p.donne...@ti.com Sent: Jan 2, 2013 2:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: RMF and ISFOUT We have been executing an IBM process that collects DA ALL type system views for a long time. EDIT SYS1.PROCLIB(RMFM3B) - 01.00Columns 1 Command === Scroll === ** * Top of Data *** 50 //RMFM3B PROC RMF=SYS1,ISPF=SYS1,REPORT=WFEX,HLQ= 51 //*** 52 //* 53 //* PROPRIETARY STATEMENT: 54 //*LICENSED MATERIALS - PROPERTY OF IBM 55 //*RESTRICTED MATERIALS OF IBM 56 //*5694-A01 57 //*COPYRIGHT IBM CORP. 1998, 2007 58 //*STATUS=HRM7740 (Z/OS V1R9 RMF) 59 //* 60 //* DESCRIPTION: 80 //*RMF MONITOR III REPORTER BACKGROUND SESSION 000100 //*PRODUCES FREE SELECTABLE REPORTS ACCORDINGLY 000200 //*TO THE REPORT INPUT PARAMETER 000210 //*THE REPORT FREQUENCY DEPENDS ON THE MINTIME 000220 //*OPTION OF THE MONITOR III GATHERER (DEFAULT 100S) 000221 //* On 22DEC12 this started task abended with: IEC130I ISFOUT DD STATEMENT MISSING ISF037I SDSF SDUMP NOT TAKEN, SUPPRESSED BY DAE ISF012I SDSF ABEND USER 13 AT 11203582 IN MODULE ISFBDSP ISF013I SDSF ABEND R0-R7 8000 800D 0041 0388 ISF014I SDSF ABEND R8-R15 11201BCC 11201AF8 11204318 00998730 IEA995I SYMPTOM DUMP OUTPUT 528 USER COMPLETION CODE=0013 We have been trying to find an environment change to explain this to no avail. Might someone have some insight into this situation? Thankyou John Donnelly Texas Instruments SVA 2900 Semiconductor Drive Santa Clara, CA 95051 408-721-5640 408-470-8364 Cell john.p.donne...@ti.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMF and ISFOUT
Did someone commit adultery with either proc RMFM3B or CLIST/EXEC RMFM3B (or both)? Tom Vacation Notice: None Tom Puddicombe Mainframe Performance Capacity Planning CSC 31 Brookdale Rd, Meriden, CT 06450 ITIS | (860) 428-3252 | tpudd...@csc.com | www.csc.com This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. From: Donnelly, John john.p.donne...@ti.com To: IBM-MAIN@listserv.ua.edu Date: 01/02/2013 04:16 PM Subject:RMF and ISFOUT Sent by:IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu We have been executing an IBM process that collects DA ALL type system views for a long time. EDIT SYS1.PROCLIB(RMFM3B) - 01.00Columns 1 Command === Scroll === ** * Top of Data *** 50 //RMFM3B PROC RMF=SYS1,ISPF=SYS1,REPORT=WFEX,HLQ= 51 //*** 52 //* 53 //* PROPRIETARY STATEMENT: 54 //*LICENSED MATERIALS - PROPERTY OF IBM 55 //*RESTRICTED MATERIALS OF IBM 56 //*5694-A01 57 //*COPYRIGHT IBM CORP. 1998, 2007 58 //*STATUS=HRM7740 (Z/OS V1R9 RMF) 59 //* 60 //* DESCRIPTION: 80 //*RMF MONITOR III REPORTER BACKGROUND SESSION 000100 //*PRODUCES FREE SELECTABLE REPORTS ACCORDINGLY 000200 //*TO THE REPORT INPUT PARAMETER 000210 //*THE REPORT FREQUENCY DEPENDS ON THE MINTIME 000220 //*OPTION OF THE MONITOR III GATHERER (DEFAULT 100S) 000221 //* On 22DEC12 this started task abended with: IEC130I ISFOUT DD STATEMENT MISSING ISF037I SDSF SDUMP NOT TAKEN, SUPPRESSED BY DAE ISF012I SDSF ABEND USER 13 AT 11203582 IN MODULE ISFBDSP ISF013I SDSF ABEND R0-R7 8000 800D 0041 0388 ISF014I SDSF ABEND R8-R15 11201BCC 11201AF8 11204318 00998730 IEA995I SYMPTOM DUMP OUTPUT 528 USER COMPLETION CODE=0013 We have been trying to find an environment change to explain this to no avail. Might someone have some insight into this situation? Thankyou John Donnelly Texas Instruments SVA 2900 Semiconductor Drive Santa Clara, CA 95051 408-721-5640 408-470-8364 Cell john.p.donne...@ti.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMF and ISFOUT
On Wed, 2 Jan 2013 21:16:12 +, Donnelly, John john.p.donne...@ti.com wrote: We have been executing an IBM process that collects DA ALL type system views for a long time. EDIT SYS1.PROCLIB(RMFM3B) - 01.00Columns 1 Command === Scroll === ** * Top of Data *** 50 //RMFM3B PROC RMF=SYS1,ISPF=SYS1,REPORT=WFEX,HLQ= 51 //*** 52 //* 53 //* PROPRIETARY STATEMENT: 54 //*LICENSED MATERIALS - PROPERTY OF IBM 55 //*RESTRICTED MATERIALS OF IBM 56 //*5694-A01 57 //*COPYRIGHT IBM CORP. 1998, 2007 58 //*STATUS=HRM7740 (Z/OS V1R9 RMF) 59 //* 60 //* DESCRIPTION: 80 //*RMF MONITOR III REPORTER BACKGROUND SESSION 000100 //*PRODUCES FREE SELECTABLE REPORTS ACCORDINGLY 000200 //*TO THE REPORT INPUT PARAMETER 000210 //*THE REPORT FREQUENCY DEPENDS ON THE MINTIME 000220 //*OPTION OF THE MONITOR III GATHERER (DEFAULT 100S) 000221 //* On 22DEC12 this started task abended with: IEC130I ISFOUT DD STATEMENT MISSING ISF037I SDSF SDUMP NOT TAKEN, SUPPRESSED BY DAE ISF012I SDSF ABEND USER 13 AT 11203582 IN MODULE ISFBDSP ISF013I SDSF ABEND R0-R7 8000 800D 0041 0388 ISF014I SDSF ABEND R8-R15 11201BCC 11201AF8 11204318 00998730 IEA995I SYMPTOM DUMP OUTPUT 528 USER COMPLETION CODE=0013 We have been trying to find an environment change to explain this to no avail. Might someone have some insight into this situation? Thankyou But it is working now (one time abend)? That part wasn't clear. Since that proc doesn't use SDSF in batch, did someone overlay it? Did someone compress the proclib recently before the abend? -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMF and ISFOUT
On Wed, Jan 2, 2013 at 3:16 PM, Donnelly, John john.p.donne...@ti.com wrote: deleted On 22DEC12 this started task abended with: deleted John Donnelly Its the Mayan Apocalypse. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMF and ISFOUT
Just a delayed Mayan effect Scott ford www.identityforge.com Tell me and I'll forget; show me and I may remember; involve me and I'll understand. - Chinese Proverb On Jan 2, 2013, at 4:47 PM, Mike Schwab mike.a.sch...@gmail.com wrote: On Wed, Jan 2, 2013 at 3:16 PM, Donnelly, John john.p.donne...@ti.com wrote: deleted On 22DEC12 this started task abended with: deleted John Donnelly Its the Mayan Apocalypse. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
New Kaiser Permanente Data Center in Colorado
Happy New Year.There was a recent article in the Denver Post regarding a new Kaiser Permanente data center being ramped-up in the Denver Area, Englewood to be specific. The Denver paper stated that there would be approximately 800 employees in this facility. I'm presuming that Mainframe support personnel would be in included, but I'm not sure, and I'm not seeing any IT support jobs being advertised in the Denver area. Does anybody on this post know anything about this new facility? If this is not an appropriate topic for this Listserve, I apologize ahead of time. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: New Kaiser Permanente Data Center in Colorado
Kaiser out sourced it's IT to IBM a few years back. Some of the regulars should fill in the blanks. In a message dated 1/2/2013 5:08:24 P.M. Central Standard Time, michael_j_see...@nbc.gov writes: would be in included, but I'm not sure, and I'm not seeing any IT support jobs being advertised in the Denver area. Does anybody on this post know anything about this new facility? If this is not an appropriate topic -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFSMRCL0 usermod - was: I broke it
Peter, We have 1.10 running level 0903 , it's there...in sys1.lpalib Scott ford www.identityforge.com Tell me and I'll forget; show me and I may remember; involve me and I'll understand. - Chinese Proverb On Jan 2, 2013, at 3:29 PM, Peter Hunkeler peter.hunke...@credit-suisse.com wrote: ADCD is used by ISVs - typically the smaller ones. This list is full of people who have experience with it (including me), so this may be the best user group for ADCD. Is anyone of you using an ADCD system still having a V1.10 system? If so, would someone please see, if the DFSMRCL0 module is in any of the LPA libraries in addition to the ADCD...LINKLIB. Just curios, because it still isn't clear why Barbara had no problem with FTP on her V1.10 system. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DFSMRCL0 usermod - was: I broke it
Scott, Also ran isrddn selects on both it was found on 1.10 but not found on 1.12 could you please check SMPE on the 1.12 system (MVS.GLOBAL.CSI) if sysmod IMS0001 is installed? If so, then please check where DFSMRCL0 is located on the 1.12 system (adcd.*.linklib?) We have 1.10 running level 0903 , it's there...in sys1.lpalib This is interesting. SYS1.LPALIB is not covered in the 1.13 RACF database by any profile in the PROGRAM class. Not sure if it was covered by a program profile in the 1.10 database. What about program control for programs loaded from LPA? LPA modules fetched from LPA in z/OS are considered APF auth'd, is there a similar rule for address spaces requiring program control? Just curios, because it still isn't clear why Barbara had no problem with FTP on her V1.10 system. I am told by our provider that ftp works on all 1.13 ADCD systems where the RACF database wasn't cleaned up by me. I am inclined to believe them because they use ftp to do the IP definitions, usually using the ADCDMST userid. Which is how I found out that ftp was broken. So either there is another backdoor that would allow ftp to run in a non-program-controlled environment (remember, that system comes with bpx.daemon defined with UACC(READ) and userids WEBSRV, IMWEBSRV, CBLDAP, IBMUSER and ZOSMFAD having explicit access up to alter to it - none of them looks like having anything to do with ftp, and adcd.z113.linklib is not program-controlled) or I made a huge (but not obvious to me) mistake when I cleaned up RACF. Which is why I am harping on this. Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z10/zVM DS6800 Problem
On Mon, 31 Dec 2012 09:16:10 -0600, Karl Severson karl_j_sever...@raytheon.com wrote: Our support team came up with a question having to do with licenses. Is there a license that identifies the SM PC to the z10 during the IML or IPL process? We reckoned that perhaps SM was allowed to boot up only so far so as to be able to be initially configured but when the time comes to actually IPL the mainframe there had to be a handshake between the SM and the DS6800 in order for the disk array to be seen by the z10 thereby allowing the IPL to proceed. Either that or we're still missing something that is in the original configuration file on our SM PC that isn't on the one at the customer site. Karl, 'm not a DS6800 expert, but I can tell you that the SM PC does not have to be identified to the z10, as the z10 doesn't talk to it. If it is a FICON attachment (vs. FC), then you will need to have activated the FICON Attachment feature on the controller and the usual FICON configuration tasks are needed. In particular, it means you need to have used the SM to configure the FICON ports on the controller. Alan Altmark IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
