Endevor R7/SP4 in der Itergo System- und Subsystemumschlüsselung Düsseldorf, 19.05.2009

Endevor R7/SP4 in der Itergo

System- und Subsystemumschlüsselung

Düsseldorf, 19.05.2009

2

Inhalt

Allgemeine Endevor-Zahlen

Endevor-Installation

System-/Subsystemwechsel im Endevor

die Beweggründe

die Anforderungen

die Szenarien

Agenda

~

3

Inhalt




die Beweggründe

die Anforderungen

die Szenarien

Agenda

~

4


Mengengerüst

13 Environments mit 17 „aktiven“ Stages

[Hauptentwicklungszweig: 4 Environments, 6 „aktive“ Stages]

50 Endevor-Systeme mit jeweils ca. 8 Subsystemen (Tendenz steigend)

190 Prozessoren

238.000 aktive Elemente

193.000 in Produktion

ca. 45.000 laufend in der Entwicklung

Endevor-Nutzer

insgesamt 1339 Nutzer

davon ca. 500 Entwickler

ca. 800.000 Endevor-Aktionen pro Jahr (2008)

nur ADD/Update, Generate und Move

Zahlen und Fakten

~

5

Inhalt




die Beweggründe

die Anforderungen

die Szenarien

Agenda

~

6


Allgemeines

(!) Elementbeschreibungssatz (!) [ELM-Name, Sys, Sub, Typ, ...]

eigene TSO/ISPF-Oberfäche für Endevor-Aktionen

keine Nutzung von „QuickEdit“

Nutzung „LServ“

4 LPARs für die Endevornutzung in einem sog. Anwender-Plex

Endevor-‘Online‘ auf den Entwickler-Stages

Endevor-‘Batch‘ ab den Fach-Stages (Paketverarbeitung)

unter (fast) jeder aktiven Stage liegt ein eigenes DB2-Subsystem

es wird auf jeder Zielstage ein neues LOAD erzeugt (außer PROD1)

Technik

~

7


4 Maps für die Anwendungsentwicklung

Technik

1 2

TEST(histor. Name)

1 2

TESTF

1 2

RELEASE

1 2

PROD

1 2

SEFA

1 2

SEDV

1 2

PROJFA

1 2

PROJDV

~

8

Inhalt




die Beweggründe

die Anforderungen

die Szenarien

Agenda

~

9


Gründe für einen System-/Subsystemwechsel

Organisatorische Änderung (z.B. neue Zuständigkeit)

Endevor-System entfällt, Elemente werden woanders hin verteilt

Endevor-System wird durch neues Subsystem ‚verfeinert‘

Trennen der Endevor-Systeme

u.v.a

Beweggründe

~

10

Inhalt




die Beweggründe

die Anforderungen

die Szenarien

Agenda

~

11


Anforderungen:

Massenverarbeitung ermöglichen

Refresh der Crossreferenzdaten im Rochade

Refresh der ACM-Records („Print Element“+BC1PACMO per Batchjob)

(in nachfolgenden Szenarien nicht immer explizit erwähnt)

Erhaltung der Endevor-Konsistenz (Footprints, MCF, …)

Kein neues ‚Produkt‘ erstellen (= OBJ, LOAD, etc bleiben erhalten)

Grund:

Umwandlung einer ALTEN Unterkomponente führt ggf. zu unvorhersehbaren Ergebnissen

keine neue Level-Erstellung (weder Source- noch Komponentenlevel)

IST- und SOLL-Zustand

~

12


Das Auswertungsformular aller folgenden Szenarien




Kein neues ‚Produkt‘ erstellen (= OBJ, LOAD, etc bleiben

erhalten)

keine neue Level-Erstellung (weder Source- noch

Komponentenlevel)

Refresh ACM-Records (Batchjob)

~


13


Das Auswertungsformular aller folgenden Szenarien







~


14

Inhalt




die Beweggründe

die Anforderungen

die Szenarien

die konkrete Aufgabe

Allgemeines – die Hilfsmittel

Szenario1 – bisherige Verfahrensweise

Szenario2+3 – diverse Versuche

Szenario4 – jetzige Verfahrensweise

Agenda

~

15

Inhalt




die Beweggründe

die Anforderungen

die Szenarien






Agenda

~

16


konkrete Aufgabe zur Umstellung eines Elementes:

Element ist die Copystrecke „SYS242“

Daten ALT: System=RB3 / Subsystem=MVS

Daten NEU: System=MB / Subsystem=MBP

Das Element befindet sich ausschliesslich in der Stage „PROD2“

Source-Level 01.05

Komponentenlevel 01.03

Szenarien

~

17

Inhalt




die Beweggründe

die Anforderungen

die Szenarien






Agenda

~

18


Allgemeines – die Hilfsmittel :

Endevor-Aktionen

ARCHIVE

RESTORE

Delete-Prozessor mit CCID-Steuerung

ARCHIVE darf das ‚Produkt‘ nicht löschen:

Werkzeuge

//DPGMP2 PROC START=START, * ERSTER=DUMMY// RXDBG=NO, * REXX DEBUG // API=NO, * API / LSQL // LOADLIB=&HLQPGM..&C1EN..&C1TY(1,4).LOADLIB,..........// ZZ=ENDE //* //* //* //IFNODEL IF ('&C1CCID(1,8)' NE 'NODELETE') THEN //* //** -INC XYZ //** -INC ABC//* ..........//** //IFNODEL ENDIF //* ~

19

Inhalt




die Beweggründe

die Anforderungen

die Szenarien






Agenda

~

20


Szenario1 – die bisherige Verfahrensweise:

ARCHIVE element mit CCID=‚NODELETE‘ von PROD2

Szenario1

ARCHIVE ELEMENT 'SYS242'

FROM ENVIRONMENT 'PROD' SYSTEM 'RB3' SUBSYSTEM 'MVS'

TYPE 'CPY' STAGE 2

TO DDNAME ARCHIV

OPTIONS CCID 'NODELETE' OVERRIDE SIGNOUT .

RESTORE element mit neuem (SUB-)SYSTEM nach PROD2RESTORE ELEMENT 'SYS242' FROM FILE ARCHIV TYPE 'CPY'

ENVIRONMENT 'PROD' SYSTEM 'RB3' SUBSYSTEM 'MVS'

STAGE NUMBER 2

TO ENVIRONMENT 'PROD'

TYPE 'CPY'

SYSTEM 'MB' SUBSYSTEM 'MBP'

STAGE NUMBER 2

OPTIONS BYPASS GENERATE PROCESSOR PROCESSOR GROUP 'CPY' .~

Archive -> Restore mit SCL-Statements

21


MCF/Footprints aus Szenario1:

Ergebnisse:

MCF-Daten sind durch die Endevor-Aktion ‚RESTORE‘ angepasst worden (MB/MBP)

Footprints im ‚Produkt‘ (CPYLIB) haben noch alte Werte (RB3/MVS)

Auswirkungen:

Wenn das Element nach dem RESTORE in die Entwicklung genommen und geändert wieder nach PROD2 gestellt wird (GENERATE), gibt es keine Folgeauswirkungen

Wird das Element nur wegen neuer fachlicher Zugehörigkeit restored und nicht neu generiert, führt dieses zu einem Folgeproblem…

Szenario1

~


22


Auswirkungen:

Vorteile:

schnelles Verfahren

unkompliziertes Verfahren

geringe Fehleranfälligkeit

Requirements erfüllt?

Nein, nicht alle !

Nachteile:

keine neuen Crossreferenzdaten geschrieben

(ohne Prozessor nicht möglich)

MCF-Daten stimmen mit Footprints nicht mehr überein

… dessen Auswirkungen gleich gezeigt werden…∞

Szenario1

~


23


Folgeproblem des Szenario1:

Gegeben:

Szenario1

Element/Typ MCF ‚Product-Lib‘

SYS242 (Copystrecke) MB/MBP RB3/MVS

NDHA375 (Hauptprogramm) Egal/egal Egal/egal

Hauptprogramm beinhaltet Copystrecke: WORKING-STORAGE SECTION. *

COPY SYS242. 10 INTERVALL PIC 9(6).

...etc...

~


24


Umwandlung NDHA375:

Componentlist NDHA375:

MEMBER VV.LL DATE TIME SYSTEM SUBSYS ELEMENT TYPE STG ENVRMNT

SYS242 01.05 11APR97 08:31 RB3 MVS SYS242 CPY 2 PROD

MCF SYS242:ELEMENT: SYS242 ENV: PROD SYS: MB SUB: MBP TYPE: CPY

PROC GRP: CPY STG: 2 VV.LL: 01.05 LAST ACTION: RESTORE

Paket-CAST für MOVE des NDHA375:PKMR791I COMPONENT VALIDATION STARTED

FPVL001E INPUT COMPONENT VALIDATION ERROR HAS OCCURRED FOR

C1G0000I ELEMENT NDHA375

PKMR801I OF ENV:PROJDV SYS:IS SUBSYS:IS TYPE:PGMHCOB STG:2

FPVL002E NO MCF RECORD FOUND FOR C1G0000I INPUT COMPONENT SYS242

C1G0000I FROM DATA SET VAPGM.PROD.CPY.CPYLIB

PKMR802I FP ENV:PROD SYS:RB3 SUBSYS:MVS TYPE:CPY STG:2

PKMR799I COMPONENT VALIDATION COMPLETED : HIGHEST RC = 12

Szenario1

~


25


Sind unsere Requirements nach der Durchführung alle erfüllt?







~

Archive -> Restore mit SCL-Statements Auswertung Szenario1

26


Bewertung des Szenario1:

Brauchbar, wenn das Element kurzfristig geändert und wieder produktiv wird

(Generierung in Produktion = refresh Footprint in CPYLIB)

Unbrauchbar, wenn nicht neu generiert wird

besonders ärgerlich, wenn es eine zentrale Copystrecke ist.

unbefriedigend, wenn nicht generiert werden darf (stat. UPROs)

Schlüsselfrage: Wie bekommt das ‚Produkt‘ den neuen Footprint ??

Bewertung Szenario1

~


27

Inhalt




die Beweggründe

die Anforderungen

die Szenarien






Agenda

~

28


Ideensammlung für einen Footprintwechsel:

BSTCOPY erforderlich

MOVE-Prozessor erforderlich

der auch gleich die Rochade-Sätze schreiben kann…

Aktion TRANSFER erforderlich

Hilfs-Environment erforderlich

neues Szenario2:

Restore in das HilfsEnvironment -> TRANSFER nach PROD2 -> Anstossen des MOVE-

Prozessors -> BSTCOPY des ‚Produktes‘ -> Rochadesätze schreiben -> ACM

Ideen

~

Restore in HilfsEnvironment->Transfer PROD2 -> Move -> BSTCOPY -> Rochade -> ACM

29


Szenario2:

Hilfs-Environment „SYSTEM“ erstellt

Prozessorgruppe in „SYSTEM2“ erstellt

Move-Prozessor erstellt (used for Transfer action = M)

BSTCOPY des ‚Produktes‘ von CPYLIB nach &TEMP und von &TEMP zurück nach CPYLIB

(nur für Unterkomponenten nötig)

BC1PMVCL (um die Componentlists nach PROD2 mitzunehmen)

Rochade-Sätze schreiben

RESTORE nach SYSTEM2 und TRANSFER nach PROD2

Restore-SCL wie in Szenario1

TRANSFER-SCL:

Szenario2

~


RESTORE ELEMENT 'SYS242' FROM FILE ARCHIV TYPE 'CPY'


STAGE NUMBER 2

TO ENVIRONMENT ‘SYSTEM'

TYPE 'CPY'


STAGE NUMBER 2

OPTIONS BYPASS GENERATE PROCESSOR PROCESSOR GROUP 'CPY' .

30


Szenario2:

TRANSFER ELEMENT 'SYS242' FROM ENVIRONMENT 'SYSTEM' SYSTEM 'MB' SUBSYSTEM 'MBP' TYPE 'CPY' STAGE NUMBER 2 TO ENVIRONMENT 'PROD' SYSTEM 'MB' SUBSYSTEM 'MBP' TYPE 'CPY' STAGE NUMBER 2 OPTIONS OVERRIDE SIGNOUT PROC GROUP 'CPY' IGNORE GENERATE FAILED WITH HISTORY .

Szenario2

~


31








1. die Komponentenlisten sind alle verloren und es wird nur ein (unbrauchbarer) Level 01.00

erzeugt !

2. BC1PMVCL kann keine Historie ‚moven‘


~

Restore in HilfsEnvironment->Transfer PROD2 -> Move -> BSTCOPY -> Rochade -> ACM Auswertung Szenario2

32



Unbrauchbar !

es gehen wichtige Informationen verloren (NoGo)

Schlüsselfrage: Wie können wir die Komponentenhistorie erhalten ??

Idee: Versuchen wir es umgekehrt:

neues Szenario3:

Restore nach PROD2 -> TRANSFER nach SYSTEM2 (ohne Delete) -> Anstossen des MOVE-

Prozessors -> BSTCOPY des ‚Produktes‘ -> Rochadesätze schreiben -> ACM schreiben ->

Löschen ELM in SYSTEM2

Bewertung Szenario2

~

Restore PROD2 ->Transfer SYSTEM2 -> Move -> BSTCOPY -> Rochade -> ACM -> Delete SYSTEM2

33


Szenario3:

Hilfs-Environment „SYSTEM“ existiert bereits




[BC1PMVCL nicht notwendig, da Löschkandidat]

Rochadesatz (für alle Elemente)

RESTORE nach PROD2 und TRANSFER nach SYSTEM2

Restore-SCL wie vorher

TRANSFER.SCL:

Szenario3

~




STAGE NUMBER 2

TO ENVIRONMENT ‘PROD'

TYPE 'CPY'


STAGE NUMBER 2


34


Szenario3:

TRANSFER ELEMENT 'SYS242' FROM ENVIRONMENT 'PROD' SYSTEM 'MB' SUBSYSTEM 'MBP' TYPE 'CPY' STAGE NUMBER 2 TO ENVIRONMENT 'SYSTEM' SYSTEM 'MB' SUBSYSTEM 'MBP' TYPE 'CPY' STAGE NUMBER 2 OPTIONS OVERRIDE SIGNOUT PROC GROUP 'CPY' IGNORE GENERATE FAILED BYPASS ELEMENT DELETE .

Szenario3

~


35


Szenario3:

Move-Prozessor anstossen




DELETE auf SYSTEM2

per Paket (Standard SCL)

Szenario3

~


36









Auf den ersten Blick ist alles erfüllt,…

~

Restore PROD2 ->Transfer SYSTEM2 -> Move -> BSTCOPY -> Rochade -> ACM -> Delete SYSTEM2 Auswertung Szenario3

37









…, wenn es nicht das Feld „ENVRMNT“ in den Footprints gäbe !

~

Auswertung Szenario3Restore PROD2 ->Transfer SYSTEM2 -> Move -> BSTCOPY -> Rochade -> ACM -> Delete SYSTEM2

38


Erscheinungsbilder des Footprints:

Footprints der SYS242 auf der CopyLib: !--------------------- F O O T P R I N T --------------------!MEMBER SYSTEM SUBSYSTEM ELEMENT TYPE S VV.LL DATE TIME LD

SYS242 MB MBP SYS242 CPY 2 01.05 11APR97 08:31

Footprints des NDHA375 nach der Generierung:MEMBER VV.LL DATE TIME SYSTEM SUBSYS ELEMENT TYPE STG STE ENVRMNT LDSYS242 01.05 11APR97 08:31 MB MBP SYS242 CPY 2 1 SYSTEM

Das Feld „ENVRMNT“ wird im Endevor unter „Footprint Display“ nicht angezeigt (R7/SP4).

Das Feld „ENVRMNT“ ist nur in der Component-List sichtbar.

Wenn das Element später auf „SYSTEM2“ gelöscht wird, gibt es im CAST des NDHA375 wiederum einen „NO MCF RECORD FOUND…“-Fehler.

~

Restore PROD2 ->Transfer SYSTEM2 -> Move -> BSTCOPY -> Rochade -> ACM -> Delete SYSTEM2 Bewertung Szenario3

39



Unbrauchbar !

der Footprint des ‚Produktes‘ ist falsch

es führt weiterhin zu CAST-Fehlern nach der Bereinigung von „SYSTEM2“ (NoGo)

Schlüsselfrage: Wie können wir die Komponentenhistorie erhalten und den Footprint

auf die korrekten Werte ändern??

=> damit stehen wir wieder am Anfang…

… gäbe es nicht diese neue Idee:

neues Szenario4:

Restore nach PROD2 + Restore nach SYSTEM2 -> TRANSFER nach PROD2 -> Anstossen

des MOVE-Prozessors -> BSTCOPY des ‚Produktes‘ -> Rochadesätze schreiben

~

Restore PROD2 ->Transfer SYSTEM2 -> Move -> BSTCOPY -> Rochade -> ACM -> Delete SYSTEM2 Bewertung Szenario3

40

Inhalt




die Beweggründe

die Anforderungen

die Szenarien






Agenda

~

41


Szenario4:

Hilfs-Environment „SYSTEM“ existiert bereits




[KEIN „ BC1PMVCL“ und KEIN Monitoring verwenden (!)]


RESTORE nach PROD2 und nach SYSTEM2

Restore-SCL für beide Stages

TRANSFER von SYSTEM2 nach PROD2

Transfer-SCL:

Szenario4

~

Restore PROD2 ->Restore SYSTEM2 -> Transfer PROD2 -> Move -> BSTCOPY -> Rochade -> ACM



STAGE NUMBER 2

TO ENVIRONMENT ‘PROD'

TYPE 'CPY'


STAGE NUMBER 2




STAGE NUMBER 2

TO ENVIRONMENT ‘SYSTEM'

TYPE 'CPY'


STAGE NUMBER 2


42


Szenario4:

TRANSFER ELEMENT 'SYS242' FROM ENVIRONMENT 'SYSTEM' SYSTEM 'MB' SUBSYSTEM 'MBP' TYPE 'CPY' STAGE NUMBER 2 TO ENVIRONMENT 'PROD' SYSTEM 'MB' SUBSYSTEM 'MBP' TYPE 'CPY' STAGE NUMBER 2 OPTIONS OVERRIDE SIGNOUT PROC GROUP 'CPY' IGNORE GENERATE FAILED WITH HISTORY .

Szenario4

~

Restore PROD2 ->Restore SYSTEM2 -> Transfer PROD2 -> Move -> BSTCOPY -> Rochade -> ACM

43









Ziel erreicht .

~

Restore PROD2 ->Restore SYSTEM2 -> Transfer PROD2 -> Move -> BSTCOPY -> Rochade -> ACM Auswertung Szenario4

44

System-/Subsystemwechsel

- Die Lösung ist (eigentlich) ganz einfach… -

- …aber für eine ‚einfache‘ Umbenennung zu komplex -

Meine Fragen an das Plenum:

=> Alle: Gibt es eine einfachere Lösung?

=> CA: Wird es zukünftig ein Utility dafür geben?

Vielen Dank für Ihre Aufmerksamkeit…

¿Ihre Fragen ?~

Résumé

Documents

Endevor R7/SP4 in der Itergo System- und Subsystemumschlüsselung Düsseldorf, 19.05.2009