View Full Version : Welche Aufrufe lösen einen zusätzlichen Thread aus?
Ist der Kunde u.U. das Computermuseum in München?
Zumindest haben die mit Hackerangriffen überhaupt kein Problem, da die Hackersoftware auch mindestens XP-SP3 voraussetz.
Und was QDLS angeht: Wie kommen die dann noch mit den 8.3-Namen zurecht;-)?
Und was QDLS angeht: Wie kommen die dann noch mit den 8.3-Namen zurecht;-)?
Das ist richtig pfiffig gelöst: Dateiname = Programmname (8-stellig) + '.ZIP'
Die Jobs werden in eine JOBQ gestellt, in der nur ein Job zulässig ist... mannmannmann... :rolleyes::rolleyes:
Pfiffig? Da dürfen Programmnamen ja auch nur 8 statt 10 Zeichen lang sein. Was für eine Verschwendung.
Damit bekomsmt du zwar QDLS nicht weg, aber es läuft dann auch:
Erstelle ein neues Subsystem und schiebe die Jobqueue dahin.
Anschließend änderst du das Subsystem auf single threading:
https://www.ibm.com/support/pages/subsystem-single-or-multiple-threads
(https://www.ibm.com/support/pages/subsystem-single-or-multiple-threads)
...das 'pfiffig' war ironisch von mir- ich finde die Vorgehensweise dezent angestaubt ;-)
Naja- es ist eben eine über Jahre gewachsene Ansammlung an Programmen, die eben noch den SNDDST verwenden (seit welchem Rel. gibt´s den SNDSMTPEMM?).
Das von dir verlinkte Dokument hatte ich schon gefunden- es hilft mir nur leider nicht:
Die problematischen Jobs laufen im SBS QBATCH mit der QDFTJOBD. Hier wurde von uns bezüglich Multithreading nix verändert- somit sollten die Jobs eigentlich als Singlethread laufen.
In diesen Jobs werden SQLs aufgerufen- und dort entstehen (sobald der Sysval QQRYDEGREE abweichend zu *NONE gesetzt ist) mehrere Threads (SQL-Optimizer).
Das SBS ist dabei nach wie vor als Single definiert.
Aber ich glaube ja eher dass es den Jobs in einem SBS völlig egal ist, ob das SBS als S oder M definiert ist. D. h. ich glaube nicht, dass ich einen Job mit "CALL QWTMAINT PARM(1 7 SBS BIB S)" dazu zwingen kann als Singlethread zu laufen.
Das bleibt eben auszuprobieren. Wenn das Subsystem dies verweigert, dürfte auch SQL das nicht dürfen.
Aber da kann auch eine QAQQINI helfen:
PARALLEL_DEGREE ist eine einstellbare Option.
Du kannst im SBSD eine zusätzliche Subsystemlib einstellen und dort eine QAQQINI erstellen.
Dann würde Batch eben nicht von der Parallelausführung im SQL profitieren, der Dialog und andere SBS' schon.
Es gäbe noch eine interessante Variante:
SQL im Servermode:
http://www.redbooks.ibm.com/abstracts/tips0658.html
Du brauchst also nur das API QWTCHGJB() mittels Vorlauf-Programm aufzurufen und SQL's werden in einem Serverjob gehosted. Das habe ich ganz früher mal ausprobiert (bevor das mit den ACTGRP's ging) und funktioniert reibungslos.
Es gibt doch bestimmt ein zentrales Service-/Programm, dass von jedem Programm initial aufgerufen wird. Dann kann man dies darüber gut steuern.
Das Mulitthreading findet dann im Serverjob statt.
Eine separate QAQQINI für diese Jobs scheint mir eine prima Idee zu sein.
Momentan können wir zwar mit einem QQRYDEGREE *NONE gut leben, ich werde aber mal rein vorsorglich diese Jobs in ein separates SBS verlegen.
Merci
Ede
holgerscherer
23-09-20, 13:17
es arbeitet heute auch keiner mehr mit Win3.1 Win95, Win98, WinXP
Das ist eine mutige Aussage ;-)
Siehe oben;-) => ggf. XP-SP2.
Es verwenden sicherlich noch viele Behörden XP-Rechner. Da die ja alle sowieso nicht ins Intenet dürfen, reicht das immer noch und die alten 486er rennen wahrscheinlich auch noch.
Wobei ich mich frage: Untestützt die IBM i noch PC/Support?