Re: SPAM: How to suppress some informational VTAM messages ?
I'm looking for the best way to suppress some informational VTAM messages in syslog. Is there anybody want to share this to me ? -- Check the various offerings from Greg Price on the CBT site There are some very handy MPF exits there. Between them and the MFPLIST you can suppress just about anything I always left everything in the SYSLOG and only suppressed some messages from the actual consoles. -- 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: SPAM: How to suppress some informational VTAM messages ?
On Tue, 29 Jan 2008 22:17:09 -0600, Rick Fochtman <[EMAIL PROTECTED]> wrote: > > >>I'm looking for the best way to suppress some informational VTAM messages in syslog. Is there anybody want to share this to me ? >> >-- >Check the various offerings from Greg Price on the CBT site > >There are some very handy MPF exits there. Between them and the MFPLIST >you can suppress just about anything > >I always left everything in the SYSLOG and only suppressed some messages >from the actual consoles. I thought the whole idea of SUPPRESS was to keep them from running across an operator's console with all that *other* clutter, but they were KEPT in the SYSLOG, no?! Even with an MPFList? Not sure about what can be accomplished with an MPF exit? Another suggestion: If you have CA's OPSMVS product, use that. -- 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: SPAM: How to suppress some informational VTAM messages ?
--- I thought the whole idea of SUPPRESS was to keep them from running across an operator's console with all that *other* clutter, but they were KEPT in the SYSLOG, no?! Even with an MPFList? Not sure about what can be accomplished with an MPF exit? --- The selection of exits is such that you can suppress console only, SYSLOG only or both, just by choosing the correct exit name. Try it; you might even like it! -- 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: SPAM: How to suppress some informational VTAM messages ?
>I thought the whole idea of SUPPRESS was to keep them from running across an >operator's console with all that *other* clutter, but they were KEPT in the SYSLOG, no?! There is/was an option, under NETVIEW (I believe), that would supress messages in SYSLOG. I believe it was: SYSLOG(y/n) -- with Y as the default. I don't think it was/is supported by MPF. I think, from an audit perspective, this is not a good idea to use. I caught a SYSPROG doing this, almost 20 years ago, when controls weren't as tight. Almost everything he did was never journaled to SYSLOG (or the CONSOLE). That's how I caught him. He did something, that I knew about, and I happened to be looking at the SYSLOG under SDSF and noticed none of the messages, regarding what he did, showed up. - Too busy driving to stop for gas! -- 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: SPAM: How to suppress some informational VTAM messages ?
There are also some start options in VTAM. These options can also be specifed as operator commands. Look in the VTAM Operations and Resource Definition Reference manuals for the syntax of these options. Some of them are ASIRFMSG, DSIRFMSG, ESIRFMSG, FSIRFMSG, LSIRFMSG, RSIRFMSG, SIRFMSG. Usually I issue the commands to supress them after VTAM has fully started up. This way I know about problems during the initialization phase. Of course I have been bitten by problems which did not show themselves because the messages were suppressed. On Wed, 30 Jan 2008 17:43:28 +, Ted MacNEIL <[EMAIL PROTECTED]> wrote: >>I thought the whole idea of SUPPRESS was to keep them from running across an operator's console with all that *other* clutter, but they were KEPT in the >SYSLOG, no?! > >There is/was an option, under NETVIEW (I believe), that would supress messages in SYSLOG. >I believe it was: >SYSLOG(y/n) -- with Y as the default. > >I don't think it was/is supported by MPF. > >I think, from an audit perspective, this is not a good idea to use. >I caught a SYSPROG doing this, almost 20 years ago, when controls weren't as tight. >Almost everything he did was never journaled to SYSLOG (or the CONSOLE). >That's how I caught him. >He did something, that I knew about, and I happened to be looking at the SYSLOG under SDSF and noticed none of the messages, regarding what he did, showed up. > >- >Too busy driving to stop for gas! > -- 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: SPAM: How to suppress some informational VTAM messages ?
The VTAM messages depend on the MPF member used and it's options. The messages flow through the SSI to Netview and at that point the message automation table logic takes control. The sysprog at this time can Tailor the message automation table to do what the installation needs to have done. Regards, Scott Ford IDF - Host Developer -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Matthew Stitt Sent: Wednesday, January 30, 2008 1:04 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: SPAM: How to suppress some informational VTAM messages ? There are also some start options in VTAM. These options can also be specifed as operator commands. Look in the VTAM Operations and Resource Definition Reference manuals for the syntax of these options. Some of them are ASIRFMSG, DSIRFMSG, ESIRFMSG, FSIRFMSG, LSIRFMSG, RSIRFMSG, SIRFMSG. Usually I issue the commands to supress them after VTAM has fully started up. This way I know about problems during the initialization phase. Of course I have been bitten by problems which did not show themselves because the messages were suppressed. On Wed, 30 Jan 2008 17:43:28 +, Ted MacNEIL <[EMAIL PROTECTED]> wrote: >>I thought the whole idea of SUPPRESS was to keep them from running across an operator's console with all that *other* clutter, but they were KEPT in the >SYSLOG, no?! > >There is/was an option, under NETVIEW (I believe), that would supress messages in SYSLOG. >I believe it was: >SYSLOG(y/n) -- with Y as the default. > >I don't think it was/is supported by MPF. > >I think, from an audit perspective, this is not a good idea to use. >I caught a SYSPROG doing this, almost 20 years ago, when controls weren't as tight. >Almost everything he did was never journaled to SYSLOG (or the CONSOLE). >That's how I caught him. >He did something, that I knew about, and I happened to be looking at the SYSLOG under SDSF and noticed none of the messages, regarding what he did, showed up. > >- >Too busy driving to stop for gas! > -- 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 -- 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: SPAM: How to suppress some informational VTAM messages ?
On Jan 30, 2008, at 10:15 AM, Mark H. Young wrote: On Tue, 29 Jan 2008 22:17:09 -0600, Rick Fochtman <[EMAIL PROTECTED]> I always left everything in the SYSLOG and only suppressed some messages from the actual consoles. I thought the whole idea of SUPPRESS was to keep them from running across an operator's console with all that *other* clutter, but they were KEPT in the SYSLOG, no?! Even with an MPFList? Not sure about what can be accomplished with an MPF exit? Another suggestion: If you have CA's OPSMVS product, use that. Both suggestions are good. MPFLST is my preferred methodology for doing so. Why, because its in *ONE* place if there is an issue you do not have to go through 2 or 3 or more programs to find out "who". Nothing against CA OPMVS but I always like to keep things simple. Yes CA OPSMVS has some slick facilities but simpler things can be done with ISPF edit of a syslog dataset. You could probably even write a generic macro to do it. One thing I do like about say MPFLST it forces you to go through change control and everybody gets to see exactly what is being done. They cannot come back at you later and bitch. It also shows your boss that you are doing productive work. Just my opinion. Ed -- 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: SPAM: How to suppress some informational VTAM messages ?
Ed, I feel the same. MPFLIST was always my preferred method. You can suppress or pass messages into the Netview Subsystem Interface if you want to...or just use MPF vanilla Regards, Scott IDF -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ed Gould Sent: Wednesday, January 30, 2008 2:34 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: SPAM: How to suppress some informational VTAM messages ? On Jan 30, 2008, at 10:15 AM, Mark H. Young wrote: > On Tue, 29 Jan 2008 22:17:09 -0600, Rick Fochtman <[EMAIL PROTECTED]> > >> I always left everything in the SYSLOG and only suppressed some >> messages >> from the actual consoles. > > I thought the whole idea of SUPPRESS was to keep them from running > across > an operator's console with all that *other* clutter, but they were > KEPT in the > SYSLOG, no?! Even with an MPFList? Not sure about what can be > accomplished with an MPF exit? > > Another suggestion: If you have CA's OPSMVS product, use that. > Both suggestions are good. MPFLST is my preferred methodology for doing so. Why, because its in *ONE* place if there is an issue you do not have to go through 2 or 3 or more programs to find out "who". Nothing against CA OPMVS but I always like to keep things simple. Yes CA OPSMVS has some slick facilities but simpler things can be done with ISPF edit of a syslog dataset. You could probably even write a generic macro to do it. One thing I do like about say MPFLST it forces you to go through change control and everybody gets to see exactly what is being done. They cannot come back at you later and bitch. It also shows your boss that you are doing productive work. Just my opinion. Ed -- 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 -- 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: SPAM: How to suppress some informational VTAM messages ?
--- I feel the same. MPFLIST was always my preferred method. You can suppress or pass messages into the Netview Subsystem Interface if you want to...or just use MPF vanilla I agree with this basic viewpoint, but a small and WELL DOCUMENTED set of exits can be highly useful in the overall scheme of message management. Mr. Price's exits can be a highly useful adjunct for this whole process. Yes, change management should be involved, but so should operations staff and management. And, as always, audit requirements need to be observed. That's why I choose to delete messages ONLY from active consoles. In my shop, SYSLOG was considered a legal document and any interference with logging was considered a "terminal" offense. (Dept. of Commerce requirements) -- 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: SPAM: How to suppress some informational VTAM messages ?
On Wed, 30 Jan 2008 14:41:44 -0500, Scott Ford <[EMAIL PROTECTED]> wrote: >... You can suppress or >pass messages into the Netview Subsystem Interface if you want to...or just >use MPF vanilla >... The NetView "suppression" is actually a completely different technique. If you define NetView as VTAM's "primary programmed operator" VTAM passes its unsolicited messages to the PPO ACB and doesn't issue a WTO at all. That means that MPF doesn't get chance to play at all (yet). NetView can then decide to WTO the messages. If NetView WTOs them, _then_ MPF gets in the act. That word "unsolicited" is pretty important, though. Any VTAM activation message relating to resources in VTAMs configuration list - ATCCONxx - is considered solicited. VTAM WTO's those so MPF can supress them. ( BTW, Solicited VTAM messages are supposed to be command responses sent to the console issuing the command. I don't know what that means in this case. The console issuing the START NET? Consoles with AUTH=MASTER? Consoles with the network routecode (8, I think)? Whatever, they go where not wanted. Another option available in NetView V5.1 (or maybe it was 5.2) is the Message Revision Table where many MPF-ish actions (and several not so MPF-ish actions) are available in NetView's SSI. 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: SPAM: How to suppress some informational VTAM messages ?
On Jan 30, 2008, at 1:41 PM, Scott Ford wrote: Ed, I feel the same. MPFLIST was always my preferred method. You can suppress or pass messages into the Netview Subsystem Interface if you want to...or just use MPF vanilla Regards, Scott IDF I didn't mean to exclude netview, the lister just posted two options. I do like NETVIEW a little but have found it clumsy (IMO) to interact with. In my years of working with it the documentation was well on the lean side. I never figured out how to make sense out of NPDA (the first run in with this type of product was SU36(or was it 32). AFter seeing others people product for console, frankly almost every one elses product beat Netview hands down. I *THINK* that CA's product was bought by some acquisition (of course) although I am sure they made some improvements to it the before/after (I think but am not sure) they have at two products that are similar. As everyone knows I am not a fan of CA but the ops/MVS product is an OK product. I have not installed it just went to a class on it. Personally just for the syslog part of the product it is far superior, IMO, than Netview. Having said that Netview was NEVER designed to be a console management product, IMO. So I am not comparing apple to apples nor is it apples to oranges. The product that most fits your needs go with. I do not know how CA/OPS MVS interfaces with MVS. I suspect (but cannot say for sure) that it is a "honored" interface as I have not heard anyone say anything bad about the product (ie no system crashes or outages caused by CA/OPS MVS). Would operators benefit from using it is the 100K question. IBM is going in a direction that from hints on here I suspect will surprise us and before making the dollar investment in it I would wait and see what happens with the rumor of new consoles from IBM. Ed -- 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: SPAM: How to suppress some informational VTAM messages ?
Pat, Everytime I have implemented Netview including 1.0 thru the latest greatest, we used MPF to either pass or suppress Messages. Netview's message automation table can also do this If you pass all messages through MPF. Regards, Scott -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Patrick O'Keefe Sent: Wednesday, January 30, 2008 4:28 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: SPAM: How to suppress some informational VTAM messages ? On Wed, 30 Jan 2008 14:41:44 -0500, Scott Ford <[EMAIL PROTECTED]> wrote: >... You can suppress or >pass messages into the Netview Subsystem Interface if you want to...or just >use MPF vanilla >... The NetView "suppression" is actually a completely different technique. If you define NetView as VTAM's "primary programmed operator" VTAM passes its unsolicited messages to the PPO ACB and doesn't issue a WTO at all. That means that MPF doesn't get chance to play at all (yet). NetView can then decide to WTO the messages. If NetView WTOs them, _then_ MPF gets in the act. That word "unsolicited" is pretty important, though. Any VTAM activation message relating to resources in VTAMs configuration list - ATCCONxx - is considered solicited. VTAM WTO's those so MPF can supress them. ( BTW, Solicited VTAM messages are supposed to be command responses sent to the console issuing the command. I don't know what that means in this case. The console issuing the START NET? Consoles with AUTH=MASTER? Consoles with the network routecode (8, I think)? Whatever, they go where not wanted. Another option available in NetView V5.1 (or maybe it was 5.2) is the Message Revision Table where many MPF-ish actions (and several not so MPF-ish actions) are available in NetView's SSI. 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 -- 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: SPAM: How to suppress some informational VTAM messages ?
On Wed, 30 Jan 2008 19:43:52 -0500, Scott Ford <[EMAIL PROTECTED]> wrote: >... >Everytime I have implemented Netview including 1.0 thru >the latest greatest, we used MPF to either pass or suppress >Messages. Netview's message automation table can also do this >If you pass all messages through MPF. >... Sure. But that is true of VTAM messages only if you've failed to set up NetView as VTAM's primary programmed operator - NetView's (or at least NCCF's) original reason for existance. MPF will handle messages and pass them to NetView only if the MPF sees the messages - only if the messages are WTOed. VTAM does not WTO it's unsolicited messages (except for a very few - see: Message Percolation in VTAM's Messages and Codes manual) if it has an active PPO. 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: SPAM: How to suppress some informational VTAM messages ?
Pat, Absolutely agree... Scott -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Patrick O'Keefe Sent: Wednesday, January 30, 2008 11:10 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: SPAM: How to suppress some informational VTAM messages ? On Wed, 30 Jan 2008 19:43:52 -0500, Scott Ford <[EMAIL PROTECTED]> wrote: >... >Everytime I have implemented Netview including 1.0 thru >the latest greatest, we used MPF to either pass or suppress >Messages. Netview's message automation table can also do this >If you pass all messages through MPF. >... Sure. But that is true of VTAM messages only if you've failed to set up NetView as VTAM's primary programmed operator - NetView's (or at least NCCF's) original reason for existance. MPF will handle messages and pass them to NetView only if the MPF sees the messages - only if the messages are WTOed. VTAM does not WTO it's unsolicited messages (except for a very few - see: Message Percolation in VTAM's Messages and Codes manual) if it has an active PPO. 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 -- 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: SPAM: How to suppress some informational VTAM messages ?
On Wed, 30 Jan 2008 16:53:38 -0600, Ed Gould <[EMAIL PROTECTED]> wrote: >... >I didn't mean to exclude netview, the lister just posted two options. >... . As everyone knows I >am not a fan of CA but the ops/MVS product is an OK product. ... >... Personally just for the >syslog part of the product it is far superior, IMO, than Netview. >Having said that Netview was NEVER designed to be a console >management product, IMO. So I am not comparing apple to apples nor is >it apples to oranges. The product that most fits your needs go with. >... As the resident NetView bigot I'd like to comment and expand on that a bit. Comparing NetView and CA's OPS MVS *is* a bit of an unfair comparison because OPSMVS is an automation package; NetView is a platform that an automation package can be built upon. The more accurate comparison would be between OPSMVS and SA/390 (or SA for z/OS now). >I do not know how CA/OPS MVS interfaces with MVS. I suspect (but >cannot say for sure) that it is a "honored" interface as I have not >heard anyone say anything bad about the product (ie no system crashes >or outages caused by CA/OPS MVS). ... We have OPSMVS for automated operations and (on our DASD mirroring LPARs) SA z/OS for running GDPS (GDPS on top of SA z/OS on top of NetView). I don't deal directly with either automation package, but from what I've seen and heard, the suggestion of moving all automation to SA z/OS is met with derision or shudders. SA is apparently far to complex and/or counter- intuitive to be considered. However, I think the automation tools provided by NetView are very good for ad hoc automation tasks. Since VTAM messages get there first, and are not even seen by OPS MVS, I do most network automation there. > ... I never figured out how to make sense out of NPDA ... (Sorry about taking that quote out of order.) That isn't exactly the fault of the product (and doesn't relate to automation anyway). I was able to figure it out well enough that I've been generating my own alerts for years. As we've moved away from SNA networks there are many fewer devices and programs issuing their own alerts, but NPDA on a "focal point" NetView is a great central place to collect program-generated alerts notifying you of situations needing attention. 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: SPAM: How to suppress some informational VTAM messages ?
On Jan 30, 2008, at 10:41 PM, Patrick O'Keefe wrote: ... I never figured out how to make sense out of NPDA ... (Sorry about taking that quote out of order.) That isn't exactly the fault of the product (and doesn't relate to automation anyway). I was able to figure it out well enough that I've been generating my own alerts for years. As we've moved away from SNA networks there are many fewer devices and programs issuing their own alerts, but NPDA on a "focal point" NetView is a great central place to collect program-generated alerts notifying you of situations needing attention. Pat O'Keefe Pat: Getting back to my point NPDA was a PITA to just get a handle on what was going on. Every time I want to see some error it wasn't there. Heck half the time I had trouble finding the *** LU. I will be the first to admit I never attended a class on the thing but every time I would picked up a manual and go through the process I could not find what I was looking for. Plus as far as I could figure out there was no way to purge the database so I ended up putting it in NETVIEW at start up to delete and define the database. The splits got so bad and the pack busies got really bad (almost as much as the JES2 checkpoint) It just wasn't worth the effort to figure out how to fix it. It was easier just to bring down Netview and delete/define the data bases. For what it was designed for its probably OK but I would not recommend it (in reality AFAIK there is no other package out there) so its sort of mandatory you buy it. The network help desk could not even begin to figure it out. The only way I could get real information was to run TAF to trace items. BTW 95 percent of the time when I opened a 37xx (NCP) IBM always asked for a ACFTAP trace not what was in NPDA. The other 5 percent were extremely minor issues and I had the ACFTAF trace printed and ready to fax by the time they called back. They could could have accessed NPDA so from my perspective NPDA was essentially a waste of time. I thought I made it clear that I was not comparing netview to opsmvs. Ed Ed -- 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: SPAM: How to suppress some informational VTAM messages ?
Ed and Pat, I was a VTAM old timer for a long time with 3745's , etc. I used Netview's NLDM more than NPDA. I think if my memory serves me correctly that NPDA was designed for usage with IBM modemsright ? Regards, Scott IDF -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ed Gould Sent: Thursday, January 31, 2008 2:00 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: SPAM: How to suppress some informational VTAM messages ? On Jan 30, 2008, at 10:41 PM, Patrick O'Keefe wrote: > >> ... I never figured out how to make sense out of NPDA ... > (Sorry about taking that quote out of order.) > > That isn't exactly the fault of the product (and doesn't relate to > automation anyway). I was able to figure it out well enough that > I've been generating my own alerts for years. As we've moved away > from SNA networks there are many fewer devices and programs > issuing their own alerts, but NPDA on a "focal point" NetView is a > great central place to collect program-generated alerts notifying you > of situations needing attention. > > Pat O'Keefe > Pat: Getting back to my point NPDA was a PITA to just get a handle on what was going on. Every time I want to see some error it wasn't there. Heck half the time I had trouble finding the *** LU. I will be the first to admit I never attended a class on the thing but every time I would picked up a manual and go through the process I could not find what I was looking for. Plus as far as I could figure out there was no way to purge the database so I ended up putting it in NETVIEW at start up to delete and define the database. The splits got so bad and the pack busies got really bad (almost as much as the JES2 checkpoint) It just wasn't worth the effort to figure out how to fix it. It was easier just to bring down Netview and delete/define the data bases. For what it was designed for its probably OK but I would not recommend it (in reality AFAIK there is no other package out there) so its sort of mandatory you buy it. The network help desk could not even begin to figure it out. The only way I could get real information was to run TAF to trace items. BTW 95 percent of the time when I opened a 37xx (NCP) IBM always asked for a ACFTAP trace not what was in NPDA. The other 5 percent were extremely minor issues and I had the ACFTAF trace printed and ready to fax by the time they called back. They could could have accessed NPDA so from my perspective NPDA was essentially a waste of time. I thought I made it clear that I was not comparing netview to opsmvs. Ed Ed -- 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 -- 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
