Re: TN3270 emulator application scripting
In of6b3396e7.c94acf73-on48257bf9.00206eff-48257bf9.00271...@sg.ibm.com, on 10/03/2013 at 03:05 PM, Timothy Sipples sipp...@sg.ibm.com said: I don't know enough to recommend a specific path among those I suggested, What about the choice of APA versus PSS if the terminal simulator supports both? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TN3270 emulator application scripting
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: 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
Re: TN3270 emulator application scripting
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: sipp...@sg.ibm.com -- 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 jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TN3270 emulator application scripting
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
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
Re: TN3270 emulator application scripting
We have converted from host explorer to bluezone. Both support scripting and macros and/or vb and .net for creating windows apps. We have both vb and .net apps as well as scipts and macros that are launched from the emulator. You can contact me offline if you need anything more Regards Robbie GHC Confidentiality Statement This message and any attached files might contain confidential information protected by federal and state law. The information is intended only for the use of the individual(s) or entities originally named as addressees. The improper disclosure of such information may be subject to civil or criminal penalties. If this message reached you in error, please contact the sender and destroy this message. Disclosing, copying, forwarding, or distributing the information by unauthorized individuals or entities is strictly prohibited by law. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TN3270 emulator application scripting
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
Re: TN3270 emulator application scripting
Frank Swarbrick wrote: Not really sure what to title this, so... We currently have a Windows application that uses our terminal emulator's EHLLAPI functionality. If you have the application running and you hit a particular function key (I think!) while your terminal session is on an account number it will trigger the application to read a database and pull up signatures (within the Windows application) for each signer on the account. Our CTO is wondering what alternatives we might have to eliminate both the Windows application and the use of EHLLAPI. Are there perhaps features of any TN3270 emulators that would allow you to perform something similar but all within the emulator itself, rather than having an external application use EHLLAPI to communicate with the emulator? Or something else? We already have a web interface that has the same basic feature, but this is intended for those that still access CICS directly via TN3270 sessions. Pretty well every emulator I've seen supports scripting. What emulator are you using now? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TN3270 emulator application scripting
On 2013-10-01 11:37, Frank Swarbrick wrote: We currently have a Windows application that uses our terminal emulator's EHLLAPI functionality. For starters, what TN3270 emulator are you using? -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TN3270 emulator application scripting
We currently have E-Term for IBM from DCSi. I personally don't like it and really am open to any emulator. A few of use (myself included) have Attachmate Reflection for IBM. It seems to have several options, one being a .NET API. Without really knowing about it it seems like that might do the trick. I guess I'm wondering in general what type of interfaces people have written and what emulator and API was used? From: Gord Tomlin gt.ibm.li...@actionsoftware.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, October 1, 2013 9:50 AM Subject: Re: TN3270 emulator application scripting On 2013-10-01 11:37, Frank Swarbrick wrote: We currently have a Windows application that uses our terminal emulator's EHLLAPI functionality. For starters, what TN3270 emulator are you using? -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 -- 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: TN3270 emulator application scripting
Vista is a wonderful product but I don't think it is able to query a database. I just searched the Help and got zero hits on SQL or database, and the one hit on query was about querying its own options settings. You can read or write a sequential file from Vista. If you could get the data from your database to a flat file you might be able to make it work. Its scripting language appears to be self-contained with no way to break out of the Vista sandbox. You really need a scripting language that either supported database queries directly, or allowed you to escape out to a .NET language or something like that. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gord Tomlin Sent: Tuesday, October 01, 2013 2:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: TN3270 emulator application scripting On 2013-10-01 12:25, Frank Swarbrick wrote: We currently have E-Term for IBM from DCSi. I personally don't like it and really am open to any emulator. A few of use (myself included) have Attachmate Reflection for IBM. It seems to have several options, one being a .NET API. Without really knowing about it it seems like that might do the trick. I guess I'm wondering in general what type of interfaces people have written and what emulator and API was used? I've never used E-Term, but I have PCOMM and Vista TN3270 on my machine, and both offer scripting support. Our relatively old version of PCOMM supports the use of VBScript, and Vista has its won macro language. Passport PC to Host also offers macro support. I haven't specifically checked the macro/scripting support of any of the products to determine whether they would be able to query a database and return a result to the macro/script. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TN3270 emulator application scripting
Charles, I would not rush to judgement on this. *IF* it can script a response to a 3270 screen, say enter part number and it send the part number to the host and what ever is returned from the host should be readable and then the script could do its thing. I have a difficult time with this myself but it probably should be doable but it may be difficult. Ed On Oct 1, 2013, at 5:03 PM, Charles Mills wrote: Vista is a wonderful product but I don't think it is able to query a database. I just searched the Help and got zero hits on SQL or database, and the one hit on query was about querying its own options settings. You can read or write a sequential file from Vista. If you could get the data from your database to a flat file you might be able to make it work. Its scripting language appears to be self-contained with no way to break out of the Vista sandbox. You really need a scripting language that either supported database queries directly, or allowed you to escape out to a .NET language or something like that. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM- m...@listserv.ua.edu] On Behalf Of Gord Tomlin Sent: Tuesday, October 01, 2013 2:37 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: TN3270 emulator application scripting On 2013-10-01 12:25, Frank Swarbrick wrote: We currently have E-Term for IBM from DCSi. I personally don't like it and really am open to any emulator. A few of use (myself included) have Attachmate Reflection for IBM. It seems to have several options, one being a .NET API. Without really knowing about it it seems like that might do the trick. I guess I'm wondering in general what type of interfaces people have written and what emulator and API was used? I've never used E-Term, but I have PCOMM and Vista TN3270 on my machine, and both offer scripting support. Our relatively old version of PCOMM supports the use of VBScript, and Vista has its won macro language. Passport PC to Host also offers macro support. I haven't specifically checked the macro/scripting support of any of the products to determine whether they would be able to query a database and return a result to the macro/script. -- 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: TN3270 emulator application scripting
You're right. That is the sort of thing the OP wanted. I was thinking of querying a local database on the PC. IMHO an EHLLAPI program is a better way (NOT a good way LOL!) of doing this than a script. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Gould Sent: Tuesday, October 01, 2013 3:08 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: TN3270 emulator application scripting Charles, I would not rush to judgement on this. *IF* it can script a response to a 3270 screen, say enter part number and it send the part number to the host and what ever is returned from the host should be readable and then the script could do its thing. I have a difficult time with this myself but it probably should be doable but it may be difficult. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
