Talk to us

Product tour

Meridian, on a lab estate.

Three Meridian screens with example data from a lab estate with four LPARs, just after 03:49 on a Friday. Answer a WTOR, confirm a restart and open a batch, the way an operator would.

Example data. Nothing here is a real system.

The night so far Lab estate · Friday 9 October

  1. 03:12GL close monthly on PRD2 turns to SLA breach incoming.On the Batch and SLA screen
  2. 03:41SETL030 abends S0C7 in Daily settlement. Meridian proposes a restart.On the Operations screen
  3. 03:47WTOR 08 on PRD1 asks for a device name. Meridian proposes 0A81.On the Operations screen
  4. 03:49You sign in as the operator on shift C.On the Dashboard

The lab estate in Meridian, at 03:49 on Friday 9 October

On the overview page

Signed in as an operator
Shift C · 03:49 local

Dashboard Client Lab estate

Your alertsGL close monthly on PRD2: SLA breach incoming, ends about 07:20 of 06:30· rule “Month-end batches” · 03:12 ·Open GL close monthly

Dashboard

Live 3 · silent 1 · stale 0

  • PRD1

    Production, core bankingLive

    1 WTOR waiting 2 min1 abend today0 alerts

    Daily settlementOn time, but tightends about 05:48 of 06:00

    CICSPRD1 down, as plannedIMS PRD1Db2 DBP1Adabas 11

    Spool 41%Initiators 8 of 12 active

  • PRD2

    Production, cards and GLLive

    0 WTORs0 abends today1 alert

    Card statementsSlightly delayed, within the approved timeends about 05:41 of 05:30, approved to 05:45

    GL close monthlySLA breach incomingends about 07:20 of 06:30

    CICSPRD2Db2 DBP2CICSBAT2 down, as planned

    Spool 37%Initiators 10 of 10 active

  • TST1

    TestSilent 3 min

    0 WTORs0 abends todaylast line 3 min ago

    Payroll weeklyOn timeends about 04:10 of 07:00

    CICSTST1Db2 DBT1

    Spool 62%Initiators 3 of 6 active

  • DEV1

    DevelopmentLive

    0 WTORs0 abends today0 alerts

    No batch with an SLA runs here tonight.

    CICSDEV1Db2 DBD1

    Spool 18%Initiators 2 of 4 active

Today 9 October

Needs a person now
Follow-ups
  • TST1 silent: last console line 3 min ago

    The test LPAR is quiet, not down. This clears by itself at the next console message.

  • Card statements on PRD2 is running 11 min late, within the approved time

    Told the operations channel at 02:58 · nothing to do

Operations

LiveConsole of PRD1 · newest at the bottom · noise folded

03:47:10*08 IEF238DPAYR020 - REPLY DEVICE NAME OR 'CANCEL'.
Reply 080A81 Proposed because the last 12 runs of PAYR020 replied 0A81 and all ended OK.
03:40:52$HASP373SETL030 STARTED - INIT 7 - CLASS A - SYS PRD1
03:40:52IEF403ISETL030 - STARTED - TIME=03.40.52
11 lines of IEF237I and IEC130I folded
03:41:34IEA995ISYMPTOM DUMP OUTPUT SYSTEM COMPLETION CODE=0C7 REASON CODE=00000000
03:41:35IEF450ISETL030 STEP1 - ABEND=S0C7 U0000 REASON=00000000 TIME=03.41.35
03:41:35$HASP395SETL030 ENDED - ABEND=S0C7
03:42:01Meridian: Daily settlement is now On time, but tight. Restart card raised.
03:44:02IEF403IRPT110 - STARTED - TIME=03.44.02
03:46:40IEF404IRPT110 - ENDED - TIME=03.46.40
03:46:58$HASP373PAYR020 STARTED - INIT 4 - CLASS A - SYS PRD1
03:46:58IEF403IPAYR020 - STARTED - TIME=03.46.58
Proposed action · Daily settlement

Restart SETL030 from STEP1

Saw
IEF450I SETL030 STEP1 ABEND=S0C7 at 03:41
Why
The same abend three times this quarter. Each time the input tape was remounted and the job was restarted from STEP1. All three ended OK.
Scheduler
CA 7 holds SETL030 in the request queue, status A-S0C7. Nothing else is waiting on it yet.
Batch
On time, but tight If restarted by 03:55, Daily settlement ends about 05:48, 12 min inside 06:00.
Will send
RESTART,JOB=SETL030,STPSTRT=STEP1,REASON=S0C7-STEP1

Batch and SLA

Daily settlement · PRD1 · Daily · from SETL010 to SETL090

Daily settlement: On time, but tight, fairly sure

SETL030 abended at 03:41 and is not restarted yet. Restarted by 03:55, the chain ends 12 minutes inside the deadline; every later job takes its usual time for a Friday.

Deadline
06:00
Approved until
06:00
Expected end
05:48
The job that decides it
SETL030
Conditions what must be true for this batch
  • Met: Adabas 11 upup since 21:40
  • Met: CICSPRD1 down for batchdown since 23:58, as planned
  • Met: At least 6 initiators8 active
Jobs in chain order, times for a Friday
#JobStateStartedEndedUsually endsExpected to end
1SETL010done00:0500:3100:3000:31
2SETL020done00:3101:4801:4501:48
3SETL030 decides the endfailed S0C703:40not yet03:5504:05 after restart
4SETL040waitingnot yetnot yet04:4004:50
5SETL050waitingnot yetnot yet05:0505:15
6SETL060waitingnot yetnot yet05:2005:30
7SETL080waitingnot yetnot yet05:3005:40
8SETL090waitingnot yetnot yet05:3805:48
If it restarts what the end would be

Ends about 05:48, 12 min inside the deadline.

Tonight what happened, newest last
  1. 00:00Opened for Friday 9 October (daily). Deadline 06:00.
  2. 00:05SETL010 started. Words: On time, sure.
  3. 01:48SETL020 ended, 3 min later than usual.
  4. 03:41SETL030 abended S0C7 in STEP1. Words: On time, but tight, fairly sure.
  5. 03:42Restart card raised on the Operations screen. Operations channel told.
  6. 03:49Now. Waiting for the restart.
If it breaches the steps you wrote, tick as you go

Card statements · PRD2 · Daily · from CRDS010 to CRDS090

Card statements: Slightly delayed, within the approved time, sure

CRDS040 ran 14 minutes longer than usual while CRDS050 waited for it. The end falls after the deadline but inside the approved time, so the batch counts as on time with a note.

Deadline
05:30
Approved until
05:45
Expected end
05:41
The job that decides it
CRDS070
Conditions what must be true for this batch
  • Met: Db2 DBP2 upup since 20:10
  • Met: CICSBAT2 down for batchdown since 23:30, as planned
Jobs in chain order, times for a Friday
#JobStateStartedEndedUsually endsExpected to end
1CRDS010done00:1000:2500:2400:25
2CRDS020done00:2501:0201:0001:02
3CRDS040done01:0202:5102:3702:51
4CRDS050done02:5103:3003:1603:30
5CRDS070 decides the endrunning03:30not yet04:5805:12
6CRDS090waitingnot yetnot yet05:2705:41
Tonight what happened, newest last
  1. 00:00Opened for Friday 9 October (daily). Deadline 05:30, approved to 05:45.
  2. 02:51CRDS040 ended 14 min later than usual. Words: Slightly delayed, within the approved time, sure.
  3. 02:58Operations channel told.
  4. 03:49Now.
If it breaches the steps you wrote, tick as you go

Payroll weekly · TST1 · Weekly, Friday · from PAYR010 to PAYR060

Payroll weekly: On time, sure

Every job so far ended at its usual time, and PAYR020 is on its usual pace. WTOR 08 on PRD1 comes from the production copy of PAYR020, not from this test run.

Deadline
07:00
Approved until
07:00
Expected end
04:10
The job that decides it
PAYR020
Conditions what must be true for this batch
  • Met: Db2 DBT1 upup since 19:02
Jobs in chain order, times for a Friday
#JobStateStartedEndedUsually endsExpected to end
1PAYR010done01:0001:2001:2101:20
2PAYR020 decides the endrunning01:20not yet03:5503:55
3PAYR030waitingnot yetnot yet04:0204:02
4PAYR060waitingnot yetnot yet04:1004:10
Tonight what happened, newest last
  1. 00:00Opened for Friday 9 October (weekly). Deadline 07:00.
  2. 01:00PAYR010 started. Words: On time, sure.
  3. 03:49Now.
If it breaches the steps you wrote, tick as you go

GL close monthly · PRD2 · Every 1 month, seventh working day · from GLCL010 to GLCL120

GL close monthly: SLA breach incoming, fairly sure

GLCL040 has waited since 02:45 for the Db2 REORG on DBP2 to finish; the utility usually ends by 03:00 and is still running. Even at its usual pace from here the chain ends 35 minutes after the approved time.

Deadline
06:30
Approved until
06:45
Expected end
07:20
The job that decides it
GLCL040
Conditions what must be true for this batch
  • Met: Db2 DBP2 upup since 20:10
  • Not met: No Db2 utility on GL tablesREORG GLTS01 running since 02:05
  • Met: At least 8 initiators10 active
Jobs in chain order, times for a Friday
#JobStateStartedEndedUsually endsExpected to end
1GLCL010done00:3001:1001:0501:10
2GLCL020done01:1002:2002:1502:20
3GLCL040 decides the endwaiting on conditionnot yetnot yet03:4004:35
4GLCL060waitingnot yetnot yet04:5005:45
5GLCL080waitingnot yetnot yet05:4006:35
6GLCL120waitingnot yetnot yet06:2507:20
If the utility ends what the end would be

Ends about 07:20, 35 min past the approved 06:45.

Tonight what happened, newest last
  1. 00:00Opened for October (every 1 month, seventh working day). Deadline 06:30, approved to 06:45.
  2. 02:20GLCL020 ended. Words: On time, sure.
  3. 02:45GLCL040 held by its condition: a Db2 utility is running on GL tables. Words: On time, but tight.
  4. 03:12Still waiting. Words: SLA breach incoming, fairly sure. Operations channel and your rule Month-end batches told.
  5. 03:20The shift lead ticked step 1: told of the breach.
  6. 03:31The shift lead ticked step 2: ticket raised to the batch owner.
  7. 03:49Now.
If it breaches the steps you wrote, tick as you go
  • the shift lead, 03:20
  • the shift lead, 03:31

Example data from a lab estate at 03:49 on Friday 9 October: one client, four LPARs. Nothing here is a real system.

Meridian overview

Questions

Questions about the tour

Anything else, write to hello@hexab.in.

Is the tour a real estate?

No. It is an example estate with four LPARs (PRD1, PRD2, TST1 and DEV1) and example batches. Nothing on the screen comes from a customer.

Does Meridian act on its own?

It shows the action as a card and an operator confirms it. Where a team has agreed that a routine situation can go out without a person, Meridian can handle that one situation, and every action is recorded with its evidence.

Where do the SLA words come from?

Each batch says one of four things: On time; On time, but tight; Slightly delayed, within the approved time; or SLA breach incoming. The job that decides it is shown beside the words, so the operator can check it.

How do I see it on my own estate?

With a free 90-day proof of concept on one LPAR, installed with your team inside your network. Use the Book a demo form or read how pricing works.

See it on your own estate.

A ninety-day proof of concept on one LPAR, free, with our engineers on the call. After ninety days you decide on your own results.