hallo!!
wer kennt sich mit CL programmierung in der AS/400 aus?
bei uns in der firma stellt sich folgendes problem:
wenn irgendeine sicherung, der nachtjob oder sonstige sensible
programme laufen, die man nur durchführen kann, wenn kein anderer an
der maschine arbeitet, gibt es bei uns ein kleines, naja, nicht direkt
problem, sagen wir eher "unannehmlichkeit":
wärend ein solcher job läuft, können sich andere user ohne probleme
am system anmelden, und dadurch den job killen oder sonst irgendwie
stören, wenns hart kommt.
im prinzip könnte man so ein problem umgehen, wenn man alle normalen
user terminals in einem separaten subsystem fahren würde, und nur die
masterkonsole und den systemdrucker in einem eigenen subsystem.
man könnte dann das "user-subsystem" herunterfahren und hätte somit
alle bildschirme gesperrt, sodaß man in ruhe sichern kann.
aber leider laufen bei uns alle bildschirme inkl. der masterkonsole in
EINEM subsystem. und das ganze mal eben so zu ändern ist ja nicht drin.
wir müßten dann quasi JEDE der ca. 100 bildschirmadressen einzeln
abhängen.
könnte man sowas nicht in einem CL regeln? bzw. in 2 CL´s?
ein cl deaktiviert alle bilschirmadressen, die im cl selber
hinterlegt sind, und das 2te cl aktiviert alle bildschirmadressen
wieder in einem rutsch.
man müßte dann nur noch einen blick auf die virtuellen
bildschirmadressen werfen, die entstehen, wenn sich ein mitarbeiter
vom fernen system aus bei uns einwählt. aber das ist kein problem.
sind nicht viele.
hat jemand ne ahnung, wie man sowas automatiesiern kann?
Programmieren - alles kontrollieren 4.941 Themen, 20.715 Beiträge
ich kenne mich mit AS/400 nicht aus (arbeite an einem Tandem Non-Stop System unter OS Guardian 90), aber kann man das Anstarten von Job`s bzw. Programmen nicht Userabhängig gestalten.
Bei unserem System können wichtige administrative Aufgaben, wie z.B. eine Datensicherung nur mit super.super (vergleichbar Administrator) oder Gleichgestellten erledigt werden. Diese Prozesse könne selbstverständlich von keinem User auch nur eine Ebene tiefer administriert (Prioritäten, Suspendierung usw.) geschweige denn gestoppt werden.
Ich gehe mal davon aus, daß bei Euch nicht alle User mit Administratorrrechten arbeiten !! ;-((
Gruß
repi
ist schon ne Ewigkeit her, das ich mit CL gearbeitet habe, ich war mehr auf RPG/400 und C/400 ausgelegt, aber könnte man nicht auf den Arbeitsstationen mit der Jobwarteschlange arbeiten, solagen z.B. die Sicherung läuft!
Man müßte in einem CL Programm für jede Bildschirmstation eben eine neue Jobwarteschlange mit CRTJOBQ erstellen und an das Subsystem binden und mit den entsprechenden Angaben versorgen.
Die Lösung mit zwei oder mehr Subsystemen, scheint mir aber die sauberste, ... gut ist erst einmal etwas Arbeit alle Stationen umzumappen!
Wie gesagt ist ca. 6 Jahre her, wo ich das letzte mal an einer AS/400
gearbeitet habe und könnte daher mit der Idee total daneben liegen!
Frank
@repi:
also mit administratorrechten arbeiten bei uns nur 3 leute (der abt.leiter, mein kollege und ich). die anderen user haben nur normale rechte.
das problem besteht aber nicht in den rechten, sondern hat ganz
einfach praktische gründe. wenn z.b. der nachtjob läuft, dann werden die dateien
auf der maschine kräftig umgekrempelt und sind somit im zugriff des nachtjobs.
wenn sich nun z.b. ein kollege anmeldet und die auftragsbearbeitung
startet, werden verdammt viele dateien mitgeladen, die gerade vom
nachtjob bearbeitet werden. und dann knallt es!!! das liegt auch daran,
daß wir noch viele alte IBM 36´er programme nutzen.
also ganz simpel: programme und dateien, die gerade im nachtjob
von einer sicherung oder vom nachtjob benutzt werden, dürfen von keinem
anderen programm oder user angefasst werden!!!
trotzdem danke für deine mühe!
@frank kaune:
ehrlich gesagt versteh ich das nicht so ganz, wie du das meinst.
"mit den jobwarteschlangen auf den arbeitsstationen arbeiten"?
eine neue jobwarteschlange erstellen?
ich bin mir nicht so ganz sicher, was das bringen soll. die jobwarteschlangen
sind bei uns in der regel leer. die meisten jobs können parallel ablaufen.
solange ein job in der jobwarteschlange steht, wird er ja nicht ausgeführt.
wenn die sicherung gestartet wird, läuft das programm nicht submitted, sondern im vordergrund
auf dem bildschirm.
wenn nun ein anderer user seinen bildschirm anmacht, stellt er die verbindung zum system her und bekommt
ein anmeldebild. der user meldet sich mit seinem namen und kennwort an, daß startprogramm wird geladen und
er kommt dann automatisch zu seinem hauptmenü. und von dort aus sind alle
programme direkt verfügbar. auch wenn die sicherung läuft. er braucht
dann nur irgendeinen menüpunkt anzuwählen, und schon kann es knallen.
jetzt versteh ich da nicht soganz, wie man das mit den jobwarteschlangen regeln kann.
am einfachsten wäre es echt, jeden bildschirm per rpg oder cl programm
abzuhängen. man müß nur den befehl "wrkcfgsts *dev ...." mit den parametern in ein programm einbinden. jeder bildschirm
würde dann so vom system getrennt. automatisch.
mein kollege ist rpg programmierer, aber den befehl, wie man per rpg programm bildschirme abhänden kann, kennt er leider auch nicht.
wenn du den befehl kennst, oder einen vorschlag hast, wie man das
mit rpg regeln kann, würde uns das schon weiterhelfen.
vielen für deine mühe.
gruß seb.
Mit Jobwarteschlange meinte ich nur, das im laufenden Betrieb, wenn das System eine Sicherung oder sonst was fährt und keine Dateizugriffe erfolgen sollen, die aktuellen Job's an den angemeldeten Stationen eben in der Schlange stehen bleiben!
Ein Anmelden eines neuen Terminals müßte man natürlich zusätzlich verhindern! Ich kann mich erinnern das wir in der Fa. wo ich damals war, so etwas hatten.
Von RPG aus die Bildschirme abhängen, geht meines Wissens nach auch nur wenn man auf einen CL Befehl zugreift, habe hier aber auch nur noch eine Kurzreferenz von CL!
SIGNOFF - meldet einen ab!
PWRDWNSYS - schaltet das System ab
in wie weit, man diese Befehle jetzt noch parametrisieren kann, weißt du bestimmt eher!
@frank kaune:
achso, jetzt versteh ich dich erst.
ja klar, solang die sicherung läuft, kann man ja alle jobwarteschlangen solange anhalten. die wichtigste ist bei uns eh nur die "qbatch". die anderen werden kaum genutzt.
ist jetzt nur die frage, ob unsere programme grundsätzlich erst in die jobwarteschlange gestellt werden, oder ob die sofort gestartet werden.
bleibt dann nachher nur die frage, in wie fern un din welcher reihenfolge man die aufgelaufenen jobs dann freigeben kann und in welcher reihenfolge, ohne das sich programme gegenseitig stören. bei unsern alten er programmen ist das nömlich immer so ein problem.
allerdings glaube ich kaum, daß mir die befehle pwrdwnsys und signoff weiterhelfen.
die parameter, mit denen man die befehle starten kann, sind mir bekannt, aber pwrdwnsys wäre tödlich. das schaltet die komplette as400 ab!!!! und das ist ja nicht sinn der sache ;-)
mit signoff könnte man zwar was machen, aber nachdem der befehl ausgeführt wurde, hat der user wieder sein anmeldebild da und versuchts erneut. und schon haben wir das problem wieder.
am ehesten würde uns der befehl wrkcfgsts weiterhelfen, da mit damit jeden bildschirm wirklich abhängen kann, sodaß er user erst gar kein anmeldebild bekommt. aber das in ein programm einzubinden ist das problemchen.
aber ich werd mit chefchen morgen nochmal drüber quatschen. denn deine idee, die jobwarteschlangen anzuhalten ist gar nicht so übel, WENN denn die jobs bei uns grundsätzlich erst darein gestellt werden. aber das kann ich erst morgen in erfahrung bringen.
mir fällt aber grad noch was anderes ein.... könnte man nicht auch per cl oder sonstwas, eine bestimmte art benutzerprofile deaktivieren? und nachher wieder aktivieren?
aber ich glaube da stehen wir vor dem gleichen pratkrischen problem wie mit den bildschirmen....
also danke nochmals. wenn du noch ideen hast, her damit :-)
gruß seb.
hi,
versuch's doch nochmal mit deiner Frage hier:
www.as400-forum.de
oder gleich in der NG:
comp.sys.ibm.as400.misc
da finden sich bestimmt die CL Crack's :-)
hey cool, ich wußte nicht, daß es da ein forum für gibt.
danke für die info.
leider funktioniert dein 2ter link nicht....
thx seb.
Tippfehler, es muß heißen:
news:comp.sys.ibm.as400.misc
Jetzt weiss ich auch, warum sich meine Firma für Tandem-Systeme und nicht für den "Marktführer" IBM entschieden hat !
Solche Probleme stellen sich auf unserem System nicht !
Habe auch schon gehört, daß der Wartungsumfang für IBM Systeme ziehmlich hoch sein soll !
Unsere Kiste läuft manchmal 1-1,5 Jahre durch und nur zum Releasewechsel wird neu gestartet. Selbst wesentliche Hardwarekomponenten (ausser CPU-Board und RAM) werden im laufenden Betrieb gewechselt(Controler, HD's Lüfter, Netzteile usw.)
Die AS/400 ist ja auch für ein ganz anderes Marksegment gedacht, als ein Tandem-System!
@repi:
nagut, ich kenne dieses tandem system nicht, aber ein grund, warum sich unsere firma damals für die as400 entschieden hat, ist die zuverlässigkeit, und die stabilität.
os400 ist wohl eins der sichersten betriebssysteme überhaupt. bevor wir vor 2 jahren unsere jetzige 620er bekommen hatten, hatten wir 9 Jahre lang eine as400 modell D45. und in diesen 9 jahren gab es nur einen wirklichens systemausfall. und zwar fuhr die kiste ohne vorwarnung einfach im laufenden betrieb runter, weil sich einer der lüfter verabschiedet hat. mehr nicht. sonstige probleme hatten wir noch nie.
mal abgesehen davon, als sich mein chef mal fürchterlich vertan hat, aber wenn man zu viele rechte hat, kann das mal passieren, wenn man nicht aufpasst.
also ich persönlich arbeite jetzt richtig seit ca. 3 jahren mit der as400. bin also noch neuling, aber ich sachen stabilität kann ich mir echt nichts besseres vorstellen.
leider gibts das betriebssystem nicht für den pc ;-)
der wartungsumfang soll hoch sein? kann ich nicht bestätigen. wir haben stinknormale wartungsverträge. wenn mal was dran sein sollte, kommen die innerhald weniger stunden. und in den 3 jahren, wo ich jetzt intensiver mit der maschine arbeite, war noch nie was dran.
und angeblich soll das mit der alten D45 auch nicht viel anders gewesen sein.
aber wo kann ich was über das tandem system erfahren? würd mich ja auch mal interessieren.
gruß seb.