Re: Standard (needed) GUI App Launcher
On Mon, 24 Nov 2014 11:58:59 -0600, Paul Gilmartin paulgboul...@aim.com wrote: (I'm not going to experiment with it. How does z/OS Java display graphics, anyway?) Via X-Windows. Start an X-server on your PC, set the appropriate environment variables, then fire up the JVM from USS. I've done that for a couple of different things, including installing SAS and running Helma's interactive Rhino debugger. Both worked surprisingly well. (Yes, that means I was inspecting JavaScript code running under Rhino in a JVM on z/OS. Again, works somewhat surprisingly well.) Scott -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Standard (needed) GUI App Launcher
many OSes have terminal commands that take an object name as an argument and launch the associated application. For example, a browser for a URL; a file manager for a directory; or an editor for a text file. SimpList works like that. A single line of code (such as in a user written REXX dialog) can call the SimpList API and pass it one or more arguments. The arguments usually consist of a function to perform and an object to perform the function against. This might mean the SimpList API is called to browse a data set or edit a DB2 table or view a web site or print a Unix file (etc.). Depending on what SimpList was called to do, it automatically launches the associated application. For example, if SimpList was passed an URL it would use the ISPF Workstation Agent to open a browser and display the web page. Dave Salt SimpList(tm) - try it; you'll get it! http://www.mackinney.com/products/program-development/simplist.html Date: Mon, 24 Nov 2014 11:58:59 -0600 From: 000433f07816-dmarc-requ...@listserv.ua.edu Subject: Standard (needed) GUI App Launcher To: IBM-MAIN@LISTSERV.UA.EDU There's a thread on ISPF-L where the OP wants to launch a browser for a URL in an ISPF panel. Evidently he's looking for a terminal-emulator-specific solution and got several suggestions. But how about running the browser on z/OS? Lynx is Curses-constrained. Are there any others, perhaps based on X11 and fairly portable? Or?: http://sourceforge.net/projects/xamj/ (I'm not going to experiment with it. How does z/OS Java display graphics, anyway?) But more generally, many OSes have terminal commands that take an object name as an argument and launch the associated application. For example, a browser for a URL; a file manager for a directory; or an editor for a text file. Examples: OS Xopen Solaris gnome-open Linux xdg-open Cygwin cygstart Windows ? A dismaying lack of portability. One might imagina a chain of #ifdefs such as: ... #if defined(__linux__) #define GUI_open( object ) system( xdg-open object ) #endif ... Ugh! There ought to be a standard. -- gil OS X open LInux -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Standard (needed) GUI App Launcher
Windows start - but most likely a Windows terminal emulator would use the ShellExecute function to start an external browser session. About 6 months ago I was working on compiling Info-Zip (c source code). Wiki claims it is The Third Most Portable Program in the World, so you can imagine all the #ifdef's in that code. Very difficult to work with. Paul Gilmartin wrote: OS Xopen Solaris gnome-open Linux xdg-open Cygwin cygstart Windows ? A dismaying lack of portability. One might imagina a chain of #ifdefs ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Standard (needed) GUI App Launcher
On Mon, Nov 24, 2014 at 2:37 PM, Tom Brennan t...@tombrennansoftware.com wrote: Windows start - but most likely a Windows terminal emulator would use the ShellExecute function to start an external browser session. About 6 months ago I was working on compiling Info-Zip (c source code). Wiki claims it is The Third Most Portable Program in the World, so you can imagine all the #ifdef's in that code. Very difficult to work with. I wonder what the first two are. I was able to port SQLite 3 to z/OS with _NO_ source changes at all. I just had to figure out the correct ./configure and do the make. BASH took more effort. The majority was getting the embedded GNU readline to work on z/OS properly and a few ASCII-isms where the code was dependent on the ASCII binary code points. I used #if statements to separate out the required z/OS changes which were Linux incompatible. But I can't say that it was really _difficult_. Other than due to my own ignorance on how BASH works internally and of advanced C constructs. Paul Gilmartin wrote: OS Xopen Solaris gnome-open Linux xdg-open Cygwin cygstart Windows ? A dismaying lack of portability. One might imagina a chain of #ifdefs ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- The temperature of the aqueous content of an unremittingly ogled culinary vessel will not achieve 100 degrees on the Celsius scale. Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Standard (needed) GUI App Launcher
I had ASCII trouble with Info-zip too. Someone apparently added code to ignore the -a (ascii conversion) option if the input data looks binary. Well, EBCDIC text looked binary to the new code, so the -a option wouldn't work at all on MVS. That's one downside to #ifdef's - you really need to compile and test your changes on each platform. So a few platforms is no big deal, but dozens? That's just asking for trouble. John McKown wrote: I wonder what the first two are. I was able to port SQLite 3 to z/OS with _NO_ source changes at all. I just had to figure out the correct ./configure and do the make. BASH took more effort. The majority was getting the embedded GNU readline to work on z/OS properly and a few ASCII-isms where the code was dependent on the ASCII binary code points. I used #if statements to separate out the required z/OS changes which were Linux incompatible. But I can't say that it was really _difficult_. Other than due to my own ignorance on how BASH works internally and of advanced C constructs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
