Oppolzer - Informatik / Blog

Thank you. I'm no IMS wizard, and other people at our site are concerned with
these topics and do a very good job on controlling IMS and setting up the error
handling. When a program abends, diagnostics including registers, save areas,
all working storage areas and so on are sent to an archive system, the abending
module is determined, the organization responsible for the module gets an email
which points to the diagnostic information and the region is restarted.

My point was that Robin seems to ignore all the necessities of such automated
recovery efforts, to get such an operation running with limited resources
regarding systems programming people (less than 5). This is a very mature
system, and management does not spend much money and resources in this area.
Anyway, we will have some more ten years to survive with this system, because
the new system meant to replace it does not meet its development schedules
(management under-estimated the size of the task).

Kind regards

Bernd



D.L. schrieb:
> On 29 March 2010 08:02, Bernd Oppolzer <bernd.oppolzer@t-online.de> wrote:
>
>> But I'm talking of an IMS production environment, where there are
>> 3000 concurrent users, and in case of an error throwing out an error
>> message and some variables to SYSPRINT (which region, who should
>> look at it?) simply doesn't help.
>>
>
> In IMS if you take an abend then IMS will help you by sending a DFS554
> and DFS555 message to the IMS master terminal.
>
> Applications can send messages to the master terminal (or log them on
> the secondary master) by having an I/O PCB with either of those
> terminals as a fixed destination (or using an alternative I/O PCB and
> a CHNG/ISRT call to send the message).
>
> This is more a subject for IMS-L (LISTSERV@imslistserv.bmc.com (to
> subscribe) and IMS-L@imslistserv.bmc.com (to post)).
>
> IMS doesn't stop accepting messages from your 3000 concurrent users
> when a transaction abends. Unlike CICS, It simply stops the program
> and transaction and starts adding unprocessed messages to the queue.
> Handling errors and deciding when to /STArt an abended program (and
> tran) is an interesting subject for IMS automation.
>