Hey all,
I've been looking for a way to improve our deployment here, and there is still a question that's been unanswered to me yet.
Do we have a way to read the r-code info, specially display-type, by reading the .r file directly? I'm thinking in perl or python, maybe even C or java, if needed. I only found an old project that reads some parts, but only CRC/MD5 info.
Explaining in details: since we have a GUI and tty deployment, I have to work with two sets of directories. When our vendor releases a new package update, we get one zip for each. But there are some times that a program is not compiled in tty anymore, since the source changed and it doesn't create a GUI-specific r-code anymore, thus, removing the need to have a tty r-code. When this happens, I end up with an old r-code in tty directory, making the AppServer or batch process read this one instead of the updated file in the GUI directory. The packages are incremental, so not possible to discard the old tty files and have only the new ones.
I only thought of a way to get over this by having one set of directories for each package, but it would create a enormous PROPATH (now we have 13 entries in production env, twice for the TTY part, a little more in the dev/staging envs), and it would be awful to manage for each update that we have.
I wanted to create a script to read the tty dirs and check the GUI dirs if the files are still GUI only or not, while reading some other info. Spawning a new _progres for each file would not have a good enough performance (more than 57 000 files to check right now), and I had to capture info from stdout/stderr somehow. Doing the reverse approach (_progres spawning a perl script) has the same issue.
If there is no other way, I'll do this in steps, working with text files and parsing the content, which I hoped not to do.
Thanks!
PCT and the OpenEdge plugin for SonarQube both have Java code to parse rcode. A lot of data are already being extracted from rcode, although display-type is not part of this set. That probably can be added quite easily.
Yes, I've seen that. Unfortunately I need exactly display-type.
Can't you read all r-code files one by one and examine them with RCODE-INFORMATION:DISPLAY-TYPE ?
Something like this:
DEFINE VARIABLE rcode-file AS CHARACTER NO-UNDO.
INPUT FROM OS-DIR('<your folder>').
REPEAT:
IMPORT rcode-file.
IF NOT rcode-file MATCHES '*.r' THEN NEXT.
RCODE-INFO:FILE-NAME = rcode-file.
DISPLAY
rcode-file FORMAT "x(60)"
RCODE-INFO:DISPLAY-TYPE.
END.
INPUT CLOSE.
That's what I do, but I want to get that info from perl/python, not from ABL, to have it all in one place only, and not spawning several _progres just for that.
Why would you spawn several _progress executables for that? One session can walk through the whole code. And if your other scripts are in perl/python, you could export the findings of the progress program to a text file and import it in perl/python. I think extracting the display-type information is safest to do from within progress itself.
why spawning several processes for that? you can just process everything in one call and save the info in some json/xml file that you can use later from perl/python
The bad thing on doing that is having two scripts to maintain, at least three reads for each .r, since I have to read them from _progres, then again from perl, and other helpers. I'm almost finishing the latter in perl, but still have to read everything again in Progress. I'd really like to optimize everything, and reduce external dependencies by doing it all in one script.