3 ms·

A friend of mine got a job as a junior developer at an insurance company whom rely solely on IBMi and RPG programs running on it. It is not dead.

shreddit 3y ago
My company has one as their main database too, these things just run and run and run
unixhero 3y ago
[He got the job in the year 2022. They were using RPG version 4 on IBM i and are not migrating anywhere. Rather they are hiring!]
artificialLimbs 3y ago
Sadly. We're using an i currently. It has sort of locked us in because all of the programs that touch the money are written in ancient RPG. You can't just change a table (which IBM calls files...) when you want to add a field, oh no. You have to change the table AND update EVERY program in RPG that uses that table, because RPG has to know about every field in every file it touches. We are slowly working on migrating out to PHP.
- lmz 3y ago
  Some would say that's great as you get instant database integrated type checking. Some people actively look for that.
  - artificialLimbs 3y ago
    I don't know, but suspect there are better ways than having to touch all our programs when a table changes.
- crunchyX38921 3y ago
  The sad part is that the only reason you have this constraint is because your team/company chose to have it. It has nothing to do with the language or system itself, it's 100% self-inflicted. You can absolutely add new fields to database tables on the system without updating every program - if you architect the software properly. Use embedded sql, explicitly select field names (ie don't do "SELECT *"), and put default values on new fields. I haven't written a new RPG program using the old file-specs in years - all new code has been embedded sql. Not willing to give up SELECT *? Fine - create views on top of the real database tables to do your SELECT * from. Then you can still add new fields to the database tables without changing everything else. Edited to add - if you want to add new fields to a table and not change all your old programs to use SQL, create a new table, transfer your data, and then create a view with the old table name using the same fields. You just have to test a little to make sure your view has the same record format id as the old table. Honestly it's pretty easy once you get the first one done and see how to do it.
martin1b 3y ago
The hardware is solid. The development community is aging out. We have the same thing and are currently migrating off as there are no RPG developers available for hire. Most of them are retiring. There are very few schools teaching RPG 3, 4, and Free.

shreddit 3y ago

My company has one as their main database too, these things just run and run and run

unixhero 3y ago

[He got the job in the year 2022. They were using RPG version 4 on IBM i and are not migrating anywhere. Rather they are hiring!]

artificialLimbs 3y ago

Sadly. We're using an i currently. It has sort of locked us in because all of the programs that touch the money are written in ancient RPG. You can't just change a table (which IBM calls files...) when you want to add a field, oh no. You have to change the table AND update EVERY program in RPG that uses that table, because RPG has to know about every field in every file it touches. We are slowly working on migrating out to PHP.

lmz 3y ago
Some would say that's great as you get instant database integrated type checking. Some people actively look for that.
- artificialLimbs 3y ago
  I don't know, but suspect there are better ways than having to touch all our programs when a table changes.
crunchyX38921 3y ago
The sad part is that the only reason you have this constraint is because your team/company chose to have it. It has nothing to do with the language or system itself, it's 100% self-inflicted. You can absolutely add new fields to database tables on the system without updating every program - if you architect the software properly. Use embedded sql, explicitly select field names (ie don't do "SELECT *"), and put default values on new fields. I haven't written a new RPG program using the old file-specs in years - all new code has been embedded sql. Not willing to give up SELECT *? Fine - create views on top of the real database tables to do your SELECT * from. Then you can still add new fields to the database tables without changing everything else. Edited to add - if you want to add new fields to a table and not change all your old programs to use SQL, create a new table, transfer your data, and then create a view with the old table name using the same fields. You just have to test a little to make sure your view has the same record format id as the old table. Honestly it's pretty easy once you get the first one done and see how to do it.

martin1b 3y ago

The hardware is solid. The development community is aging out. We have the same thing and are currently migrating off as there are no RPG developers available for hire. Most of them are retiring. There are very few schools teaching RPG 3, 4, and Free.