Titolo su una riga

Il Piano di Qualità BNL 2014
Il contributo delle competenze RES
RES USER MEETING (2/2)
BNL DIT
Modena, 9 ottobre 2014
PDQ TNC
Res User Meeting 2014
con la partecipazione di
Scriviamo insieme
il futuro
Roberto Fasciani
Research for Enterprise Systems
Project Coordinator
PDQ TNC Cantiere A2 : Analisi del Batch
|
19/11/2014
|
2
PDQ TNC
A1
Ambito di
intervento RES
nel quadro del
progetto PDQ
TNC BNL
Piano generale
Ridisegno batch
per le Sigle Servizio
«MUST»
A2
Analisi e ottimizzazione trasversale
Spostamento batch
Reingegnerizzazione batch
Procedure Batch
Schedulazione
Ottimizzazione
Schedulazione
Parallelizzazione processi batch
Semplificazione dei legami
Ottimizzazione scarichi multipli
Dismissioni parziali o totali
Chiusure periodiche
Svecchiamento dati
Partizionamento DB
Ottimizzazione
Gestione Dati
Partizionamento DB
Ottimizzazione programmi
Flash Copy e Buffering/BLSR
Revisione uso del VTS
Analisi specifiche su
ulteriori azioni di :
Ottimizzazione,
Dismissione,
Spostamento
|
19/11/2014
|
3
PDQ TNC
RES Suite
L’esperienza RES orientata alla revisione ed ottimizzazione dei
servizi batch.
RES da ormai 15 anni collabora con BNL fornendo consulenza e tecnologia
specializzata.
In particolare la cartografia del sistema informativo è una fonte costante di
informazioni che la banca utilizza quotidianamente.
BNL si è pertanto rivolta a RES al fine di identificare una strategia attuativa che
potesse supportare il progetto PDQ TNC 2014 mettendo in campo tutte le
esperienze e tecnologie di cui RES dispone.
E’ nata così una sinergia tra le diverse componenti di RES Suite e l’esperienza già
maturata in progetti finalizzati all’ottimizzazione dei servizi batch.
|
19/11/2014
|
4
PDQ TNC
RES Suite
L’esperienza RES orientata alla revisione ed ottimizzazione dei
servizi batch
Alla componente di cartografia (DOCET) sono state affiancate quelle di
Reengineering e di CPF «Critical Path Finder».
E’ stato quindi impostato un «Servizio a Progetto» che ha fatto seguito ad una
prima fase di analisi, realizzata nel novembre 2013, che ha permesso di
sperimentare con successo la metodologia d’approccio suggerita da RES.
Lo studio e l’attivazione dei tool applicati su sigle applicative “pilota” ha consentito
di determinare un “modus operandi” in linea con le aspettative di BNL.
|
19/11/2014
|
5
PDQ TNC
CANTIERE A2: Piano degli interventi
2014
Apr
2015
Mag
Giu
Lug
Ago
Set
Lotto 1
FLASH COPY
Ott
………….
Nov
Dic
Gen
Altri lotti da definire
Decisione di estensione intervento
BUFFERING
…………………….……..
primo insieme
…………………….………………….
completamento
Più Rilasci
BLSR
Uso VTS
Più Rilasci
………..
Rilasci continui
…………………….……………………………….
Suggerimenti di ottimizzazione
Lotto 1
STUDIO
OTTIMIZZAZIONE
SCHEDULAZIONE
completamento
Lotti 2,3
…………
….....
Lotti 4-7
Lotti 8-12
Tutti i lotti
……. Non pianificabili (indagini a campione) …………………………….
Lotto 1
AZIONI
post analisi
Lotto 1 (completamento)
Lotti 2, 3
Lotti 4-7
Lotti 8-12
Tutti i lotti
Dipendenti da studio batch
Data rilevazione
|
Rilascio PIANIF
Rilascio PARZ
Rilascio TOT
19/11/2014
|
6
PDQ TNC
CANTIERE A2: BATCH
OTTIMIZZAZIONE SCHEDULAZIONE : Pianificazione a lotti
LOTTO 1
JJ
NE
NJ
NK
LOTTO 2
CE
CO
NP
PG
VL
LOTTO 3
DX
PZ
LOTTO 4
A3
B1
G2
JN
MI
NB
NS
Media Sec Cpu
(20-03)
34856
3501
8386
14616
8354
24070
2837
6752
9457
2273
2751
6421
5102
1320
4834
367
334
936
296
1291
437
1172
n° Applic
1147
52
382
107
606
721
128
57
186
122
228
983
809
174
759
250
224
14
43
184
10
34
Il perimetro applicativo di indagine è stato definito sulla base di una lista
ordinata di sigle a maggiore consumo.
Tra queste è stata data priorità, per quanto possibile, alle sigle non in cantiere
A1 ed escludendo quelle delle società del gruppo ed alcune sigle con attività
di subentro fornitore.
Il lavoro è previsto sulla base di circa 20 lotti, ciascuno comprendente sigle
servizio per un totale di circa 1000 applicazioni ciascuno.
Al 15/9/2014 sono stati esaminati i primi sette lotti. Entro il 31/10/2014
saranno disponibili tutte le evidenze e suggerimenti di ottimizzazione per i lotti
fino al 14.
I risultati vengono condivisi con i responsabili applicativi e si richiede
un feedback in tempi rapidi per gran parte dei target di analisi.
|
19/11/2014
|
7
PDQ TNC
CANTIERE A2: BATCH
TIPOLOGIE DI EVIDENZE
Le tipologie di evidenze che vengono fornite della revisione BATCH, per ciascuna sigla
servizio nell’ambito di ciascun lotto, sono le seguenti:
TG1 - Re-ingegnerizzazione delle Applicazioni TWS con riduzioni in termini di elapsed
(Easy Reengineering)
TG2 - Parallelizzazione dei processi a livello JOB
TG3 - Semplificazione dei legami attraverso l’eliminazione delle ridondanze
TG4 - Eliminazione scarichi/copie multiple per lo stesso archivio DB2 o applicazione
multipla di utilities (SORT) per stesso File
TG5 – Analisi ed evidenza delle ADD dinamiche di applicazioni TWS presenti nei JCL
TG6 – Individuazione dei file batch allocati e non usati
CPF – Critical Path Finder per stabilire, a partire dai CUT OFF principali (tipicamente
EOSOKBA di inizio TP), possibilità di ottimizzazione dei percorsi critici nell’esecuzione delle
applicazioni con spostamento di batch non critici verso orari non di picco.
|
19/11/2014
|
8
PDQ TNC
CANTIERE A2: BATCH
PROCESSO DI LAVORO PER OGNI LOTTO/SIGLA SERVIZIO
Per tutti i target di analisi l’obiettivo è di stabilire gli interventi da effettuare e procedere alla
implementazione.
Verifica e
arbitraggio dai
responsabili
applicativi
Pianifica
zione
PI Presenta le proposte di
intervento/analisi ai gruppi
applicativi, per ciascuna
sigla
del
LOTTO
analizzato.
Ogni gruppo applicativo
(sigla servizio) verifica le
proposte ed effettua le
analisi necessarie. PI in
questa
fase
resta
a
disposizione per supporto
alle verifiche e dopo avere
ricevuto le note da parte SI
convalida il perimetro di
intervento operativo.
Si concorda tra PI
e
SI
la
pianificazione
degli
interventi,
che normalmente
possono
essere
fatti con flessibilità
nel rispetto dei
processi
di
change.
In caso di necessità
SI effettua le richieste
di change.
Tutti gli interventi
sono svolti da PI nelle
modalità
e
tempi
concordati.
SI: Responsabili di
PATRIMONIO
SI: Responsabili di
PATRIMONIO
SI: Responsabili
di PATRIMONIO
SI: Responsabili di
PATRIMONIO
Presentazione
delle proposte
Attuazione
Misure
PI effettua i confronti
di misure pre e post
interventi,
con
metodologia
già
applicata per gli altri
ambiti del PDQ.
|
19/11/2014
|
9
PDQ TNC
CANTIERE A2: BATCH
TARGET 1
Il target 1 (ER – Easy Re-engineering) analizza tutte le applicazioni TWS per ogni Sigla Servizio.
ER effettua poi una simulazione di ristrutturazione in cui ottimizza i legami interni di ciascuna
Applicazione TWS basandosi sull’impiego delle risorse dei JOB (File / Tabelle DB2). L’obiettivo è di
favorire, ove possibile, l’utilizzo di parallelismi. Le applicazioni ottimizzate potranno essere introdotte
nel flusso di schedulazione se non in contrasto con l’obiettivo principale di riduzione dei consumi delle
fasce orarie in esame.
Applicazione
NEPULANA
NECOPXMK
NEAGGINDB
NEBAKYCO
NEBAKYCOFC
CP originale
3623
3121
3368
5075
5075
CP calcolato
da ER
2384
1917
2514
4322
4322
DELTA IN
SECOND
1239
1204
854
753
753
REAL EXECUTION
IN SECOND
1440
2260
0000
3407
0000
EXECUTION
NUMBER
01
28
00
28
00
Sono disponibili i seguenti file sequenziali in supporto al processo:
• J3BA.BJNEWTIE.§§ (indicazione dei legami aggiunti)
• J3BA.BJOLDTIE.§§ (indicazione dei legami eliminati)
• J3BA.OPCSYSIN.§§ (Batch loader TWS puntuale )
"§§" rappresenta la sigla servizio.
|
19/11/2014
|
10
PDQ TNC
CANTIERE A2: BATCH
TARGET 1
Applicazione attuale
Per facilitare la lettura
viene
messo
a
disposizione
lo
strumento
WIC,
utilizzabile con utenza
TSO. Questo mostra
la rappresentazione
grafica
dell’applicazione
attuale (es. a fianco)
e
della
nuova
applicazione
proposta
(pag
seguente), per una
rapida valutazione.
|
19/11/2014
|
11
PDQ TNC
CANTIERE A2: BATCH
TARGET 1
Nuova applicazione
proposta
La verifica della
proposta
di
ristrutturazione da
parte
di
chi
conosce
le
funzioni
applicative
può
essere
normalmente
molto rapida.
|
19/11/2014
|
12
PDQ TNC
CANTIERE A2: BATCH
TARGET 2
Il target 2 offre suggerimenti analoghi a quelli del target 1 ma a livello JOB.
Vengono analizzati i JOB contenenti più di uno step applicativo per verificare la possibilità di reingegnerizzazione anche tramite lo split in job differenti.
L’obiettivo è di ottenere una nuova Applicazione TWS a partire da un singolo JOB molto complesso
realizzando tutti i parallelismi possibili in funzione delle risorse utilizzate dagli step originali.
Le attuali modalità di implementazione di JOB e applicazioni sconsigliano di produrre job con
più passi applicativi. Tuttavia questa è una pratica che può essere riscontrata in applicazioni
realizzate diversi anni fa.
Per la quasi totalità delle sigle applicative si prevede che questo target di analisi non produca risultati.
In questo caso viene confermato implicitamente che i job sono al loro interno sufficientemente
performanti.
Step
ProgramNam Elapsed
Old Elapsed
New Elapsed
PGM
Applicazione Adfrom JobName Number e
Time(PGM) Time (APPL)
Time (APPL)
split
CEMCELAB
130610 ECE00522
26 BNLIM040
675
00:58:27
00:43:27
N
CEMCELAB
130610 ECE00522
32 BNLIM050
706
00:58:27
00:43:27
N
|
19/11/2014
|
13
PDQ TNC
CANTIERE A2: BATCH
TARGET 3
Sono evidenziati tutti i legami interni ridondanti per le applicazioni TWS analizzate. Non costituisce
una vera ottimizzazione in termini di consumi o di elapsed, ma contribuisce alla migliore gestibilità dei
piani.
Applicazione TWS Consuntivo
NEBA0000
Dettaglio del legame
061215-LEGAMI ELIMINATI(0001 ) 0043 /0042
REDUNDANCY BETWEEN OPNO 0105 AND OPNO 0045
NEDAIFED
130927-LEGAMI ELIMINATI(0001 ) 0021 /0020
REDUNDANCY BETWEEN OPNO 0030 AND OPNO 0020
NEQUIESCE
080508-LEGAMI ELIMINATI(0001 ) 0018 /0017
REDUNDANCY BETWEEN OPNO 0010 AND OPNO 0003
NEQUIESCEFC
130326-LEGAMI ELIMINATI(0001 ) 0016 /0015
REDUNDANCY BETWEEN OPNO 0010 AND OPNO 0003
Nella normalità dei casi questi interventi di semplificazione dei legami vengono effettuati da PI con sola
comunicazione informativa a SI.
|
19/11/2014
|
14
PDQ TNC
CANTIERE A2: BATCH
TARGET 4
Questo Target tende a individuare utilizzi ridondanti di estrazione dati da parte dei JOB. Sono
analizzati i soli programmi di sistema indicati come “Anchor Point” di ricerca: CDBPROV9 e
DSNTIAUL. Le ridondanze sono considerate tali solo se non esistono, tra i JOB sospetti, altri processi
che tra una lettura e l’altra operano delle modifiche sugli archivi estratti. Il risultato potrebbe
interessare anche JOB appartenenti ad una sigla applicativa estranea al lotto analizzato.
Il target 4 è composto di due report:
UNLOAD Multiple, che lista tutte le unload per singola tabella ed evidenzia quelle che sono
uguali o molto simili
SORT multipli, che lista tutti i SORT applicati a ciascun file prodotto dalla sigla servizio ed
evidenzia quelli uguali o molto simili
In entrambi i casi i report tengono conto del fatto che non esistano nel lasso temporale tra
applicazione di utility uguali o simili operazioni di aggiornamento tabelle o file sotto analisi.
Fa eccezione, in quanto è impossibile intercettarlo staticamente, il caso in cui una SS utilizzi chiamate
a moduli software dipendenti dai risultati di select su DB ( es, sigla JJ).
|
19/11/2014
|
15
PDQ TNC
CANTIERE A2: BATCH
TARGET 4: UNLOAD multiple
JOB-CHK APPLNAME
VLINSVEL
VLINSVEL
VLINSVEL
VLICFUONPR
VLQUIESCE
VLLAVPRE
VLLAVPRE
VLLAVPRE
VLLAVPRE
VLLAVPRE
VLPORTAB
VLPORTAB
CHECKJ-> VLPORTAB
CHECKJ-> VLPORTAB
VLMAVNOPRE
VLMAVNOPRE
JOBNAME NUM-STEP PGMMVS
EVLXP367
20 VLG60B
EVLXS123
20 DSNTIAUL
EVLXL120
10 CDBUTIL
EVLXIO03
10 CDBUTIL
EVLXQUI1
10
EVLXP121
10 VLL10B
EVLXS067
10 DSNTIAUL
EVLXL054
10 CDBUTIL
EVLXL054
10 CDBUTIL
EVLXS044
10 DSNTIAUL
EVLXP392
10 VLPR03B
EVLXP393
10 VLPR02B
EVLXS129
20 CDBUTIL
EVLXS130
20 CDBUTIL
EVLXP975
10 VLG104B
EVLXP973
10 VLG102B
PROCNAME TYPE I/O
DB2GO
O
I
O
I
DSNUPROC O
DB2GO
O
I
O
O
I
DB2GO
O
DB2GO
O
I
I
DB2GO
O
DB2GO
O
NOME TABELLA
LST UPDT
VLT_VLJ14T
05/07/2014
VLT_VLJ14T
05/07/2014
VLT_VLJ14T
05/07/2014
VLT_VLJ14T
05/07/2014
VLT_VLJ14T
05/07/2014
VLT_VLJ14T
05/07/2014
VLT_VLJ14T
05/07/2014
VLT_VLJ14T
05/07/2014
VLT_VLJ14T
05/07/2014
VLT_VLJ14T
05/07/2014
VLT_VLJ14T
05/07/2014
VLT_VLJ14T
05/07/2014
VLT_VLJ14T
05/07/2014
VLT_VLJ14T
05/07/2014
VLT_VLJ14T
05/07/2014
VLT_VLJ14T
05/07/2014
TS LAST START
2014-07-03-15.39.00.000000
2014-07-03-15.39.00.000000
2014-07-03-15.40.00.000000
2014-07-03-17.00.00.000000
2014-07-03-18.30.00.000000
2014-07-03-18.40.00.000000
2014-07-03-18.40.00.000000
2014-07-03-18.41.00.000000
2014-07-03-18.42.00.000000
2014-07-03-18.42.00.000000
2014-07-03-18.49.00.000000
2014-07-03-18.49.00.000000
2014-07-03-18.49.00.000000
2014-07-03-18.49.00.000000
2014-07-03-20.07.00.000000
2014-07-03-20.08.00.000000
TS LAST END
2014-07-03-15.39.00.000000
2014-07-03-15.39.00.000000
2014-07-03-15.40.00.000000
2014-07-03-17.02.00.000000
2014-07-03-18.31.00.000000
2014-07-03-18.40.00.000000
2014-07-03-18.40.00.000000
2014-07-03-18.41.00.000000
2014-07-03-18.42.00.000000
2014-07-03-18.42.00.000000
2014-07-03-18.49.00.000000
2014-07-03-18.49.00.000000
2014-07-03-18.49.00.000000
2014-07-03-18.50.00.000000
2014-07-03-20.07.00.000000
2014-07-03-20.08.00.000000
RUNCYCLE
GIORNO
GIORNO
GIORNO
GIORNO
GIORNO
GIORNO
GIORNO
GIORNO
GIORNO
GIORNO
GIORNO
GIORNO
GIORNO
GIORNO
GIORNO
GIORNO
La vista sintetica mostra l’applicazione delle UNLOAD su stesse tabelle con gli orari di applicazione,
mentre la vista di dettaglio fa vedere il contenuto delle select; nel caso mostrato sotto si tratta di
scarico identico.
TABLENAME
VLT_VLJ14T
JOBNAME STATEMENT
EVLXS129
SELECT * FROM
DB2A0.VLT_VLJ14T
EVLXS130
SELECT * FROM
DB2A0.VLT_VLJ14T
LASTELAP LASTCPU LASTIO
15,8
0,9
17899
12,3
0,9
15683
Ci sono due scarichi dalla stessa tabella e con stessa select a poca distanza di tempo l’uno dall’altro.
Sono giustificati ?
|
19/11/2014
|
16
PDQ TNC
CANTIERE A2: BATCH
TARGET 4: UNLOAD multiple
TABLENAME
NPT_DATE
JOBNAME STATEMENT
ENPXS084 SELECT * FROM DB2A0.NPT_FLANN
WHERE DT_ACQ_FLUSSO >= (SELECT (DT_CONT_OGGI -10 DAYS)
FROM DB2A0.NPT_DATE);
ENPXS040 SELECT * FROM DB2A0.T08CT006
WHERE COD_EMPRESA = '0001' AND
COD_TIP_EXPE = '00' AND
FEC_CONTABLE = (SELECT DT_CONT_OGGI FROM DB2A0.NPT_DATE) AND
COD_USU_ALTA NOT LIKE 'ENPXP19%' ;
ENPXS087 SELECT * FROM DB2A0.T08CT006_STOR
WHERE COD_EMPRESA = '0001'
AND COD_TIP_EXPE = '00'
AND (FEC_CONTABLE = (SELECT DT_CONT_IERI FROM DB2A0.NPT_DATE)
AND COD_CANALE = 'BAT'
AND COD_PROV_BATCH ^= '0655'
AND FEC_OPERACION = FEC_CONTABLE );
ENPXS108 SELECT * FROM DB2A0.T08CT006
WHERE COD_EMPRESA = '0001'
AND COD_TIP_EXPE = '00'
AND FEC_CONTABLE > (SELECT DT_CONT_IERI FROM DB2A0.NPT_DATE)
AND FEC_CONTABLE <= (SELECT DT_CONT_OGGI FROM DB2A0.NPT_DATE)
ENPXS047 SELECT * FROM DB2A0.NPT_SALDI
WHERE FEC_CONTABLE = (SELECT DT_CONT_IERI FROM DB2A0.NPT_DATE)
AND COD_EMPRESA = '0001'
LASTELAP LASTCPU LASTIO
83,1
1,6
32923
58,5
3,4
31333
60,8
4,8
21106
36,6
2,3
42769
12,6
0,7
6601
La rilevazione di unload duplicate è molto poco frequente nelle applicazioni e questo è positivo.
I report possono essere comunque ugualmente utili per altre indagini applicative, perché mostrano
nello stesso foglio tutte le operazioni di unload che vengono effettuate su ogni tabella.
|
19/11/2014
|
17
PDQ TNC
CANTIERE A2: BATCH
TARGET 4: UNLOAD multiple
Ci sono alcuni casi (es. JJQAQGS) in cui le chiamate di accesso dati non sono statiche, ma ad
esempio dipendenti dai risultati di query dinamiche su tabelle DB2, per effettuare azioni SQL diverse al
verificarsi di differenti condizioni.
Per facilitare in questi casi non
comuni la verifica di dettaglio
della effettiva inutilità di una
unload multipla, è utile il foglio
di TAB usage, che mostra tutti
i programmi che utilizzano
ogni tabella. Da questi si
possono trarre evidenze di
comportamenti dinamici per
verificarne la dinamica.
NOME TABELLA
T08CT003
T08CT005
PGMNAME
NPB37030
CTB0075
LQB2278
LQB8001
NKBBERS
NKBSCOL4
NKB06038
NKB11023
NKB11025
NKB11034
NKB11035
INSERT UPDATE DELETE ALTER PGMTYPE
Y
BATCH
Y
BATCH
Y
????
Y
????
Y
BATCH
Y
BATCH
Y
Y
BATCH
Y
BATCH
Y
BATCH
Y
BATCH
Y
BATCH
|
19/11/2014
|
18
PDQ TNC
CANTIERE A2: BATCH
TARGET 4: SORT multipli
JOB-CHK APPLNAME
NEBAGES1
CHECKJ-> J6ANAICEBERG
CHECKJ-> F1BATCHG
CHECKJ-> F1BATCHG
CHECKJ-> ILALIMANAG
CHECKJ-> B0SEGMENNEW
CHECKJ-> ZTALIGEMO
N7XEPC01
CHECKJ-> N7C6ANAG
JOBNAME NUM-STEP PGMMVS
ENEXP223
10 NEBAGES1
EJ600591
20 SORT
EF10002A
50 SORT
EF10002A
50 SORT
EIL01906
80 SORT
EB0XP041
230 SORT
EZT00640
50 SORT
EN700910
240 N7BAE012
EN700564
20 SORT
PROCNAMETYPE I/O
DSNAME
DB2GO O
NEBA.NEFGESOU.NEBAGES1
I
NEBA.NEFGESOU.NEBAGES1
I
NEBA.NEFGESOU.NEBAGES1
I
NEBA.NEFGESOU.NEBAGES1
I
NEBA.NEFGESOU.NEBAGES1
I
NEBA.NEFGESOU.NEBAGES1
I
NEBA.NEFGESOU.NEBAGES1
I
NEBA.NEFGESOU.NEBAGES1
I
NEBA.NEFGESOU.NEBAGES1
LST UPDT TS LAST START
TS LAST END
RUNCYCLE
18/06/2014 2014-06-17-20.53.00.000000
2014-06-17-20.54.00.000000
GIORNO
18/06/2014 2014-06-17-21.42.00.000000
2014-06-17-21.47.00.000000
GIORNO
18/06/2014 2014-06-17-21.43.00.000000
2014-06-17-21.43.00.000000
FASTCLL
18/06/2014 2014-06-17-21.43.00.000000
2014-06-17-21.43.00.000000
GIORNO
18/06/2014 2014-06-17-21.43.00.000000
2014-06-17-21.51.00.000000
GIORNO
18/06/2014 2014-06-17-22.11.00.000000
2014-06-17-22.56.00.000000
GIORNO
18/06/2014 2014-06-18-00.14.00.000000
2014-06-18-00.14.00.000000
GIORNO
18/06/2014 2014-06-18-04.15.00.000000
2014-06-18-04.19.00.000000
GIORNO
18/06/2014 2014-06-18-05.30.00.000000
2014-06-18-05.30.00.000000
GIORNO
La vista sintetica mostra l’applicazione dei SORT su stessi file della sigla, con gli orari di applicazione,
mentre la vista di dettaglio fa vedere il contenuto dei sort; normalmente SORT uguali sullo stesso file
vanno eseguiti una sola volta, ma anche SORT simili possono essere oggetto di indagine applicativa.
DSNAME
NEBA.NEFGESOU.NEBAGES1
JOBNAME STATEMENT
EJ600591
SORT FIELDS=(01,18,ZD,A)
END
EF10002A SORT FIELDS=(1,18,ZD,A)
EIL01906
SORT FIELDS=(1,18,CH,A)
END
EB0XP041 SORT FIELDS=(1,18,CH,A)
EZT00640 SORT FIELDS=(1,18,ZD,A)
END
EN700564 SORT FIELDS=(1,18,CH,A)
|
19/11/2014
|
19
PDQ TNC
CANTIERE A2: BATCH
TARGET 4: SORT multipli
DSNAME
NEBA.NEFGESOU.NEBAGES1
JOBNAME STATEMENT
EJ600591
SORT FIELDS=(01,18,ZD,A)
END
EF10002A SORT FIELDS=(1,18,ZD,A)
EIL01906
SORT FIELDS=(1,18,CH,A)
END
EB0XP041 SORT FIELDS=(1,18,CH,A)
EZT00640 SORT FIELDS=(1,18,ZD,A)
END
EN700564 SORT FIELDS=(1,18,CH,A)
La situazione di più sort uguali per stesso file viene rilevata con una certa frequenza anche perché
normalmente quando una sigla servizio sviluppa nuovi JCL si alimenta giustamente dall’owner dei dati,
ma potrebbe non verificare se altri hanno già effettuato i sort che le sono necessari.
Quando ci si trova in presenza di più SORT uguali effettuati da job diversi, la soluzione consiste nel
creare un passo di sort unico, il cui owner è la sigla servizio che produce il file.
Quindi gli altri job potranno avere in input il file già sortato, evitando di ripetere ciascuno il passo di sort.
Questo tipo di miglioramento può essere quindi facilmente verificato dai gruppi applicativi e viene
effettuato quindi tramite il solo cambio di passi di schedulazione.
|
19/11/2014
|
20
PDQ TNC
CANTIERE A2: BATCH
TARGET 5: ADD dinamiche TWS
Esecuzione del processo di censimento dei JOB (da DOCET) al fine di documentare eventuali utilizzi
di “ADD dinamiche” TWS. BNL fornisce l’indicazione dei programmi/procedure catalogate utilizzati per
le operazione di ADD dinamiche. L'obiettivo è di individuare tutti i JCL in ambito che attraverso
l'utilizzo di specifici programmi TWS quali EQQADD e EQQOCL prevedono azioni di COMPLETE e/o
ADD di applicazioni TWS.
E’ una attività volta prevalentemente ad un migliore monitoraggio da parte PI.
In prima istanza non sono previste azioni di modifica nell’ambito del PDQ TNC; in ogni caso saranno
evidenziate da SI situazioni per cui l’applicazione di add dinamiche non ha più ragione di essere e
quindi si può procedere alla eliminazione (ristrutturazione applicazione in modo statico).
Applname
AdFrom Jobname
Comando Applicazione coinvolta Runcycle
NKTXIDX5
111014 ENKCHEK1 COMPLETE NLSBLOCCO
GIORNO,TARGET
NEFORCERV
131125 ENEOCL02
TRIMESTR
COMPLETE &OADID
|
19/11/2014
|
21
PDQ TNC
CANTIERE A2: BATCH
TARGET 6: FILE allocati e non usati
Individuazione di eventuali file allocati all’interno dei JCL e non utilizzati dal processo di
schedulazione. Sono in ambito i file allocati attraverso programmi di sistema e Cobol unitamente alle
“Utility BNL” che il tool di cartografia (DOCET) riconosce.
Parte dei file individuati sono relativi a SCARTI ed ERRORI. E' normale che essi possano essere
acceduti manualmente e su specifica richiesta al verificarsi di eventi particolari.
E’ da notare che l’analisi di non utilizzo dei file viene comunque fatta tenendo conto anche di quanto
presente nel SMF (System Management Facility) per intercettare eventuali attività di utenze
individuali.
Applname
NEAGGANA
NEAGGANA
NEAGGANA
NEAGGANA
NEAGGNDG
NEAGGSOC
NEAGGUM
NEAGSOF1
NEAGSOF1FC
NEALPHA
NEBACIB
NEBACIB
AdFrom
Jobname
60427 ENEXP082
60427 ENEXP082
60427 ENEXP083
60427 ENEXP083
120413 ENEXP034
131014 ENEXP168
130917 ENEXP166
91022 ENE01010
130318 ENE01010
130605 ENEXP159
71109 ENEBACIB
71109 ENEBACIB
OpNum
WSID
40 CPUA
40 CPUA
50 CPUA
50 CPUA
25 CPUA
20 CPUA
10 CPUA
80 CPUA
80 CPUA
10 CPUA
10 CPUA
10 CPUA
StepNumDsname
2 NEBA.NEFIELAB.NEBA5040
2 NEBA.NEFISCAR.NEBA5040
2 NEBA.NEFIELAB.NEBA5050
2 NEBA.NEFISCAR.NEBA5050
4 NEBA.NEFIRMPM
2 NEBA.NESTORI.NERLNDG.UPDATE
2 NEBA.NEF02100.NEB02100
3 NEBA.NEFISCAR.NEBA5020.GDG
3 NEBA.NEFISCAR.NEBA5020.GDG
2 NEBA.ALPHA.ANOMALIE.OUTPUT
14 NEBA.NEFSCART.OUT
16 NEBA.NEFPECIB.OUT.SPAZIO.COPIA
GDG
Y
Y
Y
Y
DDname
NEFIELAB
NEFISCAR
NEFIELAB
NEFISCAR
NEFIRMPM
NESTORI
NEF02100
SORTOUT
SORTOUT
NEFAN01
NEFSCART
OUT
|
Pgmname
NEBA5040
NEBA5040
NEBA5050
NEBA5050
NESIS119
NESIS290
NEB02100
SORT
SORT
NEBAAL01
NEBACIB2
IDCAMS
19/11/2014
|
22
PDQ TNC
CANTIERE A2: BATCH
TARGET CPF: Critical Path Finder
L’analisi “Critical Path Finder” ha lo scopo di:
Calcolare il calcolo del cammino critico delle applicazioni (BOTTOM – UP) a partire dai JOB di CUT OFF, che
sono normalmente riferiti all’apertura TP ma possono anche consistere in altri vincoli temporali come ad
esempio per la trasmissione di flussi di pagamento
Selezionare tra tutte le applicazioni quelle che insistono prevalentemente sulla fascia oraria critica 20 – 24
Permettere la selezione dei JOB che hanno un consumo molto significativo tra quelli candidati allo
spostamento in diversa fascia oraria
L’obiettivo è quello di effettuare lo spostamento di applicazioni dalla fascia oraria di consumo critico ad altra
a minore rischio di stress CPU.
Per facilitare la determinazione degli spostamenti i report forniscono anche:
Evidenza di “fermi” di elaborazione tra la fine di un JOB di un’Applicazione TWS e l’inizio di un’altra
applicazione
l’elapsed tra il primo successore (se presente) e l’ultimo.
Queste informazioni sono utili a verificare che, sebbene non esistano vincoli di CUT-OFF per gli spostamenti, non si
rischi di eseguire le elaborazioni in sovrapposizione con gli orari TP.
|
19/11/2014
|
23
PDQ TNC
CANTIERE A2: BATCH
TARGET CPF: Critical Path Finder
Per lo svolgimento dell’attività si parte dal riconoscimento dei CUT OFF forniti da BNL (apertura TP e orari specifici di
alcuni JOB):
NOME JOB
EOSOKBA (aperture TP)
ENPXP128
ENPXP106
EA3HCF05
EEJEM001
EDJTX000
ECDTRSIA
ORARIO LIMITE
variabile
03.00
00.00
00.35
01.00
00.00
01.30
Il sistema permette di definire anche proposte di miglioramento dei parallelismi e quindi degli elepsed complessivi.
|
19/11/2014
|
24
PDQ TNC
CANTIERE A2: BATCH
TARGET CPF: Critical Path Finder
SCHEDA ANALISI
periodo analisi
GIORNI DI ANALISI
1
Sigla Applicative
NE
NET TARGET NESTATRAN
START DATE 20/05/2014
3
LOTTO
END DATE \
14141
Fascia oraria 20:00-24:00
NETIN
NETOU
93
4
97
95,88%
4,12%
100,00%
48
49
97
49,48%
50,52%
100,00%
14142
Fascia oraria 20:00-24:00
NETIN
88 95,65%
NETOU
4 4,35%
92 100,00%
NET in Critical Path
YCPF
46 50,00%
NCPF
46 50,00%
92 100,00%
24
25
49
50,52%
48,98%
51,02%
100,00%
Dettaglio NCPF
50,00%
Dettaglio NCPF
NETCF.
22 47,83% 23,91% NETCF.
22
NETOK.
24 52,17% 26,09% NETOK.
25
46 100,00% 50,00%
47
NET in Critical Path
YCPF
NCPF
Dettaglio NCPF
NETCF.
NETOK.
24,74%
25,77%
50,52%
14143
Fascia oraria 20:00-24:00
NETIN
88 95,65%
NETOU
4 4,35%
92 100,00%
NET in Critical Path
YCPF
45 48,91%
NCPF
47 51,09%
92 100,00%
51,09%
46,81%
53,19%
100,00%
<------ Nr. NET dentro Fascia Oraria Target
<------ Nr. NET fuori Fascia Oraria Target
<------ Nr. NET dentro cammino Critico
<------ Nr. NET Fuori Cammino Critico
23,91% <------ Net legate ai CUT OFF
27,17% <------ Net NON legate ai CUT OFF
51,09%
Le applicazioni identificate con NETOK sono quelle suscettibili di spostamento per sgravare la fascia critica di consumi
|
19/11/2014
|
25
PDQ TNC
CANTIERE A2: BATCH
TARGET CPF: Critical Path Finder
L’indicatore NETIN / NETOU identifica le applicazioni che sono dentro o fuori la fascia oraria critica
20.00 – 24.00.
Gli altri indicatori identificano i vincoli riferiti ai CUT OFF:
Per la sigla in esame, YCPF / NCPF specifica se le applicazioni sono o meno nel cammino critico della
net target (nell’esempio NESTATRAN)
Sull’intero piano OPC, le applicazioni NCPF si distinguono poi in:
NETCF che sono quelle legate ad almeno uno dei cut-off presi in considerazione, a prescindere
dalla sigla applicativa di riferimento. (cut off di tutte le SIGLE SERVIZIO);
NETOK che sono quelle non legate ad alcun CUT-OFF e quindi candidate allo spostamento.
|
19/11/2014
|
26
PDQ TNC
CANTIERE A2: BATCH
TARGET CPF: Critical Path Finder
Dal primo report disponibile per il target CPF, è possibile identificare le applicazioni in fascia critica
(NETIN) a maggiore consumo di CPU che non sono legate ad alcun CUT-OFF (NETOK): queste sono le
prime candidate allo spostamento.
|
19/11/2014
|
27

Download Report