As an example of the stuff I do, my last mainframe Rexx program was designed to scan a PDS searching for members that contained ALL search strings. The tools that were available returned any member that contained at least one, but necessarily all, search strings. This could easily(?) be adapted to work with SPFLite. Obviously the input panel would have to be replaced by line prompts and the search folder/file names handled by DOS commands etc. This was not an edit macro but it might be something I try if the FIND command was somehow available. Maybe there is some DOS utility that I don't know about that could do that in which case the possibility of Rexx with SPFLite would be a moot point.
Macros I could think of would be for writing program header comments, function/procedure header blocks and even a basic skeleton program for various languages.
Macros that I do have in my tool box: HX - toggles HEX ON/OFF; : NX - excludes all lines except those that contain the string parameter.
However - what I most miss is what I would not expect you to come up with and that is Dialog Services. :-)
Yes, YES ! Was my first thought, because I like to use REXX for about anything ;-) But on the other hand, I didn't use a lot of REXX-Macros and I do not require ISREDIT or ISPEXEC syntax-support, I can live with the current macro language. So, if you include REXX support with the same functions as now in thinBasic, I will use REXX instead of thinBasic. And if it would be possible to start a new EDIT-session with an Initial-Macro, yes, I would use that ;-) Or maybe, calling a macro in the File-Manager-Session ;-)
There's a few reasons. First, there is only one decent Rexx engine, and that is Open Object Rexx, or ooRexx. As a stand-alone Rexx engine, it does a fine job. As something for another program like SPFLite to interface to, it is quite complicated, and doesn't fit well into our architecture. That is not an insurmountable problem, but it takes work.
I actually use Regina Rexx as I do not do OO programming. You could approach Mark Hessling, the maintainer of Regina, to see if he would be prepared to help out in including Rexx as a macro language.
At my stage in life, everything is a hobby and nurturing technical vitality is just another way of avoiding brain atrophy. Elsewhere I wrote
I had a background of mainframe VM/REXX. I discovered how to start TSO in mainframe MVS and run REXX within it . . . I did not pursue REXX on the PC , but . . (a) . . quick comment just reminded me to check it out again.
This puts me at the same stage of re-learning REXX that I had with DOS batch script about three years ago. At my level, I am just happy to edit and run the code. I cannot contribute much to your choice, but thanks, for your discussion, which has influenced me to allow OORexx onto my PATH. So I remain a loyal user with no pressing demand on this survey topic.
Post by RPrinceton on Apr 15, 2019 16:44:42 GMT -5
Hello, I currently have CTC's product. I also have the ORIGINAL CTC SPF product. In their quest to be more Windows oriented, CTC decided to implement a subset of 'C' in lieu of REXX. HUGE mistake. It is extremely cumbersome to do anything, especially dialog manager functions. As I have stated I have the original CTC SPF. It functions under 32 bit Windows systems. I have 32bit Win7 loaded into a VM and the original CTC SPF still functions although it is a 16bit app and admittedly is becoming increasingly more difficult to make work. It had full blown REXX! The only thing missing in the original CTC SPF was "long file name" support. In my considered opinion, CTC should have pursued supporting "long file names" instead of destroying a stable product. I am looking for a replacement and came across SPFLite. I am beginning to embrace it. I am having a bit of an issue making the file profiles work as I thought they would. I will address that in a different area of the forum. With all that said please make REXX part of the product. I'd be more than happy to be a beta tester for the REXX component. Sincerely, RPrinceton
SPFLite is touted to be an ISPF Editor look alike. ISPF Editor supports Edit Macros written in REXX, (not Basic). (My guess... mainframers, by in large, do not know Basic, nor have a desire to learn Basic, (no matter how Thin)). Therefore SPFLite should support Rexx Edit MARROs. QED :-}
Ren: Look, Robert and I are both old mainframers, and both of us spent years using REXX and ISPF, so our initial "lets add macros" thoughts were to add REXX.
But experimenting with the interface to ooREXX and drafting even basic specs for what it would take basically just freaked me out. There was simply no way I could see it getting done.
So thinBasic was used as it was something we could actually accomplish in our lifetime. And actually, given the choice of REXX/ISREDIT and thinBasic/SPFLite functions, I'll take our choice every day.
And most mainframers in their career probably had to learn a whole list of languages, it was never a problem. I can't believe having to use Basic would throw anyone for a loop.
Tossing this all off by saying since ISPF did it, therefore SPFLite should do it is asking a bit much from a free package, supported by 2 people trying to back out of working on this thing every day of our retirement.
I think you guys have done an amazing job. I was just giving you my opinion, which was for what you asked at the start of this thread.
Hmmm, I wonder if a translator (emulator) could be written that would generate ThinBasic from Rexx? Albeit, no ISPEXEC (Except that the VPUT, VGET, and VERASE handling could be mimicked using SETVARS and/or actual file writes).
PS: REXX and the Dialog Manager are my favorite languages (products). I think the Dialog Manager is vastly under-rated and vastly un-exploited. (I guess the Dialog Manager didn't use enough machine time compared to CICS and IMS/DC, so it was not really marketed by Big Blue). I used it all the time when prototyping on-line screens.
Ren: I agree Dialog manager was super. Where I worked for years I supported a dialog extension which was like a version of 3.4 on steroids. It did everything including interfacing with the Tape management system making a seamless display of files regardless of what media they existed on. It had every option under the sun, like PDS member recovery, variable free space release, PDS directory expand (before the PDSE days) etc. Most users, I bet even today, have no appreciation of what could be done using dialog manager.
Rexx support isn't just supporting REXX, the hardest part is ISREDIT. And if we said we support it, users would expect to import old ISPF REXX scripts and have them work flawlessly. A lot of users didn't really write their REXX scripts, they just 'got a copy' from someone else and are not really capable of debugging them when they don't work. We'd end up with user's saying "why doesn't this REXX work perfectly" and expecting us to do the debug work. Any implementation we did would never be good enough.
George, too bad there is not more interest in REXX. Based on your implementation of SPFLite, I have no doubt that if you chose to implement REXX Edit MACROs it would be as clean. But you are right a lot of work for no payback. :-(
Robert, yeah, I was thinking an Edit MACRO that would read the REXX source and generate ThinBasic source. (At least as much as it can).
I see your point, if you want to use the product, here are your choices: CLIST or REXX, period. (But, IMHO, REXX is a wonderful language, and the "stems" and INTERPRET are very cool). Cowlishaw did not have a choice about giving it away, he was an IBM employee, and anything he developed was theirs. I'm just glad that IBM embraced it and thought so much of it they replaced EXEC on VM with it and ported it to MVS, VSE, AS400, AIX, OS/2, IBM-DOS. :-)
I'm starting to get my "Thin" MACROs to work. :-) I've been thinking of re-writing one of my smaller REXX programs into ThinBasic just as an learning experience.
I can't believe it's taken me this long to register this thread(!) but for what it's worth, I would use Rexx if available. I can definitely relate to many of the above comments, both about Dialog Manager and how CTC destroyed what was a great product. It sounds like a shed load of work to do, so I'm not holding my breath. SPFLite is a great product anyway, but that's my two penn'orth (two cents worth)!
Clive: One thing not mentioned in this thread is that thinBasic and SPFLite are BOTH written in PowerBasic. And PowerBasic is fast, after all it was originally called TurboBasic. So the interfaces are all very efficient, no need for 'wedges' to handle transferring back and forth.
When I first experimented with thinBasic to see whether it would work as the macro language. It was basically trivial. The real work was in figuring out just what functions we needed/wanted and writing each one. We evolved to over 150+ functions, none were very difficult, it was the Doc. that was a killer.
Compare the steps needed to creating a new Line command with REXX in ISPF-land and doing the same in SPFLite. A world of difference.