Rational Developer for i – Rdi – Unable to edit IBM i source members with RDI

Index

Toggle

Introduzione

Questo articolo non vuole essere una vera guida a Rational Developer for i – Rdi ma solo una raccolta di tips and tricks, da riguardarsi di tanto in tanto per utilizzare meglio questo ottimo IDE di sviluppo per ambiente RPG e Cobol.

Rdi-Caso di studio:

Dal momento in cui ho deciso di focalizzare la mia attenzione sui sorgenti IBM I, l’unico strumento con il quale desidero sviluppare è RDI. Non è pensabile in alcuno modo continuare ad utilizzare il SEU e credo che sia arrivato il momento di scrivere sempre più codice in formato **free. Tale IDE integra strumenti per lo sviluppatore, ad esempio funzionalità di ricerca, modifica, sviluppo, analisi, refactoring e debugger con il framework Eclipse ad ampia diffusione, per lo sviluppo e la modernizzazione di applicazioni in modo più rapido e semplice.

Ma come sempre, può capitare che sussistano dei problemi….

Con RDI, abbiamo il grande vantaggio di avere in linea più connessioni in contemporanea sui server IBM I e quindi, abbiamo la possibilità con un semplice drag and drop di spostare i sorgenti senza troppe difficoltà. Sino ad ora tutto bene, ma da un paio di giorni a questa parte, non riuscivo più ad editare con LPEX alcun sorgente presente solo ed esclusivamente sul mio ambiente di pre-produzione.

In prima battuta, ho subito pensato che potessi avere dei problemi con il Workspace Rdi che, per qualche strana ragione, si guasta e crea strani problemi. In questi casi la prima cosa che ho provato a fare, è creare un nuovo workspace pulito e verificare se i problemi si risolvono, ma così non è stato.

Pian piano vado avanti, e la questione diventa sempre più interessante.

Decido di collegarmi con una sessione 5250 al mio ambiente di pre-produzione ed inizio ad editare un qualsiasi sorgente senza alcun problema. Qui, purtroppo ahimè ho dovuto dar ragione ai miei colleghi più anziani, che ancora non si sono convertiti al nuovo IDE e continuano a ripetermi che non ne vale la pena, ma da buon testardo che sono, decido di proseguire la mia corsa contro la risoluzione del problema.

Rdi-Risoluzione:

Nell’ordine eseguo come da documentazione IBM, tutti questi check:

Un firewall potrebbe bloccare la connessione TCP/IP dalla stazione di lavoro locale alla porta 446 sul server IBM i –> STRTCPSVR * DDM
Esegui il comando DSPNETA sulla sessione 5250 e verifico il valore per DDM RICHIEDI ACCESSO. L’impostazione predefinita deve essere * OBJAUT.
In casi molto rari ci sono tabelle parser su IBM I che possono, in rari casi, essere danneggiate. –> DLTUSRSPC USRSPC (QSYS/QCNPRSTBLS)
Verificare che il sottosistema QUSRWRK non sia limitato al numero di lavori che può essere eseguito. L’impostazione predefinita è * NOMAX.
Come da documentazione IBM, cercando il codice di errore, ho anche provato a pulire la cache di RDI, ma nulla.

Dopo tutte queste verifiche terminate con esito positivo, ancora nulla! L’ultima step, sarebbe verificare tutte le librerie presenti nella mia *JOBD ed accertarsi che non siano presenti per qualche strano motivo “bad library references”, ma mi sembra un qualcosa di impensabile, anche perché dal SEU tramite sessione 5250 funziona tutto egregiamente!

Ebbene si! Decido a questo punto di ricrearmi una nuova *JOBD ed associarla al mio profilo utente, e scopro che c’è una libreria, non più necessaria, che non è stata allineata sul mio ambiente di pre-produzione e quindi, presenta una “reference errors“ solo nel momento in cui, tra l’altro, si decide di ricreare o confermare l’attuale *JOBD. A questo punto, decido di rimuoverla dalla lista di librerie e provo nuovamente ad editare un sorgente con il mio fantastico RDI! Ovviamente, tutto funziona!

In definitiva, RDI è molto più intelligente rispetto al nostro “comodo” SEU, poiché ogni qualvolta che si effettua l’accesso, fa un check di tutte le “library references” e nel caso in cui, ci sia un semplice errore per un motivo qualsiasi, inibisce la modifica dei sorgenti!