You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
NetRPG was such a passion project when I was into developing it fully. It was so fun to implement display files and to handle EBCDIC literals for multiple CCSIDs. I stopped working on it because other work came up at the time and I never got back into it.
I even blogged a couple of times about implementations:
The issue with implementing RPG, is that you're basically implementing a lot of the operating system. RLA (Record Level Access) uses system APIs, interacting with data areas uses system APIs, embedded SQL uses system APIs, almost everything uses system APIs.
NetRPG even re-implements some of these APIs, so it's already partway there. The issue with NetRPG is that it is unorganised. The VM and language is a single application. I really should have separated them out (and still can). Because we're going to be separating them out, it means that the VM needs to be separate from the OS. It also means that a lot of the OS needs to be implemented within the VM - whether it's using the existing RPG implementation or implementing an easier language to interact with the system APIs.
Whenever I get a chance, this could be a plan for me to follow:
VM to be separated out of language
VM to support multiple databases for RLA APIs (SQLite, ODBC)
Display file support needs to be finished
VM would be simulating an interactive job only.
VM needs to be able to interact with the database (SQL CLI apis)
Base of OS
OS needs to use an internal database
Used to store objects, users, etc. There is a lot to this. Need a way to store binary/instruction representation of programs.
Needs to create displays, programs to simulate navigating the OS
Using CL commands?
Basic CL support
Implementation of the command object
Handler programs for the command
Reimplementing a lot of system commands, programs, and displays (WRKJOB, WRKOBJ, DLT*, etc)
This is a lot. This is the kind of project I start on a 10-day cruise from Jamaica to Southampton. It is mostly a brainstorm, but it could be fun.
The text was updated successfully, but these errors were encountered:
NetRPG was such a passion project when I was into developing it fully. It was so fun to implement display files and to handle EBCDIC literals for multiple CCSIDs. I stopped working on it because other work came up at the time and I never got back into it.
I even blogged a couple of times about implementations:
The issue with implementing RPG, is that you're basically implementing a lot of the operating system. RLA (Record Level Access) uses system APIs, interacting with data areas uses system APIs, embedded SQL uses system APIs, almost everything uses system APIs.
NetRPG even re-implements some of these APIs, so it's already partway there. The issue with NetRPG is that it is unorganised. The VM and language is a single application. I really should have separated them out (and still can). Because we're going to be separating them out, it means that the VM needs to be separate from the OS. It also means that a lot of the OS needs to be implemented within the VM - whether it's using the existing RPG implementation or implementing an easier language to interact with the system APIs.
Whenever I get a chance, this could be a plan for me to follow:
VM to be separated out of language
Base of OS
Basic CL support
This is a lot. This is the kind of project I start on a 10-day cruise from Jamaica to Southampton. It is mostly a brainstorm, but it could be fun.
The text was updated successfully, but these errors were encountered: