| Forum List • Thread List • Reply • Refresh • New Topic • Search • Previous • Next  1  |  1. Data stack#12115 Posted by: vpaldi 2007-12-04 13:50:00 | Hi,
years ago I wrote a series of REXX scripts for my PC. Those scripts used the data stack to pass mass data to each other. Now I do not have anything from the original running environment, only the scripts.
Yesterday I had to run some of the REXX programs in a hurry (it is ALWAYS urgent, eh?). I picked up and installed Reginald and launched the program. The first routine stopped with error at the QUEUE statement. The Programmer Center did the same.
I tried to find the reason, and did not find the QUEUE statement in the documentation. I am a little bit confused, since Data Stack with associated statements and functions (PUSH, PULL, QUEUE, QUEUED()) are part of the original REXX specification.
Question: what has happened?
- did I download an erroneous version?
- did I make a mistake during installation?
- is the data stack dropped from Reginald's functionality?
- or ...?Best regards,
Vince | 2. #12119 Posted by: DougA 2007-12-04 23:44:51 | I recall stack being a major (only?) transfer medium when i wrote in VM/CMS rexx, also recall the the Querkus (sp?) rexx package for the PC also contained an extension to allow stack/execio/etc to work on the pc. Perhaps that's what you've used ?
Bottom line is, no, stack isn't part of Reginald. Which means you have to recode to fix it, but, you will find the alternatives in Reginald much better than stack, that's the good news.
Once you get the hang of it, you'll not regret losing stack.Doug | 3. #12120 | Right. I found that the concept of a data stack wasn't all that useful, so it was removed from Reginald Lite. It's not powerful enough to be of much use as a means to pass data across a process boundary (ie, sharing data between separate programs). And for passing data between scripts, it's vastly inferior to Reginald's USE ARG, or enhanced PROCEDURE EXPOSE.
The legacy version of Reginald still has it. But don't use legacy Reginald with the newest REXX Programmer Center. They aren't compatible. | 4. #12123 Posted by: vpaldi 2007-12-06 05:23:35 | Hi, thanks for the reactions.
The data stack in my case - as you guessed - is for mass data transfer between programs. What is the point? Imagine that you write program primitives in rexx, which are able to run on multiple platforms from MVS to Windows through VM. What is the COMMON problem? Yes, data transfer between modules. What is the DIFFERENCE? The environment dependent operations. FILE IO!!!!! So: write the functional routines according to standard specification. Write system specific code ONLY for the file I/O routines as external REXX programs. Pass data via the data stack... The logic is portable, and you write file IO-s only once for all platforms. Subsequent programs will use the same set of IO routines.
That was my approach: build system independent functional routines. It worked with Reginald a few years ago, but fails today.
The story is not unique: incompatibility in Java, Javascript, Cobol, SQL implementations (slangs) - all well known for me. Now I lost an other illusion: base rexx specification is not FULLY implemented in all realizations.
I have to re-think, re-design, re-build. Or give up cross-platform scripting. Or find another interpreter.
Best regards,
VinceBest regards,
Vince | 5. #12124 Posted by: Jeff Glatt 2007-12-06 06:59:30 Last edited by: Jeff Glatt 2007-12-06 07:00:15 (Total edited 1 time) | As mentioned, you can use legacy Reginald, which still has the data stack. Look for the link on my web page. (But note that legacy Reginald is "done". I no longer add new features to it, nor work with that particular code base any further). I know Regina also has a data stack, and Object REXX should.
But yeah, Reginald Lite has definitely moved away from the "REXX standard" because frankly, I think that the pre-existing REXX standard is not even close to being a useful programming base circa 2007/2008. If that's all a REXX interpreter could do, I just couldn't see why anyone would want to use REXX when there are so many more powerful programming languages/tools today. So I definitely felt that Reginald needed to change in some fundamental way, if there were any purpose to me developing it further.
I don't see REXX as a useful cross-platform language circa 2008, and I think that if cross-platform is what someone really wants, his best plan is to migrate to Java, NET, or Python. I expect that you'll see those other choices offering many more options, right now, and even moreso in the future.
I feel that the only marketable benefit REXX offers today, compared to other languages, is that it's a really easy language for a self-taught hobbyist to use. (Well, it's really easy with the simplifications that Reginald, and its toolset, offer. It's not hobbyist friendly if you're talking about Regina or Object REXX. I see those more as tools existing just to run REXX scripts written years ago).
So, after talking it over with Reginald users/participants on this forum, we collectively agreed that I would vastly clean up Reginald's codebase by jettisoning any features of the language which I deemed too "dated" in its design, and then work on this new code base to add new "non-standard" features geared for hobbyist programmers. In this way, I could try to keep the new features implemented in the most simplified way possible, without legacy constraints. That's the target demographic I'm going for -- the hobbyist programmers -- the guys who don't want to spend years learning how to program, and want to use a fairly intuitive IDE to create GUI-based utilities. So everything I do is tailored to that demographic.
Now it's true that there will be a Linux version of Reginald at some point (and I've already been doing a bit of Linux development), with the aim to support as many of Reginald's "non-standard" features as possible. But I don't really see it as a way for people to run their scripts under both operating systems (ie, cross-platform). I just see it as a way for Linux users to use something geared for hobbyist programmers, just as Reginald also happens to also offer something geared for Windows hobbyist programmers. For example, any GUI features supported on Linux Reginald will very likely not be compatible with Windows Reginald GUI features. There will be Linux GUI features, but they will be implemented using whatever way I think is easiest to do on Linux -- which likely will not be the same as the easiest way to do things on Windows. With REXX, I see it as being all about ease-of-use to a hobbyist programmer. Other languages have the market all sewn up for cross-platform development circa 2008, and frankly, there's no way I can compete with Sun or Microsoft, etc, to that end. | 6. I'll just add my 2c's worth as well #12129 Posted by: Michael S 2007-12-06 16:41:15 Last edited by: Michael S 2007-12-06 16:42:10 (Total edited 1 time) | As you can understand, Vince, I do a load of Rexx development on the mainframe under TSO.
The "trouble" with that Rexx is that a lot of it is based on edit macros - and they're not really "translatable" to the PC (a guy here HAS written a "translation engine", but he hasn't done anything about a GUI front-end).
Then you have a potential design difference. For example, on the m/f, I have an edit macro that reads through a file looking for possible errors. The way I've designed it there is to issue an ISPF error message as soon as I find an error - then I stop. I could continue checking, but that would mean I'd probably have to splatter the errors onto the terminal as simple WTO's - not too elegant. Instead, with Reginald, I simply create a list control and add errors as I find them - more elegant.
Bottom line - I download the actual logic to the PC, but any I/O or GUI stuff I tailor in Reginald. | 7. Everybody has his own story #12131 Posted by: vpaldi 2007-12-06 17:33:50 | Hi,
I really appreciate the in-depth explanation from Jeff and thanks for all comments and suggestions. The consequence is that I will scrap the fresh version and install the traditional Reginald version. But let me tell you my story:
Maybe you understood that my REXX code was a legacy one, I did not touch it for years on the PC. My problem was an urgent one, and I thought that I do have a solution - which apparently was not the case. This situation implied my original post.
The second post is more generic. I wrote lots of scripts which run UNCHANGED on different platforms. A few example:
- analysis of textual data using the very powerful parsing capabilities of REXX
- dumping files in HEX/EBCDIC/ASCII
- code page conversion
- converting national language characters in HTML text to HTML character entities (we have 18 in Hungarian!)
- building CSV files for Excel input on the platform where the data resides
- and many more
Nothing to do with ISPF, Editor macros or TSO line mode commands. Simply file IO and text manipulation. (Nota bene I wrote huge applications for ISPF, but that is a different story)
The key was the data transfer between routines via the data stack.
Let me spend a few minutes on the word of "efficiency". Efficiency has a meaning in the performance arena, and also in the human sphere. REXX is efficient for myself because I can easily solve problems with a REXX interpreter on any operating system. I can be a pro in one or two systems but not in all. Rarely I do need some scripting or fast programming on systems where I am novice (last week in AS/400 - I used REXX to dump ASCII data in the EBCDIC environment), so I treated - and still treat - REXX as one of my best "friends".
I hope that this gives an explanation why I feel so important the legacy functions and downward compatibility.Best regards,
Vince | | Forum List • Thread List • Reply • Refresh • New Topic • Search • Previous • Next 1 |
|
|
搜索
论坛
Home
回顶部
g.yi.org Hits:0
