Joel C. Ewing writes: >Anyone who ever used the old TSO BookManager interface to look at >manuals and display figures in manuals was experiencing the GDDM 3270 >graphics support, and that experience more than likely made them glad to >forget such support existed.
I'm going to mostly disagree with you here, Joel. The BookManager interface used GDDM, yes, but it used it in ways quite unlike Frank's use case. >Most images required bit-image display, and images with significant >detail could easily require 5-10 seconds to display; Yes, and the most likely reason for that was you remember 9600 bps (or slower) connections via terminal controllers. You remember GDDM of a particular era, not GDDM. (One of the recurring problems in IT: the assumption that a past experience within particular constraints would be like today without those constraints.) I also remember 300 baud modem connections. Interacting with Facebook over such a connection wouldn't be viable either. That's not today's world. The relevant constraints were lifted some time ago. >each zoom or re-position of the image to adequately view the entire image >required a repeat of that lengthy display process; and >normal text couldn't be shown at the same time. Yes, you're describing a part of GDDM over bandwidth-constrained connections. I'm recommending using another part of GDDM, the one that gets along great with BMSes, to display signature images with text. GDDM has many parts, many APIs, each with different characteristics and attributes, none of which have to cope with 1970s/1980s bandwidth constraints. >Serving the same BookManager manual from a z/OS-based web server and >BookServer was much faster and allowed the full power and convenience >of graphical support on a workstation to be used and gave much better >image quality. Well sure, stipulated, Web browsers are wonderful (with bandwidth). I also illustrated Web-based approaches, and I like them too. But the Web wasn't a viable choice (or any choice) between 1979 (GDDM's inception) and the mid-1990s or later. Frank has users that want 3270 interfaces, as many users do. (Not all! Web, mobile, IVR, etc. are all important!) In that case, GDDM *has* to be on the short list for displaying signature images. Not necessarily the final choice, but definitely on the short list as one of the viable approaches. When you reduce the problem statement to its essence, the question is "How (else) do I display a signature image in or with a 3270 screen?" And one simple answer is, "Just send the image to the 3270 terminal (3179G or better emulator); it can display images." Sure, there are options that are a little closer to Rube Goldberg -- I provided some, though mine are all less Rube Goldberg than the status quo -- but the simple answer has got to be on any short list, one would think. >Admittedly, one of the cute things about GDDM 3270 graphics was that a >3270 image could be easily printed on a 3270-protocol-compatible >dot-matrix printer. Back in the old days before workstations and >3270-emulators, and when 3179Gs were considered an extravagance by >management, at one point I realized GDDM provided graphic support on our >existing 4224 printers at no additional cost. Yes, exactly. "Hardcore" 3270 users will have these sorts of capabilities with GDDM (and some others). If their personal workflows are important -- they often are -- then these sorts of simple capabilities will often be deciding. (Not printing to 4224 printers, though, but to local and network PC-addressable printers, print-to-PDF drivers, etc.) >We used this for years to generate and print a daily CPU performance >graph from SMF CPU data until the cost of GDDM-PGF became excessive >and better alternatives were by then available. You don't need GDDM-PGF for anything in Frank's use case -- or for GDDM printing. Everything required for the use case and a GDDM solution approach should be in base z/OS. -------------------------------------------------------------------------------------------------------- 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
