On 10/03/2013 02:05 AM, Timothy Sipples wrote: >> GDDM sounds very interesting, though perhaps too much in >> the way of programming requirements on the z/OS side. > > "It depends," but probably not. If the signature images are already in DB2 > for z/OS, fantastic. If not, there are fairly straightforward ways for a > CICS, IMS, TSO, or other 3270 application to get them. Getting them into > the right GDDM-friendly format might be slightly interesting though > certainly not insurmountable. COBOL, C, PL/I, REXX, and Assembler are all > fine -- and anything else that can invoke such interfaces (which should > cover everything including Java) -- so you can pick your preferred language > (s). GDDM gets along fine with Basic Mapping Support (BMS) in CICS, for > example. > > It all looks well documented and reasonably straightforward for anyone > doing development and maintenance of applications with 3270 interfaces. > > I don't know enough to recommend a specific path among those I suggested, > but I think all are viable. If the 3270 emulation client you already have > is one of those that supports GDDM (at least full 3179G) then there'd be > *zero* to do on the client with the GDDM approach except perhaps flip a > switch (and shut off the EHLLAPI client code). And I think it's the only > approach if the "hardcore" users want a non-popup (in-line) presentation of > the signature image while keeping everything else exactly the same (highest > performance 3270 interface). Anyway, it's important not to forget that 3270 > protocols and interfaces do actually support graphical content via the GDDM > extensions, and assuming you have a 3270 emulator which supports those > extensions. Displaying graphical information is not particularly new. There > were a couple ways to do it even before GDDM first came along in 1979. > (SAGE in 1955 comes to mind.) > > My understanding is that everybody with a z/OS license has GDDM. There are > two GDDM add-ons (GDDM-Presentation Graphics Facility and GDDM-REXX) that > require additional licensing, but I don't see how you'd need either option > for this use case. > > To correct an earlier comment, I think (in addition to Personal > Communications) Host On-Demand would also be sufficient for this particular > use case with a GDDM approach, but please check me on that. PComm provides > some more comprehensive GDDM functions, but HOD also looks like it'd work > quite well for displaying a signature image delivered with GDDM (as a 3179G > emulator). > > -------------------------------------------------------------------------------------------------------- > Timothy Sipples > GMU VCT Architect Executive (Based in Singapore) > E-Mail: [email protected] > ----------------------------------------------------------------------
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. Most images required bit-image display, and images with significant detail could easily require 5-10 seconds to display; 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. 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. 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. 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. -- Joel C. Ewing, Bentonville, AR [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
