On 05/18/2016 03:36 PM, Tito Garrido wrote:
> I have a bunch of console logs from VMLOGS that I would like to read from
> Linux. I have used cmsfs-fuse -a to mount it on /mnt but there are a lot of
> strange chars in the file:
Since you mentioned logs, I was reminded that "log processing" doesn't
always necessarily mean file-resident traffic. Two things which
facilitate logging and related activities for Linux on z/VM: AF_IUCV and
SYSLOG. When you use these guys you don't need to worry about CMS Packed
format or other such special handling.
*AF_IUCV*
CMS and Linux both talk AF_IUCV sockets. It's like AF_INET but uses VM
IUCV instead of TCP/IP.
You can write a "socket program" in either environment using AF_IUCV
along with the usual client/server methodology. Many Unix/Linux people
know this stuff. There are ample examples. (Even a nifty one from Sir
Alan Altmark himself.)
Better still (on the CMS side) you can write a simple IUCV "client" or
"server" which can interact flawlessly with a Linux counterpart. (The
latter using AF_IUCV.) The point is that you don't have to right a C
program for the CMS side. I'm fond of C, but there are plenty of cases
where good ole assembler is better.
Either way, feeding traffic directly to Linux is one thing IUCV is good
for. And it's secure.
Oh ... and there's also REXX/IUCV. It's been several months since I
worked with it so I don't recall how well it plays with AF_IUCV
partners. (Maybe someone could fix it to do better.)
IUCV is good for way more than just logging. _Think full blown
client/server. Think plain text protocols._ (Since IUCV is secure, you
don't need messy extra layers like TLS/SSL.)
*SYSLOG*
There have been at least six implementations of SYSLOG for VM CP/CMS
that I know of. The protocol is really really easy. With Pipelines, it's
easier still. No reason one can't have a master console listener
collecting virtual machine traffic and feeding SYSLOG. Think of perhaps
even CP OPERATOR running Pipelines and slurping up all that SCIF
traffic, logging some locally, sending some remotely. All safely under
control of policy set by your VM admins. (You could probably wire in a
SYSLOG sender to PROP.)
SYSLOG protocol is plaintext, originally carried via UDP. The value of
UDP is that SYSLOG would then be self-throttling should your network get
swamped. (It happens.) These days people use TCP and even SSL/TLS. A
SYSLOG UDP packet looks roughly like ...
<token>date-n-time process[pid]: message
... where the "token" is a decimal integer combination of the
"facility" and "priority". _Priorities_ nicely map to CMS message
severity codes, if one chooses to do that. There are a dozen or more
standard _facilities_ and more can be added. The "process" could be a VM
ID. Otherwise it is typically the program name (for which the PID might
be meaningful). PID is optional. The "message" is free-form, though
there are structured meanings for SYSLOG messages these days.
https://en.wikipedia.org/wiki/Syslog
The beauty of SYSLOG is that it can fan-in or fan-out any way you need.
Your VM team doesn't have to bow down to some Unix nerd to get the
SYSLOG traffic. Your Linux guys don't have to kiss-up to the mainframe
masters to get the SYSLOG traffic. Everyone gets an equal share!
Use the Pipelines 'UDP 514' stage as input for reading SYSLOG traffic.
Take the first 16 bytes as network info. (You'll need to convert.) The
remainder is the SYSLOG record (translate from ASCII).
Use the Pipelines 'UDP 514' stage as output for sending SYSLOG traffic.
Compose the network info (first 16 butes) indicating where you want the
packet to go. Tack on the (translated from EBCDIC to ASCII) body of the
SYSLOG record and off she goes.
-- R; <><
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
