write PrtF-Satzformat obwohl Fehlerebezugszahl an. Normal?

[votch]

Hallo zusammen,

ich habe aktuell ein(in meinen Augen) sehr seltsames und gleichzeitig dringendes Problem...

In ein bestehendes und sehr umfangreiches Druck-Prg aus dem letzten Jahrtausend soll ich eine Erweiterung einbauen.

Das Prg erstellt diverse Listen und Etiketten mit unterschiedlichsten Angaben aus über 50 PF's in einer mir bisher unbekannten Art und Weise...

Der Überlauf wird weder über eine Bezugszahl in den F-Bestimmung noch über einen Zeilenzähler gesteuert, sondern über eine Fehlerbezugszahl beim write des Druckformats. Da das Programm über10.000 Zeilen hat, habe ich meine Programmierung aus Gründen der Übersichtlichkeit an die bestehende angepaßt.

In das Programm habe ich eine 3zeilige Summenzeile eingebaut die ich ebenfalls mit einem write mit Fehlerbezugszahl ausgebe. Leider funktioniert es nicht ganz so wie ich will. Im Normalfall, wenn z.B. die Summe in die Mitte oder an den Anfang der Liste gedruckt werden soll, funktioniert es. Erreicht die Ausgabe der Summe jetrzt aber die Zeile 66-68(Gesamtzeilen 72, Überlauf Zeile 66; 7,5/13,3 CPI), passiert im Debugger Folgendes:

Die Fehlerbezugszahl geht an beim write, dann wird die Summe in Zeile 66-68 gedruckt, dann werden die Kopfangaben und Kopftexte gedruckt und danach wird die Summenzeile wieder gedruckt. Eigentlich will ich aber die Summe in Zeile 66-68 nicht haben, sondern nur auf der neuen Seite. Ändere ich aber jetzt etwas am Überlauf oder der Gesamtzeilen-Anzahl, erscheinen die Kopfangaben und -texte nur noch auf der ersten Seite.

Kann mir jemand weiterhelfen und sagen, warum die Summenzeile trotz *IN27 = *on trotzdem doppelt gedruckt wird und nicht nur auf der neuen Seite?

C *IN26 IFEQ *ON
C 27 WRITE SUMME BZ28(NI)
C *IN28 IFEQ '1'
C *IN27 IFEQ *ON
C eval #PageV = #PageV +1
C ENDIF
C 27 WRITE KOPF04 BZ28(NI)
C EXSR KOPTXT
C 27 WRITE SUMME
C END
C ENDIF

26=bestimmte Firma
27=bestimmte Auftragsart
28=Fehlerbezugszahl(NI) beim write

In KOPTXT werden Kopftexte ermittelt und es wird ein write KOTX04 gedruckt und ggf's(bei Überlauf) auch noch mal ein write KOPF04, bedingt wie oben gemacht.

Ich wäre sehr glücklich, wenn mir jemand hier weiterhelfen könnte, damit ich die Logik verstehe, die hinter dieser Fehlerbezugszahl beim write steckt. Da die PrtF's im Prg leider auch noch des öfteren mit diversen Angaben überschrieben werden und ggf's auch Barcodes gedruckt werden, ist es leider auch schon eine größere Sache einen Zeilenzähler einzubauen oder einen Überlauf auf das PrtF in den F-Bestimmungen zu definieren...

Vorab schon mal vielen Dank,
votch

[Fuerchau]

Die Bezugszahl für Überlauf wird nach der Ausgabe gesetzt, der Druck ist also erfolgt!
Da du die Summenzeile also 2 mal ausgibst, wird sie auch 2 Mal gedruckt.

Im Extremfall kann es auch dazu kommen, dass ein automatischer Seitenwechsel innerhalb der Summenzeilen passiert.
Wenn Z.B. auf Zeile 66 (vor dem Überlauf) ein Format mit 6 Zeilen ausgegeben wird, werden eben 5 Zeilen auf der aktuellen und 1 Zeile auf der nächsten Seite ausgegeben.
Anschließend erfolgt der Kopfdruck mit einem erneuten Seitenwechsel (SKIPB).

Hier hilft nur eine INFDS (Beschreibung und Aufbau musst du suchen).
Hier gibt es eine aktuelle Info auf welcher Zeile die PRTF ist und wie der Überlauf definiert ist.
So kann man den Überlauf vorher prüfen.
Das funktioniert aber nur mit Formaten, die SKIP und SPACEx verwenden. Bei AFPDS mit POSITION wird ja frei auf der Seite positioniert.

[votch]

Hallo und vielen Dank fuerchau, das erklärt Einiges. Manchmal sieht man den Wald vor lautere Bäumen nicht...

Das PrtF wird hier mit devtype(*SCS) überschrieben. Meine Analyse ergab jetzt auch gerade, dass sämtlich Barcodes zwar im Prg ermittelt und gefüllt werden, aber seit 2003 im Prg definiert und im PrtF ausgesternt wurden. Auch die ganzen Escape-Sequenzen scheinen keinerlei Auswirkungen mehr zu haben...

Es scheint wirklich nur noch mit SKIPB und SPACEB gearbeitet zu werden

Ich mache mich gleich mal auf die Suche nach der INFDS und prüfe dann den ob es zu einem Überlauf kommt(neue Seite mit Summe oder ob die Summe noch auf die aktuelle Seite paßt).

Vielen Dank, dann habe ich ja evtl. doch noch 2-3 Std. von meinem "Urlaubstag" übrig...

[K_Tippi]

Hi,
falls es hilft hier die beiden Zeigerfelder für Seite und Zeile:

fmkublsp1 o e printer infds(prtds)


dprtds ds
d $$zeile 367 368i 0
d $$seite 369 372i 0

Klaus

[votch]

Hallo und vielen Dank nochmals an alle Beteiligten.

Es funktioniert jetzt dank fuerchau genauso wie es soll...

@K-tippi

genauso hab ich es auch gemacht und jetzt läuft alles wie gewünscht(Lösung siehe unten).

Hier der Source-Code, falls jemand mal ein ähnliches Problem mit Sourcen aus dem letzten Jahrtausend haben sollte...

FPrtF01 O E PRINTER USROPN
f INFDS( prtfInfDs )

d #HCurLin s 2 0

d PrtFInfDS ds
d OvrFlw 188 189i 0
d CurLin 367 368i 0

C *IN26 IFEQ *ON
C eval #HCurlin = CurLin
C eval #HCurLin += 3
C #HCurLin ifge OvrFlw
C 27 eval #PageV += 1
C 27 WRITE KOPF04 BZ28(NI)
C EXSR KOPTXT
C ENDIF
C 27 WRITE SUMME BZ28(NI)
C ENDIF

[Fuerchau]

Wenn du schon bei ILE bist gehts auch so:

if CurLin + 3 >= OvrFlw

dann sparst du dir das Hilfsfeld.

[votch]

@ fuerchau,

wenn ich mir das heute so anschaue muss ich Dir vollkommen Recht geben. Das Hilfsfeld hätte ich mir sparen können.