Le 08/07/2020 à 00:55, Don Brown via MIDRANGE-L a écrit :
Thanks Marc,
I understand your concept but where is it being used ?
In my company, we use it for more than 20 years now. I am pretty sure
that the main program, or at least, its structure, was not changed this
century. A lot of tries did happen to replace it by some graphical tools
(provided mainly by Tivoli and similar software). But, as it was
perfect for its function, costs to migrate were too high. And on another
hand, the team I work with does love to remain isolated around dedicated
IBM i environments only. We are a small entity versus those entities
dedicated to Linux/Unix/Windows environments. And as you probably know,
they do not understand at all how IBM i works, at least in my
organization :-)
We have a proverb in French which says more or less "want to live happy?
live hidden!" :-)
What I mean - is this going to a wall board or something that then
highlights the error/issue rather than to a single PC 5250 session for a
single user ?
Exactly like a wall board. I am no longer in the implementation details,
but there are several monitoring centers around the world. They install
big displays dedicated to show the list of alerts grouped by systems or
groups of systems. Those devices use an automatic refresh of alerts,
based on a program waiting on data queues populated by jobs receiving
the alerts. In term of user interaction, the program does only handle
function keys such as F3 to exit. There is no entry field, as the
selections are done by the receiving jobs. The display shows alerts
sorted by their status (new in red first, then acknowledged in yellow,
then handled in blue). Closed alerts (in green) can be displayed as well
based on a function key but this is not the purpose here.
If a single 5250 session then this is for the IT Manager to monitor ? or ?
This function is used by monitoring people. They have their own devices,
where they manage the alerts. They are assigned to a specific wall board
(to use your words, which are close to the reality). They acknowledge,
handle, close the alerts according to documentation. For every alert (or
group of alerts in case of storm), they have to open an incident ticket
and document it for an assignee group which will close the ticket. The
allocation of systems or groups of systems helps to balance the workload
of monitoring people. Automation can be setup on the source system to
reduce alerts flow as well.
Of course, this environment is driven by the number of systems to
monitor. The one I know well is connected to several hundred of systems,
and they have 6 or 7 wall boards. Other locations manage several tens of
systems. And there is only one (two for redundancy) "hub" to receive the
alerts and display them per region/geography. And they all use this old
program with a display file attached to a data queue.
However, now, it is in the process to be withdrawn. We have two options:
the first one to keep the same kind of organization, but based on https
interfaces powered by php; the second is simply to bypass the manual
monitoring actions by an automatic connection with the ticketing systems.
Appreciate your reply.
Hope it is clear :-)
Cheers
Bye
Don
Marc
[cut]
midrange.com
