Total free rpg

[Fuerchau]

Dann hast du dir .Net-Core noch nicht angeschaut.
Das ist quasi die ursprüngliche und nun zugelassene Raubkopie von .Net, ehemals genannt Mono.
Auf Grund eines sogar amerikanischen Kartellurteils musste Microsoft die Quellen offen legen.
Somit ist aus Mono (nur .Net 2.0) nun Core geworden.

Warum also soll Core nicht auf der AS/400 ebenso laufen wie auf Linux oder sogar Android?
Man könnte damit dann mal tatsächlich zumindest aus der C#/VB.Net-Ecke auch Entwickler wieder für unsere AS/400 ködern.

[Fuerchau]

Also was die Fehlererkennung zur Compilezeit angeht, so hört es bei der Verwendung von DS'n als Parameter allerdings auf.
Bei Reference wird zumindest nicht einmal die Länge der DS geprüft.
Bei CONST/VALUE ist das noch nachvollziehbar aber nicht bei Reference.
Bisher konnte ich immer erst zur Laufzeit Tippfehler im Parameternamen erkennen, da die Folgeverarbeitung ggf. durch Pufferüberschreibungen abstürzte.
Intellisense hat zwar schon Vorteile, aber schnell ist da auch schon mal ein Name verwechselt.

Die Prüfung sollte mindestens bei DS-Parametern eine Struktur-Signatur ermitteln und prüfen.
Damit könnten schon so einige Fehler früher behoben werden.

Das selbe gilt immer noch bei SQL-Feldern.
Hier sollte eine Verpflichtung zur Compilezeit (Option?) der Existenz von SQL-Variablen einstellbar sein.
Dann würden auch hier eine Vielzahl von Tippfehlern frühzeitig erkannt werden.

[Fuerchau]

@MK
Warum denn nicht gleich mit IFS-Streams?
Dann entfällt das Ganze Membergedöhns, man kann z.B. GiT nutzen und sonstige Tools die mit IFS-Streams umgehen können.

[harkne]

Ich bin aktuell mittendrin. In meiner Informationsdatenstruktur habe ich das Unterfeld CPOS was definiert ist mit (von) 370 (bis) 371B 0.
Ich denke mal ich muss "bindec" als Datenart Schlüsselwort verwenden. Aber welche Länge muss ich angeben ? Bestimmt nicht bindec(2) oder ?

Viele Grüße Harald

[Fuerchau]

Die Frage ist, welche Wertigkeit du benötigst:
int(5) bzw. bindec(4) belegen die 2 Bytes, wobei int(5) eben +/- 32767 kann, ansonsten geht nur +/- 9999.

[harkne]

Das ist die Cursorposition aus der Informationsdatenstruktur. Einfach nur verwendet, nie darüber nachgedacht, hat ja funktioniert. Also bei 2 Stellen B 0 in der "alten" Datenstruktur gebe ich bindec(4) an, wenn ich das richtig verstanden habe ?

[B.Hauser]

Wenn Du schon dabei bist, die Datei-Status-Datenstruktur von Display-Files zu überarbeiten, würde ich Dir empfehlen 2 Felder je Uns(3), eines für Zeile (Position 370) und eines für Spalte(Position 371) zu definieren. Dann kannst Du Dir die Dividiererei sparen und Zeile bzw. Spalte direkt auslesen.

Ansonsten würde ich, falls Du beides zusammenfassen willst oder musst, Uns(5) empfehlen. (negative Werte für Zeile/Spalte gibt es nicht!)

BINDEc solltest Du auf alle Fälle vermeiden und je nachdem INT oder UNS verwenden. Bei BINDEC wird der Inhalt (intern) in gepackt konvertiert, während bei INT und UNS die Integer-Datentypen direkt verwendet werden.

Birgitta

[camouflage]

Es gibt auch Referenzen von IBM...

DCL-F MYFILE WORKSTN(*EXT) INFDS(DSPFBK);


   DCL-DS DSPFBK;
     DSP_FLAG1     CHAR(2)    POS(367);    // Display flags
     DSP_AID       CHAR(1)    POS(369);    // AID byte
     CURSOR        CHAR(2)    POS(370);    // Cursor location
     DATA_LEN      INT(10)    POS(372);    // Actual data len
     SF_RRN        INT(5)     POS(376);    // Subfile rrn
     MIN_RRN       INT(5)     POS(378);    // Subfile min rrn
     NUM_RCDS      INT(5)     POS(380);    // Subfile num rcds
     ACT_CURS      CHAR(2)    POS(382);    // Active window cursor location
     DSP_MAJOR     CHAR(2)    POS(401);    // Major ret code
     DSP_MINOR     CHAR(2)    POS(403);    // Minor ret code
   END-DS;

[harkne]

Wenn Du schon dabei bist, die Datei-Status-Datenstruktur von Display-Files zu überarbeiten, würde ich Dir empfehlen 2 Felder je Uns(3), eines für Zeile (Position 370) und eines für Spalte(Position 371) zu definieren. Dann kannst Du Dir die Dividiererei sparen und Zeile bzw. Spalte direkt auslesen.

Ansonsten würde ich, falls Du beides zusammenfassen willst oder musst, Uns(5) empfehlen. (negative Werte für Zeile/Spalte gibt es nicht!)

BINDEc solltest Du auf alle Fälle vermeiden und je nachdem INT oder UNS verwenden. Bei BINDEC wird der Inhalt (intern) in gepackt konvertiert, während bei INT und UNS die Integer-Datentypen direkt verwendet werden.

Birgitta

Ah gut. Dann mache ich das so. Vielen Dank

[harkne]

Jetzt hab ich noch mal eine Frage. Wenn ich das richtig lese gibt es im Free kein KLIST und KFLD mehr. Ich muss dass über eine Datenstrukur und %kds machen wenn ich so wie früher mit einer Schlüsselliste auf eine Datei zugreifen möchte ?

[camouflage]

Das ist so, allerdings vermeide ich, wenn es geht, den Einsatz %kds. Ist irgendwie noch ein alter Zopf.
Hier noch ein Link, falls Du automatisiert in free umsetzen möchtest. Tut nicht alles, aber immerhin mehr als RDi. Und als Anschauungsunterricht auch nicht schlecht.
https://sourceforge.net/projects/cvtrpgfree/

[B.Hauser]

Du kannst natürlich %KDS verwenden, wenn Du willst, ...
aber im Free-Format kannst Du die Schlüssel-Felder (in einer runden Klammer) einfach auflisten:

  Chain (KeyFld1: %Date(): 'X': 123: KeyFldX) YourFile;

Birgitta