Inhalt Variable Wert zuweisen

[BenderD]

das geht ja wüst hin und her, was ich bisher verstanden habe:
- es geht um Kommunikation zwischen DSPF und Programm
dafür gilt erst einmal:
=> das geht über einen Buffer, der für In und Out in (mehreren) Formaten beschrieben ist und zwar doppelt, einmal im DSPF und einmal im Programm, das sich die Beschreibung zur Compiletime auch aus dem DSPF holen kann.
=> selber kann man sich die Beschreibung auch aus dem DSPF holen, mit DSPFFD oder mit dem im Thread bereits benannten API, das ist nicht explizit dokumentiert, wird sich aber (zumindest rückwirkend) nicht ändern, sonst müsste man nämlich neu compilieren und mit WebFacing hätte man ins selbige gegriffen (was man aus anderen Gründen eh hat).
=> ob man jetzt den Buffer über Programmvariablen, oder Bit weise über die DSPF Buffer Beschreibung verarbeitet, oder teils teils, das ist letztlich Gechmacksache (ich habe meinen Geschmack benannt, W seinen, andere ihren), am Wahrheitsgehalt des Programms ändert das nix, wenn man es denn richtig macht. Ob ich meinen Geschmack an dieser Stelle ändern würde, weiß ich nicht so genau, da habe ich mich zu wenig mit den DSPFs beschäftigt (z.B.: woran erkenne ich die Attribut Felder? 1 p ist mir zu wenig, Namensgedöns auch...)

So ein paar Sachen sind mir immer noch im Nebel:
- die Sortiererrei und dieses AAAAAAA Feld scheinen mir überflüssig
- die Userspace APIs sind es definitiv, da kann man direkt Pointer im Programm nehmen (mit denen kann man auch rechnen!!!), selbst Substring würde es schon tun, oder ein Array of Character
- diese Biton Bitof Arie würde ich durch named Constants ersetzen (die kann man in der Deklaration Hex belegen)

D*B

der nix gegen Jugend forscht hat

[Fuerchau]

@Dieter
Das Problem in ILE/RPG ist doch dieses, dass die Varablen aus der F-Bestimmung nichts mit dem Dateipuffer, der intern verwaltet wird, zu tun hat.
Jeder Dateibefehl stellt die entsprechend benötigten Variablen in den Puffer oder entnimmt sie daraus.

Die Verwendung der API's steht ja auch ausser Frage, einzig und allein der Zugriff auf die Programmvariablen, die vom Compiler (in RPG irgendwo, in ILERPG anscheinend sortiert) im Speicher definiert werden, steht hier zur Diskussion.

Und da bin ich eben der Meinung, dass man sich hier vom verwendeten Compiler (ILERPG) abhängig macht und beim nächsten Release oder Compiler auf der Nase liegen kann und sich dann wundert warum nix mehr klappt.

Aber du hast Recht, dem Forscherdrang sollte man nicht entgegenwirken.

[woodstock99]

@Fuerchau

Also ich hab diese Technik mal in ein ILE-Rpg eingebunden und in ein SQLRPGLE.
Funktioniert beides.
Hab aber keine Ahnung ob die denselben Compiler benutzen..

Um in Rpg das aufzurufen müsst ich erst mal meine Prozeduren ändern und auflösen, den zulange Variablennamen usw ((. Callp geht ja in RPG auch nicht oder??

Desweiteren muß ich dir recht geben das es eine recht heikle Angelegenheit ist.

Arbeitet hier keiner bei IBM und weiß zufälligerweise wann der nächtes Compiler rauskommt und wie des Ding funktioniert ????



@BenderD:

Sortieren tu ich gar nix.
Dieses aaaaaa 1 P Feld bräuchte man wirklich nicht aber so hat man immer das Feld mit der niedrigsten Startadresse im Speicher.

Und da diese 1P Felder aufsteigend sortiert werden ist das schon ne kleine Hilfe.

Wenn ich dieses Feld nicht definiere müsste ich innerhalb der ganzen Maske nach dem kleinsten Wert eines Feldnamen suchen und den mit an mein Programm-Api übergeben.

Diese bitand und or Geschichten
benützen wir im Serviceprogramm dazu ein Attribut dem Feld hinzuzufügen oder wieder wegzunehmen. Das geht doch nicht anders. Die Attribute haben wir natürlich per Constanten z.b.

Color_BLU C Const(x'3A')
definiert...


Die Userpacesache dient dazu die Felder (bist du ein 1p ATR DSPATR(&ATRxxxxx) )zu identifizieren.
Rechnen tun wir da gar nix..


Alles im allen ist das ein schmaller Grad auf dem wir uns bewegen würden. Diese ganze Geschichte brauchen wir auch nur um die Felder zu
initialisieren ...

Aber es ist zumindest mal eine Lösüng die Funktionieren würde....

[woodstock99]

oder gibt es evtl einen Befehl den man im dspf angeben kann`` defaultwert, inz, keine ahnung. kann man die dspatr variable nicht irgendwie auf einen defaultwert setzten initialisieren ?????????

[Fuerchau]

Innerhalb der DSPF gibt es für P-Felder keinen INZ-Wert (DFTVAL geht nur für Eingabefelder).
Das muss scshon das Programm selber machen.

Allerdings weiß ich nicht, ob du da unbedingt ein CALL-API brauchst und nicht lieber eine Copy-Strecke mit den Konstanten bereitstellst.

Es ist allemal einfacher mit den Namen als mit Calls zu arbeiten, insbesonders bei so simplen Sachen wie Attributen.

Auch das Problem der Init's verstehe ich nicht, da ich doch weiß, dass ich die Attribute vernünftig setzen muss.

Alaso ich gehe da immer folgendermaßen vor:

if Bedingung true;
DspAtr = Attribut_Red;
else;
DspAtr = Attribut_Green;
endif;

Schließlich muss ich ja ggf. das Rot-Attribut beim nächsten Durchlauf eh wieder auf Grün setzen, so dass es fehlerhafte Init's ja eigentlich nicht geben dürfte. Schließlich stellt man das ja schon beim Testen fest, wenn da was ungültig ist.

[woodstock99]

ja das ist ja das problem das ich p felder nicht inzen kann ((.
hätt mir aber gedacht evtl kannst du ja mal einen zaubertrick aus deinem ärmel schütteln . hast ja schon genügend kampferfahrung auf diesem system .


ach wir wollen halt ( weil wir extrem schreibfaul sind ) alles irgenwie über serviceprogramme lösen und das programm so schlank wie möglich zu halten.
ja copystrecke könnten wir uns auch automatisch generieren lassen aber das wollen wir nicht. wir wollen halt mal ein zeichen setzen auch ohne copystrecken,bezugszahlen usw auszukommen.
sind eigentlich auf einem sehr guten weg wie ich finde aber so kleinichkeiten wie das inzen von 1p feldern bricht uns das genick. oder wir setzen doch unser
api-programm ein was aber einer zeitbombe gleichen kann .
eigentlich heisst es ja immer ein junger mensch muß sich was trauen aber die nummer wär schon verdammt heiss .

wir sind halt grad dabei eine funktionsbibliothek zu erstellen die alle nützen können und in der wir soviel funtionen wie möglich reinpacken wollen und den anderen programmieren das leben so leicht wie möglich zu machen...

[woodstock99]

ach ja das probem mit den inits.
wir haben ja überhaupt keine attributte mehr im displayfile definiert. wenn ich jezt das programm calle und nicht initialisiere kommt das ganze durcheinander. keine ahnung warum. verstehe ich ehrlich gesagt auch nicht. geh mal davon aus das irgendein müll in den variablen steht. ich finde das sind lauter kinderkrankheiten der ibm,denn wenn ich ohne zu inzen ri zuweise macht er es ab uns zu und ab zu zu nicht. wenn ich aber das feld inze funktioniert es einwandfrei. find ich auch komisch...

[Fuerchau]

Tja, da hilft nur, doch eine Copystrecke zu generieren, die die ATR-Felder als Single-Felder deklariert. Dann gibts auch keine Probleme.
Da eine Variable nur einmal vorhanden ist und es für DS'n von DSPF-Formaten keinen Grund gibt, kann man die ATR-Felder auch initialisieren:

Copy für Attribut-Values:
d AtrValue_Green const(x'nn')

Generierte Atr-Copy:
d MyAtr1 s 1 inz(AtrValue_Green)
:

Auch HLL/5GL usw. kommen ja nun mal ohne Includes/Copies nicht aus, was spricht also dagegen, neben den Funktionsprototypen eben auch Konstanten festzulegen ?
Und eine Copy-Strecke zu generieren (ggf. in einem automatischen Programmerstellungslauf) dürfte auch nicht das Problem sein.

Wenn es nur um den blöden INZ geht (den man eben meiner Meinung nach nicht braucht), ist das vielleicht ein Weg.

Ausserdem:
Trotz aller Bibliotheken und Funktionen sollte man den performance-Aspekt nicht soganz vernachlässigen.

[woodstock99]

ja aber das geht eben nicht ohne zu inzen siehe vorherige antwort. ich war gard nen tick schneller wie du . das ist ja genau das problem. ich werd mir jetzt auch einen programmgenerator basteln der das dspf durchliest und autmoatisch die copystrecke generiert.
das alles brächte ich halt nicht machen wenn ich an die wenigstens an die recorddresse kommen würde den die offset adressen der felder bekomm ich ja. also startadresse + offset und dann würd es passen oder??.

das problem bei copystrecken ist ja das wenn ich hier mal einen fehler mache und ich komme erst später drauf muß ich alle programme wandeln falls ich die copystrecke ändere. das muß ich halt beim serviceprogramm nicht....

[Fuerchau]

Nunja, an die Recordadresse zu kommen löst nicht dein Problem, da ja der Aufbau je nach Format eben unterschiedlich ist und zur Laufzeit aufgebaut wird.
Eine Initialisierung des Recordpuffers würde beim nächsten WRITE automatisch zerstört und bringt eben überhaupt nichts.

Ich würde mir auch wirklich nichts für INZ überlegen, da dies nun mal Sache des Programmes ist.

Es gibt auch noch ein weiteres Problem in diesem Zusammenhang.

Es soll Programme geben, die DSPF's gemeinsam nutzen, das Programm A den einen Teil der Formate und das Programm B einen anderen Teil.

In RPG musst ich in den F-Bestimmungen das Format auf IGNORE setzen, damit der Compiler keinen Fehler macht.
In ILERPG ist das nun egal, wenn mal ein Format nicht verwendet wird.
Kann ja auch sein, dass mal ein Format nicht mehr benötigt wird, aber aus historischen Gründen (oder Faulheit) noch definiert bleibt.

Allerdings sind die Variablen des nicht verwendeten Formates auch nicht im Speicher definiert, quasi also nicht vorhanden !

Das kann dein Unterprogramm aber nicht merken und überschreibt damit ggf. falsche Speicheradressen.

Da ist eine (ggf. falsch) generierte Copystrecke absolut unkritisch.
- entweder merkts der Compiler
- oder es spielt keine Rolle

[woodstock99]

ja aber wenn ich doch die recordaddresse hätte kann ich doch den offset der felder den ich über das api bekomm einfach draufzählen und dann nur einmal inzen.

folgender lösungsvorschlag.

xxxx likerec format


zeiger auf xxxx

inz (xxxx + offset)


ich bekomm doch dadurch die speicher adresse der felder oder versteh ich da was falsch??
wenn das funtioniert wär ich auch kompiler unabhängig...

danach sollen die felder ja sowieso vorbelegt werden..



falls das nicht funktioniert is schicht im schacht

[Fuerchau]

Mittels likerec legst du eine DS an.
Hier ist jedoch das Problem, dass eine Variable nur in einer DS vorkommen darf !
Ausnahme: quailified.

Qualified-Strukturen müssen allerdings in den F-Bestimmungen mit Prefix angegeben werden, da sonst die automatische Zuordnung F-Feld zu DS-Feld nicht vorgenommen wird.
M.a.W:
Alle Felder, die über F-Bestimmungen automatisch deklariert werden, sind Single-Felder (S statt DS).
Definierst du eine DS mittels Likerec, übernimmt der Compiler diese Definition und unterläßt die Deklaration der S-Felder.

Ein Ein-/Ausgabebefehl verwendet die Felder, die durch F-Bestimmungen deklariert werden:
a) Single-Felder
b) DS-Felder ohne Qualified
c) Prefix-Felder für DS mit Qualified

Qualified hat halt den Nachteil, dass jedes Feld nur mittels "DsName.FeldName" angesprochen werden kann, was den Tippaufwand nicht unbeträchtlich erhöht und Erstfehler erzeugt.

Desweiteren musst du für deinen Init-Call den Aufruf dann je Satzformat (DS) machen !

Ob das die Programmierung nun erleichtert, wage ich zu bezweifeln.

PS:
Wenn du zusätzlich zu einer DSPF noch Namensgleichheit zu DISK und PRINTER innerhalb eines Programmes hast, verschärft sich das Ganze noch weiter.