Fehlermeldung wegen ungültiger ZANBE findet man im Protokoll von smgr (DebugLevel=0).
Vom Zeitraum 20.+21.5.2010 habe ich keine Protokolle von Serco.

Aus einem früheren Protokoll:
02/11/10 03:44:13.957 smgr invalid record:'0006324301 0010.02.10 18.31 30.00 36.22 009'
02/11/10 03:44:13.957 smgr flg=00002, err:ZANBE,

Datensatz:
'0006324301 0010.02.10 18.31 30.00 36.22 009'

BDEGR

INFO1-INFOA

ZMAIL

ZDGBE

PINC

ZANBE

ZAUVE
++++++++—————————————————————-
++++++++——————————
ZAUSW (8 Stellen)
ZANBE genauer angeschaut:
'0006324301 0010.02.10 18.31 30.00 36.22 009'
……….^^

Ab Build 4.61 bereitet spoll die Sätze hex-numerisch auf, sofern terminal.ini, [spoll], IllZanbeNum=1 Im ACS-Modus werden von spoll die ungültigen ZANBE auf hex FF gesetzt (Build 4.62 = aktuell).

Es gibt bei Serco 2 Fehlersituationen:
„ “ (2x blank) wird im spoll je nach Einstellung durch den Wert „IllZanbeDefault=01“ ersetzt „ 1“ oder „1 “ wird durch spoll nicht verändert und im smgr abgelehnt.
IllZanbeDefault:
# Verhalten bei Stammsaetzen mit ungeeignetem ZANBE-Feld
# IllZanbeFlag: 0..2, default=0
# 0 : ZANBE bleibt unveraendert
# 1 : wird durch IllZanbeDefault ersetzt, wenn gesetzt
# 2 : Datensatz wird als fehlerhaft aussortiert
# IllZanbeDefault: 2stellig numerischer Wert

Bei 2xblank ist die Situation ja eindeutig, es wird das Default-ZANBE eingetragen, smgr ist zufrieden. Was aber bei Zahl+Blank machen? Numerisch (genauer Hex) analysieren (atoi bzw. sscanf) und dann korrekt reinschreiben? Scheint mir am sinnvollsten.

Gleich noch, damit es rund wird: was tun bei völlig irregulären ZANBE?
- vom spoll aussortieren
- durch IllZanbeDefault ersetzen
- durch FF ersetzen

Tests:(Ausgaben DebugLevel >=1)
- ACS-Mode
06/01/10 18:31:25.016 spoll zausw (00000005) zanbe ( a) nonhex, replaced by FF (ACS) 06/01/10 18:31:25.016 spoll zausw (00000021) zanbe (xy) nonhex, replaced by FF (ACS)

- kein ACS, [spoll], IllZanbeNum=0 wobei „(…)“=kompletter Stammsatz 06/01/10 18:05:13.016 spoll zausw (00000004) zanbe ( ) illegal (…)
06/01/10 18:05:13.016 spoll change zanbe ( ) → (01) default
06/01/10 18:05:13.016 spoll zausw (00000005) zanbe ( a) illegal (…)
06/01/10 18:05:13.016 spoll change zanbe ( a) → (01) default
06/01/10 18:05:13.016 spoll zausw (00000021) zanbe (xy) illegal (…)
06/01/10 18:05:13.016 spoll change zanbe (xy) → (01) default

- kein ACS, IllZanbeNum=1
06/01/10 18:06:06.016 spoll zausw (00000005) zanbe ( a) nonhex, replaced by (0A)

smgr erlaubt Hexwerte bei ZANBE und produziert diese Werte auch, bei ACS wird die ZANBE vom smgr aus acsper stringmäßig kopiert ohne Prüfung.

Im Stammsatz (also von der perso1) wird im smgr nur akzeptiert „ “ (also 2xBlank) oder „vollnumerisch“, also 00..99, sonst wird der Stammsatz im smgr abgelehnt.

Lustigerweise akzeptiert smgr aber z.B. ein „1f“ für die ZANBE, wenn sie in acsper.dat steht und würde das auch in den Stammsatz eintragen.

Ich muß also nur die Datenübernahme perso1 auf Hexwerte für ZANBE erweitern.

Ein Zusatzfeature eingebaut: Mit „smgr ?“ oder „tmgrc ?“ kann man smgr ja veranlassen, ein „stamm.d/mr.dmp“ zu schreiben, wo man zu jedem Terminal den Status des Stammsatz an diesem Terminal sehen kann. Zusätzlich habe ich jetzt einfach die Stammsatzdaten (also die Y0-Sätze) für das jeweilige Terminal drangehängt. Da kann man also rasch analysieren, was der smgr produzieren würde, ohne es erst mühsam im log rauszufieseln.

Beispiel: Master records in terminal format

Terminal 0001/05/30: STV=2
E^ Y000000020041fFFFF00
……………^^ hier übrigens der Test mit Hex-ZANBE (acsper.dat)
…………………..|||||||+|||||||+|||||||+|||||||+ Salden sind leer, wegen „InfoComposit=„
E^ Y0000000300404FFFF00 « Zeilenende
E^ Y0000000400401FFFF00
E^ Y0000000500401FFFF00

Terminal 0002/01/10: STV=4
AJ Y0000000100001FFFFFFFF00 25.49- 25.00 0.00 0.00 00000000000
AJ Y0000000200005FFFFFFFF00 25.49- 25.00 0.00 0.00 00000000000
AJ Y0000000300007FFFFFFFF00 21.49- 25.00 0.00 0.00 00000000000
AJ Y0000000400001FFFFFFFF00 25.49- 25.00 0.00 0.00 00000000000
AJ Y0000000500001FFFFFFFF00 25.49- 25.00 0.00 0.00 00000000000

Terminal 0003/01/11: STV=8, masterrecords redirect to terminal 0002/01/10

Terminal 0004/01/12: STV=8, masterrecords redirect to terminal 0002/01/10