View Full Version : SQL und CLLE
RobertMack
12-03-21, 15:46
Falls das jemand nachmachen möchte: ich schreibe gar keine CLLE's mehr, mache alles in Free mit QCMDEXC - die Anweisungen Monitor und Commit sind in diesem Kontext unschlagbar!
Nun ja, wenn ich im CLP/CLLE mit Commands umgehe erleichtert das das Schreiben schon.
Aber jedem das Seine.
camouflage
12-03-21, 15:59
Robert,
alles zu seiner Zeit und an seinem Platz. Gut, ich verwende eher 'system' als QCMDEXC und einer der nütztlichsten BIF's den %scanrpl um die Platzhalter innerhalb eines Command-Strings zu ersetzen, wenn ich es denn über RPG löse. Doch immer ein RPG Programm zu schreiben, finde ich jetzt auch ein wenig übertrieben. ;-)
RobertMack
12-03-21, 16:05
Da gebe ich Dir sogar recht! Allerdings muss ich immer den kleinsten gemeinsamen Nenner unter den Kunden wahren (die einen sind noch auf V5.4 oder 6, andere sind nicht sattelfest in CL/CLLE und wieder andere leisten sich nichtmal RDi...
Ich muss also so schreiben, dass die vorhandenen human resources das lesen können. Das prägt ;- )
Ich habe bisher nur einen einzigen Kunden, der RDi einsetzt. Alle anderen muss ich mir Greenscreen und PDM verarzten.
Und RDi remote macht nicht gerade Spaß, zumal das Autovervollständigen nicht innerhalb SQL funktioniert. Da brauchts immer noch Splitscreen und copy/paste.
Da sind andere IDE's erheblich weiter. Bereits VB6 (seit1997) konnte da schon mehr.
Andreas_Prouza
12-03-21, 17:12
Und RDi remote macht nicht gerade Spaß, zumal das Autovervollständigen nicht innerhalb SQL funktioniert.
Wenn's ganz schlimm wird, arbeite ich mit Projekten und synchronisieren dann einfach rüber.
Am besten ist es wenn die Sourcen im IFS sind, dann arbeite ich mit dem Visual Code, der hat da viel weniger Probleme mit den Verbindungen.
Aber ja, nur selten ist eine Umgebung perfekt oder gar "gut".
RobertMack
12-03-21, 20:03
Am besten ist es wenn die Sourcen im IFS sind ...
...was ich ganz stark anzweifle! Wenn sich da mal ein Tsunami aus versemmelten CCSIDs, unerfahrenen Codern in Verbindung mit unerwarteten Havarien (RDi oder Anwendung) entwickelt, möchte ich nicht in Deiner Haut stecken!
Bitte sportlich nehmen ;- )
Andreas_Prouza
15-03-21, 07:53
Für konstruktiven Erfahrungsaustausch bin ich immer offen. Nur so können wir uns alle weiterentwickeln :-)
Ich habe ehrlich gesagt, mehr Probleme mit unterschiedlichen CCSIDs bei Source-Files gehabt als im IFS.
Im IFS kann ich wenn nötig recht einfach die Sourcen korrigieren. Bei Source-Files hängt's ja auch an der CCSID des Source-Files ab und dann auch noch am Member mit welchem Job & CCSID man dort drinnen gearbeitet hat.
Da tu ich mir einfacher im IFS alles mit UTF-8 zu speichern und fertig.
Gerade wenn's dann darum geht unterschiedliche Länder unter einem Hut zu bekommen die mit unterschiedlichen CCSIDs arbeiten, erspart mir das einige Probleme.
Falls jemand Probleme mit der Variante im IFS mal gehabt hat würde mich das sogar wirklich interessieren.
Warum gibts nur soviele Probleme mit CCSID's?
Wenn man sich an die simplen Regeln hält:
- Systemwert QCCSID auf die Sprache einstellen (z.B. 1141), kein Job ohne CCSID
- Alle Dateien haben eine CCSID wenn man sie mit DDS oder SQL erstellt.
- Bildschirmcodepage immer passend zum Job, z.B. 1141
- Mehrsprachigkeit (West+Ost), immer Unicode 1200, im ACS Unicode aktivieren
- NetServer CCSID 1252
- FTP CCSID 1252
- Streambefehle (CPYxxx) nie PCASCII sondern passend 1252 verwenden.
Und schon gibts keine CCSID-Probleme mehr.
Andreas_Prouza
15-03-21, 08:04
Tja, wenn sich jeder überall an Regeln halten würde, gäbe es generell fast keine Probleme mehr ;-)