Page 1 of 2

Tracking errors from z/os's syslog

PostPosted: Tue Apr 15, 2014 12:46 am
by musecz
Hello everyone,

I need to reference the errors related to jobs present in the syslog.

Is it preferable to use messages from the ordonnancer e.g EQQE036I (TWS) or those from MVS e.g IEF451I, IEF452I etc ...

Thank you in Advance for your replies,

Regards

Re: Tracking errors from z/os's syslog

PostPosted: Tue Apr 15, 2014 2:50 am
by steve-myers
Provided the errors are directed to SYSLOG, yes. Most are not. A couple of years ago I wrote 2000+ lines to extract some errors from SYSLOG, but I rarely run the program any more.

Re: Tracking errors from z/os's syslog

PostPosted: Tue Apr 15, 2014 1:41 pm
by musecz
Thank you for your reply :)

According to the companies I worked with, they used TWS and CA and there were always a specific message for jobs felt in Error.

So in fact it depends of the company's policies ?

Regards

Re: Tracking errors from z/os's syslog

PostPosted: Tue Apr 15, 2014 5:16 pm
by steve-myers
I do not have access to a system using TWS, so I have no idea what messages are sent to SYSLOG. My analysis was for RACF violations; the program primarily looked for ICH408I messages.

Looking up the IEF451I and IEF452I message codes, I see they require the MN JOBAMES,T command be in effect, which is not always true; mn jobnames is not used for the system I analyze.

Analyzing SYSLOG can be expensive in CPU, but this can be mitigated by careful design.

Re: Tracking errors from z/os's syslog

PostPosted: Wed Apr 16, 2014 1:28 pm
by musecz
Thank you Steve.

I've a last question for you :)

Do you know if it exists a Syslog Protocol in Z/OS as existing in Unix ? ( I would like to send the syslog to a distant server )

Cordially

Re: Tracking errors from z/os's syslog

PostPosted: Wed Apr 16, 2014 7:26 pm
by steve-myers
I can't help you as I know essentially nothing about *nix at that level of detail. The z/OS SYSLOG is a text data set kept within JESx. When the data set is released from recording it is essentially an ordinary SYSOUT data set that can be sent to any "server" known to JESx within the network. Using a product like SDSF or similar product, or by using the XWTR interface, SYSLOG data can be copied to an ordinary sequential data set.

N 4000000 ZZZZ 14106 00:00:00.00 STC18980 00000090 +SHH001I IT IS WEDNESDAY, APRIL 16, 2014 (14.106) 0:00:00

The "SHH001I IT IS WEDNESDAY, APRIL 16, 2014 (14.106) 0:00:00" part of the line is the original SYSLOG message. The remainder of the line was added by the SYSLOG recording process.

Re: Tracking errors from z/os's syslog

PostPosted: Wed Apr 16, 2014 8:18 pm
by musecz
Thank you for your reply

I'm sorry my question wasn't enough clear :

I was wondering if it was possible to send the syslog in real time to a distant server ?

Re: Tracking errors from z/os's syslog

PostPosted: Wed Apr 16, 2014 11:42 pm
by dick scherrer
Hello,

If you are permitted to read the syslog, you can copy it and send the copy wherever you want . . .

Possibly i misunderstand.

Expect this to be rather large . . .

Re: Tracking errors from z/os's syslog

PostPosted: Thu Apr 17, 2014 12:06 am
by musecz
Thank you for the reply.

I agree but what i'm searching for in fact is to have access to it from an external server and in real time (as the syslog protocol from *nix).

Regards

Re: Tracking errors from z/os's syslog

PostPosted: Thu Apr 17, 2014 2:20 am
by steve-myers
No, not in "real time," whatever you mean by that. A "bot" on a remote server could be written to logon to TSO and access the live SYSLOG through SDSF .

Or, perhaps, a "bot" server on z/OS could be written to access the SYSLOG on behalf of a "client" on a remote system. The mechanics are relatively simple. There are several primary problems that might make a project of this nature unlikely.
  • Many JES2, and essentially all JES3 systems are configured so JESx operates in an environment where the SPOOL data areas are shared by several systems, but each system has an independent SYSLOG.
  • Many systems are configured so SYSLOG data sets are switched several times during a day and the SYSLOG is offloaded for archival processing by products such as CA-SMR, though that particular product is not that widely used and its vendor does not appear to be actively marketing it. Combining this proposed server with something like a CA-SMR might present some serious difficulties.
  • The amount of data is fairly large; I would expect 100 megabytes / day is not that uncommon.
  • SYSLOG data is rather unstructured.
  • Rather than use the JESx SYSLOG, intercept it using the SSI function JESx uses and save it there. Doing it this way keeps the "server" "bot" and CA-SMR type products from stepping on each other's toes.