Dumps when starting Started Tasks
Good morning, Yesterday we had an issue I'd like to share just in case someone has experienced it before. Sometime in the morning this piece of log appeared on syslog IEE501I CONSOLE UC4CN000 FAILED, REASON=ABTERM. ALL ALTERNATES UNAVAILABLE , CONSOLE IS NOT SWITCHED IEA631I OPERATOR UC4CN000 NOW INACTIVE, SYSTEM=CPUA, LU=UC4TR000 IEE828E SOME MESSAGES NOW SENT TO HARDCOPY ONLY Please notice this is not a "standard" console, it is somehow related to the product UC4 which is a Batch scheduler. We are still talking to support in order to know how this exactly works. The real problem was that from this moment no started tasks could be started, all of them crashed on start: START MVTASA.ST8005 $HASP100 MVTASA ON STCINRDR OMS9612I PROCESSING INIT (STC09784) IEF695I START MVTASA WITH JOBNAME MVTASA IS ASSIGNED TO USER STCSYS , GROUP STCGRP $HASP373 MVTASA STARTED IEA995I SYMPTOM DUMP OUTPUT 893 SYSTEM COMPLETION CODE=602 REASON CODE= TIME=08.32.24 SEQ=09184 CPU=0041 ASID=008F PSW AT TIME OF ERROR 070C1000 80FEB316 ILC 2 INTC 0D NO ACTIVE MODULE FOUND NAME=UNKNOWN DATA AT PSW 00FEB310 - 00181610 0A0D 00FF6258 AR/GR 0: /8400 1: /84602000 2: 0181001D/ 3: /00F61100 4: /008FFBF8 5: /000AB76C 6: /89494736 7: /00FB8D00 8: /00FEA621 9: / A: / B: /008FECA8 C: /0041 D: /0BF00E78 E: /00FF0280 F: / END OF SYMPTOM DUMP IEA989I SLIP TRAP ID=X33E MATCHED. JOBNAME=*UNAVAIL, ASID=008F. $HASP310 MVTASA TERMINATED AT END OF MEMORY We arrived a few minutes later. At this point some critical tasks in this shop required to be started as a started task so we had to stop and IPL the whole LPAR before major incidents appeared. With the fresh IPL the whole system worked fine. The last few lines of log (stopping JES2) during the stop showed us these lines. IEA989I SLIP TRAP ID=X33E MATCHED. JOBNAME=*UNAVAIL, ASID=0024. IEA989I SLIP TRAP ID=X33E MATCHED. JOBNAME=*UNAVAIL, ASID=002D. IEA989I SLIP TRAP ID=X33E MATCHED. JOBNAME/ASID NOT AVAILABLE. IEA989I SLIP TRAP ID=X33E MATCHED. JOBNAME/ASID NOT AVAILABLE. IEA989I SLIP TRAP ID=X33E MATCHED. JOBNAME/ASID NOT AVAILABLE. IEA989I SLIP TRAP ID=X33E MATCHED. JOBNAME/ASID NOT AVAILABLE. IEA989I SLIP TRAP ID=X33E MATCHED. JOBNAME/ASID NOT AVAILABLE. IEA989I SLIP TRAP ID=X33E MATCHED. JOBNAME/ASID NOT AVAILABLE. $HASP310 INIT TERMINATED AT END OF MEMORY $HASP310 INIT TERMINATED AT END OF MEMORY $HASP310 INIT TERMINATED AT END OF MEMORY $HASP310 INIT TERMINATED AT END OF MEMORY $HASP310 INIT TERMINATED AT END OF MEMORY $HASP310 INIT TERMINATED AT END OF MEMORY $HASP310 INIT TERMINATED AT END OF MEMORY $HASP310 INIT TERMINATED AT END OF MEMORY $HASP310 INIT TERMINATED AT END OF MEMORY $HASP310 INIT TERMINATED AT END OF MEMORY $HASP310 INIT TERMINATED AT END OF MEMORY Has anyone experienced something similar? Regards, Ferran -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
The Register discovers IBM Hursley
http://www.theregister.co.uk/2014/04/10/geeks_guide_visits_ibm_hursley/ Located just off the A3090. How cool is that? 8-) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Accessing DASD areas that have no DSCB (UNCLASSIFIED)
:>: -Original Message- :>: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :>: Behalf Of Paul Gilmartin :>: Sent: Monday, April 14, 2014 8:51 PM :>: To: IBM-MAIN@LISTSERV.UA.EDU :>: Subject: Re: Accessing DASD areas that have no DSCB (UNCLASSIFIED) :>: :>: On Wed, 9 Apr 2014 14:27:28 +, Storr, Lon A CTR USARMY HRC (US) :>: wrote: :>: > :>: >When a dataset is deleted, it is scratched and its DSCB in the VTOC is :>: freed. Hence, as far as I know, the dataset's data can only be accessed :>: in one of two ways: :>: > :>: Pedantry: "have no DSCB"? Is there not in fact a DSCB describing such :>: an extent? Perhaps a Format 5, or thereabouts? Only for non-indexed volumes. If the volume is indexed, the free space details are kept in the index, not the VTOC. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dumps when starting Started Tasks
Only a guess, however this is what my first suspicion would be : (1) You have an ISV product that is detecting a new address or jobstep - (maybe via the IEFUJI or IEFUSI). (2) The ISV product exit is attempting to notify its associated server via a cross-memory post using an ASCB address stored somewhere in common storage. (3) It is possible your ISV product has terminated without cleaning up, leaving behind the exit and the common storage control block. (3a) It is also possible that the common storage block has been overlaid somehow without the ISV server terminating. (4) The exit is attempting to cross-memory post using bad (or out of date) information from the common storage control block. This would explain the S602 abends that you are seeing. Capture a dump and you should be able to find the address of the POST-issuing program. Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ferran Perxas Sent: 15 April 2014 08:29 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Dumps when starting Started Tasks Good morning, Yesterday we had an issue I'd like to share just in case someone has experienced it before. Sometime in the morning this piece of log appeared on syslog IEE501I CONSOLE UC4CN000 FAILED, REASON=ABTERM. ALL ALTERNATES UNAVAILABLE , CONSOLE IS NOT SWITCHED IEA631I OPERATOR UC4CN000 NOW INACTIVE, SYSTEM=CPUA, LU=UC4TR000 IEE828E SOME MESSAGES NOW SENT TO HARDCOPY ONLY Please notice this is not a "standard" console, it is somehow related to the product UC4 which is a Batch scheduler. We are still talking to support in order to know how this exactly works. The real problem was that from this moment no started tasks could be started, all of them crashed on start: START MVTASA.ST8005 $HASP100 MVTASA ON STCINRDR OMS9612I PROCESSING INIT (STC09784) IEF695I START MVTASA WITH JOBNAME MVTASA IS ASSIGNED TO USER STCSYS , GROUP STCGRP $HASP373 MVTASA STARTED IEA995I SYMPTOM DUMP OUTPUT 893 SYSTEM COMPLETION CODE=602 REASON CODE= TIME=08.32.24 SEQ=09184 CPU=0041 ASID=008F PSW AT TIME OF ERROR 070C1000 80FEB316 ILC 2 INTC 0D NO ACTIVE MODULE FOUND NAME=UNKNOWN DATA AT PSW 00FEB310 - 00181610 0A0D 00FF6258 AR/GR 0: /8400 1: /84602000 2: 0181001D/ 3: /00F61100 4: /008FFBF8 5: /000AB76C 6: /89494736 7: /00FB8D00 8: /00FEA621 9: / A: / B: /008FECA8 C: /0041 D: /0BF00E78 E: /00FF0280 F: / END OF SYMPTOM DUMP IEA989I SLIP TRAP ID=X33E MATCHED. JOBNAME=*UNAVAIL, ASID=008F. $HASP310 MVTASA TERMINATED AT END OF MEMORY We arrived a few minutes later. At this point some critical tasks in this shop required to be started as a started task so we had to stop and IPL the whole LPAR before major incidents appeared. With the fresh IPL the whole system worked fine. The last few lines of log (stopping JES2) during the stop showed us these lines. IEA989I SLIP TRAP ID=X33E MATCHED. JOBNAME=*UNAVAIL, ASID=0024. IEA989I SLIP TRAP ID=X33E MATCHED. JOBNAME=*UNAVAIL, ASID=002D. IEA989I SLIP TRAP ID=X33E MATCHED. JOBNAME/ASID NOT AVAILABLE. IEA989I SLIP TRAP ID=X33E MATCHED. JOBNAME/ASID NOT AVAILABLE. IEA989I SLIP TRAP ID=X33E MATCHED. JOBNAME/ASID NOT AVAILABLE. IEA989I SLIP TRAP ID=X33E MATCHED. JOBNAME/ASID NOT AVAILABLE. IEA989I SLIP TRAP ID=X33E MATCHED. JOBNAME/ASID NOT AVAILABLE. IEA989I SLIP TRAP ID=X33E MATCHED. JOBNAME/ASID NOT AVAILABLE. $HASP310 INIT TERMINATED AT END OF MEMORY $HASP310 INIT TERMINATED AT END OF MEMORY $HASP310 INIT TERMINATED AT END OF MEMORY $HASP310 INIT TERMINATED AT END OF MEMORY $HASP310 INIT TERMINATED AT END OF MEMORY $HASP310 INIT TERMINATED AT END OF MEMORY $HASP310 INIT TERMINATED AT END OF MEMORY $HASP310 INIT TERMINATED AT END OF MEMORY $HASP310 INIT TERMINATED AT END OF MEMORY $HASP310 INIT TERMINATED AT END OF MEMORY $HASP310 INIT TERMINATED AT END OF MEMORY Has anyone experienced something similar? Regards, Ferran -- 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: Accessing DASD areas that have no DSCB (UNCLASSIFIED)
W dniu 2014-04-15 11:11, retired mainframer pisze: :>: -Original Message- :>: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :>: Behalf Of Paul Gilmartin :>: Sent: Monday, April 14, 2014 8:51 PM :>: To: IBM-MAIN@LISTSERV.UA.EDU :>: Subject: Re: Accessing DASD areas that have no DSCB (UNCLASSIFIED) :>: :>: On Wed, 9 Apr 2014 14:27:28 +, Storr, Lon A CTR USARMY HRC (US) :>: wrote: :>: > :>: >When a dataset is deleted, it is scratched and its DSCB in the VTOC is :>: freed. Hence, as far as I know, the dataset's data can only be accessed :>: in one of two ways: :>: > :>: Pedantry: "have no DSCB"? Is there not in fact a DSCB describing such :>: an extent? Perhaps a Format 5, or thereabouts? Only for non-indexed volumes. If the volume is indexed, the free space details are kept in the index, not the VTOC. Nevermind, the question was about free space, regardless of the wording used to descirbe it. -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając 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 authorized 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. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2014 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.696.052 złote. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dumps when starting Started Tasks
On Tue, 15 Apr 2014 09:19:30 +, Rob Scott wrote: > Capture a dump and you should be able to find the address of the POST-issuing > program. If it were my shop I'd be mighty cranky if a Stand Alone Dump wasn't taken - big likelihood this is a "one-off" and not something where a dump can be captured at will. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dumps when starting Started Tasks
Of course, the first line should be : "(1) You have an ISV product that is detecting a new address space or jobstep - (maybe via the IEFUJI or IEFUSI)." Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rob Scott Sent: 15 April 2014 10:20 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dumps when starting Started Tasks Only a guess, however this is what my first suspicion would be : (1) You have an ISV product that is detecting a new address or jobstep - (maybe via the IEFUJI or IEFUSI). (2) The ISV product exit is attempting to notify its associated server via a cross-memory post using an ASCB address stored somewhere in common storage. (3) It is possible your ISV product has terminated without cleaning up, leaving behind the exit and the common storage control block. (3a) It is also possible that the common storage block has been overlaid somehow without the ISV server terminating. (4) The exit is attempting to cross-memory post using bad (or out of date) information from the common storage control block. This would explain the S602 abends that you are seeing. Capture a dump and you should be able to find the address of the POST-issuing program. Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ferran Perxas Sent: 15 April 2014 08:29 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Dumps when starting Started Tasks Good morning, Yesterday we had an issue I'd like to share just in case someone has experienced it before. Sometime in the morning this piece of log appeared on syslog IEE501I CONSOLE UC4CN000 FAILED, REASON=ABTERM. ALL ALTERNATES UNAVAILABLE , CONSOLE IS NOT SWITCHED IEA631I OPERATOR UC4CN000 NOW INACTIVE, SYSTEM=CPUA, LU=UC4TR000 IEE828E SOME MESSAGES NOW SENT TO HARDCOPY ONLY Please notice this is not a "standard" console, it is somehow related to the product UC4 which is a Batch scheduler. We are still talking to support in order to know how this exactly works. The real problem was that from this moment no started tasks could be started, all of them crashed on start: START MVTASA.ST8005 $HASP100 MVTASA ON STCINRDR OMS9612I PROCESSING INIT (STC09784) IEF695I START MVTASA WITH JOBNAME MVTASA IS ASSIGNED TO USER STCSYS , GROUP STCGRP $HASP373 MVTASA STARTED IEA995I SYMPTOM DUMP OUTPUT 893 SYSTEM COMPLETION CODE=602 REASON CODE= TIME=08.32.24 SEQ=09184 CPU=0041 ASID=008F PSW AT TIME OF ERROR 070C1000 80FEB316 ILC 2 INTC 0D NO ACTIVE MODULE FOUND NAME=UNKNOWN DATA AT PSW 00FEB310 - 00181610 0A0D 00FF6258 AR/GR 0: /8400 1: /84602000 2: 0181001D/ 3: /00F61100 4: /008FFBF8 5: /000AB76C 6: /89494736 7: /00FB8D00 8: /00FEA621 9: / A: / B: /008FECA8 C: /0041 D: /0BF00E78 E: /00FF0280 F: / END OF SYMPTOM DUMP IEA989I SLIP TRAP ID=X33E MATCHED. JOBNAME=*UNAVAIL, ASID=008F. $HASP310 MVTASA TERMINATED AT END OF MEMORY We arrived a few minutes later. At this point some critical tasks in this shop required to be started as a started task so we had to stop and IPL the whole LPAR before major incidents appeared. With the fresh IPL the whole system worked fine. The last few lines of log (stopping JES2) during the stop showed us these lines. IEA989I SLIP TRAP ID=X33E MATCHED. JOBNAME=*UNAVAIL, ASID=0024. IEA989I SLIP TRAP ID=X33E MATCHED. JOBNAME=*UNAVAIL, ASID=002D. IEA989I SLIP TRAP ID=X33E MATCHED. JOBNAME/ASID NOT AVAILABLE. IEA989I SLIP TRAP ID=X33E MATCHED. JOBNAME/ASID NOT AVAILABLE. IEA989I SLIP TRAP ID=X33E MATCHED. JOBNAME/ASID NOT AVAILABLE. IEA989I SLIP TRAP ID=X33E MATCHED. JOBNAME/ASID NOT AVAILABLE. IEA989I SLIP TRAP ID=X33E MATCHED. JOBNAME/ASID NOT AVAILABLE. IEA989I SLIP TRAP ID=X33E MATCHED. JOBNAME/ASID NOT AVAILABLE. $HASP310 INIT TERMINATED AT END OF MEMORY $HASP310 INIT TERMINATED AT END OF MEMORY $HASP310 INIT TERMINATED AT END OF MEMORY $HASP310 INIT TERMINATED AT END OF MEMORY $HASP310 INIT TERMINATED AT END OF MEMORY $HASP310 INIT TERMINATED AT END OF MEMORY $HASP310 INIT TERMINATED AT END OF MEMORY $HASP310 INIT TERMINATED AT END OF MEMORY $HASP310 INIT TERMINATED AT END OF MEMORY $HASP310 INIT TERMINATED AT END OF MEMORY $HASP310 INIT TERMINATED AT END OF MEMORY Has anyone experienced something similar? Regards, Ferran
Re: Dumps when starting Started Tasks
Hi Rob and Shane, Yes this is a "one-off" at least we hope it. In this shop they have some sort of policy in capturing dumps vs DASD space that I do not like to comment. Far beyond cranky feels more appropriate. Thanks Rob, that's such a nice first guess (I did understand your (1) ) But then, if they're not able to patch the program in order to clean all the mess and do not leave exits behind, is there something we can do to clean the Address ourselves. I can't think about anything "not dangerous". Regards, Ferran On Tue, Apr 15, 2014 at 11:49 AM, Rob Scott wrote: > Of course, the first line should be : > > "(1) You have an ISV product that is detecting a new address space or > jobstep - (maybe via the IEFUJI or IEFUSI)." > > Rob Scott > Lead Developer > Rocket Software > 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA > Tel: +1.781.684.2305 > Email: rsc...@rs.com > Web: www.rocketsoftware.com > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Rob Scott > Sent: 15 April 2014 10:20 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Dumps when starting Started Tasks > > Only a guess, however this is what my first suspicion would be : > > (1) You have an ISV product that is detecting a new address or jobstep - > (maybe via the IEFUJI or IEFUSI). > (2) The ISV product exit is attempting to notify its associated server via > a cross-memory post using an ASCB address stored somewhere in common > storage. > (3) It is possible your ISV product has terminated without cleaning up, > leaving behind the exit and the common storage control block. > (3a) It is also possible that the common storage block has been overlaid > somehow without the ISV server terminating. > (4) The exit is attempting to cross-memory post using bad (or out of date) > information from the common storage control block. > > This would explain the S602 abends that you are seeing. > > Capture a dump and you should be able to find the address of the > POST-issuing program. > > Rob Scott > Lead Developer > Rocket Software > 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA > Tel: +1.781.684.2305 > Email: rsc...@rs.com > Web: www.rocketsoftware.com > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Ferran Perxas > Sent: 15 April 2014 08:29 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Dumps when starting Started Tasks > > Good morning, > > Yesterday we had an issue I'd like to share just in case someone has > experienced it before. > > Sometime in the morning this piece of log appeared on syslog > > IEE501I CONSOLE UC4CN000 FAILED, REASON=ABTERM. ALL ALTERNATES > UNAVAILABLE , CONSOLE IS NOT SWITCHED > IEA631I OPERATOR UC4CN000 NOW INACTIVE, SYSTEM=CPUA, LU=UC4TR000 > > IEE828E SOME MESSAGES NOW SENT TO HARDCOPY ONLY > > Please notice this is not a "standard" console, it is somehow related to > the product UC4 which is a Batch scheduler. We are still talking to support > in order to know how this exactly works. > > The real problem was that from this moment no started tasks could be > started, all of them crashed on start: > > START MVTASA.ST8005 > $HASP100 MVTASA ON STCINRDR > OMS9612I PROCESSING INIT (STC09784) > IEF695I START MVTASA WITH JOBNAME MVTASA IS ASSIGNED TO USER STCSYS > , GROUP STCGRP > $HASP373 MVTASA STARTED > IEA995I SYMPTOM DUMP OUTPUT 893 > SYSTEM COMPLETION CODE=602 REASON CODE= > TIME=08.32.24 SEQ=09184 CPU=0041 ASID=008F > PSW AT TIME OF ERROR 070C1000 80FEB316 ILC 2 INTC 0D >NO ACTIVE MODULE FOUND >NAME=UNKNOWN >DATA AT PSW 00FEB310 - 00181610 0A0D 00FF6258 >AR/GR 0: /8400 1: /84602000 > 2: 0181001D/ 3: /00F61100 > 4: /008FFBF8 5: /000AB76C > 6: /89494736 7: /00FB8D00 > 8: /00FEA621 9: / > A: / B: /008FECA8 > C: /0041 D: /0BF00E78 > E: /00FF0280 F: / > END OF SYMPTOM DUMP > IEA989I SLIP TRAP ID=X33E MATCHED. JOBNAME=*UNAVAIL, ASID=008F. > $HASP310 MVTASA TERMINATED AT END OF MEMORY > > We arrived a few minutes later. At this point some critical tasks in this > shop required to be started as a started task so we had to stop and IPL the > whole LPAR before major incidents appeared. With the fresh IPL the whole > system worked fine. > > The last few lines of log (stopping JES2) during the stop showed us these > lines. > > IEA989I SLIP TRAP ID=X33E MATCHED. JOBNAME=*UNAVAIL, ASID=0024. > IEA989I SLIP TRAP ID=X33E MATCHED. JOBNAME=*UNAVAIL, ASID=002D. > IEA989I SLIP TRAP ID=X33E MATCHED. JOBNAME/ASID NOT AVAILABLE. > IEA989I SLIP TRAP ID=X33E MATCHED. JOBNAME/ASID NOT AVAILABLE. > IEA989I SLIP TRAP ID=X33E MATCHED. JOBNAME/ASID NOT AVAILABLE. > IEA989I SLIP TRAP ID=X33E MATCHED.
Re: Dumps when starting Started Tasks
Ferran Perxas wrote: >Yes this is a "one-off" at least we hope it. Something must have changed. I would sit down and review all and every changes on the whole SysPlex just to be sure. Everything like, parmlib changes, exit assembly, version change, etc. >But then, if they're not able to patch the program in order to clean all the >mess and do not leave exits behind, is there something we can do to clean the >Address ourselves. I can't think about anything "not dangerous". Perhaps IPL after setting up your SLIPs? I believe some residual memory areas are still sitting eating up precious bits and bytes. On what z/OS version are you? 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: Dumps when starting Started Tasks
You can remove dynamic exits (of which IEFUJI and IEFUSI are part) using the SETPROG EXIT command. But the above assumes that the product is, in fact, using them. Rob Scott Lead Developer Rocket Software 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ferran Perxas Sent: 15 April 2014 10:54 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dumps when starting Started Tasks Hi Rob and Shane, Yes this is a "one-off" at least we hope it. In this shop they have some sort of policy in capturing dumps vs DASD space that I do not like to comment. Far beyond cranky feels more appropriate. Thanks Rob, that's such a nice first guess (I did understand your (1) ) But then, if they're not able to patch the program in order to clean all the mess and do not leave exits behind, is there something we can do to clean the Address ourselves. I can't think about anything "not dangerous". Regards, Ferran On Tue, Apr 15, 2014 at 11:49 AM, Rob Scott wrote: > Of course, the first line should be : > > "(1) You have an ISV product that is detecting a new address space or > jobstep - (maybe via the IEFUJI or IEFUSI)." > > Rob Scott > Lead Developer > Rocket Software > 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA > Tel: +1.781.684.2305 > Email: rsc...@rs.com > Web: www.rocketsoftware.com > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Rob Scott > Sent: 15 April 2014 10:20 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Dumps when starting Started Tasks > > Only a guess, however this is what my first suspicion would be : > > (1) You have an ISV product that is detecting a new address or jobstep > - (maybe via the IEFUJI or IEFUSI). > (2) The ISV product exit is attempting to notify its associated server > via a cross-memory post using an ASCB address stored somewhere in > common storage. > (3) It is possible your ISV product has terminated without cleaning > up, leaving behind the exit and the common storage control block. > (3a) It is also possible that the common storage block has been > overlaid somehow without the ISV server terminating. > (4) The exit is attempting to cross-memory post using bad (or out of > date) information from the common storage control block. > > This would explain the S602 abends that you are seeing. > > Capture a dump and you should be able to find the address of the > POST-issuing program. > > Rob Scott > Lead Developer > Rocket Software > 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA > Tel: +1.781.684.2305 > Email: rsc...@rs.com > Web: www.rocketsoftware.com > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Ferran Perxas > Sent: 15 April 2014 08:29 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Dumps when starting Started Tasks > > Good morning, > > Yesterday we had an issue I'd like to share just in case someone has > experienced it before. > > Sometime in the morning this piece of log appeared on syslog > > IEE501I CONSOLE UC4CN000 FAILED, REASON=ABTERM. ALL ALTERNATES > UNAVAILABLE , CONSOLE IS NOT SWITCHED > IEA631I OPERATOR UC4CN000 NOW INACTIVE, SYSTEM=CPUA, LU=UC4TR000 > > IEE828E SOME MESSAGES NOW SENT TO HARDCOPY ONLY > > Please notice this is not a "standard" console, it is somehow related > to the product UC4 which is a Batch scheduler. We are still talking to > support in order to know how this exactly works. > > The real problem was that from this moment no started tasks could be > started, all of them crashed on start: > > START MVTASA.ST8005 > $HASP100 MVTASA ON STCINRDR > OMS9612I PROCESSING INIT (STC09784) > IEF695I START MVTASA WITH JOBNAME MVTASA IS ASSIGNED TO USER STCSYS > , GROUP STCGRP > $HASP373 MVTASA STARTED > IEA995I SYMPTOM DUMP OUTPUT 893 > SYSTEM COMPLETION CODE=602 REASON CODE= > TIME=08.32.24 SEQ=09184 CPU=0041 ASID=008F > PSW AT TIME OF ERROR 070C1000 80FEB316 ILC 2 INTC 0D >NO ACTIVE MODULE FOUND >NAME=UNKNOWN >DATA AT PSW 00FEB310 - 00181610 0A0D 00FF6258 >AR/GR 0: /8400 1: /84602000 > 2: 0181001D/ 3: /00F61100 > 4: /008FFBF8 5: /000AB76C > 6: /89494736 7: /00FB8D00 > 8: /00FEA621 9: / > A: / B: /008FECA8 > C: /0041 D: /0BF00E78 > E: /00FF0280 F: / > END OF SYMPTOM DUMP > IEA989I SLIP TRAP ID=X33E MATCHED. JOBNAME=*UNAVAIL, ASID=008F. > $HASP310 MVTASA TERMINATED AT END OF MEMORY > > We arrived a few minutes later. At this point some critical tasks in > this shop required to be started as a started t
Re: Dumps when starting Started Tasks
Hi Elardus, A new version of the ISV program was installed about 6 months ago. We've just find out what made it crash (this time) and it won't happen again. No other changes were made, this is a very old shop, a z/os 1.4. What we are trying to do is (just in case some other thing makes it ABEND again and it leaves some garbage behind) have some kind of workaround before having to stop and IPL the LPAR. Thanks Rob, I'll chat with the product manager to see if your theory is possible and then study the SETPROG possibility. Regards, Ferran On Tue, Apr 15, 2014 at 12:40 PM, Rob Scott wrote: > You can remove dynamic exits (of which IEFUJI and IEFUSI are part) using > the SETPROG EXIT command. > > But the above assumes that the product is, in fact, using them. > > Rob Scott > Lead Developer > Rocket Software > 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA > Tel: +1.781.684.2305 > Email: rsc...@rs.com > Web: www.rocketsoftware.com > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Ferran Perxas > Sent: 15 April 2014 10:54 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Dumps when starting Started Tasks > > Hi Rob and Shane, > > Yes this is a "one-off" at least we hope it. In this shop they have some > sort of policy in capturing dumps vs DASD space that I do not like to > comment. Far beyond cranky feels more appropriate. > > Thanks Rob, that's such a nice first guess (I did understand your (1) ) > > But then, if they're not able to patch the program in order to clean all > the mess and do not leave exits behind, is there something we can do to > clean the Address ourselves. I can't think about anything "not dangerous". > > Regards, > > Ferran > > > On Tue, Apr 15, 2014 at 11:49 AM, Rob Scott >wrote: > > > Of course, the first line should be : > > > > "(1) You have an ISV product that is detecting a new address space or > > jobstep - (maybe via the IEFUJI or IEFUSI)." > > > > Rob Scott > > Lead Developer > > Rocket Software > > 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA > > Tel: +1.781.684.2305 > > Email: rsc...@rs.com > > Web: www.rocketsoftware.com > > > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of Rob Scott > > Sent: 15 April 2014 10:20 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Dumps when starting Started Tasks > > > > Only a guess, however this is what my first suspicion would be : > > > > (1) You have an ISV product that is detecting a new address or jobstep > > - (maybe via the IEFUJI or IEFUSI). > > (2) The ISV product exit is attempting to notify its associated server > > via a cross-memory post using an ASCB address stored somewhere in > > common storage. > > (3) It is possible your ISV product has terminated without cleaning > > up, leaving behind the exit and the common storage control block. > > (3a) It is also possible that the common storage block has been > > overlaid somehow without the ISV server terminating. > > (4) The exit is attempting to cross-memory post using bad (or out of > > date) information from the common storage control block. > > > > This would explain the S602 abends that you are seeing. > > > > Capture a dump and you should be able to find the address of the > > POST-issuing program. > > > > Rob Scott > > Lead Developer > > Rocket Software > > 77 Fourth Avenue . Suite 100 . Waltham . MA 02451-1468 . USA > > Tel: +1.781.684.2305 > > Email: rsc...@rs.com > > Web: www.rocketsoftware.com > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of Ferran Perxas > > Sent: 15 April 2014 08:29 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Dumps when starting Started Tasks > > > > Good morning, > > > > Yesterday we had an issue I'd like to share just in case someone has > > experienced it before. > > > > Sometime in the morning this piece of log appeared on syslog > > > > IEE501I CONSOLE UC4CN000 FAILED, REASON=ABTERM. ALL ALTERNATES > > UNAVAILABLE , CONSOLE IS NOT SWITCHED > > IEA631I OPERATOR UC4CN000 NOW INACTIVE, SYSTEM=CPUA, LU=UC4TR000 > > > > IEE828E SOME MESSAGES NOW SENT TO HARDCOPY ONLY > > > > Please notice this is not a "standard" console, it is somehow related > > to the product UC4 which is a Batch scheduler. We are still talking to > > support in order to know how this exactly works. > > > > The real problem was that from this moment no started tasks could be > > started, all of them crashed on start: > > > > START MVTASA.ST8005 > > $HASP100 MVTASA ON STCINRDR > > OMS9612I PROCESSING INIT (STC09784) > > IEF695I START MVTASA WITH JOBNAME MVTASA IS ASSIGNED TO USER STCSYS > > , GROUP STCGRP > > $HASP373 MVTASA STARTED > > IEA995I SYMPTOM DUMP OUTPUT 893 > > SYSTEM COMPLETION CODE=602 REASON CODE= > > TIME=08.32.24 SEQ=09184 CPU=0041 ASID=008F > > PSW AT TIME OF ERROR 070C1000 80FEB316
Re: Enterprise COBOL v5.1 and RDz v9.x
On Mon, 14 Apr 2014 12:24:05 +, Chase, John wrote:
>Hi All,
>
>I learned via PMR that Rational Developer for System z ("RDz") v9.x ("latest &
>greatest") does not "officially" support Enterprise COBOL v5.1. The
>workaround suggested by RDz Support was to specify COBOL v4.2 and
>XMLPARSE(XMLSS) in the RDz wizard, because COBOL v5.1 does not support
>XMLPARSE(COMPAT). We did that, and the resulting program source generated by
>RDz compiled "clean" with COBOL v5.1, but ABENDs when invoked in CICS. The
>same source compiled with the COBOL v4.2 compiler runs fine in CICS.
>
>At the suggestion of the IBMer handling the RDz PMR I've opened a Request for
>Enhancement (RFE) on Developerworks. You may view the RFE at:
>
>http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=50856
>
>An "IBM ID" is required to view it, and to vote on it. If you have access to
>IBMLink, you have an "IBM ID".
>
>Please consider voting in favor of this RFE.
>
>Thanks,
>
>-jc-
>
>**
>Information contained in this e-mail message and in any attachments thereto is
>confidential. If you are not the intended recipient, please destroy this
>message, delete any copies held on your systems, notify the sender
>immediately, and refrain from using or disclosing all or any part of its
>content to any other person.
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
When an upgrade to zOS 2.1 is performed is one automatically at Cobol 5.1 as
well?
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Enterprise COBOL v5.1 and RDz v9.x
W dniu 2014-04-15 13:24, Govind Chettiar pisze: [...] When an upgrade to zOS 2.1 is performed is one automatically at Cobol 5.1 as well? Well, IT DEPENDS. AFAIK you cannot order downlevel COBOL. So, when you order z/OS 2.1 now and you also order COBOL - you will get 5.1 version. In general you can order only current versions of the products and system. Current at the time of order. Note, there is limited time window of "version coexistence" - time when you can order two versions of the software. Note GA (premiere) date of z/OS and COBOL need not to be synchronized. So, when did you make the order? -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając 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 authorized 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. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2014 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.696.052 złote. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Emulator Screen Size with Attachmate Extra X-treme 9.3
> -Original Message- > From: IBM Mainframe Discussion List On Behalf Of Ed Finnell > > From years of experience the x'02' is the query. If that's not on, you gets > what's dealt so to speak. > As one of the local auto dealers says 'irregardless'. Actually, it's the x'80' that contains the "query bit". The x'02' specifies LUTYPE2. -jc- > > > In a message dated 4/14/2014 4:55:19 P.M. Central Daylight Time, > edja...@phoenixsoftware.com writes: > > PSERVIC=X'02804450448E7F00' > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu > with the message: INFO IBM-MAIN ** Information contained in this e-mail message and in any attachments thereto is confidential. If you are not the intended recipient, please destroy this message, delete any copies held on your systems, notify the sender immediately, and refrain from using or disclosing all or any part of its content to any other person. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Enterprise COBOL v5.1 and RDz v9.x
This is not true. I ordered a ServerPac for z/OS 2.1 a couple of months ago and I had no problem ordering Enterprise COBOL 4.2 along with it - there was no requirement to upgrade to 5.1. Anyway, we can't upgrade to 5.1 until we migrate to a sysplex across our 3 LPARs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Enterprise COBOL v5.1 and RDz v9.x
W dniu 2014-04-15 13:52, Peter X. DeFabritus pisze: This is not true. I ordered a ServerPac for z/OS 2.1 a couple of months ago and I had no problem ordering Enterprise COBOL 4.2 along with it - there was no requirement to upgrade to 5.1. Anyway, we can't upgrade to 5.1 until we migrate to a sysplex across our 3 LPARs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Can you order COBOL v3 or z/OS 1.12 ? However, you are right: COBOL 4.2 is still orderable. One more remark: IBM policy is when they show new product, it is usually compatible with all *current* co-requisities. Regards -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając 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 authorized 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. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2014 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.696.052 złote. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dumps when starting Started Tasks
At 11:54 +0200 on 04/15/2014, Ferran Perxas wrote about Re: Dumps when starting Started Tasks: Yes this is a "one-off" at least we hope it. In this shop they have some sort of policy in capturing dumps vs DASD space that I do not like to comment. Far beyond cranky feels more appropriate. If they will not allow you to use DASD for storing the dump, why not use a tape as the target device? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dumps when starting Started Tasks
Thanks Robert, it's a nice suggestion, we have already asked for it. Thank you all, I'm talking with the ISV support I'll let you know if there are any updates. Regards On Tue, Apr 15, 2014 at 3:05 PM, Robert A. Rosenberg wrote: > At 11:54 +0200 on 04/15/2014, Ferran Perxas wrote about Re: Dumps when > starting Started Tasks: > > > Yes this is a "one-off" at least we hope it. In this shop they have some >> sort of policy in capturing dumps vs DASD space that I do not like to >> comment. Far beyond cranky feels more appropriate. >> > > If they will not allow you to use DASD for storing the dump, why not use a > tape as the target device? > > > -- > 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
Host on Demand and z/OS 1.13
We have just migrated our test lpar to z/OS 1.13 and we are having a problem with HOD. We have a ticket opened with HOD support but it will probably be transferred to z/OS HTTP. We set up a trace and it shows a handshake error and this error: Thd-7 ERROR default_setsocketoptions(): setsockopt (TCP-NODELAY) failed for socket 11: 121 - EDC5121I Invalid argument. Thd-7 ERROR gsk_secure_socket_init(): Default callback failed to restore socket options EDC5121I Invalid argument. Has anyone else experienced this problem with HOD? We are scheduled to go to production on April 27 and this might be a showstopper. Thank you. E-mail correspondence to and from this address may be subject to the North Carolina Public Records Law and may be disclosed to third parties by an authorized state official. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Accessing DASD areas that have no DSCB (UNCLASSIFIED)
If you deleted a dataset and the DASD is thin provisioned, it will recycle the tracks when the VTOC is updated, and the records are gone. If you deleted a dataset and RACF has Secure erase, the tracks are erased before the VTOC is updated. If you deleted a dataset and another dataset has allocated and written on those tracks, the data is destroyed when overwritten. If you deleted a dataset, and the three ways to destroy the data have not occurred, then you use Absolute Track allocation to re-allocate those tracks and read them. The DCB must match, along with directory entries. On Mon, Apr 14, 2014 at 10:50 PM, Paul Gilmartin wrote: > On Wed, 9 Apr 2014 14:27:28 +, Storr, Lon A CTR USARMY HRC (US) wrote: >> >>When a dataset is deleted, it is scratched and its DSCB in the VTOC is freed. >>Hence, as far as I know, the dataset's data can only be accessed in one of >>two ways: >> > Pedantry: "have no DSCB"? Is there not in fact a DSCB describing such > an extent? Perhaps a Format 5, or thereabouts? > > -- gil > > -- > 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: Accessing DASD areas that have no DSCB (UNCLASSIFIED)
On Tue, 15 Apr 2014 11:33:39 -0500, Mike Schwab wrote: > >If you deleted a dataset, and the three ways to destroy the data have >not occurred, then you use Absolute Track allocation to re-allocate >those tracks and read them. The DCB must match, along with directory >entries. > FSVO "match". Nearly anything ought to be readable with RECFM=U. Keys make it more complicated, but there are (used to be?) CCWs for this (backup utilites need them). An assembler program can read beyond end-of-file (to wit the utilities for recovering deleted PDS members). PDSE, HFS, and zFS are harder yet, in part because of ab$ence of documentation. I thought no DCB information as such is retained for a deleted data set. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dumps when starting Started Tasks
On Tue, 15 Apr 2014 16:31:00 +0200, Ferran Perxas wrote: >Thanks Robert, it's a nice suggestion, we have already asked for it. > >> >> If they will not allow you to use DASD for storing the dump, why not use a >> tape as the target device? Be aware that this might be *VERY* slow. - was last time I tested it, but that was on 3590 (: In production outages time is usually a more prized commodity than DASD space - educate your operations people. Much has been done to allow disk dumps to run pretty quickly - none of that probably helps on tape. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dumps when starting Started Tasks
Sometimes EREP data can provide enough to distinguish the stomper from the stompees. Active PSW REGs and a few lines of failing module can be enough to see where it started. If it's vendor code they might have seen it before or know under what conditions it can be caused. The DB/2 folks were particularly adept in my opinion. Had one where all but the last few dumps had been purged for space, but the offender was the first one. Turns out a table had been dropped and recreated. When tried to reload it failed. REG 6? Oh, it had been extended on the fly. Just recreate the table, extend and then do the reload. Oh, OK-it worked. In a message dated 4/15/2014 2:59:41 P.M. Central Daylight Time, ibm-m...@tpg.com.au writes: In production outages time is usually a more prized commodity than DASD space - educate your operations people. Much has been done to allow disk dumps to run pretty quickly - none of that probably helps on tape. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Emulator Screen Size with Attachmate Extra X-treme 9.3
Good catch, My old yellow notes just had PSERVIC starting with x'0280' as queryable. The next page describes the entries... In a message dated 4/15/2014 6:41:52 A.M. Central Daylight Time, jch...@ussco.com writes: Actually, it's the x'80' that contains the "query bit". The x'02' specifies LUTYPE2 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Fileaid Error
Hello. I am running File aid job and getting the errored out, could someone please let me know what is the issue in the card? //STEP03 EXEC PGM=FILEAID //DD01 DD DSN=P01.MPLTD.D0415.NEW,DISP=SHR //SYSLIST DD DSN=RKKUDE.S1ANCOPY.LIBR,DISP=(,CATLG,CATLG), //RECFM=FB,LRECL=132, //SPACE=(CYL,(50,20),RLSE) //**&& ADD $$DD CARDS //SYSINDD * $$DD01 LIST IF=(1,0,C'BAIS_LIMIT'), ORIF=(1,0,C'CALC_ETHOD_CODE'), ORIF=(1,0,C'COMENT_TEXT'),OUT=0 ORIF=(1,0,C'C1MENT_TEXT'),OUT=0 ORIF=(1,0,C'C2MMENT_TEXT'),OUT=0 ORIF=(1,0,C'C3MMENT_TEXT'),OUT=0 /* Here I am getting the below error. $$DD01 LIST IF=(1,0,C'BASIS_LIMIT'), ORIF=(1,0,C'CALC_METHOD_CODE'), ORIF=(1,0,C'COMMENT_TEXT'),OUT=0 ABOVE FUNCTION ENDED ON DIRECTORY ENDRC=0 MEMBERS-READ=23,SELECTED=23,RECORDS-READ=25449 ORIF=(1,0,C'C1MMENT_TEXT'),OUT=0 CONTROL CARD DOES NOT BEGIN WITH $$DD .SKIPPING TO NEXT $$DD CARD RC=4 Thanks Rajeev V -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Fileaid Error
you will need to put comma at the end of every out (except the last) On 2014-04-15, 20:20, Ron Thomas wrote: Hello. I am running File aid job and getting the errored out, could someone please let me know what is the issue in the card? //STEP03 EXEC PGM=FILEAID //DD01 DD DSN=P01.MPLTD.D0415.NEW,DISP=SHR //SYSLIST DD DSN=RKKUDE.S1ANCOPY.LIBR,DISP=(,CATLG,CATLG), //RECFM=FB,LRECL=132, //SPACE=(CYL,(50,20),RLSE) //**&& ADD $$DD CARDS //SYSINDD * $$DD01 LIST IF=(1,0,C'BAIS_LIMIT'), ORIF=(1,0,C'CALC_ETHOD_CODE'), ORIF=(1,0,C'COMENT_TEXT'),OUT=0 ORIF=(1,0,C'C1MENT_TEXT'),OUT=0 ORIF=(1,0,C'C2MMENT_TEXT'),OUT=0 ORIF=(1,0,C'C3MMENT_TEXT'),OUT=0 /* Here I am getting the below error. $$DD01 LIST IF=(1,0,C'BASIS_LIMIT'), ORIF=(1,0,C'CALC_METHOD_CODE'), ORIF=(1,0,C'COMMENT_TEXT'),OUT=0 ABOVE FUNCTION ENDED ON DIRECTORY ENDRC=0 MEMBERS-READ=23,SELECTED=23,RECORDS-READ=25449 ORIF=(1,0,C'C1MMENT_TEXT'),OUT=0 CONTROL CARD DOES NOT BEGIN WITH $$DD .SKIPPING TO NEXT $$DD CARD RC=4 Thanks Rajeev V -- 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
