IBM führt für SPSS Statistics 32 unter macOS 27 einen möglichen Stillstand beim CSV-Export als bekanntes Problem. Sichern Sie zuerst das Originalprojekt und prüfen Sie den Fehler nur mit einer Arbeitskopie; migrieren Sie einen laufenden Forschungsworkflow nicht, bevor der konkrete Export verifiziert ist. IBM führt den Fehler in seiner Supportaufzeichnung.
Geeignet ist dieser Leitfaden für Forschende, deren CSV-Ausgabe hängt oder fragwürdig aussieht.
Auch Hochschul-Supportteams finden hier ein Verfahren, um Versionen, Reproduktionsschritte und Freigabegrenzen zu dokumentieren.
Zuletzt aktualisiert am 02.11.2026; geprüft anhand der IBM-Supportaufzeichnung und der IBM-Lizenzdokumentation. Die IBM-Aufzeichnung wurde am 12.10.2026 aktualisiert und war zum Prüfzeitpunkt nicht geschlossen. Den Eintrag und seinen Status finden Sie bei IBM.
[ SECTION_01 ] Was der bekannte CSV-Fehler aussagt – und was nicht
IBM bestätigt in der Supportaufzeichnung, dass SPSS Statistics 32 Classic in der dortigen Testumgebung unter macOS 27 ausgeführt wurde. Als bekanntes Problem nennt IBM, dass der Export nach CSV hängen bleiben kann. Daraus folgt weder, dass alle Installationen betroffen sind, noch dass jede Analyse-, Speicher- oder Exportfunktion ausfällt. Die Aufzeichnung dokumentiert einen bestimmten Fehlerfall, keine allgemeine Diagnose für einen konkreten Rechner.
Das ist für die Fehleranalyse wichtig: Ein hängender CSV-Export ist zunächst eine Beobachtung. Er beweist nicht, dass das Projekt beschädigt ist, dass die macOS-Installation fehlerhaft ist oder dass ein anderes Exportformat garantiert funktioniert. IBM nennt in der verlinkten Aufzeichnung keine allgemeine Ursache und keine garantierte Umgehung. Solange die Aufzeichnung keine bestätigte Korrektur ausweist, sollte auch kein bestimmtes Update als zugesicherte Lösung behandelt werden.
Vor jeder Änderung sind deshalb drei Fragen getrennt zu beantworten:
- Lässt sich das Projekt zuverlässig öffnen?
- Laufen die für die Fragestellung benötigten Analysen?
- Tritt der Stillstand speziell beim CSV-Export auf, und ist eine erzeugte Datei tatsächlich vollständig?
Diese Trennung verhindert, dass ein einzelner fehlgeschlagener Export vorschnell als Ausfall der gesamten Forschungsumgebung gewertet wird. Sie schützt zugleich vor einem riskanten Gegenfehler: eine fehlerhafte Datei weiterzugeben, nur weil sie nach dem Exportversuch im Zielordner liegt.
[ SECTION_02 ] Fehlerbild dokumentieren und Originaldaten schützen
Bevor der Export wiederholt wird, sollte das Team eine knappe, nachvollziehbare Fehlernotiz anlegen. Darin stehen die installierte SPSS-Version, die macOS-Version, das gewünschte Exportformat und die genaue Aktion, nach der die Anwendung nicht mehr reagiert. Ergänzen Sie, ob ein Fortschrittsdialog sichtbar blieb, ob die Anwendung beendet werden musste und ob eine Ausgabedatei angelegt wurde. Die Versionsangaben sind wichtig, weil IBM sein bekanntes Problem auf SPSS Statistics 32 Classic und macOS 27 bezieht; andere Kombinationen sind damit nicht automatisch geprüft. IBM dokumentiert die betroffene Kombination und den Exportfehler.
Gehen Sie anschließend in dieser Reihenfolge vor:
- Originalprojekt unverändert sichern. Erstellen Sie eine zusätzliche Kopie an einem freigegebenen Speicherort. Überschreiben Sie die einzige Arbeitsdatei nicht, um einen Exportversuch zu wiederholen.
- Arbeitskopie kenntlich machen. Vergeben Sie einen eindeutigen Namen und notieren Sie, welche Kopie für den Test verwendet wurde. Bewahren Sie die Ausgangsversion separat auf.
- Sensibilität prüfen. Entfernen oder ersetzen Sie identifizierende Angaben, bevor ein Projekt für eine Supportanfrage oder einen isolierten Reproduktionstest weitergegeben wird. Eine Kopie ist nicht automatisch anonym.
- Einen einzelnen Testlauf dokumentieren. Halten Sie Auslöser, gewählte Exportoptionen und sichtbares Ergebnis fest. Wiederholte Versuche mit wechselnden Einstellungen erschweren die spätere Zuordnung.
- Abbruchgrenze setzen. Wenn die Anwendung wiederholt hängt oder sich die Datenlage nicht sicher beurteilen lässt, beenden Sie die Versuche mit der Arbeitskopie und eskalieren Sie mit der Dokumentation. Wiederholen Sie keinen riskanten Vorgang mit dem Original.
Für eine Supportanfrage reicht häufig eine präzise Beschreibung des Ablaufs plus ein bereinigtes Minimalprojekt, sofern dessen Weitergabe institutionell zulässig ist. Geben Sie keine Rohdaten allein deshalb weiter, weil sie die Fehlersuche erleichtern könnten. Klären Sie bei personenbezogenen oder anderweitig geschützten Forschungsdaten zuerst mit der zuständigen Stelle, ob eine Übermittlung und die dafür genutzte Umgebung erlaubt sind.
[ SECTION_03 ] Projekt-, Analyse- und Exportverhalten getrennt prüfen
Ein aussagekräftiger Test verändert jeweils nur einen Teil des Ablaufs. Öffnen Sie zunächst die Arbeitskopie und kontrollieren Sie, ob Variablen, Fälle und relevante Einstellungen sichtbar sind. Führen Sie danach nur eine repräsentative, nicht destruktive Analyse aus, deren erwartetes Ergebnis bereits bekannt ist. Prüfen Sie anschließend, ob das Projekt wie gewohnt gespeichert werden kann. Erst dann testen Sie den CSV-Export separat.
Das Ergebnis lässt sich als Gegenüberstellung festhalten:
| Beobachtung | Aussagekraft | Nächster Schritt |
|---|---|---|
| Projekt lässt sich öffnen, Analyse läuft, nur CSV-Export hängt | Der Fehler ist auf den beobachteten Exportweg eingegrenzt; eine Ursache ist damit nicht bewiesen. | Exportoptionen und Reproduktionsschritte dokumentieren, Supportstatus prüfen. |
| Projekt lässt sich öffnen, aber eine bestimmte Analyse schlägt ebenfalls fehl | Es gibt mehr als ein beobachtetes Problem; der CSV-Eintrag allein erklärt es nicht. | Analyse, Eingabedaten und Fehlermeldung getrennt erfassen. |
| Speichern oder Öffnen schlägt bereits fehl | Der CSV-Fehler ist keine ausreichende Erklärung für den gesamten Zustand. | Keine weiteren Versuche mit der einzigen Projektdatei; Sicherung und Wiederherstellung prüfen. |
| CSV-Datei wird angelegt, Inhalt ist aber unvollständig oder unlesbar | Ein vorhandenes Ausgabedokument ist kein Nachweis für einen erfolgreichen Export. | Datei nicht als Lieferergebnis freigeben; mit einer verlässlichen Referenz vergleichen. |
Diese Einordnung beschreibt Testbeobachtungen, keine von IBM bestätigte Ursachenanalyse. Auch wenn nur der Export auffällig ist, bleibt offen, ob die konkrete Installation aus demselben Grund betroffen ist wie der Supportfall. Die IBM-Dokumentation zu Dateitypen und Speichermöglichkeiten hilft dabei, das gewünschte Zielformat von der Projektdatei zu unterscheiden. Sie bestätigt jedoch nicht, dass ein alternatives Format den dokumentierten Fehler behebt.
[ SECTION_04 ] CSV-Datei auf Vollständigkeit und Nutzbarkeit prüfen
Für die Abgabe oder Weiterverarbeitung zählt nicht, ob eine Datei vorhanden ist, sondern ob sie die benötigten Daten korrekt enthält. Öffnen Sie eine erzeugte Ausgabe zunächst in einer dafür freigegebenen Anwendung, ohne die Originaldatei zu verändern. Vergleichen Sie die Variablennamen und die erwarteten Fälle mit dem Projekt oder einer bereits verifizierten Ausgabe. Bei großen oder vertraulichen Datensätzen sollte die Prüfung nach den Regeln der Arbeitsgruppe erfolgen, nicht durch unkontrolliertes Kopieren in externe Werkzeuge.
Prüfen Sie dabei mindestens diese Punkte:
- Spalten und Zeilen: Sind die erwarteten Variablen und Fälle vorhanden? Ein abgeschnittener Export kann trotz Datei im Zielordner unbrauchbar sein.
- Fehlende Werte: Bleiben definierte fehlende Werte von gültigen Werten unterscheidbar? IBM beschreibt die Behandlung fehlender Werte in der Dokumentation zu Missing Values. Vergleichen Sie die Ausgabe mit der Bedeutung im Projekt, statt leere Felder automatisch als Fehler oder als fehlende Werte zu interpretieren.
- Trennzeichen und Textkodierung: Prüfen Sie, ob Felder in der Zielanwendung korrekt getrennt und Sonderzeichen lesbar dargestellt werden. IBM beschreibt Optionen für Textausgaben in der Dokumentation zu den Textoptionen des SAVE-Befehls. Die passenden Einstellungen hängen vom nachgelagerten Arbeitsablauf ab.
- Referenzvergleich: Stimmen ausgewählte Werte mit dem Projekt oder einer vertrauenswürdigen früheren Ausgabe überein? Prüfen Sie auch, ob Werte durch Trennzeichen, Dezimaldarstellung oder Textinterpretation anders eingelesen werden.
Geben Sie die Datei erst frei, wenn die Prüfung für den vorgesehenen Zweck ausreicht. Eine CSV-Datei kann formal lesbar sein und trotzdem für eine Analyse, Weitergabe oder Archivierung ungeeignet bleiben. Wenn keine verlässliche Referenz verfügbar ist, kennzeichnen Sie das Ergebnis als ungeprüft und verwenden Sie es nicht als bestätigte Datengrundlage.
[ SECTION_05 ] Entscheidung nach Risiko und Arbeitsbedarf
Die Wahl zwischen Weiterarbeit, Aufschub und Support hängt davon ab, wie zentral der CSV-Export für den aktuellen Forschungsablauf ist. Für eine interne Exploration mit gesichertem Projekt kann ein dokumentierter Test vertretbar sein. Wenn ein Datensatz zeitnah als CSV an Kooperationspartner oder für einen festgelegten Analyseschritt übergeben werden muss, sollte eine nicht verifizierte Umgebung nicht stillschweigend zur Produktionsumgebung werden.
| Option | Vorteil | Risiko oder Grenze | Bewertung |
|---|---|---|---|
| Mit einer Arbeitskopie testen | Liefert nachvollziehbare Hinweise zum konkreten Fehlerbild. | Bestätigt keine allgemeine Fehlerursache und garantiert keine vollständige Ausgabe. | Hoch, wenn Datenkopie und Referenz vorhanden sind. |
| macOS 27 sofort für alle Arbeitsplätze freigeben | Einheitlicher Zielstand im Team. | Ein bekannter Exportfehler kann einen kritischen Ablauf treffen; ohne Reproduktion fehlt eine belastbare Freigabegrundlage. | Niedrig, solange der erforderliche CSV-Workflow ungeprüft ist. |
| Bestehende, bereits verifizierte Arbeitsumgebung vorläufig beibehalten | Vermeidet einen ungeprüften Wechsel im laufenden Projekt. | Kann die gewünschte Umstellung verzögern und löst den Fehler in der neuen Umgebung nicht. | Hoch bei einem kritischen, zeitgebundenen Export. |
| IBM oder den institutionellen Support einschalten | Ermöglicht eine dokumentierte Klärung des konkreten Falls und des aktuellen Status. | Eine Anfrage ist keine Zusage für eine sofortige Lösung oder ein bestimmtes Veröffentlichungsdatum. | Hoch, wenn der Fehler reproduzierbar oder die Datenabgabe blockiert ist. |
Die Bewertungen beziehen sich auf das Ausfallrisiko im beschriebenen Arbeitsablauf, nicht auf allgemeine Softwarequalität. Für eine Migration gilt daher eine klare Freigabebedingung: erst die tatsächlich benötigten Abläufe mit einer Kopie prüfen, dann Ergebnisse gegen eine Referenz abgleichen und erst danach den Einsatz für kritische Exporte beschließen. Wenn die Abgabe unmittelbar bevorsteht und dieser Nachweis fehlt, ist Aufschub sicherer als eine ungetestete Umstellung.
[ SECTION_06 ] Remote-Test, Lizenz und Forschungsdaten
Ohne lokalen Mac kann ein entfernter Mac ein Kandidat für einen isolierten Reproduktionstest sein. Er ist aber keine zugesicherte Lösung für den IBM-Eintrag: Ein anderer Rechner hebt einen dokumentierten Softwarefehler nicht automatisch auf. Vor dem Test muss die Hochschule klären, ob die Lizenz die konkrete entfernte Nutzung erlaubt, ob eine Einzel- oder Mehrbenutzung vorgesehen ist und welche Regeln für Forschungsdaten gelten.
IBM beschreibt die Lizenzierung und ersten Schritte für SPSS Statistics 32. Für die konkrete institutionelle Konstellation sind außerdem die IBM-Anleitungen für autorisierte Einzelplatzlizenzen und Concurrent-Lizenzen relevant. Diese Unterlagen ersetzen nicht die Prüfung des Hochschulvertrags. Insbesondere dürfen technische Zugriffsmöglichkeiten nicht mit einer erteilten Nutzungsberechtigung gleichgesetzt werden.
Vor der Übertragung einer Projektkopie sind deshalb die zuständige Lizenzverwaltung, die Vorgaben des Projekts und die Datenschutzverantwortlichen einzubeziehen. Bei sensiblen Daten sollte der Test mit synthetischen oder wirksam bereinigten Daten erfolgen, wenn das zur Reproduktion ausreicht. Ist eine solche Bereinigung nicht möglich oder nicht freigegeben, gehört der Test in eine institutionell zugelassene Umgebung. Für die Risikoprüfung zählen auch Zugangskontrolle, Speicherort, Löschvorgaben und die Frage, wer die Testdatei einsehen kann.
Wenn die institutionellen Voraussetzungen erfüllt sind, lässt sich ein Remote-Test wie ein lokaler Test dokumentieren: dieselbe bereinigte Projektkopie, dieselben Exportoptionen und ein Vergleich mit einer verlässlichen Referenz. Das Ergebnis gilt dann für genau diese geprüfte Kombination. Es ist weder ein allgemeiner Kompatibilitätsnachweis noch ein Beleg dafür, dass der Fehler dauerhaft behoben wurde.
[ SECTION_07 ] Versionswechsel und nächste Prüfung
Ein Update von SPSS oder macOS sollte den Test nicht ersetzen. Prüfen Sie vor einem erneuten Versuch den aktuellen Status des IBM-Eintrags und die zugehörigen Versionshinweise. Die Supportaufzeichnung bezeichnet den CSV-Fehler als bekanntes Problem und war zum oben genannten Prüfzeitpunkt nicht geschlossen. Ein künftiger Plan oder ein erwarteter Versionsschritt ist keine veröffentlichte Korrektur; IBM muss eine tatsächliche Änderung oder einen behobenen Status bestätigen, bevor die Arbeitsgruppe davon ausgeht.
Nach einem relevanten Update wiederholen Sie den Test mit einer neuen Arbeitskopie und denselben dokumentierten Prüfschritten. Das macht den Vergleich aussagekräftiger als ein spontaner Versuch mit veränderten Daten oder Einstellungen. Halten Sie fest, ob sich das Verhalten geändert hat, ob die Datei vollständig ist und ob die nachgelagerte Anwendung sie korrekt verarbeitet. Erst dieser Nachweis kann eine Freigabe für den konkreten Ablauf stützen.
Wer keinen eigenen Mac für eine getrennte Prüfung bereitstellen kann, sollte zunächst die erlaubte Lizenznutzung und die Datenfreigabe klären. Ein gemischtes Labor mit Windows- oder Linux-Rechnern kann zwar viele Forschungsaufgaben abdecken, ersetzt aber keinen Test der benötigten macOS-Konstellation. Ein ausgeliehener Arbeitsplatz wiederum kann zeitlich knapp oder nicht für sensible Daten freigegeben sein. Wenn ein gesonderter Mac-Test zugelassen ist, kann ein zeitweiser Remote-Zugang eine weitere Möglichkeit sein; er beseitigt jedoch weder Lizenzauflagen noch den bekannten Fehler. Informationen zu einem Remote-Mac-Zugang von NOVAKVM sollten daher erst nach diesen institutionellen Prüfungen in die Entscheidung einfließen.
Für einen kurzen, isolierten Test kann ein Remote-Mac-Zugang organisatorisch einfacher sein als ein zusätzlicher Kauf, sofern Nutzung, Daten und Lizenz freigegeben sind. Er eignet sich nicht automatisch für jedes Projekt: Wer dauerhaft stark ausgelastet arbeitet, physische Anschlüsse benötigt oder Forschungsdaten nicht außerhalb einer zugelassenen Umgebung verarbeiten darf, sollte eine institutionelle oder lokale Lösung vorziehen. Wer einen dauerhaft verfügbaren lokalen Rechner benötigt, kann als Alternative auch die Anschaffung eines Mac mini prüfen. Wenn dagegen nur eine bereinigte Projektkopie für die Fehlerreproduktion fehlt und die Freigaben vorliegen, prüfen Sie die Rahmenbedingungen von NOVAKVM, bevor Sie die Testumgebung einrichten. Der nächste sinnvolle Schritt bleibt in jedem Fall derselbe: Fehlerstand dokumentieren, Ausgabe verifizieren und erst danach über den Einsatz für kritische Forschungsdaten entscheiden.