Re: ALTER of open VSAM cluster
On 7/29/2010 at 7:53 PM, in message 4c5230b4.2010...@acm.org, Joel C. Ewing jcew...@acm.org wrote: On 07/29/2010 06:26 PM, Thompson, Steve wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Frank Swarbrick Sent: Thursday, July 29, 2010 5:53 PM To: IBM-MAIN@bama.ua.edu Subject: ALTER of open VSAM cluster It appears we can ALTER FREESPACE while a file is open to CICS (or anywhere else, I assume). Is this an OK thing to do, so the next time the file is reloaded it will use the new freespace values? SNIP The ALTER modifies the definition info in the Catalog (as I recall). So the effect is rather immediate. What this will do is allow you to LOAD with x y for freespace, and then when running change to m n for freespace. So, let us say that you LOAD a KSDS with FREESPACE(0 0) that has 50 CYLs of data. Once the load is complete you ALTER it to FREESPACE(25 25). You know that the majority of the adds to the file will start in the last 2 cylinders of data (as loaded) and go from there. So the CA/CI splits will start at that point. Regards, Steve Thompson ... Steve, If you are implying that changing FREESPACE of a loaded file will affect future adds at the high end of the key range, this is not true. Changing FREESPACE has no effect on a VSAM file already containing records. FREESPACE is only used when the file is in a reset or initial empty state with no records and an initial file load is done. I am also certain that if you could ALTER the VSAM catalog entry while the file is still OPEN for that initial load process, that the running program doing the load is at that point only using in-memory control blocks for the VSAM file with values that were derived at OPEN time, and only future OPENS would see any change. After that intial load, adding a record than doesn't fit in an existing CI results in a CI split with about half the CI records going to a new CI, and if there are no free CI's in that CA, a CA-split is first done to put about half of that CA's CI's in a new CA. The FREESPACE is totally ignored in that process. Even if all the future adds have ascending key values, the add logic is the same. Unless you define the VSAM file with REUSE and have an application that resets the file to empty and reloads all records at some later time without deleting and redefining the dataset, changing FREESPACE after initial load would have no effect. CI splits are relatively cheap, so using CI FREESPACE to minimize CI-splits after initial load has minimal benefit and in cases where a large percent of records must be read may actually reduce performance by requiring reading of more CIs to get the same data. CA-splits are relatively expensive, so there may be special cases where CA-FREESPACE can improve update response consistency after an initial load. But even with FREESPACE(0,0), if updates are clustered by key, performance will improve after the initial CI and CA splits from earlier updates introduce free space at the precise points in the file undergoing repeated changes. Here are the details on the file in question. I just did a CLO ENA in CICS to get update VSAM stats: ATTRIBUTES KEYLEN-9 AVGLRECL-250 BUFSPACE---15872 CISIZE--7168 RKP0 MAXLRECL1900 EXCPEXIT--(NULL) CI/CA105 SHROPTNS(2,3) SPEED UNIQUE NOERASE INDEXED NOWRITECHK NOIMBED NOREPLICAT UNORDERED REUSE NONSPANNED STATISTICS REC-TOTAL-791636 SPLITS-CI---8135 EXCPS1125532 REC-DELETED0 SPLITS-CA228 EXTENTS1 REC-INSERTED---9 FREESPACE-%CI--0 SYSTEM-TIMESTAMP: REC-UPDATED---659805 FREESPACE-%CA--0 X'C65CE0AD26274284' REC-RETRIEVED2903925 FREESPC146055168 The file is REUSE and is reloaded at the beginning of every business day. (So as of the above stats it's been open about 24 hours.) The end of each record is a transaction table that contains up to 20 transactions per day. In other words, as the customer has new transactions the length of the record is extended to allow for this new record and then the record is rewritten. Updates are random (not clustered). When we were on VSE I think we
Re: ALTER of open VSAM cluster
On 7/30/2010 at 5:56 AM, in message 23b13969513a9846a621a4620543d4f977119da...@cdcmw12e.na.convergys.com, John H Kington john.king...@convergys.com wrote: Frank, It appears we can ALTER FREESPACE while a file is open to CICS (or anywhere else, I assume). Is this an OK thing to do, so the next time the file is reloaded it will use the new freespace values? Altering the freespace parameters on a loaded vsam file will not have any effect. If the vsam file has the REUSE attribute and you reload the file, the new freespace parameters will be honored. Be sure to change the freespace parameters on the original define in case you do a delete, define and reload of the vsam file. This is exactly what I want. Interesting comment on the original define. We don't save our original defines; nor do we generally do a DELETE/DEFINE when we reload a file. We always (except when not allowed; ie AIX) use REUSE. Thanks, Frank -- Frank Swarbrick Applications Architect - Mainframe Applications Development FirstBank Data Corporation - Lakewood, CO USA P: 303-235-1403 The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ALTER of open VSAM cluster
No wonder I couldn't find it. I was looking under ALTER in DFSMS Access Method Services for Catalogs and could fine no mention of when it would take affect. On 7/30/2010 at 7:52 AM, in message cd22aa1aee707d489d9250d13e3862a1858765b...@nihmlbxcms02.nih.gov, O'Brien, David W. (NIH/CIT) [C] obrie...@mail.nih.gov wrote: Please see 2.5.3.2 Altering the Free Space Specification When Loading a Data Set in z/OS V1R11 DFSMS Using Data Sets for a definitive answer. The manual does state the file needs to be closed for the new Freespace values to take effect. Thank You, Dave O'Brien NIH Contractor From: Thompson, Steve [steve_thomp...@stercomm.com] Sent: Friday, July 30, 2010 9:41 AM To: IBM-MAIN@bama.ua.edu Subject: Re: ALTER of open VSAM cluster -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Joel C. Ewing Sent: Thursday, July 29, 2010 8:54 PM To: IBM-MAIN@bama.ua.edu Subject: Re: ALTER of open VSAM cluster SNIPPAGE ... Steve, If you are implying that changing FREESPACE of a loaded file will affect future adds at the high end of the key range, this is not true. Changing FREESPACE has no effect on a VSAM file already containing records. FREESPACE is only used when the file is in a reset or initial empty state with no records and an initial file load is done. I am also certain that if you could ALTER the VSAM catalog entry while the file is still OPEN for that initial load process, that the running program doing the load is at that point only using in-memory control blocks for the VSAM file with values that were derived at OPEN time, and only future OPENS would see any change. SNIP Unless something has changed since z/OS 1.1, and a third party product would give new behaviors -- even when not being directly invoked, that is exactly what we did at a certain insurance type company for their customer claims file. It was laid down with NO freespace. Then it was altered pretty much the way I said. The CICS system was brought up after the ALTER (which is why I said the catalog info was changed -- I didn't mean to imply an open file would get this behavior without an intervening close). Meanwhile, I was interpreting the original op's question on the basis of the alter being done for current operations, not later reloading the file. Yes, in that case the file must be defined with REUSE. SNIP Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html The information contained in this electronic communication and any document attached hereto or transmitted herewith is confidential and intended for the exclusive use of the individual or entity named above. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any examination, use, dissemination, distribution or copying of this communication or any part thereof is strictly prohibited. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Access z/OS 3270 TSO from smartphone?
IBM could probably pay some 12-year-old $50 to write it between classes at grammar school. My nephew (he's 12) told me last week that he was upset that his Java teacher didn't even know how to properly set up the IDE to write and debug. I felt really old. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
ALTER Freespace
A long time ago, I encountered a concept called Resume Load in VSAM. It addressed the case where multiple (two or more) records (in Ascending Key sequence) were added to a file either at its end, or between two consecutive records. In each case FreeSpace would be honoured. The former case addresses the load the file in chunks already discussed. SPEED would only apply to the first such loading. The latter case was designed to overcome the problems when a file had a trailer record which always had a higher key (often nX'FF') than the data records being inserted. This was a recognised problem with ISAM whose performance deteriorated when this situation occurred. The presence of trailer records was reputedly introduced (at least partly) by the desire to detect EOF on a sequential file rather than rely on tape drives (I am talking about the early sixties here.). Subsequently the trailer record was found to be useful in collating hash values etc and often became a part of system design, even if the file was accessed both randomly and sequentially, therefore mandating its placement on disk (when a key of low values would have been file). But old habits died hard.. At least that is how I remember it.. Others may amend the above MKB -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: History of Hard-coded Offsets (Was: TSSO problems)
In of2e79944d.48a16ac6-on85257766.00544229-85257766.0054b...@uscmail.uscourts.gov, on 07/20/2010 at 11:25 AM, John Kelly john_j_ke...@ao.uscourts.gov said: The assemble didn't take labels for lengths and displacement Of course it did, even in DOS/360. going thru fiche, to find displacement and lengths They were available in System Control Blocks and there were optional source tapes for the mapping macros that weren't in MACLIB or AMODGEN. -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: History of Hard-coded Offsets (Was: TSSO problems)
In 8924.40203...@web82202.mail.mud.yahoo.com, on 07/20/2010 at 08:08 AM, Lloyd Fuller leful...@sbcglobal.net said: Remember: there used to be several levels of assembler: D, E, and F as well as H. D and E in particular had lots of restrictions on what MACROs and COPYs could do because of lack of memory. I believe D would run in a 64K real machine and E required 96K machine. The DOS/360 and TOS/360 Assembler (D) had a 16 KiB design level and, while it exceeded that, I don't believe that it exceeded it by that much. Similarly, the OS/360 Assembler (E) and (F) had 32KiB and 64KiB design points; again, they didn't exceed those sizes by that much. Perhaps you meant that Assembler (F) required a 96 KiB machine. I believe HLASM is based on the H level assembler with lots of changes. Soem of which had been developed at SLAC. -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
AUTO: Witold Scislak/Poland/IBM is out of the office. (returning 08/04/2010)
I am out of the office until 08/04/2010. I am on vacation. Limited access to mailbox. Do not hesitate to call on my mobile: + 48 601606821. Note: This is an automated response to your message Re: History of Hard-coded Offsets (Was: TSSO problems) sent on 1/8/10 13:38:23. This is the only notification you will receive while this person is away. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
At 10:07 AM -0500 on 7/30/10, Paul Gilmartin wrote about Re: remove() of PDSE member leaves PDS locked: As for the attempt to remove a member in a PDS: dsn=datasetname(member),disp=(old,delete) is NOT the way to do it. While it is certainly possible to address a member of a PDS in the dsname, the DISPOSITION is always for the full dataset, NOT any Well documented; inexcusably counterintuitive. I suspect the historical rationale is that 40+ years ago allocation couldn't muster the resources to perform a STOW to delete a member when the allocation had the form above. Nowadays the only rationale, spurious, is that it's always been that way. And ever shall be, as long as descendants of OS/360 endure. But such anomalies give me neither high expectations nor good wishes for the destiny of z/OS. I agree that this failure to do what was requested is counterintuitive. DSN=datasetname(member) turns the member into a sequential dataset. Thus a disp=(old, delete) should act the same way as if the DSN pointed at an actual sequential dataset - IOW: Delete the member (which at this point IS the sequential dataset). Since this capability needs to be added to correct the it's always been that way behavior either add a REMOVE JCL value that can be used in lieu of DELETE to say to remove (ie: Delete the member) as a valid 2nd DISP Parm value, or add a PARMLIB setting to trigger the deletion of a member when requested via dsn=datasetname(member). In addition, there should be a PARMLIB setting to fix this DESIGN FLAW/BUG to return an error message and NOT delete the PDS when this type of request has been made. There are cases where IBM has changed the way that a function works and via a PARMLIB Setting you can turn off the new way the operation is performed so that it works the old way. Add the correct member delete code and require that it be activated via PARMLIB to work (IOW: Unless you add the needed setting, it will still do the old erroneous PDS Delete and not give an error message). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
Nowadays the only rationale, spurious, is that it's always been that way. This is not spurious, in this case. For 40+ years, people have expected it to work this way. Why should IBM, just because of a malcontent, suddenly change well-documented, consistant, and expected behavior? And ever shall be, as long as descendants of OS/360 endure. Every OS has its foibles. But, the people working with them know what they are (or should). But such anomalies give me neither high expectations nor good wishes for the destiny of z/OS. Ranting on IBM-Main does not change the behaviour. Documenting reasons for changes, along with sound business justification does. I should tell you the same thing, you told me, about the discussion regarding whether JCL was a programming language, a couple a weeks ago. I should, as tempting as it is, but I won't. - I'm a SuperHero with neither powers, nor motivation! Kimota! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Curious statement From IBM
AT:http://www.computerweekly.com/Articles/2010/07/22/242070/mainframes-still-not-dead-says-ibm.htm There is a sentence which (I believe) is stand alone and to me it is curiously worded: We can run Windows on zEnterprise, but we have not decided whether we can justify this financially. I think this says what I have been saying for a long time IBM has gotten Windows to work on the mainframe. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
On 8/1/2010 5:25 PM, Robert A. Rosenberg wrote: I agree that this failure to do what was requested is counterintuitive. DSN=datasetname(member) turns the member into a sequential dataset. Thus a disp=(old, delete) should act the same way as if the DSN pointed at an actual sequential dataset - IOW: Delete the member (which at this point IS the sequential dataset). Exactly what do you wish to delete? If the member has alias entries, should these be deleted also? If no, will they stay widowed or should one be promoted to a non-alias? On the other hand, if the name points to an alias, should the alias be deleted alone, or with all associated entries? It looks to me as though you're trading one counterintuitive problem for another. At least the current behavior is documented, and most programmers won't do it more than once. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Curious statement From IBM
On Sun, Aug 1, 2010 at 6:12 PM, Ed Gould ps2...@yahoo.com wrote: AT: http://www.computerweekly.com/Articles/2010/07/22/242070/mainframes-still-not-dead-says-ibm.htm There is a sentence which (I believe) is stand alone and to me it is curiously worded: We can run Windows on zEnterprise, but we have not decided whether we can justify this financially. I think this says what I have been saying for a long time IBM has gotten Windows to work on the mainframe. No, I think it means that they can run it on zBX but aren't sure they want the support load and/or to have to support it through the HMC interface. But I don't know, that's just my interpretation! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Curious statement From IBM
On Sun, 1 Aug 2010, zMan wrote: On Sun, Aug 1, 2010 at 6:12 PM, Ed Gould ps2...@yahoo.com wrote: AT: http://www.computerweekly.com/Articles/2010/07/22/242070/mainframes-still-not-dead-says-ibm.htm There is a sentence which (I believe) is stand alone and to me it is curiously worded: We can run Windows on zEnterprise, but we have not decided whether we can justify this financially. I think this says what I have been saying for a long time IBM has gotten Windows to work on the mainframe. No, I think it means that they can run it on zBX but aren't sure they want the support load and/or to have to support it through the HMC interface. But I don't know, that's just my interpretation! Actually, I think if one could run bochs or qemu on mainframe, then one could also run Windows on top of this. I am not sure about performance. Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did rm -rif on the programmer's home** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_r...@bigfoot.com ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Curious statement From IBM
On Mon, 2010-08-02 at 01:43 +0200, Tomasz Rola wrote: On Sun, 1 Aug 2010, zMan wrote: On Sun, Aug 1, 2010 at 6:12 PM, Ed Gould ps2...@yahoo.com wrote: AT: http://www.computerweekly.com/Articles/2010/07/22/242070/mainframes-still-not-dead-says-ibm.htm There is a sentence which (I believe) is stand alone and to me it is curiously worded: We can run Windows on zEnterprise, but we have not decided whether we can justify this financially. I think this says what I have been saying for a long time IBM has gotten Windows to work on the mainframe. No, I think it means that they can run it on zBX but aren't sure they want the support load and/or to have to support it through the HMC interface. But I don't know, that's just my interpretation! Actually, I think if one could run bochs or qemu on mainframe, then one could also run Windows on top of this. I am not sure about performance. Regards, Tomasz Rola And Mantissa is still taking, a bit, about z/VOS which run Windows under z/VM. I think it is an emulator / JIT type process. -- John McKown Maranatha! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Curious statement From IBM
Tomasz Rola wrote: Actually, I think if one could run bochs or qemu on mainframe, then one could also run Windows on top of this. I am not sure about performance. Sure, you could do that. Adam Thornton did it on an MP3000 a decade ago. Performance was...suboptimal :-) And John McKown wrote: And Mantissa is still taking, a bit, about z/VOS which run Windows under z/VM. I think it is an emulator / JIT type process. Basically, yes: http://www.mainframezone.com/it-management/windows-and-other-x86-operating-systems-on-system-z But I'm quite sure IBM isn't talking about emulation. That doesn't make any sense for them. I'm sure they're talking about zBX, because the pre-announce user group discussions all mentioned System x and now it's not until next year. So the next question is, Will that be Linux on x or Windows? -- ...phsiii Phil Smith III -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: History of Hard-coded Offsets (Was: TSSO problems)
Shmuel Metz (Seymour J.) wrote: I believe HLASM is based on the H level assembler with lots of changes. Soem of which had been developed at SLAC. Yep. I was one of the ones that helped develop the business case for them so that John could get the HLASM written after he moved to IBM. We spent lots of time at SHARE and at home documenting which we wanted and why. Lloyd -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: History of Hard-coded Offsets (Was: TSSO problems)
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Lloyd Fuller Sent: Sunday, August 01, 2010 8:36 PM To: IBM-MAIN@bama.ua.edu Subject: Re: History of Hard-coded Offsets (Was: TSSO problems) Shmuel Metz (Seymour J.) wrote: I believe HLASM is based on the H level assembler with lots of changes. Soem of which had been developed at SLAC. Yep. I was one of the ones that helped develop the business case for them so that John could get the HLASM written after he moved to IBM. We spent lots of time at SHARE and at home documenting which we wanted and why. Lloyd SNIP I really wish you all had seen the benefits of the MACRO/conditional assembly diagnostics that the F Assembler had. Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Access z/OS 3270 TSO from smartphone?
IBM has introduced specific iPhone/iPod touch support in Rational HATS (Host Access Transformation Services), so that's one nice option. More information here: http://www.ibm.com/software/awdtools/hats/ That'd be a universal approach -- the only client requirement is a Web browser -- which has its advantages. If you want something old school, MochaSoft offers 3270 emulators for the iPhone, iPod touch, iPad, Blackberry, etc. I have no personal experience with them. More information here: http://www.mochasoft.dk/products.htm - - - - - Timothy Sipples Resident Enterprise Architect STG Value Creation Complex Deals Team IBM Growth Markets (Based in Singapore) E-Mail: timothy.sipp...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Access z/OS 3270 TSO from smartphone?
On Sun, Aug 1, 2010 at 10:05 PM, Timothy Sipples timothy.sipp...@us.ibm.com wrote: If you want something old school, MochaSoft offers 3270 emulators for the iPhone, iPod touch, iPad, Blackberry, etc. I have no personal experience with them. More information here: And they have a 5250 client for Android but no 3270, alas. So close... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Access z/OS 3270 TSO from smartphone?
How about C compilers to compile Hercules? On Sun, Aug 1, 2010 at 9:39 PM, zMan zedgarhoo...@gmail.com wrote: On Sun, Aug 1, 2010 at 10:05 PM, Timothy Sipples timothy.sipp...@us.ibm.com wrote: If you want something old school, MochaSoft offers 3270 emulators for the iPhone, iPod touch, iPad, Blackberry, etc. I have no personal experience with them. More information here: And they have a 5250 client for Android but no 3270, alas. So close... -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
