View Full Version : wieviele Sätze gehen wirklich in ein Member ?
... die message geht an QSYSOPR und der muss das toppen. Kurios finde ich, dass die extends scheint's unter diversen Releases nicht stimmen.
D*B
Oder die Beschränkung nur ein Vorschlag ist und Vorschläge müssen ja nicht befolgt werden.
@Fuerchau: es kommt ja bei 190'000 die Meldung, dass die Datei voll ist. Also keine Sicherheitslücke. Das habe ich nicht ganz genau beschrieben.
@BenderD: die extents stimmen in diesem Fall auch. 3 wurden beim CRTPF erstellt und die 100 wurden dazugegeben, weil ich dies als Antwort auf die Meldung eingegeben haben. Damit sinds 103.
---> alles roger ....
Wenn man ganz an den Anfang dieses issues schaut, scheints bei der Antwort 9999 ein Problem zu geben ????
@Fuerchau: es kommt ja bei 190'000 die Meldung, dass die Datei voll ist. Also keine Sicherheitslücke. Das habe ich nicht ganz genau beschrieben.
@BenderD: die extents stimmen in diesem Fall auch. 3 wurden beim CRTPF erstellt und die 100 wurden dazugegeben, weil ich dies als Antwort auf die Meldung eingegeben haben. Damit sinds 103.
---> alles roger ....
Wenn man ganz an den Anfang dieses issues schaut, scheints bei der Antwort 9999 ein Problem zu geben ????
... nicht nur da:
[SIZE=1][FONT=courier new]Teildateibeschreibung
Größe der Teildatei SIZE
Anfangsanzahl der Sätze . . . . . . . . : 10000
Satzanzahl für Erweiterung . . . . . . : 1000
Maximale Anzahl Erweiterungen . . . . . : 32767
Aktuelle Anzahl Erweiterungen . . . . . . : 1950079
Satzkapazität . . . . . . . . . . . . . . : 1950089000
Aktuelle Anzahl Sätze . . . . . . . . . . : 32793064
Anzahl gelöschter Sätze . . . . . . . . . : 19
In der Datei sind bei 32793064 nur 19 gelöschte
wieso kam da die Meldung voll?
Ein (korrekter) RGZPFM kann danach nicht gewesen sein, der setzt auf den definierten Stand zurück.
D*B
Das ist doch ein Service vom System, daß man die Datei erweitern darf, wenn sie voll ist. So belegt sie am Anfang nur wenig Platz, darf sich ein paar mal strecken bis sie eine Grenze erreicht, die man aber verschieben darf. Wär 'ne feste Grenze besser, obwohl noch Platz da wär?
Da stellt man in die Datei ein, dass es maximal 3 Erweiterungen geben darf und das System erlaubt trotzdem 103?
Die Kapazität sollte auf 30000*3 + 100000 = 190.000 beschränkt sein.
... das ist kein Service, das sind anachronistische Altlasten. Mach mal ein CHGPF und setze eine Datei auf *NOMAX und sieh dir mal die Objektgrößen im Vergleich an.
D*B
Nun, das Ganze stammt wohl noch aus Diskettenzeiten, als der Platz noch rar war (daher das rar-Format;-)), um zu verhindern, dass eine Datei plötzlich keinen Platz mehr für Daten hätte.
Heute kann man damit ganz gut den Platz künstlich verknappen da man ja für alle Dateien den zukünftigen Platz (100Mio/Jahr für 10 Jahre) schon mal reservieren kann.
So etwas ähnliches hatte ich letztens im Microsoftforum bzgl. VM's und virtuellen Platten (VHD/VHDx/...).
Am besten sei es da doch tatsächlich, die VHD's in ihrer Größe fest anzulegen da die Datensicherung ja intelligent ein Disk-Image sichert und nicht belegten Platz komprimiert.
Dazu muss man allerdings wissen, dass das NTFS beim Löschen den Platz in der MFT (MasterFileTable) nur als frei markiert, den Platz allerdings nicht mit X'00' initialisiert. Nun, die Löschtools für die unwiederbringliche Datenlöschung von Dateien schreiben da i.d.R. sogar noch wilde Muster in die freien Bereiche.
Und schwups wunderte man sich, warum a) die Sicherung so lange läuft und b) der geplante Sicherungsplatz trotz Komprimierung nicht ausreichte.