Thanks Timothy! I will put these on the list of options. (GDDM sounds very interesting, though perhaps too much in the way of programming requirements on the z/OS side.) Frank
>________________________________ > From: Timothy Sipples <sipp...@sg.ibm.com> >To: IBM-MAIN@LISTSERV.UA.EDU >Sent: Wednesday, October 2, 2013 2:29 AM >Subject: Re: TN3270 emulator application scripting > > >Frank, just to clarify, are these the ingredients for the new pattern: > >1. Maintain the 3270 user interface paradigm; >2. Allow in-line or pop-up presentation of contextual information >(signature images) based on a field value (account number) displayed in the >3270 interface; >3. If possible, eliminate the Windows application and its use of an API >that the emulator provides (EHLLAPI in this case) -- "make it simpler." (I >like that impulse.) >? > >If I've understood the basic ingredients correctly, I can think of at least >a couple options. In no particular order: > >A. IBM's emulators (Personal Communications and Host On-Demand) support >platform-agnostic Host Access Class Libraries (HACL). A HACL program could >be invoked by the user via hotkey which would then provide the same >function. This is Java coding with well-documented class libraries (HACL), >so it should be comfortable and familiar to anyone with Java programming >skills. It works on any platform that supports the IBM emulators: Windows, >Mac OS X, Linux, etc. (I would probably use HACL rather than macros for >this use case to get some more flexibility and power.) > >The HACL program (applet) can be stored and maintained on any HTTP server >accessible from the client. > >B. Another simple way to do this would be to change the 3270 presentation >very slightly so that the account number appears somewhere on screen more >or less like this: > >http://xyz.ab/n?ABC54321 > >where ABC54321 is the account number. The account number could even have a >different attribute to make it stand out (and the http://xyz.ab... part >maybe gray on black or something like that). The xyz.ab part refers to a >short internal Web server URL accessible from the client. That in turn >opens a Web page to that Web server, and the Web application would pick up >the account number and display the desired results in the Web browser. > >The reason this sort of approach would work is that many terminal emulation >programs -- including IBM's Personal Communications and Host On-Demand, but >also some others (that copied IBM?) -- will automatically turn anything >that looks like a Web address into a clickable link. If that clickable link >then happens to go to a Web application that grabs some of the information >from the URL (account number) and processes it to display other results, >great. All you have to do is prepend "http://xyz..."; in front and the >(modern) terminal emulator will take care of making that a clickable >hotspot for the user. > >Well over a decade ago I put in a requirement to implement this feature, >and IBM did. I guess I'll take credit at least if nobody else wants it. :-) >The intention was to make it really easy to bridge between 3270 and Web >presentations on a flexible, ad hoc basis. And so it is. As said, I don't >think the whole URL string has to have the same 3270 display attributes -- >you can have the first part gray and the latter part green, or whatever. It >requires changing the 3270 presentation slightly, and then of course you >have to have a "catcher" Web application that knows what to do with such a >URL. You'd also need to make sure the user's Web browser presents the >information in the right spot in the right way, so you might have some >Javascript to do window positioning (also letting the browser know that's >OK, that this particular Web site should be allowed to pop up windows and >resize them). This works really well if you already have a Web application >that can display the information you need, though it's best if you set up a >"tiny URL" entry point if you don't have one already so that you don't have >to spend too many characters (gray or otherwise) inside the 3270 >presentation. You could even try hidden text for the first part of the URL >and see if the emulator still likes that. It might. > >I'm not sure which hotkey is mapped to URL clicking or whether it's >remappable, but probably yes, there is that flexibility. Or the user can >just click on it. Probably, though, you'll have some keyboard jockeys who >will prefer the hotkey approach, and thus you'll want to make sure you can >tie that specific hotkey to a "click on the URL" action. Yes, that's doable >one way or another, at least in IBM's emulators. > >Note that the URL can point directly to a Web application running on z/OS. >No separate servers are required. > >C. IBM GDDM (Graphical Data Display Manager), which is supported in >Personal Communications for example. That is, you can embed graphical >content directly in the 3270 presentation -- 3270 with GDDM supports that. >Signature images are a classic use case for GDDM, in fact. There are >absolutely zero client requirements except to have a 3270 terminal emulator >with GDDM support -- everything else is handled and maintained on the host >side, including deciding which function keys bring up particular image >data. This would likely be the most elegant solution for the 3270 >enthusiast user in part because it would maintain single "plane." rather >than pop-up windows. > >D. GDDM is about adding image content to 3270 presentations. The converse >(obverse?) of GDDM would be to bring the 3270 content, look-and-feel, and >most behaviors into a Web browser. That would be Rational Host Access >Transformation Services (HATS) within the IBM portfolio. HATS can do many >things, but one thing it can do very well is present a high fidelity 3270 >terminal emulation environment using HTML and Javascript ("Classic >Terminal" template), and then that presentation of course can also have >in-line image content added. However, if you're addressing the needs of >"hardcore" 3270 interface users, even HATS and "Classic Terminal" might be >too much too soon. It depends on whether and how quickly you want to move >them into Web user interfaces. If these users love to do their own keyboard >remapping, run client macros, do a lot of special printing, run other >client/server API applications, or otherwise have "hardcore" emulator needs >then one of the other options might be better. "It depends." > >Hope that helps, and please follow up if I didn't explain these ideas >clearly enough. > >-------------------------------------------------------------------------------------------------------- >Timothy Sipples >GMU VCT Architect Executive (Based in Singapore) >E-Mail: sipp...@sg.ibm.com >---------------------------------------------------------------------- >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
