SYSVAL AUTOVRT

[Fuerchau]

Nein.
Deshalb dauert der Boot ja auch so lange. Wobei der Client (Windows 11 und Vorgänger) da inzwischen stark optimiert hat und einiges verzögert im Hintergrund erledigt.
Früher gabs sogar Bootoptimizer (Window 98), bei XP gings schon besser.
Dieser hat ein Ladeprotokoll beim Booten erstellt um anschließend durch
- verschieben der Dateien auf dem Laufwerken zur schelleren Erreichbarkeit.
- berechnen der Bootfolge, also was zuerst oder später geladen wird
- u.v.m.
einen schnelleren Start zu zaubern.

Nach jeder Softwareinstallation/-update war das zu wiederholen um einen verträglichen Start zu haben. Ohne das konnte ein Entwicklungsrechner schon mal mehrere Minuten benötigen, bis endlich der Logonschirm kam.
Die heutigen Rechner sind da eh schneller und z.B. im Taskmanager kann man Apps für verzögerten Start einrichten.
Mein Rechner benötigt ca. 30-45 Sekunden bis zum Logon. Mein Kundenlaptop schafft das in 20 Sekunden, da ist allerdings ja außer Office, ACS und RDi nichts drauf.

Auch die IBM i muss beim Booten so einiges tun, bis denn der letzte Bildschirm online ist.
Da sind tote Jobs noch das kleinste Problem.

[Pikachu]

Wer fährt seinen Computer heutzutage immer noch jeden Tag brav herauf und herunter? Das dauert doch immer so ewig. Was bringt das? Außer beim System Aktualisieren.

[Fuerchau]

Ich;-). Immerhin verbrauchen Laptop (I7, 17" mit NVidea Graphik ca. 250W) und Bildschirm (Breitwand, 100W) gut 350W/Stunde.
Wenn diese also 10 Stunden aus sind, macht das 3500W, bzw. 3,5KW.
Aufs Jahr bei 365 Tagen sind das 1277,5 KW!
Beim derzeitigen Stromtarif von 32,4 Cent sind das immerhin auch schlappe 414€.
Die kann man dann eher für die Rente anlegen;-).

Nur meinen Fernseher und AVR lasse ich im Standby, trotz gegenteiliger Empfehlung;-).
Solange die Hersteller nicht alle Einstellungen auf einen nicht flüchtigen Speicher schreiben, macht das nämlich keinen Sinn. Ich habe nämlich keine Lust, nach 2-3 Tagen Kurzurlaub , oder auch mal länger, alle Settings zu wiederholen. Früher gabs da mal EEProms, die wohl zu teuer sind. Jetzt tuts wohl ein Kondensator, der allerdings nur wenige Tage hält.

[Pikachu]

Gibt’s unter Unix oder Linux oder anderen Betriebssystemen nach einem Neustart auch Jobs oder Prozesse oder wie das da heißt von vor dem Neustart oder gibt’s sowas nur unter IBM i mit Jobs im Status JOBQ oder OUTQ?

[Fuerchau]

OUTQ eher nein. Wobei z.B. im Windows-Printserver in der Warteschlange durchaus noch Ausdrucke warten können. Das regelt aber der Prozess "PrintQueues".

Eine JOBQ ist im Windows mit Aufgabenplanung gleichzusetzen und in Unix mit cron-Tables.
Das sind halt wartende Jobs, die irgendwann dran, aber noch nicht gestartet sind.
Eine JOBQ (mit Subsystemen) direkt ist mir nicht bekannt, es gibt da aber bestimmt genug Werkzeuge, die sowas auch wieder anbieten.

OUTQ ist ein Fall der IBM i, da dort halt Jobs geparkt werden, die noch Ressourcen haben, i.W. wartende Joblogs oder eben Spools.

Im Windows/Linux sind nach dem Neustart alte Prozesse erst mal weg, im Gegensatz zu Hibernate oder Standby.
Allerdings kann es da auch jede Menge Schrott im System geben, da es keine automatischen Aufräumprozesse gibt. Diese muss man selber anstoßen.
Z.B. Plattenbereinigung und Löschen von %TEMP%-Verzeichnissen, da viele Programme vergessen hinter sich aufzuräumen.
Das währe ähnlich den Bereinigungsaufgaben der IBM i.

Temp's gibt es auch gerne bei der IBM im IFS/PASE.

Windows ist da besonders schlimm, da es viele Standorte von Schmutzdaten gibt:
%TEMP%, %APPDATA%, %LOCALAPPDATA%, %DriverData%, %ProgramData%.
Zusätzlich noch im Systemverzeichnis von Windows.

[Pikachu]

Das erklärt warum IBM i alle Jobs (wegen Status JOBQ oder OUTQ) in permanente Objekte schreiben muß aber andere Betriebssysteme bei denen nach einem Neustart sowieso alle Jobs oder Prozesse oder wie das da heißt weg sind dies nicht machen müssen!?

[Fuerchau]

JOBQ sind nicht gestartete sondern geplante Jobs und daher als Objekte auch sichtbar.

Das hat auch den Effekt, dass ein aktiver Job eine JOBQ bremst und nach dem Neustart dann die Folgejobs noch ausgeführt werden.
Wenn z.B. sog. Nachtjobs in einer JOBQ durch einen wartenden Job (DLYJOB) die Queue anhält und das System neu gestartet wird, dass die Folgejobs dann plötzlich losrennen.
Das ist schon passiert, dass durch Stromausfall und Wiederanlauf am Morgen die Subsysteme wieder beendet wurden und die Datensicherung anlief.

Im Windows z.B. gibts je Aufgabe die Einstellung: falls der Job nicht gestartet werden konnte, dann gar nicht ausführen.

Und trotzdem finde ich die IBM i immer noch am besten.

[Pikachu]

Im WRKJOBSCDE gibt's *SBMRLS, *SBMHLD und *NOSBM.

[Fuerchau]

Ja, aber manche machen einen Job in eine QUEUE mit
DLYJOB RSMTIME(180000)
und submitten alle Folgejobs über Tag in diese Queue.
Ab 180000 werden diese Jobs dann alle ausgeführt.
Mit scheduled Jobs funktioniert das dann so nicht.
Vergleichbar ist das mit HLDJOBQ, SBMJOB's in die Queue und um 180000 einen Scheduled Job mit RLSJOBQ.

Vorteil: die Jobs für den Abend sind dynamisch und müssen nicht kompliziert irgendwo definiert werden.

[Pikachu]

Wobei ein Job selbst kein Objekt in IBM i ist aber trotzdem über Neustart-Grenzen hinweg im System vorhanden sein kann.

[Fuerchau]

Das ist nicht korrekt.
Ich habe mich halt mal früher mit der inneren Architektur befasst.
Alles ist i.W. eine Objekt. Ein Objektname besteht immer aus Typ, 2 Bytes, (Lib, File, usw.) einen Kontext (Lib), 30 Bytes und dem Namen, 30 Bytes.
Am besten sieht man es am Jobnamen, der ja 26 Stellen lang ist und als Objekt im Kontext der internen Jobliste steht. Jobs sind im SBS und der JOBQ als Objekte sichtbar und es gibt ja auch CMD's dafür.

Man kann per MI Objekte erstellen, die längere Namen als 10 Stellen haben.
Auch Groß/Klein-Schreibung ist möglich. Und man kann eben auch unsichtbare Objekte erstellen.
Es gibt z.B. USRSPC-API's für bestimmte Zwecke wie Listen aus API's füllen.
Als MI gibts da den Befehl CRTS, der eben einen vollen Namen haben darf.
Auch der Kontext darf da z.B. auch leer bleiben und man hat dann ein unsichtbares Objekt.
Per Pointer kann man sich mit eintsprechender Berechtigung durch das ganze System hangeln und in fremde Jobs und interne Strukturen reinschauen.

Aus der objektorientierten Programmierung ist die Definition so:
Ein Objekt ist eine Einheit, die spezifische Eingeschaften und spezifische Methoden hat.
Ein Objekt kann Eigenschaften und Methoden vererben.
Und genau dies tut die IBM i.

Das Basisobjekt hat den Typ, die Beschreibung und die Berechtigungen.
Alle anderen Objekttypen erben von diesem.
Usw. usf.;-).