Thomas Adam <[email protected]> writes: > On Thu, Aug 13, 2020 at 09:02:09PM -0400, Dan Espen wrote: >> First, DTL is crap, you really want to use ISPF as it was originally >> designed. You create a text image of the screen using punctuation >> to mark input and output fields. > > Hehe. It's an interesting idea and one which probably still survives to this > day. For instance, QT still uses XML to describe layout of widgets -- or it > did. But the fact remains that the idea of using text to describe graphical > forms is cool. > > It's a little bit like Perl's now deprecated format specifier, and Oracle DB > used to have ways of formatting output to look like forms as well. > >> Second, he says you have to restart ISPF to be able to access your >> changes. But that start command he was issuing does not restart ISPF >> and he showed himself going to option 7. > > Hehe -- thankfully I wasn't using that video as anything instructional, > otherwise I'd have been up a creek without a paddle. By the way, I made an > assumption that ISPF was somehow old and not used much. But it turns out it's > still got a strong following and still maintained by IBM. > > So where would this typically get used? I can imagine its use for things like > help desks and bespoke processes where panels could be rolled out to people > for liaising with customers... > > Mind you, with things like Zendesk and other HTML-based efforts, I can see > ISPF being less attractive unless it was already there.
ISPF is used mainly for developers to enhance their workflow. That's what I was doing with it. You could develop applications with it but they'd be conversational. On mainframes you want to be transactional for the thruput. The popular transactional environments are CICS and IMS/DC. >> Third, there's zero reasons to write REXX for a menu, the panel itself >> can do the entire job. > > Yeah. I was wondering that. I've used REXX once... I rather liked it, but I > wasn't sure it was applicable to what the chap in the video was attempting to > do. Yep, there is a Unix version of REXX and it's a reasonably good scripting language. Last time I looked I think the only available GUI interface for REXX was TK. I didn't find TK appealing. >> TBADD is just like creating an array in a unix shell. >> So you build up an array then in the panel your name for the array. >> The panel figures out how big the array is and displays as many >> occurances as it can fit on the screen. > > I'm going to dig a bit deeper in to this, Dan as I find it all rather > interesting. I'll probably chat to you off-list as I'm sure others reading > this are probably wondering if FvwmForms is going to become some sort of ISPF > emulator (no, it's not! ;)). I agree about going offline. We've already covered how I was deriving some inspiration from it for FvwmForm. > Incidentally, I did find this (as someone's pet project): > > https://github.com/daniel64/lspf > > There's definitely a lot of folks around who are interested in this. Cool. Yeah I've heard of it. It looks pretty good too. If you want to see more and don't have access to a mainframe this ISPF on unix thing would probably be a good thing to look at. Like I've said, I used to do loads of work in it to automate my MVS development work flows. But around 2000 I decided I'd had enough and I moved all my development work flows over to Unix, first SunOS then Linux. I decided Emacs, Makefiles, grep, etc. were just too good for what I needed to do. I got a lot farther that way. I could work for weeks doing compiles, testing, builds the whole process without ever having to look at a 3270 screen. >> A lot of the tables you saw being displayed as he was working are the >> development panels from IBM. They're totally uninspired, I had a lot >> of fun creating replacements. > > Yes, I bet you did! > >> I once ran a help desk for a large herd of UNIX C programmers forced >> into working with ISPF. They pretty much hated the environment. >> I unleashed a bunch of panels I had written on them and they were >> converted on the spot. > > Given the length of their beards, I can only presume that's proportional to > their hatred? :) I can understand how some dyed-in-the-wool C chaps being > forced to use ISPF wouldn't like it -- and that's just me surmising with ~10 > minutes worth of video watching. :) But these panels are a God sent. > >> I never used Rational Rose. > > Neither did I in the end. Think we both dodged a bullet there. > >> I wish I could show you some of the stuff I did, but of course that >> belonged to my employers so I left it behind. > > Well, even mockups might be useful further down the road. > >> > Well, it's back: >> > >> > https://github.com/fvwmorg/fvwm3/commit/6e65b85d127de9b18022c8073974c2f3745b14a1 >> >> Good, I think you made the right choice and it should save you some work >> anyway even if the source code base is a bit larger. > > Yeah, well, sometimes it's not just about the SLOC. > > In digging around what FvwmScript offers, and what FvwmForm was doing, I can > perhaps understand why we have two similar modules. But the more I look at > FvwmScript the more I can see just how similar it is to what FvwmForm does, > and that FvwmScript doesn't provide the flexibility that FvwmForm does in how > it approaches the text <-> layout point. It's much more explicit/error prone > in FvwmScript. > > I think I'll start in getting some sort of widget parity between FvwmScript > and FvwmForm. I probably won't ever end up writing anything to convert > FvwmScript configs to FvwmForm -- that's much harder. Not least of which > because FvwmScript's config parsing is wholly written in YACC. > > Then I can look at tables. > >> By the way, I think you've been doing some impressive work. > > Cheers! > >> I don't know if I'm slowing down due to age or what, but I'm finding it >> increasingly hard to do any coding. I've been working out and doing >> lots of physical work on the house and in the yard. Maybe I'm just >> reveling in not having to do coding any more. > > I never wanted to be a computer programmer. I had my heart set on > geochemistry. Turning my hobby (programming) in to my career though hasn't > been so bad. But since I do much more management day-to-day than programming > now, it does mean I've started to enjoy programming in my spare time now more > than I used to. Interesting. I started programming in 1964 and loved it right up until I retired. I took a short cut into management and decided it definitely wasn't for me. I do enjoy manual labor too, like that guy from Office Space but I guess I liked design and coding more. > I suppose that's the difference -- you just need to indulge in something else > before the bug returns... > > Whenever that is for you, Dan, let me know. I could use the help! :) > > Same goes for anyone thinking they don't know C or can't help out. I'd much > rather mentor someone than not have them contribute -- as any help is better > than nothing, Back at the beginning of my involvement we had the current structure, one main developer and most people watching. The main guy would get burned out and progress would bog down. Then we went through a period with 4 or 5 guys that were pretty enthusiastic. That's when Fvwm Workers came about. That lasted a couple of years I think. Sadly things don't last and that era faded away and never really came back. You do seem to be getting a bit of help lately though. If you find someone enthusiastic you might want to try it again. Of course things are pretty different now. Fvwm is in some respects a finished project and there are so many other WMs it's harder to get everyone pulling in the same direction. -- Dan Espen
