Joe
If you want a log of VTAM messages for archive purposes, why not write a
simple program which extracts all "IST" messages from the log into your
exclusively VTAM logging file?
I took the trouble actually - again surely - to read up on the VTAM PPOLOG
start option. I hadn't really noticed sufficiently to remember it before
that the author of the PPOLOG description simply assumes that any program
worth its salt as a "Primary Program Operator" (PPO) would, of course,
maintain a log of its activity. This is actually rather presumptuous but
nevertheless seems to have advised the construction of the name of the start
option.
I sort-of detect a concern about possibly losing VTAM messages here -
without being able to put my finger on it - as well as redirecting them. You
might like to be clearer about what exactly you want.
If you want something a little more like the function NetView supplies for
VTAM commands, solicited messages and unsolicited messages but without the
accretions - and cost - of today's NetView, I would *like* to propose NOSP,
Network Operations Support Program.
The following is taken from the IBM Systems Journal, Volume 18, Number 4,
1979.[1] The article is entitled "An integrated approach to centralized
communications network management" and the section is "Network operation -
an historical look". The author is R.A. Weingarten then located in the IBM
labs at Kingston, the then home of VTAM and some related products.
<quote>
During 1974, a new access method called the Virtual Telecommunications
Access Method (VTAM)" was introduced by IBM. This access method provided SNA
support that included communications network management capabilities defined
in the System Services Control Point. VTAM had its own operator control
functions that allowed commands to be issued and received via the system
operator console. The sharing of the system operator console
for VTAM and operating system commands and messages could create operational
problems in systems with a large number of attached terminals. To alleviate
this problem and separate network operations from systems operation, an
interface called the programmed operator interface was made available in
VTAM in 1975.
The programmed operator interface allows an application program to issue
VTAM operator control commands and receive VTAM operator control responses
and all unsolicited operator
control notification messages. The first IBM program product that utilized
this new interface was the Network Operations Support Program (NOSP)
introduced with the announcement of the Advanced Communications Function for
multisystem networking of VTAM in 1976. NOSP allowed a designated operator
to issue and receive operator messages, both solicited and unsolicited, from
a VTAM system. In a multisystem network environment, an NOSP could
communicate with other NOSPs to control the network from either a single
central terminal or multiple distributed terminals. This function was
similar to the function provided by the Telecommunications Control System of
TCAM, with the exception that NOSP was developed for use in the SNA
networking environment. NOSP was also limited in that it could execute in a
VTAM-only network.
To satisfy the requirement for centralized operator Control of multisystem
networks with the coexistence of TCAM and VTAM in an SNA environment, NCCF
was announced in November 1978. It was an outgrowth of NOSP with extensions
for operator control for the TCAM environment and communications network
management functions for both TCAM and VTAM.
</quote>
Incidentally, I had no idea that NCCF was created to replace NOSP solely in
order to include support for TCAM! I first started work with NCCF using
release 2 which I guess must have been the release that introduced Clists.
Anyhow, I expect you can't get NOSP any more.
And, in case, you didn't know already, today's NetView is a direct
descendant from NOSP - and I've witnessed most of the barnacles attaching
themselves to the product as it has been weighed down - sorry - grown!
Apparently customers liked everything to be thrown together in the menu
rather than offered a la carte ...
... and all the skill and ingenuity I invested in being able to explain how
to integrate add-on products like NPDA, NLDM etc. into the NCCF environment
was dissipated by this humongous "NetView"!
As I said, it's not quite clear what you want but, if you have any assembler
skills, you may want to check over the VTAM API which supports these VTAM
commands and messages. It is quite simple. I was told - I think - that,
despite the veneer of supposed planning that the article espouses, NOSP grew
from a program written by a VTAM developer in order simply to exercise this
API.
As I said, the API is quite simple and, in the days of pre-program product
VTAM, had a little manual all to itself. Now that manual is carried in
Appendix L of the Communications Server SNA Programming manual together with
the description of the SENDCMD and RCVCMD macros in the sequence of all the
macros.
Note that, right at the end, there is a mention of MODIFY
net,QUERY,ID=ncp-name. You can ignore this. It relates to the interface used
by the NTune program, specifically the NTuneNCP part which involves changing
NCP control blocks "on the fly".
-
Regarding "Ferret", I had at look at the web page. It's all about trying to
make Enterprise Extender easy for folk and it may well be excellent at
achieving that goal. However, again, you'd be using a product that only
incidentally - I take Leslie's word for this - gives you what you want. The
implication will be that you are paying for the beer when you really only
want the froth.
Incidentally, I had to laugh. There is a web page box which implies life was
so much better with subarea SNA where you could plan your routes rather than
having APPN work out routes for you - there's no pleasing some people!!!
On the final page of about 4 or 5, I did find a mention of "console
messages" - without elaboration - alongside EMAIL - whatever that's got to
do with it!
-
I guess I should point out that NCP doesn't get involved with providing
messages, solicited or unsolicited. Well, some people call "path information
units" messages rather loosely but that's not the sort of message that
conveys any useful information to humans. Any information NCP has which
might be useful, it sends on the SSCP to PU type 4 (NCP) session[2] and VTAM
will create readable information from it as necessary. Sometimes it's
possible to tie a VTAM "IST" message directly to a request unit received
from NCP on the SSCP to PU type 4 session. For example, IST260I, the "lost
control point" message, is a direct result of having received a request unit
with the X'410287' "network services", LCP (Lost Control Point) header from
NCP.
Chris Mason
[1] http://www.research.ibm.com/journal/sj/184/ibmsj1804C.pdf
[2] And sometimes, it has to be admitted, on a subarea PU to subarea PU flow
as for, for example, NC-ER-OP and NC-ER-INOP traffic.
----- Original Message -----
From: "Joe Peresich" <[EMAIL PROTECTED]>
Newsgroups: bit.listserv.ibm-main
To: <[email protected]>
Sent: Friday, June 22, 2007 7:42 PM
Subject: MSYS
I've seen some discussions of MSYS on the list, but is anyone aware if
MSYS can be used to replace the network logging function of NetView?
We're running z/os1.4 at present.
We'd like to discontinue NetView but would like to have the CS/VTAM/NCP
PPO logging function that it provides and not have to rely on system
console log for unsolicited messages, and vtam operator command
responses, etc., if possible.
Can MSYS do this, or is anyone aware of another product that would
provide this function?
Thanks & regards,
Joe
----------------------------------------------------------------------
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
