Re: START fails no diagnostics!
Many thanks for the responses to my query. Based on these I changed all the SYSOUT statements for the WebSphere PROCs from SYSOUT=*,SPIN=UNALLOC,FREE=CLOSE to SYSOUT=H. WebSphere came up fine. I reverted back to the previous SYSOUT syntax and WebSphere came up fine again. I have no real idea of what's going on. There are two of us working on this box and between 1630 when I left yesterday and 0700 today no one was on and the only thing going on is DB2 activity for our automated testers. I am suspicious though, in that I am seeing JES2 resource shortages: £HASP050 JES2 RESOURCE SHORTAGE OF TGS - 94% UTILIZATION REACHED £HASP050 JES2 RESOURCE SHORTAGE OF JQES - 89% UTILIZATION REACHED On another system (z/OS 1.4) I've seen output behave strangely (not as I would have expected) with JES shortages, but nothing like this (z/OS 1.6). Don't know that this is the cause, but at this point I have no other explanation. So, for now WAS is back up, but I don't really know why, which isn't a really good feeling. But, if it happens again I'll know to modify the JES STC processing options to make sure I can get any and all output. Thanks again, www -Original Message- From: William Walsh Sent: 06 December 2005 15:01 To: 'IBM Mainframe Discussion List' Subject: START fails no diagnostics! Have you ever seen a situation where the START command is issued, but the address space fails with no diagnostics: 05340 13:30:58.39 WWALSH 0290 START BBO6ACR,JOBNAME=BBOS001,ENV=CPAC.CPAC.BBOS001 05340 13:30:58.44 0090 IRR812I PROFILE BBO6ACR.* (G) IN THE STARTED CLASS WAS USED 561 561 0090 TO START BBO6ACR WITH JOBNAME BBOS001. 05340 13:30:58.45 STC09920 0281 £HASP100 BBOS001 ON STCINRDR 05340 13:30:58.53 STC09920 0290 IEF695I START BBO6ACR WITH JOBNAME BBOS001 IS ASSIGNED TO USER ASCR1 , GROUP WSCFG1 05340 13:30:58.53 STC09920 0090 £HASP373 BBOS001 STARTED 05340 13:30:58.53 STC09920 0281 IEF403I BBOS001 - STARTED - TIME=13.30.58 05340 13:30:58.62 STC09920 0090 IEF404I BBOS001 - ENDED - TIME=13.30.58 05340 13:30:58.63 STC09920 0281 £HASP395 BBOS001 ENDED I see nothing on the JES2 queues for this address space. I have checked the WebSphere logger data, the WebSphere server1/logs filesystem, and EREP and cannot find any reason for this. It was working on Friday and we cannot identify the change that has caused this. I noticed the X33E SLIP trap being met following the end of BBOS001, but turning it off doesn't produce any additional information. I don't know LE, but tried adding the TRACE(ON,LE=3) parm to the BBOCTL program, but that didn't provide any results. The system dump datasets are empty. I can unmount the /WebSphere/V6R0 filesystem to force a JCL error and I tried creating a new WAS config file system. I can run this JCL as a job until I fail on a security issue. Any ideas? Thanks, William The information in this email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. If you are not the intended addressee please contact the sender and dispose of this e-mail. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: START fails no diagnostics!
In [EMAIL PROTECTED], on 12/06/2005 at 03:00 PM, William Walsh [EMAIL PROTECTED] said: Have you ever seen a situation where the START command is issued, but the address space fails with no diagnostics: No. How would I know that it had failed without a message to that effect? 05340 13:30:58.62 STC09920 0090 IEF404I BBOS001 - ENDED - TIME=13.30.58 That says that it ended; it doesn't say that it failed. I see nothing on the JES2 queues for this address space. Then you're probably using a purge class for MSGCLASS. Override it and look at the output. You may need to override individual SYSOUT classes on DD statements. Also check any *FS files that it creates. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: START fails no diagnostics!
On Tue, 6 Dec 2005 15:00:51 -, William Walsh [EMAIL PROTECTED] wrote: Have you ever seen a situation where the START command is issued, but the address space fails with no diagnostics: 05340 13:30:58.39 WWALSH 0290 START BBO6ACR,JOBNAME=BBOS001,ENV=CPAC.CPAC.BBOS001 05340 13:30:58.44 0090 IRR812I PROFILE BBO6ACR.* (G) IN THE STARTED CLASS WAS USED 561 561 0090 TO START BBO6ACR WITH JOBNAME BBOS001. 05340 13:30:58.45 STC09920 0281 £HASP100 BBOS001 ON STCINRDR 05340 13:30:58.53 STC09920 0290 IEF695I START BBO6ACR WITH JOBNAME BBOS001 IS ASSIGNED TO USER ASCR1 , GROUP WSCFG1 05340 13:30:58.53 STC09920 0090 £HASP373 BBOS001 STARTED 05340 13:30:58.53 STC09920 0281 IEF403I BBOS001 - STARTED - TIME=13.30.58 05340 13:30:58.62 STC09920 0090 IEF404I BBOS001 - ENDED - TIME=13.30.58 05340 13:30:58.63 STC09920 0281 £HASP395 BBOS001 ENDED I see nothing on the JES2 queues for this address space. I have checked the WebSphere logger data, the WebSphere server1/logs filesystem, and EREP and cannot find any reason for this. It was working on Friday and we cannot identify the change that has caused this. I noticed the X33E SLIP trap being met following the end of BBOS001, but turning it off doesn't produce any additional information. I don't know LE, but tried adding the TRACE(ON,LE=3) parm to the BBOCTL program, but that didn't provide any results. The system dump datasets are empty. I can unmount the /WebSphere/V6R0 filesystem to force a JCL error and I tried creating a new WAS config file system. I can run this JCL as a job until I fail on a security issue. Any ideas? Thanks, William The information in this email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. If you are not the intended addressee please contact the sender and dispose of this e-mail. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html William I don't know what this task does and I have not seen the JCL, but some of them have a DD statement like STDERR that point to an HFS file and an error message (if there was an error) is placed there. Just a thought. Heloisa -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
START fails no diagnostics!
Have you ever seen a situation where the START command is issued, but the address space fails with no diagnostics: 05340 13:30:58.39 WWALSH 0290 START BBO6ACR,JOBNAME=BBOS001,ENV=CPAC.CPAC.BBOS001 05340 13:30:58.44 0090 IRR812I PROFILE BBO6ACR.* (G) IN THE STARTED CLASS WAS USED 561 561 0090 TO START BBO6ACR WITH JOBNAME BBOS001. 05340 13:30:58.45 STC09920 0281 £HASP100 BBOS001 ON STCINRDR 05340 13:30:58.53 STC09920 0290 IEF695I START BBO6ACR WITH JOBNAME BBOS001 IS ASSIGNED TO USER ASCR1 , GROUP WSCFG1 05340 13:30:58.53 STC09920 0090 £HASP373 BBOS001 STARTED 05340 13:30:58.53 STC09920 0281 IEF403I BBOS001 - STARTED - TIME=13.30.58 05340 13:30:58.62 STC09920 0090 IEF404I BBOS001 - ENDED - TIME=13.30.58 05340 13:30:58.63 STC09920 0281 £HASP395 BBOS001 ENDED I see nothing on the JES2 queues for this address space. I have checked the WebSphere logger data, the WebSphere server1/logs filesystem, and EREP and cannot find any reason for this. It was working on Friday and we cannot identify the change that has caused this. I noticed the X33E SLIP trap being met following the end of BBOS001, but turning it off doesn't produce any additional information. I don't know LE, but tried adding the TRACE(ON,LE=3) parm to the BBOCTL program, but that didn't provide any results. The system dump datasets are empty. I can unmount the /WebSphere/V6R0 filesystem to force a JCL error and I tried creating a new WAS config file system. I can run this JCL as a job until I fail on a security issue. Any ideas? Thanks, William The information in this email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. If you are not the intended addressee please contact the sender and dispose of this e-mail. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: START fails no diagnostics!
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of William Walsh Sent: Tuesday, December 06, 2005 9:01 AM To: IBM-MAIN@BAMA.UA.EDU Subject: START fails no diagnostics! Have you ever seen a situation where the START command is issued, but the address space fails with no diagnostics: snip I see nothing on the JES2 queues for this address space. I have checked the WebSphere logger data, the WebSphere server1/logs filesystem, and EREP and cannot find any reason for this. It was working on Friday and we cannot identify the change that has caused this. I noticed the X33E SLIP trap being met following the end of BBOS001, but turning it off doesn't produce any additional information. I don't know LE, but tried adding the TRACE(ON,LE=3) parm to the BBOCTL program, but that didn't provide any results. The system dump datasets are empty. I can unmount the /WebSphere/V6R0 filesystem to force a JCL error and I tried creating a new WAS config file system. I can run this JCL as a job until I fail on a security issue. Any ideas? Thanks, William What it that STC? This action is normal if that is a UNIX type function which does a fork() and has the parent terminate. An example of this is the FTPD server. The FTPD started task terminates with no messages, but has fork()'ed another FTPD1 (or some other numeric suffix) task. Try doing a: D A,BBOS001* to see if there there are other address spaces which start with that name. If so, then the BBOS001 likely did a fork() and terminated with the child doing the actual processing. -- John McKown Senior Systems Programmer UICI Insurance Center Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its' content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: START fails no diagnostics!
In a message dated 12/6/2005 9:12:29 A.M. Central Standard Time, [EMAIL PROTECTED] writes: Any ideas? Probably need to look down the syslog and see if BBOS01 is purged. Default sysout for STC could be set to a PURGE class. So if you've got access to JCL change SYSOUT=* to SYSOUT=H or what ever your H(eld) class is. If it produced a DUMP it would be in syslog and could be in a DYNAMIC dump data set. Can pick most of these off with 3.4 sys1.dump. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: START fails no diagnostics!
I am not sure how your output processing is set... but you might check the OUTDISP on the OUTPUTCLASS associated with JOBCLASS(STC) to make sure your output is being saved. -Rob Schramm -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of William Walsh Sent: Tuesday, December 06, 2005 10:01 AM To: IBM-MAIN@BAMA.UA.EDU Subject: START fails no diagnostics! Have you ever seen a situation where the START command is issued, but the address space fails with no diagnostics: 05340 13:30:58.39 WWALSH 0290 START BBO6ACR,JOBNAME=BBOS001,ENV=CPAC.CPAC.BBOS001 05340 13:30:58.44 0090 IRR812I PROFILE BBO6ACR.* (G) IN THE STARTED CLASS WAS USED 561 561 0090 TO START BBO6ACR WITH JOBNAME BBOS001. 05340 13:30:58.45 STC09920 0281 £HASP100 BBOS001 ON STCINRDR 05340 13:30:58.53 STC09920 0290 IEF695I START BBO6ACR WITH JOBNAME BBOS001 IS ASSIGNED TO USER ASCR1 , GROUP WSCFG1 05340 13:30:58.53 STC09920 0090 £HASP373 BBOS001 STARTED 05340 13:30:58.53 STC09920 0281 IEF403I BBOS001 - STARTED - TIME=13.30.58 05340 13:30:58.62 STC09920 0090 IEF404I BBOS001 - ENDED - TIME=13.30.58 05340 13:30:58.63 STC09920 0281 £HASP395 BBOS001 ENDED I see nothing on the JES2 queues for this address space. I have checked the WebSphere logger data, the WebSphere server1/logs filesystem, and EREP and cannot find any reason for this. It was working on Friday and we cannot identify the change that has caused this. I noticed the X33E SLIP trap being met following the end of BBOS001, but turning it off doesn't produce any additional information. I don't know LE, but tried adding the TRACE(ON,LE=3) parm to the BBOCTL program, but that didn't provide any results. The system dump datasets are empty. I can unmount the /WebSphere/V6R0 filesystem to force a JCL error and I tried creating a new WAS config file system. I can run this JCL as a job until I fail on a security issue. Any ideas? Thanks, William The information in this email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. If you are not the intended addressee please contact the sender and dispose of this e-mail. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: START fails no diagnostics!
One thing I usually do with STCs that fail, is to run the STC JCL as a batch job. It would not matter if the job failed, but I would be able to see if there were any data sets that were not valid or if there were some other issue or messages. //TSTJCL JOB ... //S1 EXEC PROC=BBOS001 Since the BBOS001 is created by WS I would suspect it may fail. Second is to modify the STC JCL to have a SYSOUT=A or some other non-purgable sysout class. That way the STC output stays in JES. Also, have you tried doing an ST in SDSF for the job? Sometimes you will not see anything in any other queue under SDSF except for ST on that jobtask name. The dynamic SVC dump name would depend on your definition in your environment. You can display the dumps via D D,ST (Display Dump,Status) both dynamic dumps and SYS1.DUMPxx data sets will be displayed. Lizette Koehler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Symbols in batch JCL (was: START fails no diagnostics!)
In a recent note, Lizette Koehler said: Date: Tue, 6 Dec 2005 09:01:57 -0700 One thing I usually do with STCs that fail, is to run the STC JCL as a batch job. It would not matter if the job failed, but I would be able to see if there were any data sets that were not valid or if there were some other issue or messages. This technique is far less effective if the STC JCL contains system symbols. There's another good argument here for supporting symbols in batch JCL. -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: START fails no diagnostics!
On Tue, 6 Dec 2005 09:01:57 -0700, Lizette Koehler [EMAIL PROTECTED] wrote: One thing I usually do with STCs that fail, is to run the STC JCL as a batch job. ... Another technique that has worked for me is to override MSGCLASS. S whatever,MSGCLASS=x where x is your hold class. That will save anything with SYSOUT=* plus any of the JES datasets. At least that's the way it has worked in shops I've been. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Symbols in batch JCL (was: START fails no diagnostics!)
On Tue, 6 Dec 2005 11:30:53 -0700, Paul Gilmartin [EMAIL PROTECTED] wrote: ... This technique is far less effective if the STC JCL contains system symbols. There's another good argument here for supporting symbols in batch JCL. ... For that kind of test it's a whole lot faster to stick some SET statements in the jobstream than to wait for IBM to provide system symbol support in batch jobs. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Symbols in batch JCL (was: START fails no diagnostics!)
In a recent note, Patrick O'Keefe said: Date: Tue, 6 Dec 2005 14:18:55 -0600 On Tue, 6 Dec 2005 11:30:53 -0700, Paul Gilmartin [log in to unmask] wrote: This technique is far less effective if the STC JCL contains system symbols. There's another good argument here for supporting symbols in batch JCL. ... For that kind of test it's a whole lot faster to stick some SET statements in the jobstream than to wait for IBM to provide system symbol support in batch jobs. I'm certainly not waiting. But, equally, I'll not dissemble to IBM my dissatisfaction with such a circumvention. -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
