Re: We're losing the battle
Kirk Talman writes: The most common box used for authorizations is what used to be called Tandem. Now called HP NonStop. Mainframes do much else. They stand at short arm's length to each other. Chris Craddock replies: Tandems were used in many online banking applications as front-end switches. They didn't really process the transactions beyond queueing and sending them on to the right place. Their non-stop reliability was important to avoid lost transactions back in the day when CICS couldn't keep up. Probably not so much of an issue today, but they're probably still doing yeoman work in the same places they were in 1983 when I first bumped into them. I agree with Chris. In my (more limited) experience, if HP NonStops are used they're mainly as front-end switches at card network member banks. And their use in this niche role is fading, as Chris alludes to. A big reason is application and middleware availability trends in that industry favoring the IBM mainframe and disfavoring HP NonStop. Another is cost: typically it's more affordable to consolidate. Yet another is HP and its platform technology disruptions. (HP just announced another one this month and is trying to move understandably reluctant customers to Itanium to cut its RD costs.) Still yet another is the adoption of Parallel Sysplex and GDPS, mooting a front-end queue.? - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Specializing in Software Architectures Related to System z Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific E-Mail: [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
Oh come on Richard. There are Banks all around the world that have never possessed a MF, and get along quite nicely with five nines availability on Unix clustered solutions. We should not fool ourselves into thinking that Parallel Sysplex and GDPS are the only HA clustered solutions in the market place, whether local, metro or geographically dispersed. I had UNIX customers doing multi-site RAID-1 over RAID-5 before Hiperswap was a twinkle in IBM's eye! Damn site easier to operate too. Ron Alternatives *are in the process of maturing*. They certainly are not there yet! I am amazed at the failure tolerance of distributed application systems. If it is broke, they spend more money on it without getting to the root cause: bad architectural design. The mainframe systems have never been given this kind of leeway. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Decimal Floating Point for Java and COBOL using z390
All Java does not have Decimal Floating Point yet, and COBOL already plays very nicely with automatic conversion from Java float to COBOL float and back again with direct calls. Java and COBOL can now use open source J2SE Java based z390 Portable Assembler to execute all the HFP, BFP, and DFP instructions for short, long, and extended precision. Visit www.z390.org for more information. z390 v1.4.02 due out in the next week will package all the recent enhancements which include addition of HFP un-normaliazed instruction compatibility (previosuly they were producing normalized results); SOA application generator now supports COBOL clients using EZASOKET calls to z390 services running on any platform including mainframes, Windows, or Linux; plus numerious other improvements for compatibility with HLASM and z9/z10 mainframes. The Java support uses for DFP uses BigDecimal class which is a superset of decimal floating point with arbitrary precision, exponent, and all types of rounding. It also has built in methods specifically for IEEE compatibility such as context DECIMAL128 and DECIMAL64. You can check out the source code in pz390.java all available for download from the z390 project on sourceforge.net. Don Higgins [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Shane On Mon, 2008-06-23 at 10:55 -0500, gil wrote: Is ZFS reliable? ... (No, not that ZFS, the real one) On my meanderings I have just begun to look at OpenSolaris (principlly for ZFS and dprobes - and zones). Bumped into a mention of the following on a blog: http://youtube.com/watch?v=CN6iDzesEs0 You judge ... We're sorry, this video is no longer available. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Storage Alternation TRAP
Hi How can I set an SA trap, to specify the BEFORE and AFTER values (i.e the content before the alternation and after ) ? -- Miklos Szigetvari Development Team ISIS Information Systems Gmbh tel: (+43) 2236 27551 570 Fax: (+43) 2236 21081 E-mail: [EMAIL PROTECTED] Info: [EMAIL PROTECTED] Hotline: +43-2236-27551-111 Visit our Website: http://www.isis-papyrus.com --- This e-mail is only intended for the recipient and not legally binding. Unauthorised use, publication, reproduction or disclosure of the content of this e-mail is not permitted. This email has been checked for known viruses, but ISIS accepts no responsibility for malicious or inappropriate content. --- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Decimal Floating Point, was: replacing SAS for SMF reports?
--snip- I see what I did, whenever people talk about 'new floating point' I always assume it is Decimal Floating Point (the one that is not available in Java yet, or COBOL for that matter. z9 and PL/I and have it) To make it more confusing both the Java binary float and the newer DFP are both IEEE floating point! ---unsnip Don't confuse PL/1's FLOAT DECIMAL specification with the hardware floating point decimal feature. They are NOT the same! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
Quoting Chase, John: We're sorry, this video is no longer available. Dunno mate, (still) works for me. Go there and search for zfs (and smash if you need to). Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RRS trouble usage
Look at profiles in the RACF DSNR class. If you just starting to use RRSAF, you may have profiles of the form: ssid.BATCH (for utilities or call attach). ssid.SASS (for CICS connections). If this is the case, you need to add profiles ssid.RRSAF that will have similar access requirements as ssid.BATCH. Wayne Driscoll Product Developer NOTE: All opinions are strictly my own. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Roland Schiradin Sent: Monday, June 23, 2008 11:31 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: RRS trouble usage Seems to be a security issue Roland 00F30013 Explanation: The requester is not authorized to connect to this DB2 subsystem. This condition might indicate an attempted security violation. This reason code is issued by the following CSECT: DSN3AUCN System action: The connection request is denied. User response: Verify that you have specified the correct RACF authorization ID. If necessary, request authorization to access the DB2 subsystem from your security administrator. System programmer response: Examine the console/SYSLOG output for RACF messages issued when a request is denied. Refer the user to your security administrator if the user should be granted authorization to a DB2 subsystem. Refer to Part 3 (Volume 1) of DB2 Administration Guide for examples of how to authorize users to specific DB2 subsystems. Problem determination: During TCB connection processing, Subsystem Support invokes the RACROUTE service (causing a RACF RACHECK) to verify the authorization ID associated with the requester. If the RACF return code indicates the requester is not authorized to connect to this DB2 subsystem, the connection request is terminated with this reason code. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Displaying Quiesced zFS files
On Mon, 23 Jun 2008 15:12:50 -0700, Patrick Falcone [EMAIL PROTECTED] wrote: Hi Mark, I'm not sure if this has been mentioned/considered but did you try 'D OMVS,F'? Yes. Mentioned in my OP (I wrote no OMVS display command, nor any MODIFY ZFS command ). Here is a maintenance zFS I just quiesced: ZFS20 ACTIVE RDWR 06/15/2008 L=32 NAME=SYS1.OMVS.RESM81.XML.ZFS 01.20.14Q=0 PATH=/servz18/usr/lpp/ixm AGGREGATE NAME=SYS1.OMVS.RESM81.XML.ZFS Here is one that is not: ZFS21 ACTIVE RDWR 06/15/2008 L=33 NAME=SYS1.OMVS.RESM81.PERLZFS 01.20.14Q=0 PATH=/servz18/usr/lpp/perl AGGREGATE NAME=SYS1.OMVS.RESM81.PERLZFS -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Mark Zelden [EMAIL PROTECTED] wrote: Much to my dismay, there is no operator command I can find that shows a quiesced ZFS. No OMVS display command, nor any MODIFY ZFS command. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How to view CBT XMI files on PC
XMIT Manager works great with sequential and PDS files. Fails on PDSE. Anyone know of a free product that will work with PDSE? -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Knutson, Sam Sent: Monday, June 23, 2008 4:16 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: How to view CBT XMI files on PC http://www.cbttape.org/njw/index.html Xmit Manager is still very nice works on Windows. Dave Alcock has a good page on XMIT file format and PC tools here http://www.planetmvs.com/unxmit/index.html Thanks, Sam -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Lizette Koehler Sent: Sunday, June 22, 2008 11:28 AM To: IBM-MAIN@BAMA.UA.EDU Subject: How to view CBT XMI files on PC Does anyone know of a product that can be used on the PC to browse CBT xmi files? Lizette This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
On 23 Jun 2008 21:28:35 -0700, in bit.listserv.ibm-main you wrote: CLC] Pardon? You've never seen CVS? Or any of its zillions of commercial and open source offspring? I've built entire (mainframe!) products using these tools on PCs. And it wasn't even a hard decision to make. They're more flexible and easier to use than anything I've used on TSO. I may have never seen the tools; I've never seen the discipline - which was my (poorly stated) point. [CLC] Let's stop bashing PCs here. Only a poor workman blames his tools. I'm not blaming the tools! I'm blaming the pfcsk's. I have never seen a *ix person follow proper change control. I've seen mainframers do it for over 25 years. I'm not bashing PC's, nor did I in any of my responses. I bashed the (lack of) discipline of pfcsk's! I suspect that the ix and PC development environments that you describe are in departments that formed as a reaction to the perceived (and/or actual) rigidity and unresponsiveness of the mainframe development group. The Unix shop I was in definitely had change control and signoff. I used it in maintenance and development. It was an ex-mainframe shop. Most of the development methodologies that I have heard about include change control and build organization. I am certain that most decent package developers have good change and version control irrespective of platform. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How to view CBT XMI files on PC
It also has a problem with RECFM=V data. RECFM=F works fine. Date: Tue, 24 Jun 2008 08:21:31 -0500 From: [EMAIL PROTECTED] Subject: Re: How to view CBT XMI files on PC To: IBM-MAIN@BAMA.UA.EDU XMIT Manager works great with sequential and PDS files. Fails on PDSE. Anyone know of a free product that will work with PDSE? _ The other season of giving begins 6/24/08. Check out the i’m Talkathon. http://www.imtalkathon.com?source=TXT_EML_WLH_SeasonOfGiving -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
1.9, Imbed, ETC
I'm poised to IPL 1.9 in a test environment. Eventually we'll hook up user catalogs and master catalogs from a previous release. Questions here from the team include: 1. Are we going to have horrible catalog issues? 2. For VSAM files, does a delete/define constitute a 'new' dataset and will it blow up or just scream loudly? I've been reading posts about this, but would like a little firsthand experience to share with the team. MTIA... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 1.9, Imbed, ETC
Daniel McLaughlin wrote: I'm poised to IPL 1.9 in a test environment. Eventually we'll hook up user catalogs and master catalogs from a previous release. Questions here from the team include: 1. Are we going to have horrible catalog issues? 2. For VSAM files, does a delete/define constitute a 'new' dataset and will it blow up or just scream loudly? I've been reading posts about this, but would like a little firsthand experience to share with the team. MTIA... You shouldn't have any problems with replicate or imbed datasets under zOS 1.9. Any new allocation will simply ignore these attributes. Our master catalog hasn't been fixed yet and there is no problems using it under zOS 1.9. -- Mark Jacobs Time Customer Service Tampa, FL When the Nazis came for the communists, I remained silent; I was not a communist. When they locked up the social democrats, I remained silent; I was not a social democrat. When they came for the trade unionists, I did not speak out; I was not a trade unionist. When they came for the Jews, I remained silent; I wasn't a Jew. When they came for me, there was no one left to speak out. Pastor Martin Niemöller (1892–1984) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Displaying Quiesced zFS files
You would think that the returned *status* from 'D OMVS,F' would be 'quiesced' instead of 'active' but then again I just stumbled upon the below. 'D OMVS,F,e' where 'e' is exception. Mark Zelden [EMAIL PROTECTED] wrote: On Mon, 23 Jun 2008 15:12:50 -0700, Patrick Falcone wrote: Hi Mark, I'm not sure if this has been mentioned/considered but did you try 'D OMVS,F'? Yes. Mentioned in my OP (I wrote no OMVS display command, nor any MODIFY ZFS command ). Here is a maintenance zFS I just quiesced: ZFS 20 ACTIVE RDWR 06/15/2008 L=32 NAME=SYS1.OMVS.RESM81.XML.ZFS 01.20.14 Q=0 PATH=/servz18/usr/lpp/ixm AGGREGATE NAME=SYS1.OMVS.RESM81.XML.ZFS Here is one that is not: ZFS 21 ACTIVE RDWR 06/15/2008 L=33 NAME=SYS1.OMVS.RESM81.PERLZFS 01.20.14 Q=0 PATH=/servz18/usr/lpp/perl AGGREGATE NAME=SYS1.OMVS.RESM81.PERLZFS -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Mark Zelden wrote: Much to my dismay, there is no operator command I can find that shows a quiesced ZFS. No OMVS display command, nor any MODIFY ZFS command. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Displaying Quiesced zFS files
On Tue, 24 Jun 2008 06:55:49 -0700, Patrick Falcone [EMAIL PROTECTED] wrote: You would think that the returned *status* from 'D OMVS,F' would be 'quiesced' instead of 'active' but then again I just stumbled upon the below. 'D OMVS,F,e' where 'e' is exception. Yes I tried that (I did look at the FM before my first post on this subject). Would you expect active to be an exception? :-) Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
In my experience, the UNIX and/or PC development teams were more likely to have change integration tools, as they had to deal with multiple development environments, while many mainframe products were developed using ISPF library concatenations, so there was a much smaller number of potential sources for changes. For example, the diff tools available even in line mode unix are much more robust that ISPF 3.13. Yes it isn't always about the tools, but about the process, and as the need increases, so does the usage. Wayne Driscoll Product Developer NOTE: All opinions are strictly my own. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Clark Morris Sent: Tuesday, June 24, 2008 8:36 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: We're losing the battle On 23 Jun 2008 21:28:35 -0700, in bit.listserv.ibm-main you wrote: CLC] Pardon? You've never seen CVS? Or any of its zillions of commercial and open source offspring? I've built entire (mainframe!) products using these tools on PCs. And it wasn't even a hard decision to make. They're more flexible and easier to use than anything I've used on TSO. I may have never seen the tools; I've never seen the discipline - which was my (poorly stated) point. [CLC] Let's stop bashing PCs here. Only a poor workman blames his tools. I'm not blaming the tools! I'm blaming the pfcsk's. I have never seen a *ix person follow proper change control. I've seen mainframers do it for over 25 years. I'm not bashing PC's, nor did I in any of my responses. I bashed the (lack of) discipline of pfcsk's! I suspect that the ix and PC development environments that you describe are in departments that formed as a reaction to the perceived (and/or actual) rigidity and unresponsiveness of the mainframe development group. The Unix shop I was in definitely had change control and signoff. I used it in maintenance and development. It was an ex-mainframe shop. Most of the development methodologies that I have heard about include change control and build organization. I am certain that most decent package developers have good change and version control irrespective of platform. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Displaying Quiesced zFS files
On Tue, 24 Jun 2008 09:06:14 -0500, Mark Zelden [EMAIL PROTECTED] wrote: On Tue, 24 Jun 2008 06:55:49 -0700, Patrick Falcone [EMAIL PROTECTED] wrote: You would think that the returned *status* from 'D OMVS,F' would be 'quiesced' instead of 'active' but then again I just stumbled upon the below. 'D OMVS,F,e' where 'e' is exception. Yes I tried that (I did look at the FM before my first post on this subject). Would you expect active to be an exception? :-) Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html The following section was added to the DFS/SMB section of the PSP buckets for z/OS 1.4, 1.5, 1.6, and 1.7, as a result of a PMR that I have opened with zFS development in regards to this issue. I guess they are still working on the fix. 06/04/11 If a zfs filesystem is quiesced, either as the result of a DFSMS backup operation or explicitly via a zfsadm quiesce command, the state of the filesystem as displayed by the USS 'df' or D OMVS,F commands will NOT show as QUIESCED. This is a known design issue which is between the LFS (USS) and the PFS (zFS) , and the development teams are currently investigating this. However at this time this is working as designed. Users must be aware that to accurately determine the current status of a zFS filesystem, they must use the provided zfs administration commands: zfsadm lsaggr zfsadm aggrinfo status of the zFS filesystems and will show the status of the filesystem as QUIESCED, if in fact the filesystem is currently in a QUIESCED state. This has become a point of contention recently as backups being taken using the DFSMS DUMP/RESTORE utility will QUIESCE zfs filesystems implicitly. If users are not aware of this activity, they could see temporary 'hang' situations and/or USS Latch contention as indicated by the presence of a BPXM056E errors message displayed to the operators console. To determine ifthe current state of the ZFS filesystems, user are requiredto use the zfsadm commands to accurately determine if ZFS filesystems are QUIESCED -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Displaying Quiesced zFS files
I just thought that *maybe* I could catch you not checking that *F*M! :-) If done from the driving system then I would venture this a problem since the *F*M states that the returned status should be quiesced. Mark Zelden [EMAIL PROTECTED] wrote: On Tue, 24 Jun 2008 06:55:49 -0700, Patrick Falcone wrote: You would think that the returned *status* from 'D OMVS,F' would be 'quiesced' instead of 'active' but then again I just stumbled upon the below. 'D OMVS,F,e' where 'e' is exception. Yes I tried that (I did look at the FM before my first post on this subject). Would you expect active to be an exception? :-) Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 1.9, Imbed, ETC
I have just IPL'd z/OS V1.9 on 2 out of 5 lpars. All dasd is shared. No problems. I am using zFS files for the OMVS stuff and at this point I have not seen any issues with the OS or the maintanence I just did (433 PTFs). Just note: The z/OS 1.9 system is very touchy about its Nucleus. If you did not see the note in the PSP bucket and you get a WAIT STATE 19 (WS19 WS019 WS_19 WS 19). Then you did not use the Higher Level Binder for running your SMP/E for Nucleus. I got bit by that one. Lizette I'm poised to IPL 1.9 in a test environment. Eventually we'll hook up user catalogs and master catalogs from a previous release. Questions here from the team include: 1. Are we going to have horrible catalog issues? 2. For VSAM files, does a delete/define constitute a 'new' dataset and will it blow up or just scream loudly? I've been reading posts about this, but would like a little firsthand experience to share with the team. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
Thank you Ron I was feeling alone . i have been sometimes pulling out applications from mainframe in my shop and applied all good recipes from centralised processing ( dual computer rooms , dual replicated storage bays for dasds , dual network, load balancing , dual tape robotics and even ESX vmware to drag and drop servers on the fly) And it is reliable . ( Lotus notes windows, Lotus portal windows , WAS linux , Windows data servers , AIX applications , etc ... ) The people are younger though , and when you are younger you are less experienced . In effect they are sometimes making the same mistakes i was doing 30 years ago . But now they come and ask , and we the ancient give them advice or ask them the right questions : and what happens if blah blah ??? I think the issue is more with the people and their experience or attitude than with the platform . These guys sometimes ask me to put things in mainframe and when the cost is ok we do . Like someone said : i backup my servers with TSM on ts7700 in grid configuration with jaguar at the back , and it works ( and i tried it in AIX and z/OS and not much difference apart from the bill ) . Now i am sure that using DVD's in Z/os would slow down restoration , but then we would not think doing it . Bruno Sugliani zxnetconsult(at)free(dot)fr On Tue, 24 Jun 2008 03:07:19 -0700, Ron Hawkins [EMAIL PROTECTED] wrote: Oh come on Richard. There are Banks all around the world that have never possessed a MF, and get along quite nicely with five nines availability on Unix clustered solutions. We should not fool ourselves into thinking that Parallel Sysplex and GDPS are the only HA clustered solutions in the market place, whether local, metro or geographically dispersed. I had UNIX customers doing multi-site RAID-1 over RAID-5 before Hiperswap was a twinkle in IBM's eye! Damn site easier to operate too. Ron -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
On 24 Jun 2008 07:06:54 -0700, [EMAIL PROTECTED] (Wayne Driscoll) wrote: In my experience, the UNIX and/or PC development teams were more likely to have change integration tools, as they had to deal with multiple development environments, while many mainframe products were developed using ISPF library concatenations, so there was a much smaller number of potential sources for changes. Many of the modern environments have sophisticated version control tools, and sophisticated testing systems - which are necessary but not sufficient to provide the confidence that are/were the norm in old style applications. Big complicated systems will have bugs and service packs for their lifetimes. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well. [EMAIL PROTECTED] (Bruno Sugliani) writes: Like someone said : i backup my servers with TSM on ts7700 in grid configuration with jaguar at the back , and it works ( and i tried it in AIX and z/OS and not much difference apart from the bill ) . Now i am sure that using DVD's in Z/os would slow down restoration , but then we would not think doing it . re: http://www.garlic.com/~lynn/2008i.html#97 We're losing the battle http://www.garlic.com/~lynn/2008i.html#99 We're losing the battle http://www.garlic.com/~lynn/2008i.html#101 We're losing the battle tsm started out as renamed adsm. adsm was evoluation of workstation datasave facility ... and workstation datasave facility started out as CMSBACK ... which was deployed extensively internally old cmsback related email http://www.garlic.com/~lynn/lhwemail.html#cmsback and various posts related to (CMSBACK, workstation datasave, adsm, tsm, and other) backup/archive http://www.garlic.com/~lynn/subtopic.html#backup disclaimer, i had created and deployed the original CMSBACK internally ... before it went thru various morphs eventually becoming the current tsm product. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
SDSF XDC panel Question
Is there any way to get the XDC panel to display the JOBNAME and JOBNUMBER? When I use it for a series of XDC commands I have to remember which job is in which order. I would probably want that information on other X panels as well. Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
Ted said I'm not blaming the tools! I'm blaming the pfcsk's. I have never seen a *ix person follow proper change control. I've seen mainframers do it for over 25 years. I'm not bashing PC's, nor did I in any of my responses. I bashed the (lack of) discipline of pfcsk's! [CLC] I have seen both sides of this and, on average, I would call it a draw. I have seen very disciplined *IX and PC operations and unbelievably sloppy mainframe operations. And of course, I have seen the opposite too. It just has nothing much to do with mainframer=wise or pfcsk=dumb. It has a lot more to do with corporate policies and training and whether or not the IT staff actually follows the rules. Human nature in other words. CC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
Craddock, Chris wrote: [...] It just has nothing much to do with mainframer=wise or pfcsk=dumb. It has a lot more to do with corporate policies and training and whether or not the IT staff actually follows the rules. Human nature in other words. 1. It has little to do. There is something which we can call IT culture. PC environment (I mean human env) is more likely to restart-like, while mainframe environment is more likely tight controlled. Of course, YMMV, this is generalization, etc. etc. 2. Usually mainframe shops are big ones. Big shops tend to be better organized than small ones. 3. Technology is important. It's much harder to make a tent tamperproof, while is't easier to make a safe well closed. However you can leave the safe with key under the doormat and have bodyguards aorund the tent. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2008 r. kapita zakadowy BRE Banku SA wynosi 118.642.672 zote i zosta w caoci wpacony. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CEE3703I In HANC Control Block, the Eye Catcher is damaged.
Why are you not using the LE runtime? Not my code, not my app. As I said in the original note, The program object detecting the error was last compiled in 1999 with VS COBOL II [...]. At that time, apparently the SYSLIB for the program binder step in the change management system was set up to use the VS COBOL II runtime library first. I also don't set those SYSLIB concatenations. _If_ using the LE runtime is _known_ to fix this, I have ammunition to get such things changed. That alone may fix it. I agree. So far, no one is interested in fixing it. It happens rarely. I'd like it fixed before rarely becomes all the time. Like maybe when we go to z/OS 1.9 in a couple of months. You can have VS COBOL II modules linked with VS COBOL II and still run them without VS COBOL II run-time library, you can run them with LE library. All described in the COBOL Migration Guide: http://www-306.ibm.com/software/awdtools/cobol/zos/library/ If you think they are running with VS COBOL II run time, but you are getting an LE abend, it sure sounds like an invalid setup, with 2 different run-time libraries in the concatenation. Look for COB2LIB and SCEERUN, you can only have one of the other, and the one should be SCEERUN. Cheers, TomR COBOL is the Language of the Future! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Displaying Quiesced zFS files
On Tue, 24 Jun 2008 09:41:13 -0500, Ramiro Camposagrado [EMAIL PROTECTED] wrote: The following section was added to the DFS/SMB section of the PSP buckets for z/OS 1.4, 1.5, 1.6, and 1.7, as a result of a PMR that I have opened with zFS development in regards to this issue. I guess they are still working on the fix. 06/04/11 If a zfs filesystem is quiesced snip 04/11/2006? Over 2 years and still no relief? What about the 1.8 and 1.9 buckets (I didn't check)? Considering the push to zFS, this is really bad. Jeers for IBM on this one... Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
JCL/PARM puzzle
I have two sets of JCL that are executing BPXBATCH. The first set follows and it did not work. 10 //PS082 EXEC PGM=BPXBATCH, // // PARM='SH echo sftp -vvv -b /u/bpxbatch/mccheckftp 11 // fis-depot.ucdavis.edu |su -s bpxbtch' 12 //SYSPRINT DD SYSOUT=* 13 //STDOUTDD SYSOUT=* 14 //STDERRDD SYSOUT=* O. MESSAGE 10 IEFC621I EXPECTED CONTINUATION NOT RECEIVED 11 IEFC605I UNIDENTIFIED OPERATION FIELD This set of JCL's worked: //PS082 EXEC PGM=BPXBATCH, // // PARM='SH echo sftp -b /u/bpxbatch/mccheckftp fis-depot.ucdavis.edu // |su -s bpxbtch' //SYSPRINT DD SYSOUT=* //STDOUTDD SYSOUT=* //STDERRDD SYSOUT=* Any ideas as to why the first set fails. Thanks John Norgauer University of California Davis Medical Center 2315 Stockton Blvd ASB 1300 Sacramento, Ca 95817 916-734-0536 SYSTEMS PROGRAMMING.. Guilty, until proven innocent !! JN 2004 Hardware eventually breaks - Software eventually works anon -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
RS said 1. It has little to do. There is something which we can call IT culture. PC environment (I mean human env) is more likely to restart-like, while mainframe environment is more likely tight controlled. Of course, YMMV, this is generalization, etc. etc. [CLC] Funny you should mention that. I will assert that today there is almost nothing significant that you can fix (i.e. restore service) faster by rooting around trying to find the problem, than by just restarting the application or the server it is running on. And yes, that's a generalization. Problems do eventually have to be diagnosed, but your chances of doing that well enough during a critical situation are basically zip. Have been for many years now. This is one of those places where the economics just don't square with reality. The mainframe approach of keeping the system (and subsystems) up at all costs is based on the economics of having a lot of stuff running concurrently on the same physical resource. The non-mainframe world isn't like that and (arguably) most mainframe apps aren't like that anymore either if they're parallel sysplex enabled. CC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL/PARM puzzle
The '*' in column 72 caused the unexpected continuation error Edouard A. Myers Senior Information Technology Specialist Office of the Chief Technology Officer DC Government 222 Massachusetts Ave, NW, Suite 200 Washington, DC 20001 Phone : 202-727-4017 Fax: 202-727-3880 Email: [EMAIL PROTECTED] Website: http://www.octo.dc.gov -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of John Norgauer Sent: Tuesday, June 24, 2008 1:22 PM To: IBM-MAIN@BAMA.UA.EDU Subject: JCL/PARM puzzle I have two sets of JCL that are executing BPXBATCH. The first set follows and it did not work. 10 //PS082 EXEC PGM=BPXBATCH, // // PARM='SH echo sftp -vvv -b /u/bpxbatch/mccheckftp 11 // fis-depot.ucdavis.edu |su -s bpxbtch' 12 //SYSPRINT DD SYSOUT=* 13 //STDOUTDD SYSOUT=* 14 //STDERRDD SYSOUT=* O. MESSAGE 10 IEFC621I EXPECTED CONTINUATION NOT RECEIVED 11 IEFC605I UNIDENTIFIED OPERATION FIELD This set of JCL's worked: //PS082 EXEC PGM=BPXBATCH, // // PARM='SH echo sftp -b /u/bpxbatch/mccheckftp fis-depot.ucdavis.edu // |su -s bpxbtch' //SYSPRINT DD SYSOUT=* //STDOUTDD SYSOUT=* //STDERRDD SYSOUT=* Any ideas as to why the first set fails. Thanks John Norgauer University of California Davis Medical Center 2315 Stockton Blvd ASB 1300 Sacramento, Ca 95817 916-734-0536 SYSTEMS PROGRAMMING.. Guilty, until proven innocent !! JN 2004 Hardware eventually breaks - Software eventually works anon -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CEE3703I In HANC Control Block, the Eye Catcher is damaged.
I would point you to the COBOL and LE migrations guides. There you should find pretty plain statements that you cannot mix different levels of COBOL runtimes in the same run unit. Not sure, but I think CICS is just one run unit in that context. If you do mix, then you can expect unpredictable results. The unpredictability includes seemingly successful tests and even long periods of apparently stable production before the snake in the grass opens the can of worms that will shoot you in the foot. But no matter. If you run into a COBOL or LE issue, about all IBM can reasonably offer is advice to use the most current versions. For COBOL runtimes, that is LE. The last time I checked, IBM supports most all versions of compilers with the proviso that only the latest runtimes (LE) are used across the board. So, Q: is mixing COBOL runtimes known to cause problems? A:yes Q: will fixing that fix this specific problem? A:No way to know other than by testing. Q: Will IBM supply fixes to COBOL II runtimes? A: Yes, they did, and they were packaged under LE. HTH and good luck. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Schneiderwent, Craig Sent: Monday, June 23, 2008 8:06 AM To: IBM-MAIN@BAMA.UA.EDU Subject: CEE3703I In HANC Control Block, the Eye Catcher is damaged. Has anyone else seen this message in their CICS regions? [z/OS 1.7, CICS TS 3.1] The program object detecting the error was last compiled in 1999 with VS COBOL II 1.4 and is _not_ using the LE runtimes. I'm wondering if anyone else has seen this error and if recompiling with Enterprise COBOL and linking with the LE runtimes is _known_ to fix it. If so, it would be grist for the LE migration mill. [cross-posted to CICS-L] NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL/PARM puzzle
John Norgauer wrote: I have two sets of JCL that are executing BPXBATCH. The first set follows and it did not work. 10 //PS082 EXEC PGM=BPXBATCH, // // PARM='SH echo sftp -vvv -b /u/bpxbatch/mccheckftp 11 // fis-depot.ucdavis.edu |su -s bpxbtch' 12 //SYSPRINT DD SYSOUT=* 13 //STDOUTDD SYSOUT=* 14 //STDERRDD SYSOUT=* O. MESSAGE 10 IEFC621I EXPECTED CONTINUATION NOT RECEIVED 11 IEFC605I UNIDENTIFIED OPERATION FIELD This set of JCL's worked: //PS082 EXEC PGM=BPXBATCH, // // PARM='SH echo sftp -b /u/bpxbatch/mccheckftp fis-depot.ucdavis.edu // |su -s bpxbtch' //SYSPRINT DD SYSOUT=* //STDOUTDD SYSOUT=* //STDERRDD SYSOUT=* Any ideas as to why the first set fails. Thanks John Norgauer The rule for continuing a quoted string is: code your string up to and including col. 71; then your continuation must begin exactly in col. 16. Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques == Check out the Trainer's Friend Store to purchase z/OS == == application developer toolkits. Sample code in four== == programming languages, JCL to Assemble or compile, == == bind and test. == == http://www.trainersfriend.com/TTFStore/index.html== -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JCL/PARM puzzle
On 24 Jun 2008 10:20:54 -0700, in bit.listserv.ibm-main (Message-ID:[EMAIL PROTECTED]) [EMAIL PROTECTED] (John Norgauer) wrote: I have two sets of JCL that are executing BPXBATCH. The first set follows and it did not work. 10 //PS082 EXEC PGM=BPXBATCH, // // PARM='SH echo sftp -vvv -b /u/bpxbatch/mccheckftp 11 // fis-depot.ucdavis.edu |su -s bpxbtch' This set of JCL's worked: //PS082 EXEC PGM=BPXBATCH, // // PARM='SH echo sftp -b /u/bpxbatch/mccheckftp fis-depot.ucdavis.edu // |su -s bpxbtch' The parm is in quotes. Continuing a parm within quotes requires that the continuation line (except for the //) begin in column 16. Check the JCL manual. P.S. Likely my e-mail program will have split the quoted lines making them difficult to understand. I apologize in advance. -- I cannot receive mail at the address this was sent from. To reply directly, send to ar23hur at intergate dot com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Displaying Quiesced zFS files
I agree... two years and counting... There is no mention of this update on the z/OS 1.8 or 1.9 buckets either. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Problems that occur in production
On Fri, 20 Jun 2008 11:07:44 -0600, Steve Comstock [EMAIL PROTECTED] wrote: J. Chiampi wrote: Hello, I'm looking for information about problems that could occur in production with Cobol programs and that could generate abend. I would like to find a description and how to prevent them before they occur. For instance, I think that it could be interesting to avoid moving alphanumeric variables into numeric variable without checking them by using a IF NUMERIC or moving data into another that is shorter or avoid closing file or never check array boundaries... Do you see other important cases related to performance or robustness? Thanks in advance. Regards You could use LE condition handling to trap errors and handle them in some installation-specified standard way. In our course Enterprise COBOL Update I: Essentials we have a lab that builds and uses a condition handler to intercept most errors; the classroom version just lets the program continue; in real life, of course, you would take more severe actions. But at least we demo how to intercept and analyze conditions that arise. Check out http://www.trainersfriend.com/COBOL_Courses/d704descr.htm Kind regards, -Steve Comstock The Trainer's Friend, Inc. Thanks for your response. I totally agree with you. My objective is to prevent bugs that regularly occur and to deliver reports for developers. What I would like to do is: - identify common problems that occur regularly in production and that lead to abends - detect them with some automated routines running on Cobol source code - provide reports with impacted code location, short explanation of the problem and a solution So I'm interesting if you have information about bugs that are interesting to take into account in order to help developer work and to increase the quality of application. I do not have enough experience on this. I ask this question to all experienced developers. Thanks in advance. Regards Jerome Chiampi -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
Craddock, Chris wrote: RS said 1. It has little to do. There is something which we can call IT culture. PC environment (I mean human env) is more likely to restart-like, while mainframe environment is more likely tight controlled. Of course, YMMV, this is generalization, etc. etc. [CLC] Funny you should mention that. I will assert that today there is almost nothing significant that you can fix (i.e. restore service) faster by rooting around trying to find the problem, than by just restarting the application or the server it is running on. And yes, that's a generalization. Problems do eventually have to be diagnosed, but your chances of doing that well enough during a critical situation are basically zip. Have been for many years now. In my experience, PC programmers simply cannot or will not perform any kind of post-mortem dump analysis. And, though Micro$oft operating systems appear to have the ability to take a dump, I have never met anyone that knew how to, or cared to, read one. The only thing they know how to do is reproduce a problem under a debugger. If that can't be done, they chalk everything up to problems with the underlying OS, drivers, or services. All seasoned mainframe software developers know that a fair number of problems occur only under special circumstances -- often related to timing, asynchronous activity, or other hard-to-control variables. Such problems often can't be reproduced -- even when you *know* what's wrong. Without post-mortem analysis to identify the cause of these problems, such bugs would never be fixed. And, on PCs, they never are. Case in point: I was talking with one of our tech writers a couple of weeks ago, discussing the concepts of supported vs unsupported software for a matrix she was to publish on our web site. I tried to use Micro$oft examples because she's familiar with their products. She told me there are scores of universally-known bugs in supposedly fully supported versions of M$ Word that are decades old and still not fixed. The tech writing user community deals with these problems by avoiding them. (Doctor: It hurts when I do that. Then don't do it!) That evening, I pulled up to a gas pump that had one of those flat panel TV screens above. The thing was stuck on a Windows BSOD. Somebody was paying to advertise a trap screen! :-D These anecdotes illustrate a *huge* cultural difference between our platform and others. This sort of thing would simply not be tolerated on a mainframe! PC programmers don't have the tools they need to make their software bullet-proof because they just don't care... -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
[snip] In my experience, PC programmers simply cannot or will not perform any kind of post-mortem dump analysis. And, though Micro$oft operating systems appear to have the ability to take a dump, I have never met anyone that knew how to, or cared to, read one. The only thing they know how to do is reproduce a problem under a debugger. If that can't be done, they chalk everything up to problems with the underlying OS, drivers, or services. We (z/OS Tech Services) were allowed to ask questions of the vendors back when a previous administration was looking at converting everything to Windows. We had a number of questions. One question and answer stuck in my mind. We asked: Suppose a batch process fails, how would the programmer debug that? Their answer: Recompile the application with debugging active. Then have the programmer single step the application under the debugger until the application fails again. Use the debugger to determine why. Subsequent question: How long do you estimate this will take if the outage occurred after 2 hours of processing? No answer to that one. In the deep, dark past, I actually did use a Dr. Watson report to debug a Windows problem. [snip] These anecdotes illustrate a *huge* cultural difference between our platform and others. This sort of thing would simply not be tolerated on a mainframe! PC programmers don't have the tools they need to make their software bullet-proof because they just don't care... -- Edward E Jaffe -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Tuesday, June 24, 2008 1:35 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: We're losing the battle Craddock, Chris wrote: SNIP PC programmers don't have the tools they need to make their software bullet-proof because they just don't care... SNIP I think it is not that they don't care to have the tools. It is that it doesn't pay to be that pedantic with their coding (or precise if you will). Because it is so much easier to have *a* user reboot than it is to fix the problems, that this is the acceptable way out. Also, it is easier to point fingers at some other issue than it is to fix the problem within your own product. How many times have you heard or read (or been the victim of) that there is some collision between this product and that -- so you can't run both at the same time, or you can't even have both installed on your system at the same time? Granted, this is becoming more rare, but it still happens! And so going forward from about the time of Windows 3.1, the single user, pseudo-multi-task/programming view point is still prevalent. This is how we get memory leaks (poor coding practices), having to reboot to fix certain issues (because the registry can't be updated while some service is running, and it is tied to the kernel). Too many product designs are based on a single user using that product primarily, and the resource hoggishness has been slowly removed with later releases. But this is just one jaded programmer's opinion. Regards, Steve Thompson -- All opinions expressed by me are my own and may not necessarily reflect those of my employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Conversion work
In a convoluted way, I've found out about a project for a customer who wants to convert mainframe Assembler apps to C#. I know nothing about C#, and I don't know yet what platform the Assembler code is for (inquiries are in process). As an interim, if anyone would like to post any experience or knowledge of similar projects, it might prove to be enlightening. And, if anyone would like to pursue doing some of this work as a contractor, contact me directly, off-list. Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques == Check out the Trainer's Friend Store to purchase z/OS == == application developer toolkits. Sample code in four== == programming languages, JCL to Assemble or compile, == == bind and test. == == http://www.trainersfriend.com/TTFStore/index.html== -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Conversion work
I do not have direct experience... only guessing... I think it is probably easier to find new programmers with C experience than it is to find programmers with assembler experience. Over time, it will get harder and harder. And as with any high level language, you can write programs faster. There is probably a trade-off with performance. but as salaries go up and price of hardware goes down, it might be a good business decision for some. (No need for rebuttle... I know some will disagree.) I doubt if there is a conversion tool, but rather that they figure out what the assembler does and try to do the same in C. Pedro Vera -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Conversion work
Pedro Vera wrote: I do not have direct experience... only guessing... I think it is probably easier to find new programmers with C experience than it is to find programmers with assembler experience. Over time, it will get harder and harder. And as with any high level language, you can write programs faster. There is probably a trade-off with performance. but as salaries go up and price of hardware goes down, it might be a good business decision for some. (No need for rebuttle... I know some will disagree.) I doubt if there is a conversion tool, but rather that they figure out what the assembler does and try to do the same in C. Pedro Vera Remember, it's C#, the MicroSoft product, not just C. So the conversion is going from mainframe to Windows, it looks like. Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques == Check out the Trainer's Friend Store to purchase z/OS == == application developer toolkits. Sample code in four== == programming languages, JCL to Assemble or compile, == == bind and test. == == http://www.trainersfriend.com/TTFStore/index.html== -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Conversion work
[SNIP] Remember, it's C#, the MicroSoft product, not just C. So the conversion is going from mainframe to Windows, it looks like. Kind regards, -Steve Comstock Mono does have an MS compatable CLR and C# compiler for Linux. But I'd bet that you're right about this being a mainframe to Windows conversion. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Problems that occur in production
Hello, Comparing a subscript that had just changed to its maximum value before using it in any other operation would prevent the majority of abends and storage violations at my current facility. Of course, in the event that the maximum is exceeded, an orderly termination with the proper notifications must be coded for. EdP J. Chiampi [EMAIL PROTECTED] Sent by: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU 06/24/2008 02:21 PM Please respond to IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU To IBM-MAIN@BAMA.UA.EDU cc Subject Re: Problems that occur in production On Fri, 20 Jun 2008 11:07:44 -0600, Steve Comstock [EMAIL PROTECTED] wrote: J. Chiampi wrote: Hello, I'm looking for information about problems that could occur in production with Cobol programs and that could generate abend. I would like to find a description and how to prevent them before they occur. For instance, I think that it could be interesting to avoid moving alphanumeric variables into numeric variable without checking them by using a IF NUMERIC or moving data into another that is shorter or avoid closing file or never check array boundaries... Do you see other important cases related to performance or robustness? Thanks in advance. Regards -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Problems that occur in production
On 24 Jun 2008 12:55:15 -0700, [EMAIL PROTECTED] (Ed Philbrook) wrote: Comparing a subscript that had just changed to its maximum value before using it in any other operation would prevent the majority of abends and storage violations at my current facility. Of course, in the event that the maximum is exceeded, an orderly termination with the proper notifications must be coded for. What's funny is that shops have old, old, old standards that compile CoBOL without SSRANGE (for efficiency). Many of those shops fell in love with PL/I because boundary checking was automatic. It was just as expensive though. As time goes by, the costs of not having SSRANGE, get bigger and bigger (relative to the cost of implementing it), but the person who set the standard has been replaced a dozen times, and the standard lives on. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
On Tue, 24 Jun 2008 15:17:25 +0900, Timothy Sipples [EMAIL PROTECTED] wrote: ... I agree with Chris. In my (more limited) experience, if HP NonStops are used they're mainly as front-end switches at card network member banks. And their use in this niche role is fading, ... I don't know the details, but I know our Tandems go into a store and forward mode when anything on the mainframes slows down. That could be a processor down, CICS regions down, transaction failures, dasd contention, spin loops (Ok, that one hasn't happened lately), etc. I don't see their value lessening even if their function is needed less often. I also don't think the presence or absence of parallel Sysplex (or anything else relating to type of platform) can be singled out as the villian. It all depends on application and database design, etc. It doesn't mattter how many 9s worth of platform availability (hardware, operating system, transaction processors, network, etc.) if you have to regularly take a database offline for hours. And applications can be designed poorly on any platform. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
RSV-XCEL sunset 7/1/2008
Hi, We got this from our local IBM technical liaison. Sam Knutson === In an effort to provide you with the most current of service technology, we are pleased to announce that effective 7/1/2008, IBM Assist On-site will replace RSV-XCEL as the tool used for remote screen viewing. IBM On-site (AOS) is a secure, web based application that will provide you with the same functions as RSV-XCEL. Please refer to the following web pages for more information on AOS: Overview, general information and FAQ's : http://www.ibm.com/support/assistonsite/ AOS Security Whitepaper: http://www.ibm.com/support/docview.wss?uid=swg21247084 Please note that RSV-XCEL required a leased line for access. AOS does not have this requirement, so you may be able to remove the leased line if only used for this service. This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Storage Alternation TRAP
Miklos Szigetvari wrote: How can I set an SA trap, to specify the BEFORE and AFTER values (i.e the content before the alternation and after ) ? You could use two SA SLIPs with TARGETID on the BEFORE value SLIP to activate the AFTER value SLIP. Regards, George Kozakos z/OS Function Test/Level 3 Supervisor -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Need some CA-SPOOL/TCPIP routing help
Hi Everyone, Sorry, this is lengthy. I need some suggestions/direction to accomplish a task that may or may not be doable. We have a customer that needs to connect their Xerox printer to the mainframe (via a BARR system and network). We planned to use ESF to push the output to the BARR server. We ran into a stumbling block with the way our TCPIP stacks are defined. ESF runs on our primary TCPIP stack. The printer connection is within the user's TCPIPB stack. We can't change ESF to use the other stack since there are other printers that use it. If we try to connect through the main stack, we get nothing (which is what we should get on the main stack). If we bring up ESF on the TCPIPB stack we get the following 12:47:00 Gethostbyname 12:47:00 Socket 3 Bind port 515 from 0.0.0.0 port 721 12:47:00 Socket 3 Connect to port 515 from port 721 12:47:00 Connect errno=49. Destination host refused socket connection 12:47:00 Socket 3 Bind port 515 from 0.0.0.0 port 722 12:47:00 Socket 3 Connect to port 515 from port 722 12:47:00 Connect errno=49. Destination host refused socket connection We don't know where the error is, on our end or the users end where the BARR Server resides. The next problem is getting the output through ESF and onto a different TCPIP Stack. A suggestion was given to us that somewhere (such as a REXX exec) we should be able to tell ESF what stack the Xerox Printer/BARR server resides in and then route it out to that address. We do not have strong TCPIP experience and we are at a loss on how to accomplish this. Does anyone have any suggestions or other methods to get this to work? We're running out of ideas Thanks, Mary -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
Patrick O'Keefe wrote: On Tue, 24 Jun 2008 15:17:25 +0900, Timothy Sipples [EMAIL PROTECTED] wrote: ... I agree with Chris. In my (more limited) experience, if HP NonStops are used they're mainly as front-end switches at card network member banks. And their use in this niche role is fading, ... I don't know the details, but I know our Tandems go into a store and forward mode when anything on the mainframes slows down. That could be a processor down, CICS regions down, transaction failures, dasd contention, spin loops (Ok, that one hasn't happened lately), etc. I don't see their value lessening even if their function is needed less often. In my experience, Tandems are not switches. They process card traffic. I'm aware of one migration from mainframe to Tandem. Here in Poland, vast majority of ATMs and POS's are non-mainframe. Even no mainframe behind the Tandem. Only 3 banks are using mainframes at all. Was 4. The fourth one decided to drop the mainframe due to costs. The project was succesful - no entry for re-boot hill. Oh, two big mainframe projects I'm aware exceeded planned timeframe and budget. Only one ATM network is using mainframe. Did I mention the majority of HW elements used for sysplex can also be used in open systems environment? I mean DASD, FC switches, tapes... Disclaimer: I like mainframes, but I'm not blind. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2008 r. kapita zakadowy BRE Banku SA wynosi 118.642.672 zote i zosta w caoci wpacony. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Slow FTP transfer from z/OS to Unix
Count your hops. Holding network speed constant, each hop increases the transit time by a multiple. Let x = rated network speed. One hop = X/1 Two hops = X/2 Three hops = X/3 And so on. In other words: consider a packet traveling directly from point A to point C. It arrives at point C at network speed. Now insert point B. The packet arrives at B in the same elapsed time as before, but must traverse the network again to arrive at C. Hence, the elapsed transit time is doubled. Of course, it is a bit more complicated but you should get the idea. HTH and good luck. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of François Paré Sent: Friday, June 20, 2008 8:06 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Slow FTP transfer from z/OS to Unix Rob, We tried TRACERTE but there is no problem there, one hop a couple of milliseconds. We will work on traces and thank you for all the tracks you gave. François Paré NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Slow FTP transfer from z/OS to Unix
Hal Merritt wrote: Count your hops. Holding network speed constant, each hop increases the transit time by a multiple. Empirical testing does not seem to bear this out. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Slow FTP transfer from z/OS to Unix
What do your test results show? -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Tuesday, June 24, 2008 4:32 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Slow FTP transfer from z/OS to Unix Hal Merritt wrote: Count your hops. Holding network speed constant, each hop increases the transit time by a multiple. Empirical testing does not seem to bear this out. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Slow FTP transfer from z/OS to Unix
Hal Merritt wrote: What do your test results show? What I've seen is some measurable amount of delay at each router. When the connections are improved from 100Mb to 1000Mb, the delays are about the same even though performance is drastically improved. [An unrelated aside. Based on this interesting chart, it looks like IPv6 is really starting to come online! http://mobitec.ie.cuhk.edu.hk/projects/IPv6/hops.html ] -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well. [EMAIL PROTECTED] (R.S.) writes: In my experience, Tandems are not switches. They process card traffic. I'm aware of one migration from mainframe to Tandem. Here in Poland, vast majority of ATMs and POS's are non-mainframe. Even no mainframe behind the Tandem. Only 3 banks are using mainframes at all. Was 4. The fourth one decided to drop the mainframe due to costs. The project was succesful - no entry for re-boot hill. Oh, two big mainframe projects I'm aware exceeded planned timeframe and budget. Only one ATM network is using mainframe. re: http://www.garlic.com/~lynn/2008i.html#97 We're losing the battle http://www.garlic.com/~lynn/2008i.html#99 We're losing the battle http://www.garlic.com/~lynn/2008i.html#101 We're losing the battle http://www.garlic.com/~lynn/2008j.html#7 We're losing the battle in the 80s 90s a lot of ATM stuff was done on Tandem machines with software (base24) from these guys http://www.aciworldwide.com/company/ quicky search on tandem, atm, base24 turns up stuff like this: July 19, 1999, Indian Public Banks Move Online Slowly http://asia.internet.com/news/article.php/650391 tandem wiki page: http://en.wikipedia.org/wiki/Tandem_Computers some issues may be attributed to (after being acquired by HP, tandem line) being moved to Itanium base ... which has had its own issues. more recently ACI has been quite active with IBM (besides over the yrs providing products on some number of other platforms) http://www.aciworldwide.com/partners/sapartners.aspx?pid=118 old related post in this n.g. from last year (also reply to one of your posts): http://www.garlic.com/~lynn/2007s.html#6 ATMs as mentioned in the old post, we marketed our ha/cmp product against them in some number of markets http://www.garlic.com/~lynn/subtopic.html#hacmp -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Fw: Decimal Floating Point, was: replacing SAS for SMF reports?
Rick, yes and no ... With the current PL/I compiler and with the DECIMAL(DFP) compiler option in effect, then FLOAT DECIMAL does mean DFP. See: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ibm3pg60/1.1.1.28 With earlier versions of the Pl/I compiler (or lower ARCH levels) this is NOT true. Rick Fochtman [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... --snip- I see what I did, whenever people talk about 'new floating point' I always assume it is Decimal Floating Point (the one that is not available in Java yet, or COBOL for that matter. z9 and PL/I and have it) To make it more confusing both the Java binary float and the newer DFP are both IEEE floating point! ---unsnip Don't confuse PL/1's FLOAT DECIMAL specification with the hardware floating point decimal feature. They are NOT the same! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
z9 Crypto Express2 usage
Have a z9 with 2 Crypto Express2 cards we hope to use. Any suggested manuals for someone that has no experience with with ICSF or these cards? I reviewed the archives and found a pointer to Red Book SG24-7123 z9-109 Crypto update. I also am reviewing several ICSF manuals. Any other good sources? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z9 Crypto Express2 usage
Have a z9 with 2 Crypto Express2 cards we hope to use. Any suggested manuals
for someone that has no experience with with ICSF or these cards?
I reviewed the archives and found a pointer to Red Book SG24-7123 z9-109 Crypto
update. I also am reviewing several ICSF manuals. Any other good
sources?
What more do you need? (8-{}
You're tending to information overload.
You've hit it all.
The crypto books are pretty comprehensive.
-
Too busy driving to stop for gas!
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
I don't know the details, but I know our Tandems go into a store and forward mode when anything on the mainframes slows down. That could be a processor down, CICS regions down, transaction failures, dasd contention, spin loops (Ok, that one hasn't happened lately), etc. I don't see their value lessening even if their function is needed less often. The front ends need to be bulletproof because back ends are not always available. This has nothing to do with whether the front and back ends are Tandem or IBM. The front end and back ends may even be on the same box. It's not necessarily that the box becomes unavailable but, more likely, that the back end application does -- sometimes intentionally, sometimes not. The important thing is that the front end can continue to service transactions, stand in for the back end and SAF the results. Back in the day, Tandem was the dominant fault-tolerant platform. However, for almost two decades, sysplex technology has given mainframes fault tolerance that Tandem can only dream of. So, it's not that Tandem's front end value is lessening but that they are no longer the only game in town. Date: Tue, 24 Jun 2008 15:42:11 -0500 From: [EMAIL PROTECTED] Subject: Re: We're losing the battle To: IBM-MAIN@BAMA.UA.EDU On Tue, 24 Jun 2008 15:17:25 +0900, Timothy Sipples [EMAIL PROTECTED] wrote: ... I agree with Chris. In my (more limited) experience, if HP NonStops are used they're mainly as front-end switches at card network member banks. And their use in this niche role is fading, ... I don't know the details, but I know our Tandems go into a store and forward mode when anything on the mainframes slows down. That could be a processor down, CICS regions down, transaction failures, dasd contention, spin loops (Ok, that one hasn't happened lately), etc. I don't see their value lessening even if their function is needed less often. I also don't think the presence or absence of parallel Sysplex (or anything else relating to type of platform) can be singled out as the villian. It all depends on application and database design, etc. It doesn't mattter how many 9s worth of platform availability (hardware, operating system, transaction processors, network, etc.) if you have to regularly take a database offline for hours. And applications can be designed poorly on any platform. Pat O'Keefe _ Need to know now? Get instant answers with Windows Live Messenger. http://www.windowslive.com/messenger/connect_your_way.html?ocid=TXT_TAGLM_WL_Refresh_messenger_062008 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
Bruno. This thread, as with many on this topic, starts out with the assumption that UNIX, LINUX and Windows Server Operating Systems, along with server class hardware are no different to the Home PC they loaded up with Windows XP in order to play Warcraft, or the laptop they use for email and terminal emulators. It only goes downhill from there. It gets even more ridiculous when Linux is suddenly an anointed HA OS simply because it will run on an IBM Mainframe, along with Solaris and pre-RISC AIX. I have not figured that out yet. As Radoslaw said, I love Mainframes but I'm not blind. Those that wish to make a valid comparison between z/OS and other HA OS need to get their noses out of Windows and have a look at how HA is being done on other SERVER Operating Systems. In many cases it is not platform that provides the HA, but rather an application running on the OS like Veritas Cluster Server or HACMP. These HA applications won't even run on XP. And what I would give for backup software like Commvault or Netbackup on the Mainframe. Backup on Open System Server software is Light years ahead of anything on the MF, whether it's IBM or ISV software. It's like comparing a Ferrari to the first stone wheel... I like to take a wider view than the lint in my belly button... Ron PS For those that WOW, I'm a level 63 Human Warrior :) Thank you Ron I was feeling alone . i have been sometimes pulling out applications from mainframe in my shop and applied all good recipes from centralised processing ( dual computer rooms , dual replicated storage bays for dasds , dual network, load balancing , dual tape robotics and even ESX vmware to drag and drop servers on the fly) And it is reliable . ( Lotus notes windows, Lotus portal windows , WAS linux , Windows data servers , AIX applications , etc ... ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Conversion work
Don't forget my 370 Assembler to Intel converter. Details and download are here: http://members.ozemail.com.au/~oscarptyltd/370to486download.html __ Convert IBM 370 Assembler to Intel 486 and Pentium code. The converted code runs about 5 times faster than interpreted code thus making moving Mainframe applications to PCs a viable option. Also, it provides an excellent development platform for developing Mainframe Assembler code and provides debugging features most mainframe programmers can only dream about! ___ Regards, Clement Clarke Steve Comstock wrote: In a convoluted way, I've found out about a project for a customer who wants to convert mainframe Assembler apps to C#. I know nothing about C#, and I don't know yet what platform the Assembler code is for (inquiries are in process). As an interim, if anyone would like to post any experience or knowledge of similar projects, it might prove to be enlightening. And, if anyone would like to pursue doing some of this work as a contractor, contact me directly, off-list. Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Conversion work
Clement Clarke wrote: Don't forget my 370 Assembler to Intel converter. Details and download are here: http://members.ozemail.com.au/~oscarptyltd/370to486download.html __ Convert IBM 370 Assembler to Intel 486 and Pentium code. The converted code runs about 5 times faster than interpreted code thus making moving Mainframe applications to PCs a viable option. Also, it provides an excellent development platform for developing Mainframe Assembler code and provides debugging features most mainframe programmers can only dream about! ___ Regards, Clement Clarke Excellent point, Clement. I'll pass it on. Thanks for your note. Steve Comstock wrote: In a convoluted way, I've found out about a project for a customer who wants to convert mainframe Assembler apps to C#. I know nothing about C#, and I don't know yet what platform the Assembler code is for (inquiries are in process). As an interim, if anyone would like to post any experience or knowledge of similar projects, it might prove to be enlightening. And, if anyone would like to pursue doing some of this work as a contractor, contact me directly, off-list. Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques == Check out the Trainer's Friend Store to purchase z/OS == == application developer toolkits. Sample code in four== == programming languages, JCL to Assemble or compile, == == bind and test. == == http://www.trainersfriend.com/TTFStore/index.html== -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
Ron Hawkins wrote: Bruno. This thread, as with many on this topic, starts out with the assumption that UNIX, LINUX and Windows Server Operating Systems, along with server class hardware are no different to the Home PC they loaded up with Windows XP in order to play Warcraft, or the laptop they use for email and terminal emulators. It only goes downhill from there. It gets even more ridiculous when Linux is suddenly an anointed HA OS simply because it will run on an IBM Mainframe, along with Solaris and pre-RISC AIX. I have not figured that out yet. As Radoslaw said, I love Mainframes but I'm not blind. Those that wish to make a valid comparison between z/OS and other HA OS need to get their noses out of Windows and have a look at how HA is being done on other SERVER Operating Systems. In many cases it is not platform that provides the HA, but rather an application running on the OS like Veritas Cluster Server or HACMP. These HA applications won't even run on XP. And what I would give for backup software like Commvault or Netbackup on the Mainframe. Backup on Open System Server software is Light years ahead of anything on the MF, whether it's IBM or ISV software. It's like comparing a Ferrari to the first stone wheel... I like to take a wider view than the lint in my belly button... Ron PS For those that WOW, I'm a level 63 Human Warrior :) The problem I'm having, then, Ron, is identifying exactly where z/OS belongs today. On the one hand I hear that nothing beats the MF for reliability, security, recoverability, and so on. Then I hear people telling me not be so sure about that. So if these other platforms are up to MF levels, and they are so much cheaper, why would anyone stay with a mainframe today? What's the driving factor that gives mainframes any kind of real life expectancy, given that Windows and xNIX are now up to MF standards? Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques == Check out the Trainer's Friend Store to purchase z/OS == == application developer toolkits. Sample code in four== == programming languages, JCL to Assemble or compile, == == bind and test. == == http://www.trainersfriend.com/TTFStore/index.html== -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
On Wed, Jun 25, 2008 at 12:21 AM, in message [EMAIL PROTECTED]@sbcglobal.net, Ron Hawkins [EMAIL PROTECTED] wrote: -snip- It gets even more ridiculous when Linux is suddenly an anointed HA OS simply because it will run on an IBM Mainframe, along with Solaris and pre-RISC AIX. I have not figured that out yet. Umm, no. It's not the fact that Linux is running on the mainframe that creates high availability. As with all other operating systems, it's the infrastructure that supports HA, as well as (sometimes) some applications that are HA aware. Heartbeat, various STONITH tools and so on are what accomplish HA, not the OS itself, per se. You can get HA without the application being HA aware, but it's easier if they are. There are HA Linux clusters that have never been anywhere near a mainframe. The same holds true for Solaris, HP-UX, Tru64, AIX, and others. Having said that, having your operating systems on System z hardware makes getting HA levels of uptime more common, but not more doable. While server class midrange hardware can be very good, it's not nearly as good as System z. Which partly explains the huge price differential between them. (The rest is due to other factors that are far less satisfying to contemplate.) Even on System z, however, you still have to design the architecture as though any part of it can fail in the next few minutes. Otherwise you're just burying your head in the sand. Finally, don't compare server operating systems to Windows XP. I no longer have any love for Microsoft and the various incarnations of their Windows desktop operating systems, but they're not comparable to the server editions in the same family. Microsoft's desktop OSes don't have any sort of HA potential built into them, but their server versions do, via clustering, albeit along the lines of Microsoft's vision of what that means. Given a choice, and application availability, I would go with Linux on System z (running on z/VM) clustering versus Parallel Sysplex, for no other reason than the huge cost savings, and relative simplicity. That's a purely economic evaluation, not a technical one. I supported MVS for 20+ years, and have a great admiration for it. IBM's pricing schemes (along with most ISVs) make it difficult to justify economically these days. Mark Post -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
VSE Systems Programming Resource A/P
If there's a VSE Systems Programmer sitting around twiddling their thumbs and is interested in some contract work in the Asia/Pacific Region to undertake a storage migration, please contact me off list. I have no commercial interest in this requirement and I was asked if I knew of anyone who might be able to help. Stephen Mednick Computer Supervisory Services Sydney, Australia -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: We're losing the battle
On Wed, Jun 25, 2008 at 12:41 AM, in message [EMAIL PROTECTED], Steve Comstock [EMAIL PROTECTED] wrote: -snip- The problem I'm having, then, Ron, is identifying exactly where z/OS belongs today. On the one hand I hear that nothing beats the MF for reliability, security, recoverability, and so on. Then I hear people telling me not be so sure about that. So if these other platforms are up to MF levels, and they are so much cheaper, why would anyone stay with a mainframe today? Well, in terms of DRA, there is no comparison, particularly if you're talking about a non-trivial number of distributed systems. z/OS has its strengths in a number of areas (I would love to have the same batch capability on Linux), and the fact that 60%+ of business data resides on ECKD emulated storage argues strongly for the continued existence of z/OS, ideally in cooperation with other operating systems, both mainframe based and not. What's the driving factor that gives mainframes any kind of real life expectancy, given that Windows and xNIX are now up to MF standards? The fact that they're not. Period. Particularly not in the area of hardware reliability, and DRA. Distributed systems, whether UNIX or Linux, will likely always have their place. (The z10 closes the performance gap but the CPU cycles are still much more expensive compared to RISC or Intel/AMD.) The mainframe will also have its place, and more people are coming to realize that as time goes on. That doesn't necessarily mean z/OS, but z/OS in combination with Linux for System z (itself in combination with z/VM) is likely to be around for quite a while longer. Mark Post -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
