To Eugenio
I would like Ralph to define exactly what he expects from the GNUCOBOL project so we can align its progress as much as possible.
For now, I've solved the problem without GNUCOBOL, since I've solved the 2038 issue.
Right now, I'm more urgently trying to get out of C-ISAM, which is at its limit, than anything else.
I'd like to be able to get GNUCOBOL up and running, but right now, it's not feasible for me.
When I compile, it's also compiled in GNU, and if GNU gives errors, it's fixed. I have a nightly data pass, so I have the entire application updated in parallel every night in GNUCOBOL.
Every so often, I go back and check the list of problems I've detected, but they seem to be increasing rather than decreasing.
Now I'm also having problems with the pipes (dd_), which used to work fine.
I would really be excited to see GNUCOBOL up and running on my system soon.
Best regards.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To Eugenio
I would like Ralph to define exactly what he expects from the GNUCOBOL project so we can align its progress as much as possible.
For now, I've solved the problem without GNUCOBOL, since I've solved the 2038 issue.
Right now, I'm more urgent about getting out of C-ISAM, which is at its limit, than anything else.
I'd like to be able to get GNUCOBOL up and running, but right now, it's not feasible for me.
When I compile, it's also compiled in GNU, and if GNU gives errors, it's fixed. I have a nightly data pass, so I have the entire application updated in parallel every night in GNUCOBOL.
Every so often, I go back and check the list of problems I've detected; rather than decreasing, they seem to be increasing.
Now I'm also having problems with pipes (dd_), which used to work fine.
I would really be excited to see GNUCOBOL up and running on my system soon.
Best regards.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To Eugenio
I would like Ralph to define exactly what he expects from the GNUCOBOL project so we can align its progress as much as possible.
For now, I've solved the problem without GNUCOBOL, since I've solved the 2038 issue.
Right now, I'm more urgently trying to get out of C-ISAM, which is at its limit, than anything else.
I'd like to be able to get GNUCOBOL up and running, but right now, it's not feasible for me.
When I compile, it's also compiled in GNU, and if GNU gives errors, it's fixed. I have a nightly data pass, so I have the entire application updated in parallel every night in GNUCOBOL.
Every so often, I go back and check the list of problems I've detected, but they seem to be increasing rather than decreasing.
Now I'm also having problems with the pipes (dd_), which used to work fine.
I would really be excited to see GNUCOBOL up and running on my system soon.
Best regards.
To Eugenio
I would like Ralph to define exactly what he expects from the GNUCOBOL project so we can align its progress as much as possible.
For now, I've solved the problem without GNUCOBOL, since I've solved the 2038 issue.
Right now, I'm more urgent about getting out of C-ISAM, which is at its limit, than anything else.
I'd like to be able to get GNUCOBOL up and running, but right now, it's not feasible for me.
When I compile, it's also compiled in GNU, and if GNU gives errors, it's fixed. I have a nightly data pass, so I have the entire application updated in parallel every night in GNUCOBOL.
Every so often, I go back and check the list of problems I've detected; rather than decreasing, they seem to be increasing.
Now I'm also having problems with pipes (dd_), which used to work fine.
I would really be excited to see GNUCOBOL up and running on my system soon.
Best regards.