Defragmentieren unter VMS war mit DFU 2.4 von ca. 1996 kein Thema mehr.
Letzte Version (2.7a) auf folgendem Link:
Index of /openvms/freeware/v50/dfu027a
Vorher haben wir Shadowsets "gebrochen" und nach einem INIT eines Members wieder zusammengefügt
Einige Files konnten auch mit Convert/FDL optimiert werden.
DEChub 90 mit DECserver 90M, TL und DECRepeater 90TS sind hier auch immer mal unter Strom.
Management mit HUBWatch/Clearvisn ist einsatzbereit.
TSM auf der VAX auch.
Bin in dem Thema nicht 100% drin, aber in unserem Betrieb haben wir zum Schluß einfach ein SET HOST/SNA x.x.x.x gemacht, um die IBM Session zu starten.
Da dürfte der DEMSA eigentlich kein Rolle mehr gespielt haben.
VAX 6k steht hier rum
Habe die zwei leider nicht zuhause, aber durfte bis 2017 an dem CI-Cluster arbeiten
Das TZ87 sollte die zumindest lesen können, habe ich so im Hinterkopf
Btw.
Habe im Dezember 2023
C-Kermit 10.0 Beta.07, 07 Dec 2022, for OpenVMS(tm) VAX(tm) auf meiner VS4000/60 unter VMS 7.3 compiliert .
Könnte davon natürlich auch ein Saveset machen und bereitstellen
Ich stelle mir gerade auch die Frage ob man das auch mit DECnis 500 oder 600 machen kann ??
Ich glaube das ging auch. Wir hatten den DECnis 500 im Betrieb für diesen Zweck eingesetzt.
Wurde aber sehr schnell durch einen DEMSA ersetzt und der lief jahrelang ohne Probleme.
TK Tapes lesen und sichern könnte ich auch.
Kopien erstellen sollte kein Problem sein, da noch etliche Bänder vorhanden sind.
Könnte auch Zugriff über meine VAX anbieten, um die Savesets z.B. als ZIP Daten zum download/ftp zugänglich zu machen.
On demand only!
Das Geraet, das zwischen den Welten (IBM/SNA <-> DEC/DECNET) vermittelt war keine VAX, es war eine DEMSA.
Auf dem Ding lief dann DecNET/SNA Gateway-ST, aus der Sicht der IBM eine 3174, aus der Sicht von DEC ein Knoten im Decnet, der div. SNA Service stellt.
Korrekt, so war das auch bei uns eingerichtet.
Mit $SET HOST / SNA wurde dann ein Session auf die IBM Rechner (bei uns AMDAHL) gestartet.
Ich habe nur die CPU und den 8MB Speicher "Rechts" - die beiden 16MB Bänke die ich habe nicht eingebaut.
Aber alleine ging es wohl auch nicht und mit 8MB sollte die KA655 doch eigentlich auch laufen, oder?
Dann wäre das Timing nicht das Problem, sondern die Architektur des Boards/der Speicherchips.
Vielleicht macht das Clearpoint Modul mit, wenn es als erstes oder als letztes Speichermodul gesteckt wird.
Doch, glaube schon, dass das einen Unterschied macht.
Och, vielleicht laufen mit der Zeit noch weitere Teile zu und es wird noch eine Maschine aufgebaut.
Und ein wenig Ersatz schadet auch nicht.
ansonsten die Entscheidung 3,7 VUPs mit 32MB oder 2,7 VUPs mit 40 MB.
Vielleicht ist das Clearpoint Teil kompatibel zum -A* ?
Ich denke auch, dass das Clearpoint Modul vom Timing nicht zur KA-655 passt.
Kann man an den Bausteinen ein Timing Aufdruck erkennen und mit denen auf dem MS650-B* vergleichen?
Vielleicht reicht ja schon ein Zweizeiler als externes Comfile für die VMSler:
type sd.com
$ set def 'p1'
$ set prompt="''f$directory()' > "
und dann SD == "@DKAX:[DIR]SD.COM"
Nicht perfekt aber ein Anfang
Durchaus möglich.
Die Gebiete waren eng umschrieben und nur bei Engpässen und Notfällen wurde ein Techniker in ein anders Gebiet geschickt.
Die Jungs waren aber auch sehr begeistert bei der Sache und haben eigentlich immer sofort reagiert und sich gegenseitig unterstützt.
Wir hatten Datenbanken auf Schadowsets verteilt und wochentliche reorgs durchgeführt, um dann mit shadow copies/backups den Platz zu optimieren.
Gleichzeitig haben wir die Zugriffe auf die Datenbank Files protokolliert, um die optimale Verteilung der Files auf die Kontroller und daran hängenden Platten zu finden.
Das alles an mehreren HSJ Controllern, die ja nette Firmware Utils haben, um die Performance zu beobachten.
Fürs Load Resistor Board war auch kein Platz mehr. Jedenfalls keiner, der mir gefallen hätte (3mm unter der Floppy oder der Harddisk?
Wenn das LR_Board noch nötig sein sollte gehört das dann nicht links über das Netzteil?
Ich hatte Achim Wilde und Klaus Bednorz als Techniker und einen weiteren aus Garbenheim, da fällt mir der Name auch nicht mehr auf Anhieb ein.
Die waren in Mittelhessen und im Raum Frankfurt tätig.
Wunderschönes Ergebniss.
Das macht Freude!
https://www.computerwoche.de/a/dec-verstaerkt-das-team-computing,1158410
Hinter einem passenden Raidcontroller geht das sogar online ohne shutdown.
HSD und HSZ Controller für DSSI oder SCSI Interfaces sind ja im Moment im Umlauf. 
Freue mich schon auf das Thema
Schade.
Die ganze Arbeit hat sich trotzdem gelohnt. VS mit SCSI Bootplatte und Tapes und CDROM laufen auch. 
auf einer der Freeware CDs gibt es auch das DFU 2.7 utility. Das kann so einiges unter anderm auch Dateien defragmentieren und gelöschte wieder herstellen.
Damit habe ich auch schon Files von Platten mit zerschossenem INDEX.SYS wiederhergestellt.
Meine Praxis früher, wenn möglich, Image Backup machen und zurückspielen. Gut wenn man eine zweite Platte hat. Dann weiss man auch, dass das Backup nutzbar ist.
Gegen Image Backups kommt aber nichts an.
>>> test 51
DKA1 ? >>> dka1:
Hat da die VS2000 nicht von sich aus DKA1 angeboten?
Vielleicht mal nur DKA1 in Großschrift und ohne ":" probieren
Manche Platten werden an meiner VS4k/60 am Bios Prompt mit allen LUNs angezeigt.
Die machen dann Mount verification errors.
Glaube die IBMs waren da häufige Kandidaten für sowas.
Denke das sind keine Processe, sondern bei Schreiboperationen werden Bereiche reserviert, die unter Umständen nicht vollständig gebraucht werden.
Habe in meiner aktiven Zeit auch nur set file/trunc benutzt, um diese Bereiche frei zu geben und sonst "sh dev d" benutzt, um die freien Blocks zu beobachten
mit set file/trunc [...]*.*.* kann man nicht benötigten Platz freigeben.
bei meiner VS4k/60 sind aber 1/129 in meiner Konfig das Minimum
Hat das evtl. jemand abzugeben ?
Und wer weiß warum ich das frage
verspüre eine Beule an üblicher Stelle nach diesem Kommentar
Ich denke das Problem ist die file allocation size von VMS.
eine Datei/Directory mit nur einem Block belegt je nach Setup deutlich mehr als benötigt.
Bei meiner VS4000 mit 72GB SCA Platte sind das 129 blocks pro directory:
VEST.DIR;1 1/129 18-NOV-2003 16:40:42.38
VMS03X.DIR;1 1/129 19-NOV-2003 19:04:13.61
VMS044.DIR;1 1/129 19-NOV-2003 19:04:58.57
VMS045.DIR;1 1/129 19-NOV-2003 19:05:53.71
VMS055.DIR;1 2/129 19-NOV-2003 19:06:16.75
VMS071.DIR;1 1/129 18-NOV-2003 16:41:02.57
VMS072.DIR;1 1/129 1-NOV-2023 02:05:19.23
VMS073LP.DIR;1 1/129 18-NOV-2003 18:08:32.16
VMSTAR.DIR;1 1/129 11-NOV-2003 01:50:28.10
