Endevor R7/SP4 in der Itergo System- und Subsystemumschlüsselung

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

Inhalt Allgemeine Endevor-Zahlen Endevor-Installation
Agenda Allgemeine Endevor-Zahlen Endevor-Installation System-/Subsystemwechsel im Endevor die Beweggründe die Anforderungen die Szenarien ~

Allgemeine Endevor-Zahlen
Zahlen und Fakten 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 aktive Elemente in Produktion ca laufend in der Entwicklung Endevor-Nutzer insgesamt 1339 Nutzer davon ca. 500 Entwickler ca Endevor-Aktionen pro Jahr (2008) nur ADD/Update, Generate und Move ~

Endevor-Installation
Technik 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) ~

Endevor-Installation
Technik 4 Maps für die Anwendungsentwicklung 1 2 PROJDV 1 2 PROJFA 1 2 RELEASE 1 2 PROD 1 2 SEDV 1 2 SEFA 1 2 TESTF 1 2 TEST(histor. Name) ~

System-/Subsystemwechsel im Endevor
Beweggründe 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 ~

IST- und SOLL-Zustand 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 Das Auswertungsformular aller folgenden Szenarien Massenverarbeitung ermöglichen Refresh der Crossreferenzdaten im Rochade Erhaltung der Endevor-Konsistenz (Footprints, MCF, …) Kein neues ‚Produkt‘ erstellen (= OBJ, LOAD, etc bleiben erhalten) keine neue Level-Erstellung (weder Source- noch Komponentenlevel) Refresh ACM-Records (Batchjob) ~

IST- und SOLL-Zustand Das Auswertungsformular aller folgenden Szenarien   Massenverarbeitung ermöglichen   Refresh der Crossreferenzdaten im Rochade   Erhaltung der Endevor-Konsistenz (Footprints, MCF, …)   Kein neues ‚Produkt‘ erstellen (= OBJ, LOAD, etc bleiben erhalten)   keine neue Level-Erstellung (weder Source- noch Komponentenlevel)   Refresh ACM-Records (Batchjob) ~

Agenda Allgemeine Endevor-Zahlen Endevor-Installation System-/Subsystemwechsel im Endevor die Beweggründe die Anforderungen die Szenarien die konkrete Aufgabe Allgemeines – die Hilfsmittel Szenario1 – bisherige Verfahrensweise Szenario2+3 – diverse Versuche Szenario4 – jetzige Verfahrensweise ~

Szenarien 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 ~

Werkzeuge Allgemeines – die Hilfsmittel : Endevor-Aktionen ARCHIVE RESTORE Delete-Prozessor mit CCID-Steuerung ARCHIVE darf das ‚Produkt‘ nicht löschen: //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 ~

Archive -> Restore mit SCL-Statements Szenario1 Szenario1 – die bisherige Verfahrensweise: ARCHIVE element mit CCID=‚NODELETE‘ von PROD2 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 PROD2 RESTORE 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' OPTIONS BYPASS GENERATE PROCESSOR PROCESSOR GROUP 'CPY' . ~

Archive -> Restore mit SCL-Statements Szenario1 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… ~

Archive -> Restore mit SCL-Statements Szenario1 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…∞ ~

Archive -> Restore mit SCL-Statements Szenario1 Folgeproblem des Szenario1: Gegeben: Element/Typ MCF ‚Product-Lib‘ SYS242 (Copystrecke) MB/MBP RB3/MVS NDHA375 (Hauptprogramm) Egal/egal Hauptprogramm beinhaltet Copystrecke: WORKING-STORAGE SECTION. * COPY SYS242. 10 INTERVALL PIC 9(6). ...etc... ~

Archive -> Restore mit SCL-Statements Szenario1 Umwandlung NDHA375: Componentlist NDHA375: MEMBER VV.LL DATE TIME SYSTEM SUBSYS ELEMENT TYPE STG ENVRMNT SYS APR97 08:31 RB3 MVS SYS242 CPY PROD MCF SYS242: ELEMENT: SYS242 ENV: PROD SYS: MB SUB: MBP TYPE: CPY PROC GRP: CPY STG: VV.LL: 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 ~

Archive -> Restore mit SCL-Statements Auswertung Szenario1 Sind unsere Requirements nach der Durchführung alle erfüllt?  Massenverarbeitung ermöglichen  Refresh der Crossreferenzdaten im Rochade  Erhaltung der Endevor-Konsistenz (Footprints, MCF, …)  Kein neues ‚Produkt‘ erstellen (= OBJ, LOAD, etc bleiben erhalten)  keine neue Level-Erstellung (weder Source- noch Komponentenlevel)  Refresh ACM-Records (Batchjob) ~

Archive -> Restore mit SCL-Statements Bewertung Szenario1 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 ?? ~

Restore in HilfsEnvironment->Transfer PROD2 -> Move -> BSTCOPY -> Rochade -> ACM Ideen 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 ~

Restore in HilfsEnvironment->Transfer PROD2 -> Move -> BSTCOPY -> Rochade -> ACM Szenario2 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: RESTORE ELEMENT 'SYS242' FROM FILE ARCHIV TYPE 'CPY' ENVIRONMENT 'PROD' SYSTEM 'RB3' SUBSYSTEM 'MVS' STAGE NUMBER 2 TO ENVIRONMENT ‘SYSTEM' TYPE 'CPY' SYSTEM 'MB' SUBSYSTEM 'MBP' OPTIONS BYPASS GENERATE PROCESSOR PROCESSOR GROUP 'CPY' . ~

Restore in HilfsEnvironment->Transfer PROD2 -> Move -> BSTCOPY -> Rochade -> ACM Szenario2 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 . ~

Restore in HilfsEnvironment->Transfer PROD2 -> Move -> BSTCOPY -> Rochade -> ACM Auswertung Szenario2 Sind unsere Requirements nach der Durchführung alle erfüllt?  Massenverarbeitung ermöglichen  Refresh der Crossreferenzdaten im Rochade  Erhaltung der Endevor-Konsistenz (Footprints, MCF, …)  Kein neues ‚Produkt‘ erstellen (= OBJ, LOAD, etc bleiben erhalten)  keine neue Level-Erstellung (weder Source- noch Komponentenlevel) die Komponentenlisten sind alle verloren und es wird nur ein (unbrauchbarer) Level erzeugt ! BC1PMVCL kann keine Historie ‚moven‘  Refresh ACM-Records (Batchjob) ~

Restore PROD2 ->Transfer SYSTEM2 -> Move -> BSTCOPY -> Rochade -> ACM -> Delete SYSTEM2 Bewertung Szenario2 Bewertung des Szenario2: 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 ~

Restore PROD2 ->Transfer SYSTEM2 -> Move -> BSTCOPY -> Rochade -> ACM -> Delete SYSTEM2 Szenario3 Szenario3: Hilfs-Environment „SYSTEM“ existiert bereits 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 nicht notwendig, da Löschkandidat] Rochadesatz (für alle Elemente) RESTORE nach PROD2 und TRANSFER nach SYSTEM2 Restore-SCL wie vorher TRANSFER.SCL: RESTORE 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' OPTIONS BYPASS GENERATE PROCESSOR PROCESSOR GROUP 'CPY' . ~

Restore in HilfsEnvironment->Transfer PROD2 -> Move -> BSTCOPY -> Rochade -> ACM Szenario3 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 . ~

Restore PROD2 ->Transfer SYSTEM2 -> Move -> BSTCOPY -> Rochade -> ACM -> Delete SYSTEM2 Szenario3 Szenario3: Move-Prozessor anstossen BSTCOPY des ‚Produktes‘ von CPYLIB nach &TEMP und von &TEMP zurück nach CPYLIB (nur für Unterkomponenten nötig) Rochadesatz (für alle Elemente) DELETE auf SYSTEM2 per Paket (Standard SCL) ~

Restore PROD2 ->Transfer SYSTEM2 -> Move -> BSTCOPY -> Rochade -> ACM -> Delete SYSTEM2 Auswertung Szenario3 Sind unsere Requirements nach der Durchführung alle erfüllt?  Massenverarbeitung ermöglichen  Refresh der Crossreferenzdaten im Rochade  Erhaltung der Endevor-Konsistenz (Footprints, MCF, …)  Kein neues ‚Produkt‘ erstellen (= OBJ, LOAD, etc bleiben erhalten)  keine neue Level-Erstellung (weder Source- noch Komponentenlevel)  Refresh ACM-Records (Batchjob) Auf den ersten Blick ist alles erfüllt,… ~

Restore PROD2 ->Transfer SYSTEM2 -> Move -> BSTCOPY -> Rochade -> ACM -> Delete SYSTEM2 Auswertung Szenario3 Sind unsere Requirements nach der Durchführung alle erfüllt?  Massenverarbeitung ermöglichen  Refresh der Crossreferenzdaten im Rochade  Erhaltung der Endevor-Konsistenz (Footprints, MCF, …)  Kein neues ‚Produkt‘ erstellen (= OBJ, LOAD, etc bleiben erhalten)  keine neue Level-Erstellung (weder Source- noch Komponentenlevel)  Refresh ACM-Records (Batchjob) …, wenn es nicht das Feld „ENVRMNT“ in den Footprints gäbe ! ~

Restore PROD2 ->Transfer SYSTEM2 -> Move -> BSTCOPY -> Rochade -> ACM -> Delete SYSTEM2 Bewertung Szenario3 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 SYS MB MBP SYS CPY APR97 08:31 Footprints des NDHA375 nach der Generierung: MEMBER VV.LL DATE TIME SYSTEM SUBSYS ELEMENT TYPE STG STE ENVRMNT LD SYS APR97 08:31 MB MBP SYS CPY 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 Bewertung des Szenario3: 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 ->Restore SYSTEM2 -> Transfer PROD2 -> Move -> BSTCOPY -> Rochade -> ACM Szenario4 Szenario4: Hilfs-Environment „SYSTEM“ existiert bereits 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) [KEIN „ BC1PMVCL“ und KEIN Monitoring verwenden (!)] Rochadesatz (für alle Elemente) RESTORE nach PROD2 und nach SYSTEM2 Restore-SCL für beide Stages TRANSFER von SYSTEM2 nach PROD2 Transfer-SCL: RESTORE 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' OPTIONS BYPASS GENERATE PROCESSOR PROCESSOR GROUP 'CPY' . TO ENVIRONMENT ‘SYSTEM' ~

Restore PROD2 ->Restore SYSTEM2 -> Transfer PROD2 -> Move -> BSTCOPY -> Rochade -> ACM Szenario4 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 . ~

Restore PROD2 ->Restore SYSTEM2 -> Transfer PROD2 -> Move -> BSTCOPY -> Rochade -> ACM Auswertung Szenario4 Sind unsere Requirements nach der Durchführung alle erfüllt?  Massenverarbeitung ermöglichen  Refresh der Crossreferenzdaten im Rochade  Erhaltung der Endevor-Konsistenz (Footprints, MCF, …)  Kein neues ‚Produkt‘ erstellen (= OBJ, LOAD, etc bleiben erhalten)  keine neue Level-Erstellung (weder Source- noch Komponentenlevel)  Refresh ACM-Records (Batchjob)  Ziel erreicht . ~

System-/Subsystemwechsel
Résumé - 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 ? ~

Endevor R7/SP4 in der Itergo System- und Subsystemumschlüsselung

Ähnliche Präsentationen

Präsentation zum Thema: "Endevor R7/SP4 in der Itergo System- und Subsystemumschlüsselung"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback

Anmelden

Anmeldung über soziales Netzwerk:

Endevor R7/SP4 in der Itergo System- und Subsystemumschlüsselung

Ähnliche Präsentationen

Präsentation zum Thema: "Endevor R7/SP4 in der Itergo System- und Subsystemumschlüsselung"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback