View Full Version : security level auf 40 setzen
Hallo zusammen,
wir wollen von Security 30 auf 40 wechseln.
Lt SC415302.PDF sind 'nur' das die Unterschiede
- Programs that use unsupported interfaces fail at run time.
- Enhanced hardware storage protection is enforced for all storage.
- Pointers used in parameters are validated for user domain programs running in system state.
- A program’s associated space cannot be directly modified.
- Internal control blocks are protected.
Wenn ich ehrlich bin weis ich nicht, was da gemeint ist!
Was sind nicht unterstütze Schnittstellen?
Welche Auswirkungen hat der erweiterte Speicher schutz
was sind "user domain programs running in system state".
Hat es für das Tagesgeschäft folgen, wenn zugeordneter Speicher nicht geändert werden kann?
Was für interne Control Blöcke?
Ihr merkt schon ... ich hab nicht so viel Ahnung.
Habt Ihr von 30 auf 40 umgestellt uns was für Probleme gab es dabei?
Danke
Dietlinde Beck
... wenn ihr nur mit RPG/COBOL/CL/SQL hantiert, betrifft das eure Programme nicht. Man sollte sich aber von allen Lieferanten der eingesetzten Software Unbedenklichkeit bescheinigen lassen, sonst kann das schief gehen. Hauptsächlich geht es da um Programme, die bestimmte MI Aufrufe und/oder undokumentierte Schnittstellen benutzen.
D*B
Danke Herr Bender!
wir haben tatsächlich nur RPG CL SQL in allen Ausprägungen bei uns laufen.
Das ist zu 90 % eigen entwickelt, aber von Zig verschiedenen externen Mitarbeitern.
Außer einer Adressprüfung und einer Fax Schnittstelle gibt es keine externe Software!
Soll ich zum WE einfach mal umstellen, IPL machen und am WE die SW testen?
Kein 'Fahrplan', keine 'Prüf-Pgmme'?
DiBe
... testen kann man das schon ohne Umstellung. Wenn man auditing aktiviert, dann werden potentielle Probleme im audit Journal protokolliert. Wie das geht, sieht man hier: http://www-01.ibm.com/support/docview.wss?uid=nas8N1019668 . Es bleibt allerdings das Problem, dass ja in einem Programm ein Problem stecken könnte, dass noch nicht aufgerufen wurde, seitdem man das aktiviert hat. Bevorzugt passiert dann etwas beim Jahreswechsel oder Releasewechsel oder zu ähnlichen Anlässen, wo man das an besten gebrauchen kann.
D*B
Vielen Dank
ich habe unsere Audit reciever mal analysieren lassen und finden diese 'kritischen", weil CODE 'J', Einträge.
CODE ART DATUM ZEIT JOB- BENUTZER- JOB- PROGRAMM- OBJEKT- BIBLIO
NAME NAME NUMMER NAME NAME NAME
J NR 161215 73.106 QDBSRV03 QSYS 291.867 QDBSERVE
J PR 161215 73.107 QDBSRV03 QSYS 291.867 QDBSERVE
J NR 161215 154.548 QDBSRV03 QSYS 291.867 QDBSERVE
J PR 161215 154.548 QDBSRV03 QSYS 291.867 QDBSERVE
J RS 161215 230.839 SAV#DATEN SAVE 296.393 HCP200 QAUDRCV QGPL
J RS 161215 230.840 SAV#DATEN SAVE 296.393 HCP200 QAUDRC0001 QGPL
J RS 161215 230.840 SAV#DATEN SAVE 296.393 HCP200 QAUDRC0002 QGPL
J RS 161215 230.840 SAV#DATEN SAVE 296.393 HCP200 QAUDRC0003 QGPL
J RS 161215 230.841 SAV#DATEN SAVE 296.393 HCP200 QAUDRC0004 QGPL
J RS 161215 230.843 SAV#DATEN SAVE 296.393 HCP200 QAUDRC0005 QGPL
J RS 161215 230.843 SAV#DATEN SAVE 296.393 HCP200 QAUDRC0006 QGPL
J IN 171215 24.030 *TDE 728996 0 *NONE
J NR 171215 24.115 SCPF QSYS 0 QWCISCFR
J PR 171215 24.115 SCPF QSYS 0 QWCISCFR
J NR 171215 95.245 QDBSRV03 QSYS 301.672 QDBSERVE
J PR 171215 95.245 QDBSRV03 QSYS 301.672 QDBSERVE
so wie ich das Lese sind das Systemdinge und die Sicherung des Journals/Reciever selber
Bekomme ich bei Level 40 deswegen ein Problem?
Danke
DiBe
KingofKning
17-12-15, 14:54
Also ich habe in all den Jahren und Jahrzehnten noch nie von einem Problem bei der Umstellun von 30 auf 40 gehört.
Kannst Du ja mal fröhlich am 24ten umstellen dann hast du 4 Tage Zeit zum testen und wenn es nicht klappt stellst Du am 27ten wieder zurück.
GG
Vielen Dank
ich habe unsere Audit reciever mal analysieren lassen und finden diese 'kritischen", weil CODE 'J', Einträge.
CODE ART DATUM ZEIT JOB- BENUTZER- JOB- PROGRAMM- OBJEKT- BIBLIO
NAME NAME NUMMER NAME NAME NAME
J NR 161215 73.106 QDBSRV03 QSYS 291.867 QDBSERVE
J PR 161215 73.107 QDBSRV03 QSYS 291.867 QDBSERVE
J NR 161215 154.548 QDBSRV03 QSYS 291.867 QDBSERVE
J PR 161215 154.548 QDBSRV03 QSYS 291.867 QDBSERVE
J RS 161215 230.839 SAV#DATEN SAVE 296.393 HCP200 QAUDRCV QGPL
J RS 161215 230.840 SAV#DATEN SAVE 296.393 HCP200 QAUDRC0001 QGPL
J RS 161215 230.840 SAV#DATEN SAVE 296.393 HCP200 QAUDRC0002 QGPL
J RS 161215 230.840 SAV#DATEN SAVE 296.393 HCP200 QAUDRC0003 QGPL
J RS 161215 230.841 SAV#DATEN SAVE 296.393 HCP200 QAUDRC0004 QGPL
J RS 161215 230.843 SAV#DATEN SAVE 296.393 HCP200 QAUDRC0005 QGPL
J RS 161215 230.843 SAV#DATEN SAVE 296.393 HCP200 QAUDRC0006 QGPL
J IN 171215 24.030 *TDE 728996 0 *NONE
J NR 171215 24.115 SCPF QSYS 0 QWCISCFR
J PR 171215 24.115 SCPF QSYS 0 QWCISCFR
J NR 171215 95.245 QDBSRV03 QSYS 301.672 QDBSERVE
J PR 171215 95.245 QDBSRV03 QSYS 301.672 QDBSERVE
so wie ich das Lese sind das Systemdinge und die Sicherung des Journals/Reciever selber
Bekomme ich bei Level 40 deswegen ein Problem?
Danke
DiBe
... wenn ich das auf die Schnelle richtig sehe, sind Einträge mit Code T, Art AF und davon die, die mit
B, C, D, J, R oder S anfangen kritisch.
Von dem blank ausprobieren über die Feiertage, halte ich persönlich nix. Erstens brennt mir da die Weihnachtsgans an und dann spielt ja noch eine Rolle warum ich das mache. Oft sind sowas Revisionsanforderungen und da halte ich von Schüssen aus der Hüfte wenig.
D*B
holgerscherer
18-12-15, 00:57
Danke Herr Bender!
wir haben tatsächlich nur RPG CL SQL in allen Ausprägungen bei uns laufen.
Das ist zu 90 % eigen entwickelt, aber von Zig verschiedenen externen Mitarbeitern.
Außer einer Adressprüfung und einer Fax Schnittstelle gibt es keine externe Software!
Soll ich zum WE einfach mal umstellen, IPL machen und am WE die SW testen?
Kein 'Fahrplan', keine 'Prüf-Pgmme'?
DiBe
Mal eben umstellen und testen am Wochenende geht in der Regel schief. Da reicht die Zeit nicht, alles auszuprobieren.
Am besten auf einer eigenen Testmaschine / -Partition die Umgebung auf SecLvl40 oder 50 stellen und in Ruhe ein paar Wochen alles genau testen.
Je nach Branche und Validierungsvorschriften dauert das einige Wochen. Im Pharma-Bereich haben wir Kunden, die "mal eben" 6 Monate testen, auch vor jedem Release-Wechsel.
Wenn keine Testumgebung vorhanden ist - dafür gibts Dienstleister ;-)
KingofKning
18-12-15, 07:23
Tja,
bei meiner Umstellung von V5R4 auf V6R1 ging alles Gut........
Bis zum ersten Mal der monatliche Reorgjob lief........
GG
Bei vernünftiger Berechtigungsstruktur (kennt man ja aus anderen Beiträgen) sollte die Security mit 30 jeder Revision standhalten.
Es gibt keinen Grund zwingend auf 40 gehen zu müssen.
Mit MI-Programmen/Funktionen gehen wohl die wenigsten um. Compiler halten sich an die Regeln.
Programme, die von Anwendern entwickelt werden sind eher selten im "System"-Mode zumal die IBM das Verfahren wie dies zu erreichen ist nicht offen gelegt hat.
Solange alles per API gemacht wird gibt es keine Probleme mit der 40.