Migrazione da RPG a Java su un iSeries IBM

La mia azienda sta anche tentando di migrare a Java da RPG.

1. Non stiamo tentando di utilizzare un JRE su un thin-client, stiamo passando alle applicazioni Web fornite tramite un browser. Ciò potrebbe comportare (eventualmente) la sostituzione dei nostri vecchi scanner POS con alcuni dei più recenti basati su PC.
2. Sono stato informato (dagli architetti della società) che la JVM sul sistema operativo iSeries ha alcuni problemi di prestazioni. Non so personalmente quali siano queste limitazioni. Nel nostro nel caso in cui la migrazione abbia comportato l'allocazione di una risorsa AIX, che dovrebbe essere molto meglio - parla con il tuo rappresentante IBM se hai solo bisogno di acquistare la licenza del sistema operativo (ho solo programmato la cosa, non mi faccio coinvolgere nell'hardware).
3. Cfr.risposta alla domanda 1. In un contesto più ampio, in cui si sta tentando di aggiornare il browser (o qualsiasi altra risorsa), questo viene solitamente gestito da licenze enterprise-la maggior parte avrà opzioni per consentire forzato, remoto aggiornare.

Alcune altre note:

• Si dovrebbe essere in grado di passare al solo utilizzo di.NET, anche se potrebbe essere necessario diverso hardware/partizioni per eseguire l'ambiente. Puoi parlare con DB2 in questo modo, almeno. L'unico vantaggio che Java ha è che verrà eseguito sullo stesso sistema operativo/hardware del database.
• Ho visto un'applicazione screenscraper qui (era in VB.NET, ma sono abbastanza sicuro che l'esempio si applica). Screen-scraping è stato realizzato da ottenere / mettere caratteri in posizioni specifiche sugli schermi (l'equivalente di substring()). Potrebbe essere solo l'API che stavamo usando-penso di aver sentito parlare di soluzioni che erano in grado di leggere i nomi dei campi. Tuttavia, si basava anche sul flusso del programma RPG per la sua logica, e non era altrimenti gestibile.
• La maggior parte dei programmi RPG che ho visto e scritto tendono ad essere una violazione di MVC, il che significa che non si può fare niente di meno che test di integrazione - la storia e l'architettura del la lingua stessa (e alcuni sviluppatori) preferisce che tutto (accesso ai file alla visualizzazione dello schermo) sia in un unico file. Questo renderà anche il tentativo di avvolgere RPG per chiamare in remoto in modo efficace impossibile. SE hai correttamente separato tutto in Programmi di servizio, dovresti essere in grado di avvolgerli (come l'equivalente di una chiamata al metodo nativo, quasi) ordinatamente-sfortunatamente non ho visto nulla qui che non tendesse a fare affidamento su uno o più trucchi che non reggerebbero per tipico uso Web (ad esempio, utilizzando un file in QTEMP per controllare l'esecuzione del programma - la sessione su iSeries scompare effettivamente ogni volta che viene richiesta una nuova pagina...).
• Java come linguaggio tende a promuovere una migliore separazione del codice (si noti che può essere abusato altrettanto male), in quanto non ha abbastanza la storia di RPG. In generale, può essere utile pensare a Java come un linguaggio in cui tutto è un programma di servizio, in cui tutti i parametri vengono passati con VALUE set, OPTIONS(*nopass : *omit) non è consentito, CONST è generalmente raccomandato, e la maggior parte dei parametri sono di tipo DS (datastructure - questo è un tipo distinto in RPG) e passati in giro per puntatore. I parametri del livello del modulo sono disapprovati, se si preferisce incapsulare tutto nelle strutture dati passate o nelle procedure del programma di servizio stesso. STATIC ha un uso leggermente diverso in Java, rendendo la variabile globale e non è disponibile all'interno delle procedure.
• RPG è un po ' più semplice di Java, in generale, e la programmazione OO è un paradigma piuttosto diverso. Ecco alcune cose che rischiano di far inciampare gli sviluppatori che migrano a Java:
  1. Gli array in RPG iniziano da 1. Gli array in Java iniziano da 0.
  2. Java non ha parametri "ouput" e tutti i tipi primitivi vengono passati per valore (copiati). Ciò significa che la modifica di un numero intero non sarà visibile nei metodi di chiamata.
  3. Java non ha codifica impacchettata / firmata, e quindi la traduzione da / verso numeri / stringhe è più coinvolta. data il tipo in Java ha anche alcuni problemi seri (include il tempo, una specie di), ed è molto più difficile da cambiare in modo significativo a/da una rappresentazione di caratteri.
  4. È più difficile leggere/scrivere file in Java, anche quando si utilizza SQL (e dimenticare di usare I/O nativi direttamente con Java) - questo può essere mitigato in qualche modo con un buon framework, tuttavia.
  5. Non ci sono operatori ENDxx in Java, tutto utilizza parentesi ({}) per specificare l'inizio/la fine dei blocchi.
  6. Tutto in Java è in freeformat e non ci sono specifiche colonnari di alcun tipo (anche se le firme delle procedure sono ancora richieste). Non c'è hardlimit sulla lunghezza della linea, anche se ~80 caratteri è ancora raccomandato. Gli strumenti (i gratuiti , anche) sono migliori, punto e generalmente molto più utili (anche se possono richiedere un po ' di tempo per abituarsi a quelli esposti alla SEU). Ci sono anche enormi librerie gratuite disponibili per il download.
  7. Il segno = non è sensibile al contesto in Java il modo in cui è in RPG, è sempre utilizzato per le assegnazioni. Utilizzare l'operatore double-equals, == per i confronti dei valori in Java.
  Gli oggetti
  8. (datastructures) non possono essere confrontati in modo significativo con ==: spesso è necessario implementare un metodo chiamato equals().
  9. Le stringhe non sono mutabili, non possono essere modificate. Tutte le operazioni eseguite su stringhe (sulla classe/datastructure stessa o da librerie esterne) restituiscono riferimenti nuovi di zecca. E sì, le stringhe sono considerate datastructures , non tipi di valore, quindi non è possibile confrontarle nemmeno con ==.
  10. Non ci sono equivalenti incorporati alle direttive /copy pre-compilatore. Il tentativo di implementarli sta usando Java in modo errato. Poiché questi sono solitamente usati per gestire il codice 'boilerplate' (definizioni di variabili o codice comune), è meglio gestirlo nell'architettura. Variabile (TUTTE le specifiche D, in realtà) definitons saranno gestiti con import o import static istruzioni, mentre le varianti di codice comune sono solitamente gestite da un framework o definiscono una nuova classe.

Sono sicuro che ci sono un certo numero di altre cose là fuori, fatemi sapere se avete altre domande.